Podpisanie zlecenia pozwala handlować na określonych warunkach. Nie oznacza, że transakcja się odbyła. API może je zaakceptować, arkusz może skojarzyć część, a transakcja rozrachunkowa nadal może się nie udać.
Ten piąty artykuł serii Jak działają Polymarket i Kuest śledzi autoryzację stojącą za połączonymi arkuszami YES i NO. Przechodzimy przez oddzielne warstwy systemu: co podpisuje uczestnik, co egzekwuje usługa kojarzenia i co blockchain faktycznie zapisuje.
Zacznij od instrukcji, potem śledź aktywa
Zachowajmy hipotetyczne pytanie: „Czy Obserwatorium A opublikuje temperaturę co najmniej 30,0°C dla Miasta B o 12:00 UTC w Dniu C?”. Zakup jego tokena YES oznacza nabycie określonego aktywa wyniku; podpisanie zlecenia BUY tylko upoważnia do jego nabycia.
Używamy standardowego binarnego rynku Conditional Tokens Framework (CTF) i ogólnych jednostek zabezpieczenia. Przykłady kwot zakładają sześć miejsc dziesiętnych, wystarczające środki i uprawnienia oraz brak kosztów gasu i finansowania; opłaty pojawiają się oddzielnie tam, gdzie je wskazano.
Poniższe wyjaśnienia korzystają z publicznych standardów podpisu, publicznych przykładów CTF Exchange i hipotetycznych przepływów aktywów. Obsługiwane portfele, typy zleceń i opłaty właściwe dla platformy muszą wynikać z jej aktualnej publicznej dokumentacji integracyjnej.
Trzy autoryzacje mają różne zadania
Podpis zlecenia autoryzuje konkretną instrukcję giełdową. Uwierzytelnienie API identyfikuje uprawnionego nadawcę żądania do usługi. Podpis pakietu wywołań portfela autoryzuje oddzielny zestaw wywołań portfela, np. nadanie uprawnienia do wydawania tokenów.
Dane uwierzytelniające API identyfikują uprawnionego nadawcę żądania do usługi; nie są kluczem prywatnym uczestnika i nie zastępują podpisu zlecenia. Publiczny przewodnik Polymarket po portfelach i uwierzytelnianiu daje jeden udokumentowany przykład produktu.
Oddzielne obiekty, oddzielne kontrole. Pakiet portfela ma własny nonce i termin ważności; te pola nie stają się częścią zlecenia giełdowego.
EIP-712 definiuje haszowanie i podpisywanie ustrukturyzowanych wiadomości. Jego domena może powiązać instrukcję z blockchainem, nazwą aplikacji, wersją i kontraktem weryfikującym, uniemożliwiając uznanie podpisu przeznaczonego dla jednej domeny w innej.
Publiczny kod podpisywania CTF Exchange V2 ilustruje domenę EIP-712 właściwą dla aplikacji. Nazwa lub wersja domeny jest częścią podpisanego kontekstu; nie dowodzi, że inna giełda akceptuje tę samą wiadomość. Ograniczenia ponownego użycia podpisu zależą też od stanu i reguł weryfikacji rzeczywistego kontraktu.
Kwoty zawierają cenę
W publicznej definicji zlecenia CTF Exchange V2 podpisana instrukcja obejmuje między innymi token, stronę, kwoty maker i taker oraz tożsamości kont. Podpis autoryzuje tak zdefiniowaną wiadomość, nie dowolną cenę, którą interfejs wyświetli później.
Tutaj maker nazywa konto dostarczające aktywa, nawet jeśli jego zlecenie od razu konsumuje płynność. Nazwa tego pola różni się od roli handlowej maker, oznaczającej zlecenie oczekujące, zanim inne zlecenie zawrze z nim transakcję.
Dla BUY makerAmount oznacza oferowane zabezpieczenie, a takerAmount żądane udziały. Zlecenie oferujące 60 za 100 YES koduje limit 60 ÷ 100 = 0,60; dla SELL oferującego 100 YES za 60 cena wynosi zamiast tego takerAmount ÷ makerAmount.
Nie istnieje niezależne podpisane pole ceny, które mogłoby nadpisać ten stosunek. Zmiana wyświetlanej ceny bez ponownego zbudowania i podpisania odpowiednich kwot nie zmienia autoryzowanych warunków.
Znacznik czasu może opisywać moment utworzenia zlecenia, nie będąc egzekwowanym terminem wygaśnięcia. Integracja musi odróżniać podpisane pola od instrukcji usługi i sprawdzać ich znaczenie w aktualnej publicznej specyfikacji zlecenia.
Weryfikacja decyduje, czy zlecenie może trafić do arkusza
Przed złożeniem zlecenia sprawdź zamierzone aktywo, limit ceny, ilość, konto i obsługiwany typ zlecenia. Kontrole klienta i potwierdzenie API nie zastępują udanego rozrachunku w kontrakcie.
Krok ceny to dozwolony przyrost między kwotowanymi cenami. Przed podpisaniem sprawdź aktualne opublikowane specyfikacje rynku. Kontrola po stronie klienta, odpowiedź usługi i reguła kontraktu ustalają różne rzeczy; samo wyświetlane minimum nie dowodzi ograniczenia on-chain.
Środki i uprawnienia to różne kontrole: BUY potrzebuje dostępnego zabezpieczenia i wystarczającego uprawnienia do jego wydania przez kontrakt rozrachunkowy; SELL potrzebuje tokenów wyników i zgody na transfer. Sam podpis nie zapewnia żadnego z nich, a sprawdzenie salda przy przyjęciu nie zamraża wszystkich późniejszych zmian konta.
Post-only oznacza instrukcję mającą dodać oczekującą ofertę zamiast natychmiast konsumować płynność. Sprawdź udokumentowane kombinacje i zachowanie przy odrzuceniu na platformie; sama etykieta nie definiuje każdej implementacji.
Okres obowiązywania zlecenia mówi usłudze kojarzenia, co zrobić z niewykonaną ilością:
- GTC — good till cancelled: pozostaw dopuszczoną pozostałą ilość w arkuszu do anulowania.
- GTD — good till date: pozwól jej oczekiwać do określonego terminu wygaśnięcia.
- FAK — fill and kill: natychmiast wykonaj dostępną ilość i odrzuć resztę.
- FOK — fill or kill: wymagaj możliwości wykonania całej żądanej ilości albo nie wykonuj niczego.
Wygasające zlecenie w usłudze i podpisany termin w kontrakcie to różne zobowiązania. Sprawdź, gdzie aktualna specyfikacja egzekwuje wygaśnięcie i co dzieje się z już wysłanymi transakcjami. Obecność pola w żądaniu sama nie dowodzi gwarancji kontraktu.
Skojarzenie nadal wymaga udanego rozrachunku
Rozważ etapy dydaktyczne: podpisane → zaakceptowane/oczekujące → skojarzone → wysłane → potwierdzone. Zlecenie może zostać odrzucone przed przyjęciem; jedno zaakceptowane zlecenie może dać kilka częściowych skojarzeń i transakcji rozrachunkowych. Te etykiety wyjaśniają odpowiedzialność, nie definiują uniwersalnej listy stanów API.
Częściowe skojarzenie pozostawia ilość do dalszego kojarzenia, jeśli pozwala na to okres obowiązywania. Nieudany rozrachunek wymaga uzgodnienia stanu przed ponowną próbą.
Publiczny kontrakt CTF Exchange V2 ilustruje autoryzowane kojarzenie i kontrole kontraktu przed przepływem aktywów. Przykłady bezpośrednie, emisji i scalenia w artykule 4 wyjaśniają możliwe przepływy aktywów i wymagania ich finansowania.
Transakcja jest atomowa: jeśli wymagany transfer lub kontrola zostanie cofnięta, jej zmiany stanu są wycofywane. Nie cofa to innej transakcji, która już się powiodła, a cofnięta transakcja może nadal zużyć gas.
Hash transakcji identyfikuje wysłaną transakcję, nie udany zakup. Sprawdź jej potwierdzenie i stan potwierdzenia wymagany przez wybraną sieć. Dopóki wynik nie jest znany, interfejs powinien zachować tę niepewność zamiast informować o dostarczeniu aktywów.
W interfejsie operatora zachowuj oddzielnie identyfikator zlecenia, skojarzoną ilość i odwołanie do transakcji. Jeśli transakcja nie powiedzie się lub jej stan pozostaje niepewny, uzgodnij rzeczywisty wynik przed ponowną próbą; zmiana lokalnej etykiety nie przenosi aktywów.
Częściowe wykonania zużywają oferowane aktywo
Załóżmy, że oczekujące BUY oferuje 60 jednostek zabezpieczenia za 100 YES, a pierwsze wykonanie dostarcza 40 YES dokładnie po 0,60. Pomijając opłaty, zużywa 24 jednostki zabezpieczenia, pozostawiając podpisany limit na pozostałe 36 jednostek zabezpieczenia, równoważny 60 YES po tej samej cenie.
Oczekujące SELL oferujące 100 YES za 60 jednostek zabezpieczenia zużywa przy tym wykonaniu 40 YES i otrzymuje 24 jednostki zabezpieczenia. Pozostała kwota maker to 60 udziałów, nie 36 jednostek zabezpieczenia. Oba zlecenia mają jeszcze 60 YES do handlu, ale ich liczniki pozostałych ilości on-chain używają różnych aktywów.
To samo wykonanie 40 udziałów, różne jednostki liczników. Wykonanie dokładnie po cenie limitu; opłaty pominięto.
Publiczna arytmetyka CTF Exchange V2 działa w całkowitych jednostkach bazowych. W użytym poniżej modelu proporcjonalnego dzielenia z zaokrągleniem w dół kwota pobierana równa się kwocie dostarczanej × podpisana kwota taker ÷ podpisana kwota maker, zaokrąglona w dół. Dokładne uzgodnienie wymaga reguł zaokrąglania rzeczywistej ścieżki.
Na przykład sprzedaż 1,000001 udziału z podpisanego zlecenia na 3 udziały za 1,8 jednostki zabezpieczenia oblicza 1 000 001 × 1 800 000 ÷ 3 000 000, zaokrąglając w dół do 600 000 jednostek bazowych zabezpieczenia. Małe wykonania i opłaty wymagają więc reguł zaokrąglania implementacji; mnożenie zaokrąglonych cen z interfejsu nie wystarcza do dokładnego uzgodnienia.
Opłaty należą do osobnego rejestru
Załóż bezpośredni zakup 100 YES za 60 jednostek zabezpieczenia i hipotetyczną opłatę 0,60 dla każdego uczestnika. Kupujący potrzebuje 60,60 jednostek zabezpieczenia; sprzedający otrzymuje 59,40. Pozostałe 1,20 to łączne opłaty, więc wszystkie środki kupującego są rozliczone.
Hipotetyczne opłaty, nie aktualna stawka. Wypływ kupującego 60,60 = wpływ sprzedającego 59,40 + łączne opłaty 1,20; 100 istniejących YES przechodzi do kupującego.
W tym wyraźnym przykładzie opłata BUY jest dodawana do środków wymaganych od kupującego, a opłata SELL odejmowana od wpływów. Rzeczywiste obciążenia, odbiorców i zaokrąglenia trzeba sprawdzić dla wybranej platformy i ścieżki; przykład nie jest cennikiem.
Anulowanie ma swoje granice
Żądanie usunięcia otwartego zlecenia dotyczy jego pozostałej niewykonanej ilości. Nie odwraca ukończonych wykonań. Traktuj potwierdzenie anulowania i każdą oczekującą transakcję rozrachunkową jako oddzielne rekordy; sprawdź oba przed ponownym użyciem środków.
Jeśli rozrachunek został już wysłany, późniejsze anulowanie w arkuszu nie może obiecać jego zatrzymania. Sprawdź wynik transakcji, zanim uznasz aktywa za nadal dostępne, zwłaszcza gdy pierwotne zlecenie wykonano częściowo.
Anulowanie reszty i rozrachunek wcześniejszego skojarzenia mogą nastąpić równocześnie. Żadne z opóźnionych zabezpieczeń nie odwraca udanej transakcji.
Szersze ograniczenie konta nie jest tym samym co anulowanie jednego zlecenia. Mechanizmy odzyskiwania mogą mieć różne zakresy, opóźnienia i uprawnione podmioty. Korzystaj z opublikowanej dokumentacji kontraktu i produktu dla rzeczywistego konta zamiast zakładać, że każdy mechanizm zatrzymuje działanie natychmiast.
Deposit Wallet ma osobną pauzę i awaryjny okres oczekiwania przed awaryjnymi wypłatami lub cofnięciem uprawnień. Sama pauza portfela nie wyłącza w tym kodzie wykonania pakietów ani weryfikacji podpisów; nie jest natychmiastowym wyłącznikiem handlu.
Nazwy wersji nie definiują integracji
Starsze zlecenie CTF Polymarket podpisywało taker, expiration, nonce i feeRateBps. Oddzielne zlecenie CTF Exchange V2 usuwa te pola i dodaje timestamp, metadata oraz builder; cena pozostaje stosunkiem kwot.
Repozytorium V2 usuwa też fillOrder/fillOrders, zachowując kojarzenie przez operatora za pomocą matchOrders. Ten CTF Exchange V2 różni się od architektury pozycji Protocol V2 w polymarket-v2-external; Kuest nie dziedziczy automatycznie aktualizacji żadnego z tych repozytoriów.
Brak terminu wygaśnięcia w strukturze kontraktu nie oznacza, że produkt nie ma wygasających zleceń. Aktualna dokumentacja cyklu życia Polymarket opisuje GTD na poziomie produktu; przewodnik po pozycjach odróżnia rejestry CTF i Protocol V2. Sprawdź ścieżkę rzeczywistego rynku przed zbudowaniem integracji.
Co powinien ujawnić operator Kuest
Publiczny przewodnik Kuest dla operatorów oddziela aplikację operatora od wspólnych usług. Uczestnikom pokaż obsługiwany sposób korzystania z konta, pełny szacunek opłat i odrębne stany akceptacji, skojarzenia oraz potwierdzenia; to obserwowalne wymagania produktu, a nie szczegóły implementacji.
Publiczna dokumentacja opłat Kuest opisuje udział operatora w opłatach handlowych i konfigurowalny podział z afiliantami. Podział opłaty różni się od dodatkowego obciążenia wartości transakcji. Wyjaśniając koszty uczestnika, korzystaj z aktualnej publicznej konfiguracji i zapisów rozrachunku.
Dla operatora pod własną marką oznacza to konkretną decyzję integracyjną: zachowaj właściwą tożsamość buildera, pokaż rzeczywiste łączne obciążenie i uzgodnij jego podział z zapisami rozrachunku. Sam kod lub frontend pod własną marką nie gwarantuje przyjęcia, prawa do opłat ani przychodu.
Uruchom własny rynek predykcyjny z Kuest z polityką wykonania zrozumiałą dla uczestników: jurysdykcje docelowych odbiorców, precyzyjne zasady rynku i ścieżka rozstrzygnięcia, wymagane ilości transakcji, obsługiwany portfel, informacje o opłatach oraz oddzielne stany akceptacji, skojarzenia i potwierdzenia.