AMM’lere Kapsamlı Bir Bakış

Daha önceden paylaştığım "A Comprehensive Deep Dive to AMMs" adlı yazımın Türkçe çevirisidir.

Bu Medium yazısında, sabit çarpım (constant product) formülü ile oluşturulan bir Otomatik Piyasa Yapıcı (AMM) havuzunun detaylarını ineceğiz. Derinlemesine incelememizde, AMM’lerin tasarımlarını ve dijital varlık takasının sürekli evrilen doğasındaki işlevlerini anlamak için önemli bir öneme sahip bir dizi kritik yönü ele alacağız. Ele alacağımız başlıklar şunlar:

1. AMM’lerin gerekliliği
2. AMM’lerden neler beklediğimiz
3. Fiyatı belirlemek için kullanılan formül ve bunun mantığı
4. Fiyat tutarlılığını nasıl sağlarız
5. Fiyat kayması (slipaj) nedir ve neden var
6. AMM’lerin verimliliğini nasıl artırabiliriz
7. Likidite sağlayıcılarının rolü ve LP tokenlerinin doğası
8. Impermanent loss (geçici kayıp) kavramı

Otomatik Piyasa Yapıcılar (AMM’ler) dilediğimiz zaman takas işlemlerinin gerçekleşebilmesi için geliştirildi. Geleneksel borsalarda, A varlığını B varlığı ile satın almak için başka birinin B varlığını A varlığı ile almak istemesi ve fiyatta uzlaşı gerekmektedir. Ancak, akıllı kontratlar kullanarak, karşı bir satıcıya ihtiyacın duyulmadığı bir sistem yaratmak mümkün.

Bunun için ana fikir, hem A hem de B varlıklarını içeren bir havuz oluşturmak. A varlığını, B varlığı karşılığında satın almak istediğimizde, sistem işlemi önceden belirlenmiş bir formül kullanarak gerçekleştirmeli. Ancak doğru formülü nasıl belirleriz? Bu formülün belirli kurallara uyması gerekiyor. Örneğin, havuzdaki A ve B varlıklarının miktarı ters orantılı olmalıdır, bu da A varlığını satın almanın, havuzdaki B varlığının miktarında artışını gerektirir. Ayrıca, bir varlığının fiyatı ve miktarı ters orantılı olmalıdır, bu da kuracağımız sistemin bir varlığın miktarı azaldığında, o varlığın değerini arttırması anlamına geliyor. Birkaç olası formülü inceleyelim.

Formül 1: X — Y = C

Burada, X havuzdaki A varlığının miktarını, Y ise havuzdaki B varlığının miktarıdır ve C bu değere göre türetilen bir sabittir. Sistemimizin amacı, C’yi sabit tutarak havuz aracılığıyla işlemlere izin vermek olmalı. Örneğin, Alice havuzdan ‘p’ birim A varlığı satın almak isterse, vermesi gereken B varlığı miktarı olan ‘q’, (X — p) — (Y + q) = C denklemi kullanılarak hesaplanır. Bu denklemin sonucunda, q=-p olduğunu görürüz ki bu mantıksızdır çünkü ‘q’ değerinin negatif olması, Alice’in havuzdan ‘p’ birim A varlığı satın aldığında, havuzdan ‘p’ birim B varlığını da alması anlamına gelir. Dolayısıyla, bu formülden kesinlikle uzak durmalıyız!

Formül 2: X + Y = C

Tıpkı yukarıdaki örnekteki gibi, X ve Y sırasıyla havuzdaki A ve B varlıklarının miktarını temsil ederken, C yine bunlara bağlı bir sabit olsun. Sistemin temel hedefi, X ve Y’nin değerlerini C’yi sabit tutarak değiştirmektir. Örneğin, Alice havuzdan ‘p’ birim A varlığını satın almak isterse, vermesi gereken B varlığı miktarı olan ‘q’, (X — p) + (Y + q) = C denklemi ile belirlenir. Kolayca görebileceğimiz gibi, C’yi sabit tutmak için her şart zaman ‘q’ değerinin ‘p’ değerine eşit olması gerekir. Diyelim ki Alice, 10 ETH ve 10.000 DAI içeren havuzumuzdan 1 ETH (A varlığı) satın almak istiyor. C=10+10.000=10.010=(10–1)+(10.000+q) olduğundan, vermesi gereken DAI (B varlığı) miktarı q=1'dir.

