Eğitim | Eşleştirme Motorunu Anlama Kılavuzu: Bir Borsa Platformunu Gerçekten Anlamak için

Bu makaleyi okumak için 48 Dakika

Dört pazar, dört makine, eşleştirme motoru asla standart değildir.

Orijinal Başlık: "Sonsuz Para Basma: Kripto Spot, Vadeli İşlem, Opsiyon ve Tahmin Piyasası Sipariş eşleştirme Motoru Açıklaması"
Orijinal Yazar: danny, Kripto Analisti

Binance Spot ve Kalıcı Swap'ı açtığınızda, sipariş defteri neredeyse aynıdır. Ancak "Sat" anında, bu iki arkasında tamamen farklı bir mekanizma bulunmaktadır.

Neden perp iki farklı fiyat setine sahip olmalıdır? Neden Iron Condor'ın dört bacak birlikte işlem görmesi gerekmektedir? Tahmin piyasasının ücreti neden p=0.5'teyken en pahalıdır? Bu soruların yüzeyde mekanizma sorgulaması yaparken, aslında aynı şeyi sormaktadır - eşleştirme motoru hiçbir zaman bağımsız bir mühendislik modülü olmamıştır, hizmet verdiği varlık tarafından şekillendirilmiştir.

Spot, Kalıcı Swap, Opsiyon ve Tahmin Piyasası arasındaki dört form arasındaki farklar benzerlikten çok daha derindir. Bu makale bu formları ayrıştırarak, "eşleştirme"nin neler tarafından neredeyse bağımsız mühendislik varlıklarına dönüştüğünü açıklamaktadır.

İlk olarak, Eşleştirme Standart Bir Parça Değildir

Eğer sadece Spot Ticaretinin eşleştirme uygulamasını görmüşseniz, "Eşleştirme Motoru"nu olgunlaşmış, yakınsayan, neredeyse hiçbir teknik karmaşıklık içermeyen bir şey olarak görebilirsiniz - sıralanmış bir sipariş defteri, bir fiyat ve zaman önceliği eşleme döngüsü, tek seferlik bir uzlaşma yoluyla, hikayenin sonu.

Ama işte burada yanılıyorsunuz...

Coinbase'in BTC/USDT'sinden Binance'in BTCUSDT Kalıcı Swap'ına, ardından Deribit'in BTC-26DEC25-50000-C'sine ve son olarak belirli bir olay pazarında Polymarket'a kadar bakın, bu dört pazarın arkasındaki eşleşme motorunun yapı olarak neredeyse dört farklı makine olduğunu fark edeceksiniz.

Onlar bazı algoritmalardaki benzerlikleri paylaşırlar - alıcı, satıcı, fiyat, miktar - ancak durum makinesine, risk yönetimine bağlılık, işlem sınırlarına, güven varsayımlarına bu seviyelere derinlemesine indiğinizde, farklılıklar kelimenin tam anlamıyla "Eşleştirme Motoru" terimini aşırı soyut hale getirir.

Bu makalenin yapmak istediği, bu dört tipik formu ayırmak ve aynı temel kavramın farklı varlıklara göre nasıl farklı mühendislik varlıklarına dönüştüğünü açıklamaktır.

İkinci olarak, Spot Eşleştirme: En Temel Form

