Tokeny YES i NO powstają jako dwa prawa do wypłaty pokryte jednym pełnym zestawem zabezpieczenia. Podział tworzy te prawa, scalenie łączy je z powrotem, a wykup wypłaca środki według zapisanego wyniku. Zakup tokena od innego uczestnika jest oddzielną operacją.
Ten trzeci artykuł serii Jak działają Polymarket i Kuest śledzi aktywa pod interfejsem, giełdą i kontraktami. Jeśli wypłata i cena nadal wydają Ci się zamienne, zacznij od znaczenia ceny na rynku predykcyjnym.
Zacznij od zabezpieczenia, nie od ceny
Użyjmy naszego hipotetycznego pytania: „Czy Obserwatorium A opublikuje temperaturę co najmniej 30,0°C dla Miasta B o 12:00 UTC w Dniu C?”. Załóż, że określono źródło, zaokrąglenia, zasady awaryjne i anulowania. Zamodelujemy standardowy binarny warunek Conditional Tokens Framework (CTF), z YES jako pierwszym i NO jako drugim wynikiem.
Zabezpieczenie to aktywo przeznaczone na pokrycie pozycji. W tym przykładzie jeden zwycięski token wypłaca jedną jednostkę zabezpieczenia; jednostka nie jest automatycznie dolarem. Stablecoin wprowadza ryzyko emitenta, transferu i wartości, nawet gdy interfejs pokazuje symbol dolara.
Wszystkie poniższe salda pomijają opłaty, gas i finansowanie. Używają jednego warunku, jednego aktywa zabezpieczającego i nie mają pozycji nadrzędnej. Te założenia pozwalają uzgodnić każdą jednostkę bez mieszania w obliczeniach aktywów innego rynku.
CTF zwykle używa tokena ERC-20 jako zabezpieczenia i sald ERC-1155 dla wyników. ERC-1155 pozwala jednemu kontraktowi śledzić wiele identyfikatorów tokenów: saldo YES dla pytania o temperaturę i saldo YES dla wyborów to oddzielne aktywa, nawet jeśli oba mają ten sam symbol.
Pełny zestaw ma precyzyjną tożsamość
Przygotowanie warunku rejestruje jego wyrocznię, identyfikator pytania i liczbę wyników. Nie wpłaca zabezpieczenia ani nie tworzy sald wyników dla żadnego użytkownika. W przeanalizowanym kodzie CTF Kuest przygotowanie i podział są oddzielnymi funkcjami.
W CTF identyfikator warunku to keccak256(abi.encodePacked(oracle, questionId, outcomeSlotCount)). Adres wyroczni jest częścią tej tożsamości: ten sam identyfikator pytania przypisany do innej wyroczni tworzy inny warunek.
Kolekcja identyfikuje zbiór wyników z uwzględnieniem ewentualnej kolekcji nadrzędnej. Adres zabezpieczenia i identyfikator kolekcji określają następnie pozycję. Wyprowadzanie kolekcji ma własny algorytm; użyj funkcji pomocniczej kontraktu getCollectionId zamiast wymyślać skrót etykiet. Konstrukcję tę wyjaśnia przewodnik dla deweloperów CTF.
To mapa konstrukcji, nie wzór skrótu kolekcji. Inne zabezpieczenie lub ścieżki kolekcji tworzą inne pozycje.
W naszym binarnym przykładzie podział zbioru to [1, 2]: maski bitowe wybierające osobno pierwszy i drugi wynik. Razem pokrywają wszystkie wyniki bez nakładania się. Kolekcja nadrzędna to 32 bajty zerowe, co oznacza, że podział zaczyna się od zabezpieczenia, a nie od już warunkowej pozycji nadrzędnej.
Dlatego zgodne tytuły nie wystarczają do scalenia. Sprawdź sieć, kontrakt tokena, warunek, zabezpieczenie i ścieżkę kolekcji. YES z Polymarket i NO z Kuest nie tworzą lokalnego pełnego zestawu tylko dlatego, że pytania brzmią podobnie.
Podział: zablokuj 100, otrzymaj po 100 każdego wyniku
Zacznij od 100 jednostek zabezpieczenia. Udany podział przenosi je do kontraktu CTF i emituje dla wywołującego 100 YES oraz 100 NO. Implementacja podziału weryfikuje podział zbioru i wykonuje te zmiany aktywów w jednej transakcji; niepowodzenie cofa operację.
Jedna para odpowiada jednej jednostce zabezpieczenia. Podział tworzy salda obu wyników bez wyboru prognozy.
Portfel ma teraz 200 tokenów wyników, ale tylko 100 pełnych par. Każda para YES–NO jest pokryta jedną jednostką zabezpieczenia. Przy zwykłym wyniku YES jej YES wypłaca jeden, a NO zero; zwykły wynik NO odwraca ten przydział. Podział utworzył zapas pozycji, nie podwoił majątku.
Posiadanie obu stron nie wyraża też prognozy kierunkowej. Animator rynku może wykonać podział, aby uzyskać zapas do oferowania po obu stronach. Późniejsza sprzedaż części YES pozostawia inną ekspozycję, ponieważ portfel nadal posiada odpowiadające im NO; sam podział nie zapewnił kupującego ani nie zagwarantował przychodów z handlu.
Zwykły zakup może zamiast tego przenieść istniejące tokeny między kontami. Jeśli inny uczestnik sprzedaje Ci 10 istniejących YES, jego saldo YES spada, a Twoje rośnie; transfer nie musi emitować nowych YES ani NO. Źródło zapasu i zapłacona za niego cena to różne pytania.
Scalenie: spal 40 par, uwolnij 40 jednostek zabezpieczenia
Przed rozstrzygnięciem możesz scalić równe ilości pasujących wyników. Ze 100 YES i 100 NO scal 40 par: kontrakt spali po 40 każdego tokena i zwróci 40 jednostek zabezpieczenia. Zachowasz 60 YES, 60 NO i 40 jednostek zabezpieczenia dostępnych do wydania.
Spalenie pasujących par uwalnia ich pokrycie. Pozostałe salda wyników nie są spalane ani wypłacane.
Ten rejestr śledzi tylko nasz portfel i pokrycie przypisane jego pełnym zestawom; nie jest całym saldem kontraktu. Opłaty, gas i finansowanie nadal pomijamy.
Salda portfela podano jako zabezpieczenie / YES / NO.
Etap | Salda portfela | Pokrycie |
|---|---|---|
| Początek | 100 / 0 / 0 | 0 |
| Podział 100 | 0 / 100 / 100 | 100 |
| Scalenie 40 | 40 / 60 / 60 | 60 |
| Scalenie pozostałych 60 | 100 / 0 / 0 | 0 |
Ostatni wiersz to jeden z możliwych następnych kroków, a nie krok wykonywany przed poniższym przykładem wykupu. Przywraca początkowe salda portfela przed kosztami, pokazując zachowanie wartości, a nie zysk.
Przy 60 YES i tylko 20 pasujących NO możesz scalić najwyżej 20 par. Pozostałe 40 YES nadal ma ekspozycję na wynik. Pojedynczy YES nie może uwolnić pełnej jednostki przed rozstrzygnięciem, ponieważ nie pokrywa wyniku NO.
Implementacja scalenia nie wymaga wyniku wypłaty. Ponowne połączenie pełnego zestawu działa przed rozstrzygnięciem; funkcja nie jest ograniczona do tego okresu. Korzysta z pokrycia pary zamiast szukać kupującego w arkuszu zleceń.
Wykup: użyj wyniku, nie ostatniej ceny
Wróćmy do wcześniejszego stanu z 40 jednostkami zabezpieczenia i po 60 każdego tokena. Jeśli zapisany wynik to YES, wykup tych wybranych sald wypłaci 60 jednostek zabezpieczenia za YES i zero za NO. Portfel osiągnie 100 jednostek zabezpieczenia przed kosztami; wykupywane tokeny zostaną spalone.
Portfel posiadający tylko te 60 YES otrzymałby tę samą wypłatę 60 jednostek za YES. Wykup nie wymaga od właściciela dostarczenia również NO. To kluczowa różnica wobec scalenia przed rozstrzygnięciem: zapisany wynik określa, które pojedyncze prawa do wypłaty są wypłacane.
W przeanalizowanej funkcji wykupu kwota dla każdej wybranej pozycji to jej saldo pomnożone przez odpowiedni licznik wypłaty i podzielone przez mianownik. Mianownik jest sumą zapisanych liczników. Wybór pozycji wykupuje całe jej saldo w tej funkcji CTF; nie ma argumentu częściowej kwoty.
Wpływy zabezpieczenia ze 100 tokenów każdego wyniku, przed kosztami. Przypadek 50/50 to możliwość zwykłego CTF, a nie obietnica ani obsługiwany wynik NegRisk.
Dla 100 każdego tokena [1, 0] wypłaca 100 za YES / 0 za NO, a [0, 1] wypłaca 0 za YES / 100 za NO. Obsługiwana zwykła wypłata CTF [1, 1] ma mianownik 2 i wypłaca po 50 każdej stronie. To wpływy zabezpieczenia, nie zysk netto; koszty nabycia nadal mają znaczenie.
Ta możliwość ułamkowej wypłaty nie jest uniwersalną obietnicą zwrotu przy anulowaniu. Zasady rynku i podmiot rozstrzygający muszą dopuszczać dany wynik. Powiązane wydarzenie NegRisk potrzebuje własnych obsługiwanych zasad wypłat i odzyskiwania środków; nie zakładaj, że stosuje się zwykły wariant awaryjny rynku binarnego.
Kontrakt liczy w całkowitych jednostkach bazowych i zaokrągla dzielenie w dół. Jeśli token zabezpieczenia ma sześć miejsc dziesiętnych, 100 jednostek oznacza 100000000 jednostek bazowych; jedna jednostka bazowa przy połowicznej wypłacie zaokrągla się do zera. Wartości dziesiętnych z interfejsu nigdy nie należy przekazywać jako surowych liczb całkowitych kontraktu.
Osiągnięcie godziny zakończenia rynku nie ustala wypłaty. Wykup wymaga zapisanego niezerowego mianownika wypłaty; wyrocznia i jej skonfigurowany proces muszą najpierw dostarczyć wynik. Może to wprowadzać czas oczekiwania nawet po zakończeniu handlu.
Sprzedaż i wykup to różne sposoby wyjścia
Sprzedaż wymaga możliwego do wykonania zainteresowania kupnem. Przenosisz tokeny wyników do kupującego po uzgodnionej cenie, z uwzględnieniem dostępnej ilości, kosztów wykonania i udanego rozrachunku. Może to zamknąć pozycję przed wynikiem, ale wyświetlany punkt środkowy nie jest dostępną ofertą kupna.
Sprzedaż wymaga kupującego i ceny możliwej do wykonania. Wykup wymaga zapisanego wyniku i właściwej ścieżki kontraktu.
Wykup używa zapisanej wypłaty i odpowiedniej ścieżki kontraktu po rozstrzygnięciu. Nie wymaga nowego kupującego w arkuszu. Zakup po 0,60 zakończony zwycięską wypłatą jednej jednostki daje 0,40 zysku brutto na token; przegrany wynik daje stratę 0,60, w obu przypadkach przed kosztami.
Zakup obu wyników poniżej ich wartości scalenia daje podstawę do spreadu brutto dopiero po faktycznym wykonaniu równych ilości w tym samym pełnym zestawie. Niewykonane części strategii, błędne identyfikatory, opłaty, uprawnienia, nieudana transakcja i ryzyko zabezpieczenia mogą wymazać spread lub pozostawić ekspozycję kierunkową. Sama oferta nie jest ukończoną strategią.
Co zmienia Kuest: kontekst twórcy towarzyszy pozycjom
Kuest zachowuje te mechanizmy aktywów CTF i rozszerza przygotowanie warunku o adres twórcy oraz odwołanie do zewnętrznych metadanych. Jego funkcja aktualizacji metadanych ogranicza aktualizacje do twórcy lub administratora i zapisuje stare odwołanie, nowe odwołanie oraz aktualizującego.
Dla operatora tworzy to na poziomie kodu możliwość powiązania warunku z twórcą i śledzenia zmian odwołań do metadanych. Nie przechowuje pełnego dokumentu rynku w rejestrze CTF, nie zamraża każdej wyświetlanej zasady ani nie ustala wypłaty. Operatorzy nadal potrzebują dostępnych dokumentów i jasno wskazanej ścieżki rozstrzygnięcia.
Publiczny przewodnik CTF rozdziela operacje podziału, scalenia i wykupu rejestru pozycji. Adapter NegRisk to inna ścieżka kontraktu; sprawdź jego opublikowany interfejs i zabezpieczenie przed próbą tej samej operacji na zapasie pozycji.
Uprawnienia zależą od tej ścieżki: podział wymaga uprawnienia do wydawania zabezpieczenia dla właściwego kontraktu CTF lub adaptera. Scalenie i wykup przy ujemnym ryzyku wymagają też uprawnienia adaptera do obsługi pozycji CTF. Zgody na handel na giełdzie nie uprawniają automatycznie do tych operacji na zapasie.
Kontrola wersji na 30 października 2026: aktualna dokumentacja zarządzania pozycjami Polymarket odróżnia adaptery zabezpieczenia CTF od Router i PositionManager w Protocol V2. Numer wersji lub podobna nazwa metody nie dowodzą zgodności z inną platformą. Używaj udokumentowanej ścieżki właściwej dla danej pozycji.
Powyższe wyjaśnienia CTF Kuest można sprawdzić w jego publicznie zweryfikowanym kontrakcie Polygon. Nie ustalają one aktualnego zabezpieczenia, uprawnień ani podmiotu rozstrzygającego dla każdego rynku w katalogu. Przed włączeniem operacji na zapasie potwierdź te szczegóły i pokazuj podział, scalenie oraz wykup jako oddzielne przepływy aktywów.
Planujesz takie doświadczenie dla swoich odbiorców? Utwórz własny rynek predykcyjny z Kuest i przygotuj zasady rynku, jurysdykcje docelowych odbiorców oraz wymagania płynnościowe potrzebne do wyboru właściwej konfiguracji operacyjnej.