Gördüğümüz gibi, bu formülde ‘p’ (alınan varlık miktarı) her zaman ‘q’ değerine (verilen varlık miktarı) eşittir. Ancak, bu yaklaşım verimsiz çünkü fiyat her zaman sabit kalıyor ki bu hiç istediğimiz bir şey değil. Bizim, piyasa koşullarına uyum sağlayabilen dinamik bir fiyatlandırma sistemine ihtiyacımız var.

Formül 3: X * Y = C

Yine, X ve Y sırasıyla havuzdaki A ve B varlıklarının miktarını gösterirken, C bir sabit olacak. Sistemimizin ana hedefi, X ve Y değişirken C’yi sabit tutmak. Örneğin, Alice havuzdan ‘p’ birim A varlığı satın almak isterse, vermesi gereken B varlığı miktarı ‘q’, (X — p) * (Y + q) = C denklemi kullanılarak hesaplanacak. Bu durumda, q=(C/X-p)-Y olacaktır, ve bu ifade pozitiftir çünkü X-p<X olması C/X-p > C/X = Y olmasını sağlar. Dolayısıyla, Formül 1'deki gibi bir problemle karşılaşmayız. Ayrıca, ‘q’ değerinin ‘p’ değerine bölünmüş hali, yani fiyat, q/p=(C/X-p)/p-Y/p=(C/p*(X–p))-Y*(X-p)/p*(X-p)=(C-YX+Yp)/p*(X-p)=Yp/p*(X-p)=Y/(X-p) olarak hesaplanır. Bu nedenle, ‘p’ arttıkça fiyat da artar. Bu, piyasa koşullarına adapte olabilen dinamik bir sistem oluşturmakta ve havuzdaki varlıklardan birinin tamamen tükenmesini önlemektedir. Dolayısıyla, bu formül ihtiyaçlarımızı karşılamaktadır.

Yukarıda tartıştığımız gibi, bir havuzun fiyatı satın alınmak istenen varlığın miktarına ve havuzdaki varlıkların oranlarına bağlıdır. Burada doğal bir soru ise bir havuzdaki aynı çiftlerle oluşturulan diğer havuzlar ve merkezi borsalar arasında fiyat tutarlılığını nasıl sağlayacağımızdır. Cevapsa basit: biz bir şey yapmayacağız. Ancak, bu fiyat dalgalanmalarının kaçınılmaz olduğu anlamına gelmez. Burada çalışan anahtar mekanizma arbitraj’dır.

Arbitrajcılar, bir varlığı daha ucuz bir havuzdan (veya borsadan) satın alarak daha pahalı olanına satma yoluyla kâr ederler. Bu işlem, ucuz havuzda arzı azaltarak fiyatı arttırma ve aynı anda daha pahalı havuzda arzı artırarak fiyatı düşürme etkisine sahiptir. Bu sürecin sonunda, arbitrajcının eylemleri sonucu bir kâr garantisi vardır.

Tüm bunların sonucunda, Formül 3'ün takas kuralı olarak kabul edilebileceğini çıkarabiliriz. Ancak, bunun işleyen tek formül olmadığını belirtelim (örneğin Curve’un StableSwap formülü bundan farklıdır). Şimdi formülümüzün grafiğine bir göz atalım:


Bu grafik, c’nin sabit olduğu x*y=c formülü için genel bir grafiktir. Burada X ve Y eksenleri sırasıyla A ve B tokenlerinin miktarlarını temsil ediyor. Yakından incelendiğinde, harcanan tokenler ve kazanılan tokenler arasındaki ilişkinin doğrusal olmadığı açıktır.

Dolayısıyla, harcanan token miktarı iki katına çıktığında, kazanılan token miktarı aynı oranda iki katına çıkmaz; aslında, kazanç, orijinal miktarın iki katından daha az olacaktır. Aşağıdaki tablo, havuzdaki likidite azaldıkça kazanılan token başına maliyetin önemli ölçüde arttığını göstermektedir.


Yukarıdaki tablo, başlangıçta 100 ETH ve 100.000 DAI ile kurulan bir ETH/DAI havuzunda fiyatların nasıl değiştiğini göstermektedir. Tabloda belirtilen premium, sabit çarpım formülünün doğal bir sonucudur ve slipaj (fiyat kayması) olarak bilinir. Slipaj, verimsizliklere yol açsa da, havuzu olası saldırılardan korumaktadır. Ancak, slipajın havuzun toplam likiditesi ile doğrudan ilişkili olduğunu belirtmek önemlidir; daha büyük likidite, daha verimli takaslar sağlamaktadır.