Spot eşleştirme standart bir modeldir, neredeyse tüm ders kitapları ve açık kaynaklı projeler (LMAX Disruptor, CME Globex'in basitleştirilmiş versiyonu, çeşitli açık kaynaklı eşleştirme motorları) buradan başlar.

Core Data Structure genellikle iki fiyat ağacını (alış tarafı, satış tarafı) içeren her fiyat düğümüne bir FIFO kuyruğu olan bir ağaç içerir. Eşleme döngüsü çok doğrudur: Bir yiyici emir geldiğinde, karşı taraftan en iyi fiyat seviyesinden başlayarak taramaya başlar, zaman sırasına göre yapımcı kuyruklarını tüketir, yiyici emir miktarı tükenene veya fiyat limitini aşana kadar devam eder.

Core Features birkaç önemli noktaya değinmeye değer:

İlk olarak, Varlıklar homojen ve ayrılabilir. Alıcı quote varlığını (USDT) tutar, satıcı ise base varlığını (BTC) tutar, eşleme aslında bir varlık değişimidir. Defterdeki işlem, bir işleme bağlı olarak dengelerin arttırılması veya azaltılmasıdır, uzlaşma ve eşleme aynı işlemde tamamlanır. Eşleme motorunun neredeyse hiçbir dış bağımlılığa ihtiyacı yoktur - Eşleme, uzlaşmadır ve aşağı akış bağlantısı yoktur.

İkinci olarak, Risk anında sıfırlanır. Bir spot işlem anında tamamlandığında, tüm pozisyon ilişkileri kaybolur, eşleme seviyesinde bir "pozisyon" kavramı yoktur. Motor, fiyat dalgalanmasından dolayı bir sonraki saniyede pozisyonunuzu kapatmanız gerekip gerekmediğini umursamaz, çünkü zaten bir "pozisyon" yoktur.

Üçüncü olarak, Emir Türleri nispeten yakındır. Limit, Market, IOC, FOK, Yalnızca Gönder, Stop - Bunlar tümü emir yaşam döngüsü yönetimindeki varyasyonlardır.

Belirli bir senaryoyu düşünelim. BTC/USDT satış 1. seviye 50,001 × 1.5 BTC (üretici A 09:30:00.100'de sipariş verdi), satış 2. seviye 50,002 × 3.0 BTC (üretici B 09:30:00.200'de 1.0 sipariş verdi, üretici C 09:30:00.300'de 2.0 sipariş verdi).

4.0 BTC'lik bir piyasa emri geldiğinde. Eşleme döngüsü: Önce A'nın tüm 1.5'ini 50,001 fiyattan tüket, ardından sıradaki seviyeye FiFO sırasına göre devam et - B'den önce C, önce B'nin tüm 1.0'ını 50,002 fiyattan tüket, sonra C'nin bir kısmını 1.5 tüket (C'nin 0.5'i kuyrukta).

Yiyici hesabı aynı işlemde 200.006,5 USDT düşer, 4.0 BTC artar, üç üretici hesabı karşıt şekilde güncellenir. Bu dizi işlem bir veritabanı işlemi içinde tamamlanır, eşleme aynı zamanda uzlaşmadır. Not edilmesi gereken önemli bir nokta, B'nin C'den önce işlem görmesinin nedeni fiyat değil (aynı seviyede), aksine önce asılı olmasıdır - bu, zaman-fiyat önceliğinin gerçekten uygulanmasının bir örneğidir.

Anlık eşleştirme mühendisliğindeki zorluk aslında mantıkta değil, performansta yatar: Milyonlarca TPS altında milisaniye gecikmeyi nasıl koruyacağınız, soğuk-sıcak yol önbelleği yerelliğini nasıl yöneteceğiniz, belirlenmiş tekrarlamayı nasıl sağlayacağınız gibi konular. Bunlar optimizasyon sorunlarıdır, mekanizma sorunları değil.

Üç, Sürekli Vadeli İşlem Eşleştirme: Risk Kontrol Motorunun İfşası

Binance sürekli vadeli işlem emir defterini spot emir defterinin yanına koyarsanız, çıplak gözle farkı göremeyebilirsiniz. Ancak altında başka bir manzara vardır.

Temel değişiklik şudur: Eşleştirme motoru uzlaşmanın sonu değildir, yalnızca bir olay kaynağıdır. (yani bir domino taşı)

Her bir perpetual eşleştirme tamamlandığında karmaşık bir downstream zinciri tetiklenir: İşaret fiyatı güncellemesi, pozisyon güncellemesi, marjin yeniden hesaplama, realizasyon öncesi ve sonrası kar/zararın yenilenmesi, olası likidasyon tetiklemesi. Eşleştirme motoru ve risk motoru bu noktada derinlemesine kavuşmuştur, bu kavuşma şekli tüm sistemin karakterini belirler.

Çift Fiyat Sistemi, perpetual'ın ilk benzersiz yapısıdır. Eşleştirme kendisi halen "en son işlem gören fiyat"ı (last traded price) temel alırken, marjin tutma, likidasyon tetikleme, UPnL hesaplaması için "işaret fiyatı"nı (mark price) kullanır; işte bu, birden fazla spot piyasasının endeksine fonlama düzeltmesi eklenerek sentezlenir. Bu, bir manipülasyondan korunma tasarımıdır: Eşleştirme fiyatı ile işaret fiyatı aynı olursa, saldırgan emir defterini bir uç fiyata çekerek tüm ters yönlü pozisyonların anında likidasyonunu tetikleyebilir. Çift izleme, bu saldırı yüzeyini yok eder.

Çift fiyatın etkisini açıklamak için bir senaryo sunalım. Bir tüccar 50x kaldıraçla 1 BTC uzun pozisyondadır, giriş fiyatı 60.000, başlangıç marjı 1.200 USDT, sürdürme marjı 300 USDT'dir. Bir anda emir defteri büyük bir piyasa emri ile en son fiyat = 58.500'e aniden düşer — en sona göre hesaplanan zarar 1.500 USDT'dir, pozisyon aşılmıştır.

Ancak aynı anda işaret fiyatı (çoklu spot endeks ağırlıklı + fonlama düzeltmesi) = 59.400 olarak hesaplanırsa, işaret fiyatına göre hesaplanan zarar 600 USDT, hesap bakiyesi 600 > sürdürme marjı 300 olduğu için likidasyon tetiklenmez. Birkaç saniye sonra en son fiyat 59.400 seviyesine geri döner ve bu tüccar ani bir çöküşle yok edilmez.

Eşleştirme ve Zorunlu Likidasyon son fiyatı ortak kullandığında, saldırgan, bir küçük sermaye ile fiyatı aşırı bir seviyeye çekerek ters işlem pozisyonunu tetikleyebilir ve daha sonra düşük bir fiyattan geri alım yapabilir — Bu, BitMEX'in erken dönemlerinde sıkça yaşanan bir olay türüdür. İkili yapı, "kesinlik için" değil, "saldırıya uğramamak için" yapılmıştır.

Önce İşlem Riske Kontrolü başka bir önemli noktadır. Spot piyasada, emir geldiğinde doğrudan eşleştirilir; ancak vadeli işlemlerde, al emri önce teminat kontrolünden geçer — mevcut teminatınız bu işlemin getireceği pozisyon değişimini karşılayabilir mi? Cross-marj (çapraz-marj) modunda iseniz, bu kontrol hesabınızda bulunan tüm pozisyonların birbirini nötralize etmesini de düşünmelidir. Bu kontrol, eşleştirme döngüsünde senkronize bir şekilde tamamlanmalıdır; aksi takdirde "işlem gerçekleştikten sonra teminat yetersiz" tutarsız durumu ortaya çıkabilir.

Özel Likidasyon Eşleştirme Kanalı, vadeli işlem motorunun en ilginç kısmıdır. Hesap teminat oranı bakımından bakım seviyesinin altına düştüğünde, likidasyon motoru devreye girer — hesabın iflas fiyatına (veya belirli bir koruma fiyatına) geçerek IOC emrini sipariş defterine göndererek pozisyonu kapatmaya çalışır. Sipariş defteri çok ince ise, bu likidasyon emrini nasıl işleyecektir? Burada birkaç mühendislik seçeneği vardır: birincisi, sigorta fonuna başvurarak, ikincisi ADL'yi (otomatik pozisyon azaltma) tetiklemek, sistemin karşı tarafın karlılığını zorla azaltmasını sağlamak.

ADL aslında "eşleştirmenin son halkası"dır: sipariş defteri ve sigorta fonu başarısız olduğunda, sistem sipariş defterini atlar ve doğrudan iki hesap arasında zorunlu bir hesaplaşma yapar. Bu, "gönüllü eşleme" kavramını "gönülsüz eşleme"ye genişleten bir tasarım şeklidir — artık geleneksel anlamda bir eşleme olmamakla birlikte, var olması gereklidir, aksi takdirde sistem aşırı piyasa durumlarında iflas edebilir.

Kendine İşlem Yaptırma Önleme (STP) ayrıca vadeli işlemlere özgü karmaşık bir konudur. Spot piyasada, STP genellikle yıkama işlemlerini önlemek için kullanılır; ancak vadeli işlemlerde, aynı hesap hem uzun hem kısa pozisyonları tutabilir (korunma modu), bu nedenle STP'nin anlamı ayrılmalıdır: alt hesap, kullanıcı kimliği veya ana hesaba göre mi işlem yapılacaktır? Farklı ticaret platformları farklı seçenekler seçebilir.

Sonuç olarak: vadeli işlemlerin eşleştirilmesindeki "zorluk", sipariş defterinde değil, sipariş defterinin arkasındaki tüm risk motoruna bağlı durum makinesinde yatar. Tasarımcılar net bir şekilde düşünmelidir: hangi kontroller eşleştirme ana yolda (senkronize) olmalı, hangileri asenkron olabilir; zorunlu kapanma yürütme modeli nedir; sigorta fonu nasıl tahsis edilecek; ADL tetiklemesi için öncelikli kuyruk nasıl sıralanacak (genellikle "kar yüzdesi × kaldıraç" sıralaması yapılır, en karlı, en yüksek kaldıraçlı kişilerin öncelikle pozisyonları azaltılır).

Dört, Sürekli eşleştirme Çift Yönlüdür: Karar, Yapı ve Yürütmenin Katmanlı Halefi

Perp eşleştirme ayrıca tartışmaya değer bir katmana sahiptir: Mart Kapanış yolunun eşleştirme aşamasında ve normal emirle birleştiği ancak birleşme öncesi ve sonrasında tamamen farklı bir mantığa sahip olduğu özel bir konsepttir. Bu katmanın anlaşılması, perp motorunun tasarımı veya hata ayıklaması için son derece önemlidir - aksi takdirde "eşleştirme" ile "mutabakat" sınırını sürekli karıştırma eğiliminde olabilirsiniz.

Mart Kapanışı üç katmana ayrılarak incelenebilir:

İlk katman tetikleme kararıdır. Mark fiyatı kullanılır - amaç, bu kararın sıralama defterinin anlık manipülasyonundan etkilenmemesi için "teminatı miktarlandırmalı mı?"dır. Bu katman tamamen iç piyasa derinliğinden bağımsızdır ve bağımsız bir risk değerlendirmesidir.

İkinci katman emir yapılandırmasıdır. Mart Kapanışı motoru bir takas işlemini belirledikten sonra, bir IOC emri oluşturur ve sıralama defterine gönderir.

Bu emir ve kullanıcının normal emiri yapısal olarak farklıdır: Fiyat kullanıcının seçimi değil, ancak motor tarafından iflas fiyatına sınır fiyat olarak belirlenir; tür her zaman IOC'dir, defterde dinlenmeye izin verilmez; ücretler takas ücret oranını (0.5–1.5%) kullanır ve ek olarak sigorta fonuna gider; emir verme yetkisi hesaba ait değildir - hesap teminatı alındığında hesap hatta sahibinden tüm emirleri iptal etmesi bile zorunlu olabilir (kendinden alımı önlemek için) - başarısızlık durumları farklıdır - kullanıcı IOC bir eşleşme yapamazsa kaybolurken, Mart Kapanışı IOC bir eşleşme yapamazsa sigorta fonunu tetikler → ADL'ye kaskat düşüşü olur.

Üçüncü katman eşleştirme yürütmedir. Bir kez sıralama defterine girdikten sonra, Mart Kapanışı IOC ve normal IOC aynı fiyat-zaman önceliği kurallarına göre likiditeyi eşlemek için rekabet ederler. Bu katman simetriktir, eşleştirme motoru Mart Kapanışı emirlerine özel eşleştirme önceliği uygulamaz - eşleştirme döngüsünde bu tür bir if-else olmamalıdır, aksi takdirde belirlenmiş tekrarlama bozulur.

Dolayısıyla kesin bir tanımı yapmak gerekirse: Eşleştirme döngüsü kendisi iki ayrı katmana ayrılmaz, ancak emir kaynağı, yapılandırma, ücretlendirme, başarısızlık yolunu iki ayrı sistem izler. Eşleştirme ana yolundan bakıldığında, Mart Kapanışı ve normal emir eşit derecededir; işlem panoramasından bakıldığında ise bunlar iki paralel boruyu izler ve yalnızca eşleştirme aşamasında birleşirler.

Burada dikkat edilmesi gereken başka bir nokta da var - mark fiyatı "hangi fiyattan miktarlandırmalı?"yı belirler (tetikleme koşulu), ancak son fiyat (piyasa derinliği) "gerçekte hangi fiyattan miktarlandırmalı?"yı belirler. Sıralama defteri ince olduğunda ve derinlik doldurulduğunda, Mart Kapanışı IOC'nin aldığı gerçekleşmiş işlem fiyatı batık fiyata kıyasla oldukça düşük olabilir, bu fark sigorta fonunun "kâr/zarar kaynağı"dır. Sigorta fonu, "mark tarafından belirtilen teorik uzlaşma fiyatı" ile "piyasa uygulamasında gerçekleşen işlem fiyatı" arasındaki farkı absorbe etmek için varlığını sürdürür. Eğer bu iki değer her zaman uyumlu olursa, sigorta fonu hiç var olmamalıdır.

Daha radikal bir tasarım (dYdX'in erken dönem destek sunucusu likidatör ağı), basitçe sipariş defterinin önüne bir katman ekledi: "Teminat yolundan bağımsız karşı taraf kanalı" — böylece destek sunucusu kasası veya beyaz listeli likidatör, tüm pozisyonu öncelikle alarak sipariş defteri olan yavaş yolu atlayabilir. Bu, "kısmi kapama yürütme"yi borsa içi eşleşmeden tamamen bağımsız bir şekilde, teminat yolunun kendi eşleşme kanalına vermesi temelidir. Bu, ikili yol sorusuna farklı bir yanıt olan bir yöntemdir: Bazı ticaret platformları, iki yolun aynı sipariş defterine sıkıştırılmasının bir uzlaşma olduğunu düşünüyor ve onları ayrı eşleşme kanalları kullanmaya karar veriyor.

Perp eşleştirme karmaşıklığının kalbine geri dönme: Eşleştirme ana döngüsü kendisi basit tutulabilir, ancak etrafındaki durum makinesi — risk kontrolü, likidasyon, sigorta fonu, ADL, belki de destek sunucusu likidatör ağı — sipariş defterinden daha karmaşık bir sistem oluşturuyor.

"Sipariş defteri spot borsayla aynı uzunluğa sahip gibi görünse de", aslında iki bağımsız giriş kanalı ve dört farklı çıkış yoluna sahip olduğunu unutmamak gerekir. Bu, perp eşleştirmenin "zor" olduğu gerçek şeklidir. (Bazı borsaların b kitabı yaptığına dair duyumlar var)

Beş, Opsiyon Eşleştirmesi: Izgara ve Likidite Sağlayıcı Odaklı

Opsiyonlar, dört varlık sınıfı içinde "varlık kendisi patlama yapma" özelliğine sahip tek kategoridir. Bir BTC spot piyasasında sadece bir sipariş defteri vardır; bir BTC sürekli işlem sözleşmesi de yalnızca bir tane; ancak BTC opsiyonları — Deribit örneğinde olduğu gibi — herhangi bir anda yüzlerce aktif sözleşmeye sahiptir, grev × vade × alım/satım üç boyutunu birleştirir. Her bir sözleşme için bağımsız bir sipariş defteri gereklidir.

Bu, temel bir sorunu beraberinde getirir: Likit olmama. İçsel veya dışsal derinlikteki sözleşmeler bir günde sadece birkaç işlem yapabilir, sipariş defteri genellikle boş veya sadece iki piyasa yapıcısının emrinin bulunduğu durumlarla karşılaşılır. Bu seyreklik nedeniyle, saf LOB modeli neredeyse kullanılamaz hale gelir— normal bir alıcı limit emri için birkaç gün beklemesi gerekebilir.

Sektörün çözümü üç modeli karıştırmaktır:

LOB, en derin likiditeye sahip sözleşmeler için kullanılır, genellikle ATM opsiyonları ve yakın vadeli sözleşmelerdir. Bu kısım spot mantığı ile temelde aynıdır.

RFQ (Teklif Talebi) seyrek likiditeye sahip sözleşmeler için kullanılır. İşlemciler fiyat teklifi isteği gönderir, birden fazla piyasa yapıcı cevaplar, işlemciler en iyiyi seçer. Bu süreç, LOB dışında çalışır, eşleşme "teklif talebi vs. birden fazla teklif yanıtı" üzerinden gerçekleşir, temelde bir ters açık artırmadır.

Bloklama İşlemi (Block Trade), aşırı büyük emirler için kullanılır. İki karşı taraf, fiyat konusunda tezgahüstü anlaşır, işlem borsa defterine kaydedilir ve uzlaşı sağlanır, emir defteri eşleştirmede yer almadan yalnızca kaydedilir.

Çok Bacaklı Eşleştirme, opsiyon eşleştirmesinin başka bir temel gereksinimidir. Yaygın bir strateji olan demir kondor gibi, dört farklı opsiyon sözleşmesi aynı anda alınıp satılmasını gerektirir. Eğer dört bacaklı işlem ayrı ayrı dört farklı emir defterinde eşleştirilirse, sonuç olarak bazı bacaklar gerçekleşebilirken diğerleri gerçekleşmeyebilir ve işlemcinin risk pozisyonu istenenden tamamen farklı olabilir.

Bu nedenle opsiyon eşleştirme motoru, combo emir defteri veya çok bacaklı atomik gerçekleşmeyi desteklemelidir: Dört bacak ya tamamı gerçekleşir ya da hiçbiri gerçekleşmez, bütün olarak işlenir.

Deribit'in yaklaşımı şu anda sektörde referans standart olarak kabul edilebilir: Bağımsız bir combo emir defteri bulunmaktadır, combo emirleri ayrı ayrı bekleyebilir veya tek bacaklı emir defterleri arasında ima edilmiş eşleştirme yapabilir - sistem otomatik olarak tek bacaklı likiditeyi combo fiyata dönüştürür ve tersi de geçerlidir. Bu çok ustalıklı bir tasarım olmasının yanı sıra, eşleştirme ana yolunda 'sanal emir defteri' durumunun senkronizasyonunu korumayı gerektirir.

Bir özel senaryoyu ele alarak, çok bacaklı senkron eşleştirmenin niçin seçenek olmadığını açıklayalım. ETH mevcut fiyatı 3.000 iken, işlemci gelecek 7 gün için [2.900, 3.100] aralığında bir dalgalanma öngörmektedir ve Demir Kondor oluşturur: 3.100'e Call sat, 3.200'e Call al, 2.900'e Put sat, 2.800'e Put al. Dört bacaklı işlem net geliri, kombinasyonun maksimum kazancıdır, maksimum zarar koruma bacaklarıyla katı bir şekilde sınırlandırılmıştır - bu stratejinin gerçekleşmesi için bir ön koşuldur.

Eğer dört sipariş değişik emir defterine ayrı ayrı gönderilirse, en yaygın başarısız senaryo şudur: İlk iki sipariş (call spread kısmı) gerçekleşir, ETH 2.950'e milisaniye içinde sıçrar, sonraki iki siparişin (put spread kısmı) karşı taraf teklifi artık geçersiz hale gelir, likidite sağlayıcıları emirleri iptal eder veya büyük ölçüde değiştirir, C ve D gerçekleşmez. Sonuç olarak, işlemci çıplak bir call spread'e sahip olur - yön bazlı pozisyon tamamen tersine döner, başlangıçta "dalgalanma faydası" olan strateji "düşüş zararı" olur ve maksimum zararın da artık bir sınırı yoktur.

Combo emir defteri, dört bacağı bir bütün olarak paketler: ya hepsi gerçekleşir ya da hiçbiri gerçekleşmez; ima edilmiş eşleştirme, tek bacaklı emir defterinin likiditesinin anlık olarak birleştirilmiş combo fiyata çevrilebilmesine izin verir; benzer şekilde combo emir defterinin likiditesi de tek bacaklıya geri gider, her iki düzeydeki likidite birbirini tamamlar.

Liquidity Provider's Pricing Algorithm primarily uses IV Implied Volatility, instead of price (which is also unique to options). Liquidity providers will not quote "50000 strike call $1500"; they will quote "buy at 65 vol, sell at 67 vol", and the system will calculate the actual quote based on the current underlying price using the BSM (or a more complex model) at each quoting event.

This means that the liquidity provider's quote dynamically tracks the underlying, and the order book automatically adjusts when the underlying price changes—turning "placing an order" into a continuous function in options rather than a discrete event.

Greekified Portfolio Margin also changes risk management. In perp, each position is margined independently; in options, a liquidity provider may hold hundreds of contracts at the same time, and individually margining each contract would make capital efficiency too low to operate.

So options trading platforms typically use a Greek-letter-based (delta, gamma, vega, theta) portfolio margin, treating the entire portfolio as a net exposure and calculating margin based on net Greeks. This, in turn, affects matching—the "margin cost" of a trade depends on whether it hedges your existing position.

VI. Polymarket Matching: On-Chain/Off-Chain Hybrid Architecture

Before delving deeper, let's address a potential question: Why single out Polymarket? Why not discuss AMM? Why not merge it into a generic "DEX Matching" category?

It's because Polymarket's uniqueness does not lie in the "on-chain" label. Polymarket's real uniqueness comes from the combination of three mechanisms: [0, 1] Price Banding + CTF Complementary Forging + UMA Outcome Resolution (similar to mark price). Together, these three shape a state machine form distinct from spot, perp, options, and other DEXs—an environment where the price space is discretely bounded, liquidity is practically created out of thin air, and the lifecycle has an endpoint.

We will now follow this as the main thread, exploring these three mechanisms and the trust assumptions behind them.

Polymarket, Polygon'da inşa edilen (ilk?) bir tahmin pazarıdır, tüm pozisyonlar ERC-1155 jetonlarıdır ve Gnosis'in Koşullu Jeton Çerçevesi (CTF) tarafından oluşturulmuştur. Bir pazar — örneğin bir başkanlık seçiminin ikili tahmini gibi — iki tür jeton çıkarır: EVET jetonu ve HAYIR jetonu, pazar sona erdiğinde bir jetonun değeri $1, diğerinin değeri $0 olur.

Ek jetonlama mekanizması, CTF'nin çekirdeğidir. Herhangi bir kişi 1 USDC yatırabilir, 1 EVET + 1 HAYIR alabilir. Herhangi bir kişi aynı şekilde 1 EVET + 1 HAYIR'ı yok edebilir, 1 USDC alabilir. Bu mekanizmanın varlığı likidite sağlayıcıların pazara "hiçlikten" likidite sağlamasına olanak tanır — likidite sağlayıcının satış yapabilmek için önce bir jetona sahip olma zorunluluğu yoktur, doğrudan jetonları yaratabilir ve satabilir. Eşleştirme motoru açısından, bu, likidite sağlayıcının sonsuz bir başlangıç envanterine sahip olduğu anlamına gelir, ancak maliyet kısıtı teminatla sınırlıdır — bu, Polymarket'in geleneksel CLOB ile önemli bir farkıdır.

Off-chain eşleştirme + on-chain uzlaşma, Polymarket'ın genel mimarisidir. Belirli süreç: Kullanıcı, bir limit emri EIP-712 ile imzalar, bunu Polymarket'ın merkezi eşleştirme sunucusuna gönderir; sunucu geleneksel bir LOB sürdürür; iki emir eşleştiğinde, sunucu bu iki imzayı bir on-chain işlemde paketler, uzlaşmayı tamamlamak için takas akdini çağırır. Dolayısıyla eşleştirme kendisi off-chain'dir (milisaniyeler düzeyinde), ancak uzlaşma on-chain'dir (saniyeler düzeyinde).

Bu mimaride güven açısından özel bir durum vardır: Eşleştirme sunucusu işlemi taklit edemez, çünkü kullanıcının özel anahtarına sahip değildir; ancak işlemi inceleyebilir — bazı emirleri eşleştirmeyi reddedebilir.

Gas Ekonomisi, kullanıcı davranışını değil, uzlaşma yolunu şekillendiriyor. Yaygın bir yanlış anlama, Polymarket'in gas maliyetini kullanıcının üzerine atfetmektir — gerçekte gas, relayer'ın (Polymarket'ın operatörü) ödediği bir maliyettir. Kullanıcılar EIP-712 ile sipariş verir, relayer eşleştikten sonra gerçekleşmeleri için topluca işlem gönderir, gas Polymarket tarafından karşılanır ve işlem ücreti ile geri alınır. Bu, kullanıcılar için emir vermenin ve iptal etmenin ücretsiz olduğu anlamına gelir — iptal etmek hatta hiç blok zincire gönderilmez, yalnızca eşleştirme sunucusuna bir bildirim yapar ve emri kaldırır, mantıksal olarak CEX'te emir iptal etmekle temel fark yoktur.

Ancak bu, gas'ın zayıflatılmadığı anlamına gelmez, sadece kısıtlama relayer tarafına kaydırılmıştır: Her işlemin zincir üstü uzlaşma maliyeti Polymarket tarafından karşılanır, relayer'ın gas bütçesi + Polygon'un işlem kapasitesi limiti sistemdeki maksimum işlem sıklığını belirler. Likidite sağlayıcılar aşırı yoğunluk durumunda karşılaştıkları şey "emir ücreti" değil, uzlaşma gecikmesi ve işlem kapasitesi darboğazıdır - bu, CEX'in tamamen farklı bir sıkışma iletim yolundan kaynaklanmaktadır.

Bu mimari, eşleştirme motoruna uygulanan gerçek şekillendirme şartını yansıtmaktadır: relayer'ın birden fazla işlemi toplu olarak uzlaştırmasına (gası yayma) izin vermek zorundadır, aynı zamanda her işlemin uzlaşma sözleşmesinde bağımsız olarak doğrulanabilir olmasını sağlamalıdır (relayer'ın müdahalesini veya kayırıcılığını önlemek için).

Bu nedenle Polymarket'ın takas sözleşmesi, "çoklu imzalı sipariş + toplu gönderim" yapısını kabul edecek şekilde tasarlanmıştır. Gas, Polymarket'ı "düşük frekanslı bir pazar" haline getirmemiştir, ancak eşleştirme-uzlaşma bağlantı şeklini CEX ve saf zincir üstü DEX'ten farklı hale getirmiştir - eşleştirme katmanı tamamen CEX'in hafifliğini devralmıştır (milisaniye emir iptali, sıfır gas emri), uzlaşma katmanı ise zincir üstü DEX'in doğrulanabilirlik kısıtlamalarını devralmıştır.

Oracle Sonucu Kararının Yenilmezliği, tahmin borsasının eşleştirilmesini en belirgin şekilde etkileyen özelliktir. Diğer üç pazar türü sürekli olarak işler - fiyat her zaman değişir, pazar her zaman açıktır. Ancak tahmin pazarında net bir "sona erme anı" vardır: Olay gerçekleşir, sonuç bir orakle tarafından çözülür (Polymarket UMA'nın iyimser oracle'ını kullanır), EVET veya HAYIR belirlenir (tartışılabilecek zamanlar da vardır, ancak bu yazıda ele alınmamaktadır) ve tüm pozisyonlar 1:0 veya 0:1 olarak yerleştirilir.

Bu, eşleştirme motorunun "pazar donması" bir durumu işlemesini gerektirir: çözüm penceresi içinde yeni siparişlere izin vermez, itiraz penceresi içinde meydan okumaya izin verir ve nihai uzlaşmadan sonra tüm ticaret faaliyetlerini durdurur. Bu durum makinesi, CEX spot işlemlerinde karşılığı olmayan bir durumdur.

Fiyat [0, 1] Aralığında Kısıtlandı, başka bir mekanizma kısıtlamasıdır. Bu bir avantaj gibi görünse de (sonsuz bir şekilde tasfiye edilmeyeceksiniz), bu, emir defteri fiyat adımlarının sınırlı olacağı anlamına gelir - genellikle adım başına 1 sent, en fazla 100 adım. Bu, eşleştirme veri yapısı için güçlü bir kısıtlamadır (bir ağaç yerine sabit boyutlu bir dizi kullanabilirsiniz), ancak fiyat keşfinin hassasiyetinin bir sınırı olduğu anlamına gelir.

Bir Senaryo Örneği vererek mint/redeem'in likidite sağlama davranışını nasıl şekillendirdiğini açıklayın. Bir pazarın YES fiyatı $0.65, NO fiyatı $0.35 olarak belirlendiğinde (YES + NO toplamı her zaman $1'e eşittir, aksi takdirde arbitrajcılar derhal mint veya redeem yaparak dengeyi sağlarlar). Likidite sağlayıcı M, bu pazara satış likiditesi sağlamak istiyor ancak elinde YES bulunmuyor - CTF akıllı sözleşmesine 100 USDC yatırır ve hemen 100 YES + 100 NO alır, 100 YES'i 0.66 fiyatla satışa, 100 NO'yu ise 0.36 fiyatla satışa çıkarır.

Her iki işlem de gerçekleştikten sonra M, 0 net pozisyonda kalır ve çift taraflı fiyat farkından 0.02 × 100 = 2 USDC kazanır. Bu, Polymarket'ın likidite sağlama standardı oyunudur: mint/redeem'i kullanarak "sermaye kullanımını" "çift yönlü fiyat farkına" dönüştürme.

Özellikle analiz edilmesi gereken nokta şudur: YES + NO = 1 bu sabit değer, eşleştirme motorunun aktif olarak sürdürmesine gerek olmayan bir invariyandır, piyasa yapısı arbitrajcılar aracılığıyla otomatik olarak garanti altına alınır - bu tür "doğal piyasa yapısı invariants", geleneksel LOB'da mevcut değildir ve piyasa yapıcılar "elinde stok olmadan satış yapamaz." Polymarket'ın eşleştirme motorunun tasarımı bu nedenle bazı CEX'lerin zorunlu olduğu stok kısıtlamaları kontrolünden tasarruf sağlayabilir, ancak bu bedel, mint/redeem yolunu hesap sözleşmesine birinci sınıf bir entegrasyon olarak yapmak zorundadır.

Polymarket eşleştirme özelliklerinin özeti şöyledir: Güven varsayımı, "off-chain eşleştirme + on-chain uzlaştırma" karışımıdır, token modeli CTF'nin karşılıklı dökümüdür, fiyat aralığı [0,1] sınırlıdır, zaman boyutu nihaidir, gas ücreti relayer tarafından üstlenilir ve işlem ücretleri geri kazanılır. Bu kısıtlamalar, tamamen farklı bir eşleştirme motoru şeklini oluşturur ve önceki üç türden tamamen farklıdır.

Yedi, Farklılık Nereden Kaynaklanıyor: Beş Boyutlu Bir Çerçeve

Şu dört şekli açıklayarak, eşleştirme motorunun farklı varlıklar altında neden farklılaştığını açıklayabiliriz:

Bu beş boyutlu çerçeveyi "Eşleştirme-Risk Yönetimi Entegrasyonu" ve "Likidite Yoğunluğu" iki boyut üzerine yerleştirdiğimizde, dört formun konumu açıkça görülebilir: spot piyasalar, düşük entegrasyon ve yüksek yoğunlukta uygun bir bölgede bulunurken, perpetuals, yüksek entegrasyon ve yoğunlukta (en karmaşık mühendislik gerçekliği) yer alır, opsiyonlar yüksek entegrasyon ve düşük yoğunlukta bulunur (seyrekliği telafi etmek için RFQ + combo kullanmak zorundadır), Polymarket ise bu ikisinin arasında yer alır - entegrasyon seviyesi on-chain uzlaştırma tarafından yükseltilmiş, yoğunluk ise karşılıklı döküm tarafından yükseltilmiştir.

Her boyutlu her boyut, eşleme motoruna baskı uygular:

Varlık Biçimi, Sipariş Defterinin miktarını ve seyrekliğini belirler. Tek boyutlu homojen (spot, perp) sadece bir defter gerektirirken, çok boyutlu seyrek (opsiyonlar) yüzlerce defter gerektirir ve seyreklik sorununu çözmek zorundadır; ayrımcılık yapmayan rekabet (Polymarket) "kalıp/geri dönüş"ü eşleme yoluna entegre etmek zorundadır.

Hesaplama Sırası, durum makinesinin karmaşıklığını belirler. Anında senkronizasyon (spot), eşleştirmeyi hesaplamaya eşitler; sürekli defter tutma (perp, opsiyonlar) pozisyon durumunu, teminat durumunu, PnL durumunu korumayı ve her eşleme sonrası güncellemeyi gerektirir; sonuç çözme (Polymarket) durum makinesinin "açık"tan "donmuş"a ve ardından "çözülmüş"e dönüşümünü gerektirir.

Risk Kapsamı, risk kontrolü bağlantısını belirler. Lineer sıfır pozisyon (spot) neredeyse hiç risk kontrolü gerektirmez; lineer sinir açılımı (perp) ön işlem marjı kontrolü ve likidasyon motoru gerektirir; konveksiyon (opsiyonlar) Yunanlara dayalı kombinasyon teminatı gerektirir; ikili sınırlı (tahmin) neredeyse hiç risk kontrolü gerektirmez (maksimum zarar ödenen paradır).

Likitlik Yoğunluğu, likidite kaynağı stratejisini belirler. Yoğun pazarlar sadece LOB'u destekleyebilirken seyrek pazarlar RFQ, AMM, likidite sağlayıcı teşviki gibi ek mekanizmaları dahil etmek zorundadır.

Güven Sınırı, hangi bileşenlerin doğrulanabilir olması gerektiğini belirler. Bir Borsa'daki tüm bileşenler ticaret platformu içindedir; saf DEX'teki tüm bileşenler zincir üstündedir; karma yapıda hangisinin zincir üstüne çıkması gerektiği (hesaplaşma), hangisinin zincir dışında olabileceği (eşleştirme), saldırı modelinin ne olduğu (para çalınamaz ancak denetlenebilir) açık olmalıdır.

Sekiz, Hiçbir Adım Gereksiz Değildir: Eşleme Mekaniği Mekanizmanın Aynasıdır

Başa dönersek—neden "Eşleme Motoru" farklı pazarlarda neredeyse farklı dört makineye ayrılır?

Çünkü eşleme asla bağımsız bir mühendislik modülü olmadı, o, dayanak varlığın doğası, hesaplama modeli, risk yapısı, likidite biçimi, güven varsayımı bu beş değişkenin bütünsel etkileşiminin bir ürünüdür. Eşleme motoru, bu değişkenlerin yüzüdür—eşleme nasıl göründüğünü gördüğünüzde, bu pazarın finansal yapısının nasıl olduğunu çıkarabilirsiniz.

Spot işlem eşleşmesinin sadeliği, "Homojen Varlık + Bir Kerede Mutabakat + Sıfır Pozisyon Taşıma" temiz yapısıyla uyuşur;

Perpetual kontrat işlem eşleşmesinin karmaşıklığı, "Sentez Varlık + Sürekli Pozisyon + Risk Yönetimi-Eşleşme Derinlik Eşleşmesi" mühendislik gerçekliğiyle uyuşur;

Opsiyon işlem eşleşmesinin karma formu, "Boyut Patlaması + Likidite Seyrekliği + Likidite Sağlayıcı Odaklı" piyasa yapısıyla uyuşur;

Polymarket işlem eşleşmesinin on-chain/off-chain bölünmesi, "Denetimsizlik" ve "Hırsızlığa Karşı Direnç" olmak üzere iki güvenlik hedefinin mühendislik uzlaşmasıyla uyuşur.

Eğer Mutabakat, bir işlem platformunun vicdanıysa, o zaman eşleşme mekanizması o platformun çizgisidir.