Örneğin, yukarıda gördüğümüz gibi, Alice 100 ETH ve 100.000 DAI içeren bir havuzdan 5 ETH satın almayı denerse, %5.26'lık bir slipaj ile karşılaşacaktır. Peki ya aynı takası, 1000 ETH ve 1.000.000 DAI içeren yani on kat daha likit olan bir havuzda yapmayı denerse? Bu durumda, sabit çarpım 1000*1.000.000 = 1.000.000.000 olacaktır. Yani, 5 ETH almak istiyorsa, (1.000.000.000/995)-1.000.000=5025.13 DAI ödemek zorunda olacak ve bu da yaklaşık %0.5'lik bir slipaj oranına yol açacaktır.

Yukarıda görüldüğü üzere, havuzdaki likiditeyi artırmak daha verimli işlemlere yol açar. Dolayısıyla, havuzun likiditesini artırmanın bir yolunu bulmamız gerekiyor. Başlangıçta daha fazla varlık ekleyebiliriz, ancak daha etkili bir yaklaşım, kullanıcıları havuza likidite sağlamaya teşvik etmek olacaktır. Fakat neden bunu yapsınlar ki? Doğal olarak, kullanıcılar sadece iyilik yapmış olmak için tokenlerini kilitlemezler. Ancak, potansiyel olarak kârlı bir durum görürlerse, bunu yapmaya eğilimli olacaklardır. Bunu kolaylaştırmak için, tüm feelerin likidite sağlayıcılara (LP’lere) dağıtıldığı bir fee mekanizması dizayn edebiliriz. Hatta bazı protokoller, ek bir teşvik olarak kendi tokenlerini LP’lere dağıtmayı tercih edebilir. Alice’in bir havuza likidite eklerken, havuzun dengesini korumak için her iki varlıktan da eşit miktar katkıda bulunması gerektiğini belirtelim. Eğer sadece bir varlığı varsa, LP olmadan önce diğer varlık için bunun yarısını satması gerekecektir. Neyse ki, birçok platform bu adımı Alice adına gerçekleştirerek, kullanıcı deneyimini artırır.

Alice, bir havuzun LP’si olduğunda, LP tokenler mint edilip ona aktarılır. Bu tokenler, LP’nin havuzdaki payını temsil eder. Örneğin, Alice havuzdaki toplam likiditenin %3'üne, yani havuzdaki her iki varlığın %3'üne sahipse, toplam LP tokenlerinin dolaşımının %3'üne sahip olur. Dolayısıyla, %3 LP tokenine sahip olmak, havuz tarafından oluşturulan feelerin %3'ünün sahibi olmaya hak kazandırır. Bazı protokollerse bir LP token sistemi olmadan çalışır ve herhangi bir talep süreci olmaksızın düzenli olarak takas feelerini LP’lerine dağıtır.

Ancak, LP tokenlerinin fee talep etmekten öte işlevleri de vardır. Havuzdaki payı temsil ettikleri için bunları başka bir adrese aktarmak, bu tokenlerin haklarını yeni adrese devreder. Bu, havuzdaki varlıkların sadece kilitlenmiş olmaları yerine DeFi kullanıcılarına ciddi bir esneklik sağlamaktadır. Örneğin, bir kullanıcı, LP tokenlerini teminat olarak kullanarak bir varlık ödünç alabilir veya onları başka bir protokolde stake ederek ek teşvikler kazanabilir (mesela Curve-Convex ilişkisi).

Likidite Sağlayıcıların (LP’lerin) geliri, havuzun takas hacmiyle doğrudan ilişkilidir. Bu, yüksek işlem hacminin gerçekleştiği dönemlerde LP’lerin önemli kârlar elde edebileceği anlamına geliyor. Bunun en iyi örneklerinden biri, Arbitrum ağındaki Uniswap’ın ARB/ETH havuzunda görülebilir. ARB airdropunun claim edilebilir hale gelmesinin ardından, insanlar ARB tokenlerini ETH için takas etmek için acele ettiler. Sadece üç gün içinde, ARB/ETH havuzlarından biri 378.5M$’lık takas hacmine sahipti ve bu dönemde oluşan toplam fee 1.135M$’ı aştı. Aşağıdaki ekran görüntüsü, airdropun claim edilebilir hale geldiği ilk gün oluşturulan bir pozisyonun bir gün sonrasındaki durumunu gösteriyor. Bir kullanıcı, yaklaşık $5K değerinde bir pozisyon oluşturdu ve tek bir günde $6.3K’dan fazla fee geliri kazandı.


Likidite Sağlayıcı (LP) olmak, DeFi dünyasında en iyi iş gibi görünebilir, ancak gerçekten öyle mi? Birçok avantajına rağmen, LP olmanın “geçici kayıp” (impermanent loss) olarak bilinen kendi riski vardır. Geçici kaybın ne olduğunu anlamak için bir Otomatik Piyasa Yapıcı (AMM) havuzundaki değişim mekanizmasını incelememiz gerekiyor.

Temelde, bir trader A varlığını B varlığı karşılığında satın aldığında, A varlığını havuzdan alır ve B varlığının eşdeğer bir değerini havuza koyar. LP’ler havuz için likiditeyi sağladığından, traderın A varlığını LP’lere satarak karşılığında B varlığını aldığını söyleyebiliriz. Bu takas işleminden sonra A varlığının fiyatı B varlığına göre artarsa, LP’ler aynı miktarda varlığı sadece tuttukları duruma göre zararda olacaktır.

Bu durumu bir örnek ile açıklayalım. Başlangıçta 90 ETH ve 90.000 DAI olan standart bir ETH/DAI havuzunu düşünelim. Diyelim ki Alice ve Bob’un her birinin 10 ETH ve 10.000 DAI’si var. Alice tüm varlıklarını havuza eklerken Bob varlıklarını tutsun. Şimdi birisinin havuzdan 10 ETH satın aldığını varsayalım. Bu işlem için 11.111,11 DAI ödemesi gerekir, bu da havuzda 90 ETH ve 111.111,11 DAI bırakır.

Bu durumda Alice’in havuzdaki payı 9 ETH ve 11.111,11 DAI olacaktır, bu da 1 ETH’yi 1.111,11 DAI karşılığında sattığı anlamına gelir. Eğer ETH’nin fiyatı bu noktadan sonra yükselirse, Alice, bir ETH’ini sattığı için Bob’dan daha az kâr elde eder. Ayrıca, ETH’in fiyatı yükseldikçe, arbitrajcılar havuzdan ETH satın almaya devam edecektir, bu da zamanla Alice’in ETH bakiyesini daha da azaltacaktır.

Ancak bu kayıp kalıcı değildir. Eğer ETH’in fiyatı 1.000 DAI’ye geri düşerse, Alice tüm ETH’ini geri kazanır ve bu süre zarfında yapılan takaslardan feeler de kazanacaktır. Ancak, ETH’in fiyatının orijinal seviyesine geri döneceği konusunda bir garanti yoktur. Bu, LP’lerin göze aldığı bir risktir.

Yaklaşan yazılarda, geçici kaybın (impermanent loss) arkasındaki matematiğe daha derinlemesine dalacağız. Bu arada, Likidite Sağlayıcı (LP) olma stratejilerini test etmek için CoinGecko’nun geçici kayıp hesaplayıcısını kullanabilirsiniz. Ayrıca, UniSwap versiyon 3’ün geçici kaybı sınırlamak için zekice bir çözümü var, ancak bunu başka bir blog yazısında inceleyeceğiz.

Özetlemek gerekirse, bu blog yazısında, UniSwap tarafından öncülük edilen sabit çarpım kuralı (Curve’un stableswap formülünü bir başka yazıda inceleyeceğiz), LP token mekanizması, fiyat kayması ve geçici kayıp gibi konseptlere odaklanarak Otomatik Piyasa Oluşturucularının (AMM) anatomisini çözümledik. Bu mekanikleri daha iyi anlayarak, likidite sağlama, risk yönetimi ve getiriyi optimize etme hakkında bilinçli kararlar alarak merkezi olmayan finansın ufuklarında daha etkili bir şekilde dolaşabiliriz. DeFi dünyasının bu karmaşık, ama aynı zamanda büyüleyici yönleri hakkında daha derinlemesine dalacağımız yaklaşan yazılar için beni takipte kalın https://twitter.com/omerr_yanar.