Bot API Polymarket potrzebuje jasnej odpowiedzi na trudne pytanie operacyjne: co zrobić po wysłaniu zlecenia bez otrzymania użytecznej odpowiedzi? Zlecenie mogło być odrzucone, przyjęte, częściowo wykonane lub zakończone. Lokalny limit czasu nie odróżnia tych możliwości.
Projektowanie dla tej niepewności zmienia architekturę. Bot potrzebuje trwałych zapisów przed transmisją, ograniczonych uprawnień do nowej ekspozycji i odzyskiwania badającego pierwotny zamiar. Musi też nadal obserwować konto po zatrzymaniu tworzenia nowych zleceń. Wstrzymanie decyzji i utrata widoczności są różnymi czynnościami.
Poradnik opisuje projekt edukacyjny dla kontekstu Polymarket International. Polymarket US ma oddzielne interfejsy konta i platformy. Wszystkie limity, ilości, ceny i scenariusze awarii są wymyślonymi przykładami. Projekt nie ustala przewagi strategii ani nie upoważnia żadnego rzeczywistego działania konta.
Zdefiniuj ograniczonego bota API Polymarket
Ograniczony bot API Polymarket ma jawne limity uprawnień: konto, którego może używać, rozważane kontrakty, tworzone rodzaje zleceń i dodawaną ekspozycję. Limity powinny być egzekwowalne poza komponentem prognozowania, by błędny sygnał nie mógł po prostu ogłosić własnego zwolnienia.
Wymyślony bot może obserwować wszystkie rynki listy badawczej, lecz proponować zlecenia tylko dla dwóch zatwierdzonych kontraktów. Może mieć limit trzydziestu udziałów na zdarzenie i oddzielne maksymalne zobowiązanie zakupu. Szerokość obserwacji nie implikuje równoważnych uprawnień handlowych.
Wcześniejszy poradnik o API bota Polymarket wyjaśnia możliwości i sposoby niepowodzenia. Stosuj rozróżnienie w projekcie: dostęp do danych, tworzenie zleceń, anulowanie i operacje portfela są oddzielnymi możliwościami. Funkcja należy do programu tylko przy jasnym celu i granicy upoważnienia.
Oddzielaj prognozę od wykonawcy
Komponent prognozowania powinien tworzyć propozycję z kontraktem, kierunkiem, pożądaną ilością, maksymalnym kosztem i wygaśnięciem rozumowania. Nie powinien bezpośrednio posiadać nieograniczonych uprawnień podpisywania. Oddzielna bramka decyzji może weryfikować propozycję względem aktualnego stanu konta i limitów operacyjnych.
Rozdzielenie pomaga nawet przy jednej osobie obsługującej cały system. Czyni zachowanie programu możliwym do sprawdzenia: propozycja wyjaśnia rozważenie transakcji, a bramka jej dopuszczenie lub odmowę. Odrzucona propozycja pozostaje w zapisie badawczym bez tworzenia zlecenia.
Wykonawca powinien przyjmować tylko w pełni określoną zatwierdzoną instrukcję. Nie powinien improwizować większej ilości lub szerszej ceny z powodu braku realizacji pierwszej próby. Zmiany modyfikują decyzję ekonomiczną i wymagają świeżej walidacji względem konta i bieżących dowodów strategii.
Zachowuj jeden zamiar ekonomiczny między próbami
Zamiar ekonomiczny opisuje pożądaną zmianę konta, a próba transportu jedną próbę przekazania instrukcji. Mylenie ich jest częstym źródłem duplikacji. Limit czasu i nowe żądanie nie powinny automatycznie stawać się drugą niezależną chęcią kupna tej samej ilości.
Nadaj zamiarowi stały lokalny identyfikator i zapisz zatwierdzone warunki. Łącz każde żądanie, odpowiedź, identyfikator zlecenia i obserwację transakcji z zamiarem przy znanej zależności. Jeśli późniejsza instrukcja go zastępuje, zapisz relację jawnie zamiast nadpisywać dawną historię.
Poradnik o handlu API Kalshi daje porównanie uzgadniania konta w innym kontekście API. Ogólne rozróżnienie zamiaru i próby się przenosi, ale mechanizmy wyszukiwania i obsługi duplikatów różnią się. Bot musi weryfikować semantykę rzeczywistej platformy zamiast zakładać uniwersalną idempotencję.
Najpierw zapisuj trwały dziennik zamiarów
Trwały dziennik zamiarów musi istnieć przed możliwością dotarcia działania do platformy. Inaczej awaria po transmisji może pozostawić aktywne zlecenie bez lokalnego wyjaśnienia. Zapis po odpowiedzi jest zbyt późny dla tego konkretnego okna awarii.
Zapisuj konto, kontrakt, stronę, ilość, limit ceny, czas życia, wersję strategii, wynik upoważnienia i rezerwację. Dodaj tożsamość żądania lub odniesienie podpisanego zlecenia potrzebne do odzyskania bez ujawniania sekretów w zwykłych dziennikach. Dziennik powinien umożliwiać czytanie historii po wznowieniu procesu.
Wpis dziennika nie dowodzi wysłania zlecenia. Zachowuj oddzielne etapy przygotowania, rozpoczęcia transmisji i obserwacji odpowiedzi. Pomagają zawężać niepewność, ale nie eliminują każdej niejednoznaczności granicy sieci. Uczciwy stan odzyskiwania może nadal być nieznany do uzyskania dowodów konta.
Rezerwuj możliwości atomowo
Dwie propozycje mogą nadejść blisko siebie i zobaczyć ten sam pozorny dostępny budżet. Jeśli obie zatwierdzono niezależnie przed zapisem rezerwacji, łączna ekspozycja może przekroczyć limit. Bramka konta potrzebuje jednej spójnej operacji sprawdzania i rezerwowania możliwości.
Załóżmy wymyślony limit zdarzenia trzydziestu udziałów. Konto posiada dwanaście, a istniejące aktywne zlecenie może dodać osiem. W limicie mieści się tylko kolejnych dziesięć. Jeśli dwie nowe propozycje żądają po dziesięć i czytają tę samą starą migawkę, zatwierdzenie obu dopuściłoby łącznie czterdzieści udziałów.
Wspólny zapis rezerwacji zapobiega wyścigowi. Druga propozycja musi zobaczyć pierwszą rezerwację lub czekać na ustalenie wyniku. Oddzielne procesy robocze, strategie lub interfejsy nie tworzą oddzielnych możliwości ekonomicznych przy tym samym koncie i limicie zdarzenia.
Zachowuj rezerwacje podczas niepewności
Nieznane zgłoszenie nadal może stać się ekspozycją. Zwolnienie rezerwacji tylko przez lokalny limit czasu pozwala innej propozycji wydać tę samą zdolność. Zachowuj ostrożne zobowiązanie do rozstrzygnięcia pierwotnego zamiaru lub ustalenia bezpiecznej alternatywy przez udokumentowaną politykę.
W przykładzie trzydziestu udziałów niepewne zgłoszenie dziesięciu zużywa pozostałą zdolność nowych wejść. Bot może nadal czytać dane rynku, uzgadniać konto i przetwarzać dozwolone polityką działania ograniczające ryzyko. Nie powinien traktować nieznanej ilości jako zera tylko dla aktywności.
Zachowanie powinno być widoczne operatorowi. Jasny status, taki jak dziesięć udziałów zarezerwowano do uzgodnienia zgłoszenia, wyjaśnia wstrzymanie nowych propozycji. Bez wyjaśnienia operator może wznowić bota lub usunąć rezerwację, nieumyślnie pokonując kontrolę chroniącą konto.
Używaj aktualnej konfiguracji konta i portfela
Bot musi weryfikować bieżącego podpisującego, portfel konta, uprawnienia i zgody handlowe przed wykonaniem. Stare przykłady mogą zakładać inne rozwiązanie portfela lub interfejs klienta. Udany dostęp do danych publicznych nie zatwierdza prywatnej ścieżki handlu.
Dokumentacja portfeli i uwierzytelniania Polymarket jest aktualnym odniesieniem konfiguracji konkretnego konta. Utrzymuj sekrety w autoryzowanym środowisku podpisywania oddzielnie od zwykłych dzienników i zapisów badań. Odzyskiwanie powinno polegać na identyfikatorach i dowodach konta, a nie ujawnianiu danych uwierzytelniających do diagnostyki błędu żądania.
Przechowuj wersję klienta i konfigurację obok zapisów operacyjnych. Jeśli aktualizacja zmienia konstrukcję żądania lub interpretację odpowiedzi, bot powinien przejść odpowiednie przypadki odzyskiwania przed wznowieniem uprawnień. Zgodność jest zachowaniem do sprawdzenia, a nie cechą implikowaną znajomą nazwą pakietu.
Diagnozuj punkt awarii
Nieudany proces może zatrzymać się przed upoważnieniem, przed transmisją, po transmisji lub podczas uzgadniania. Miejsca mają różne konsekwencje. Lokalnie odrzucona propozycja nie tworzy zlecenia. Żądanie, którego transmisja nie zaczęła się, może być bezpiecznie ponowione w ramach tego samego zamiaru. Żądanie o nieznanym zdalnym wyniku potrzebuje badania.
Zapisuj informacje czasu i stanu wystarczające do rozróżnienia przypadków bez udawania większej wiedzy, niż wspierają dowody. Dziennik może mówić o rozpoczęciu wysyłania przez klienta o wskazanej porze i późniejszej utracie połączenia. Nie może wywnioskować, że platforma nigdy nie otrzymała bajtów, wyłącznie z lokalnego błędu.
Używaj kategorii błędów prowadzących do konkretnych działań. Błąd uwierzytelniania skłania do przeglądu danych lub konta. Nieprawidłowy krok ceny do przeglądu ograniczeń rynku. Nieznane zgłoszenie do uzgadniania konta. Ogólna obsługa ponawiaj wszystko ignoruje różnicę poprawiania żądania i przypadkowego powielania prawidłowego.
Badaj dowody zleceń i transakcji
Odzyskiwanie nieznanego zgłoszenia powinno szukać dowodów pierwotnego zamiaru identyfikatorami i interfejsami platformy. Bieżące otwarte zlecenia, indywidualne zapisy zleceń i transakcje konta odpowiadają na różne części pytania. Brak elementu na jednej liście nie zawsze wystarcza do dowodu braku wykonania.
Poradnik zarządzania zleceniami Polymarket opisuje uwierzytelnione odczyty śledzenia zleceń i transakcji konta. Bot powinien łączyć odpowiednie dowody z trwałym dziennikiem. Powinien też zachowywać czas zapytania i ograniczenia pokrycia, takie jak niepełne stronicowanie lub rozłączony strumień.
Po ustaleniu stanu aktualizuj rezerwację i zapis pozycji razem. Aktywne zlecenie zachowuje odpowiednie zobowiązanie. Potwierdzone odrzucenie może je zwolnić. Wykonanie zmienia pozycje i koszty. Przy sprzecznych dowodach zachowuj jawną niepewność i kieruj przypadek do odpowiedzialnego operatora.
Polecaj i zarabiaj USDC
Polecaj i zarabiaj USDCNasz program partnerski wypłaca prowizje w czasie rzeczywistym.
Nie wywodź odrzucenia z pustej listy otwartych zleceń
W pełni zrealizowane zlecenie może już nie pojawiać się w otwartych. Natychmiastowe zlecenie o anulowanej niezrealizowanej ilości też może nie zostawić oczekującego wpisu. Patrzenie tylko na listę otwartych może więc błędnie klasyfikować pełne lub częściowe wykonanie jako żądanie nigdy nieistniejące.
Bot musi sprawdzać inne odpowiednie zapisy przed decyzją o braku wpływu pierwotnego zamiaru. To szczególnie ważne przy zleceniu możliwym do natychmiastowego wykonania w chwili wysłania. Zniknięcie aktywnej reszty nie implikuje braku nabytych udziałów.
Użyteczny widok operatora oddziela trzy pytania: dalszą aktywność zlecenia, wystąpienie transakcji i uzgodnienie wynikowych zmian konta. Odrębność zapobiega traktowaniu wizualnie pustego panelu zleceń jako dowodu braku pozycji konta.
Poprawnie uzgadniaj natychmiastowe częściowe realizacje
Rodzaj zlecenia określa los niezrealizowanej ilości. Aktualna dokumentacja Polymarket definiuje FAK jako realizowanie dostępnej ilości i anulowanie reszty. Częściowe wykonanie FAK pozostawia pozycję, lecz nie pozostawia pozostałych żądanych udziałów w arkuszu.
W wymyślonym przypadku żądanie FAK dziesięciu udziałów daje cztery wykonane po 0,43 USD i sześć anulowanych. Cena zakupu wynosi 1,72 USD przed opłatami. Po ustaleniu wykonania i statusu reszty bot powinien zapisać cztery udziały i zwolnić rezerwację innych sześciu, z uwzględnieniem rzeczywistych dowodów konta.
Oczekujące zlecenie dziesięciu udziałów z czterema wykonanymi i sześcioma aktywnymi jest inne. Zachowuje możliwą przyszłą ekspozycję. Model stanów bota nie powinien zastępować jednym ogólnym statusem częściowe zarówno wykonanej ilości, jak i końcowego lub trwającego stanu reszty.
Obsługuj wyścig anulowania
Żądanie anulowania może nakładać się na realizację. Bot powinien oczekiwać uzgodnienia obu zamiast zakładać natychmiastowe usunięcie ekspozycji przez zamiar anulowania. Udane anulowanie może dotyczyć pozostałej ilości po dodatkowym wykonaniu.
Załóżmy sześć aktywnych udziałów przy rozpoczęciu anulowania i wykonanie kolejnych dwóch przed usunięciem reszty. Bot musi dodać te dwa do pozycji i zwolnić tylko rzeczywiście zakończone zobowiązanie. Propozycja zastępująca powinna używać wynikowego stanu konta, a nie ilości widocznej przed wyścigiem.
Wcześniejszy poradnik o bocie automatycznego handlu Polymarket omawia pauzę i wznowienie. Anulowanie jest składnikiem procesu, a nie uniwersalnym resetem. Zatrzymanie nowych decyzji, wycofanie anulowalnych zleceń i uzgodnienie istniejących pozycji są oddzielnymi obowiązkami mogącymi kończyć się w różnych chwilach.
Używaj jednej miarodajnej ścieżki wysyłania
Wiele procesów roboczych może zbierać dane lub oceniać niezależne hipotezy, ale wysyłanie zleceń potrzebuje skoordynowanego uprawnienia. Jeśli dwóch wykonawców działa na tym samym zamiarze bez wspólnego mechanizmu przydziału, obaj mogą go wysłać po wznowieniu lub opóźnionej wiadomości.
Wybierz jasną regułę odpowiedzialności aktywnego wykonawcy i uwidaczniaj zmiany. Nowy proces nie powinien zakładać zatrzymania starego tylko przez spóźniony sygnał aktywności. Potrzebuje mechanizmu zapobiegającego równoczesnemu użyciu tego samego uprawnienia lub polityki wstrzymującej do ustalenia odpowiedzialności.
Nie chodzi o złożoność dla niej samej. Bot jednego procesu może mieć prosty projekt przy jawnym zachowaniu wznowienia. Wraz z rozwojem zachowuj tę samą gwarancję ekonomiczną: jeden zatwierdzony zamiar nie może stać się wieloma niezależnymi zleceniami, ponieważ kilka komponentów uważa się za odpowiedzialne za ukończenie.
Odbuduj stan przed wznowieniem po restarcie
Wznowienie powinno zaczynać od obserwacji i uzgadniania. Wczytaj nierozstrzygnięte zamiary, sprawdź bieżące zlecenia i transakcje, zweryfikuj tożsamość konta i porównaj odzyskane pozycje z lokalnym zapisem. Nowa ekspozycja powinna czekać do rozstrzygnięcia rozbieżności lub jawnej obsługi według polityki.
Nie odtwarzaj każdego niedokończonego wpisu jako nowego zlecenia. Część może odpowiadać zdalnym wykonaniom o utraconych odpowiedziach. Inne mogły nigdy nie opuścić procesu. Ścieżka odzyskiwania musi klasyfikować dowodami zamiast traktować brak lokalnej flagi zakończenia jako zezwolenie ponownego wysłania.
Poradnik o bocie API Kalshi opisuje przypadki akceptacyjne innej platformy. Używaj porównania do wyostrzenia pytań odzyskiwania, utrzymując oddzielne identyfikatory i zachowanie żądań platform. Ten sam scenariusz awarii może wymagać różnych wyszukiwań w różnych interfejsach.
Utrzymuj obserwację przy wstrzymanych decyzjach
Bot wstrzymujący nowe wejścia zwykle powinien kontynuować odczyty potrzebne do rozumienia konta. Wyłączenie każdego komponentu może utrudnić rozstrzygnięcie niepewnego stanu i pozbawić operatora bieżących informacji o aktywnych zleceniach lub pozycjach.
Definiuj tryby działania przez możliwości. Tryb tylko obserwacji może odświeżać dane rynku i konta. Tryb uzgadniania może badać wcześniejsze działania. Tryb anulowania może dopuszczać konkretne autoryzowane operacje zmniejszające ryzyko. Tryb handlowy może tworzyć nową ekspozycję w limitach.
Każdy tryb powinien mieć jasne warunki wejścia i wyjścia. Sam powrót sieci nie powinien automatycznie przywracać handlu przy nierozstrzygniętych zamiarach. Z drugiej strony awaria źródła badań nie musi blokować uzgadniania konta zdrowym prywatnym interfejsem. Szczegółowe granice możliwości pomagają botowi pozostać użytecznym bez przekraczania uprawnień.
Twórz wiadomości dla operatora, które ułatwiają działanie
Operator powinien otrzymywać zwięzłe wyjaśnienie nierozstrzygniętego stanu: konto, kontrakt, pierwotny zamiar, możliwą ekspozycję, ostatnie zweryfikowane dowody i następny krok badania. Sam ślad stosu nie wyjaśnia ekonomicznej konsekwencji awarii.
Unikaj żądania wyboru ponów lub zignoruj bez kontekstu. Dostępne działania mogą obejmować zapytanie o pierwotne zlecenie, sprawdzenie transakcji konta, utrzymanie pauzy lub eskalację sprzecznego zapisu. Bot powinien zachowywać skutek każdego działania w dzienniku.
Przegląd platformy może porządkować interfejs. Poradnik o platformie handlowej Polymarket oddziela kontrolę konta, kształtowanie ceny i rozliczenie. Rozróżnienia powinny być widoczne podczas awarii, gdy czytelnik szczególnie łatwo myli działający ekran danych rynku z w pełni uzgodnionym kontem handlowym.
Testuj awarie na granicy sieci
Użyteczne ćwiczenie akceptacyjne przerywa proces w kilku punktach: po trwałym zapisie zamiaru, podczas transmisji, po zdalnym przyjęciu przed lokalnym zapisem odpowiedzi i po nadejściu realizacji przed aktualizacją widoku pozycji. Każda przerwa powinna prowadzić do odzyskiwalnego lub jawnie nierozstrzygniętego stanu.
Oczekiwanym wynikiem nie zawsze jest automatyczna kontynuacja. Część przypadków powinna kończyć się wstrzymaniem działania, ponieważ dostępne dowody nie pozwalają bezpiecznie ustalić stanu konta. Test powinien weryfikować zachowanie rezerwacji, unikanie podwójnej ekspozycji i informacje wystarczające do badania przez operatora.
Uwzględniaj powielone i opóźnione wiadomości w odtwarzaniu. Ponowne przetworzenie znanej transakcji nie powinno dodawać ilości dwukrotnie. Późne odrzucenie powinno wiązać się z poprawnym żądaniem zamiast nadpisywać inny udany zamiar. Przypadki testują model zapisów sensowniej niż wielokrotne zwykłe zlecenia w idealnych warunkach.
Przeglądaj ekonomiczny zapis bota
Miary operacyjne powinny obejmować wiek nierozstrzygniętych zamiarów, opóźnienie uzgadniania, powielone obserwacje i rozbieżności rezerwacji. Sam odsetek udanych żądań może wyglądać zdrowo przy błędnym zapisie konta. Mała liczba niepewnych zgłoszeń może znaczyć więcej niż tysiące udanych publicznych odczytów.
Wcześniejszy poradnik o API bota rynków predykcyjnych daje szerszą perspektywę architektury. Przeglądaj bota na granicach: dowody wejścia, nadane uprawnienia, wysłaną instrukcję i zwrócony stan konta. Granice wskazują, gdzie błąd zmienił znaczenie lub przekroczył zakres.
Oddzielaj ocenę strategii. Bot może wiernie wykonywać słabą strategię, a obiecująca prognoza może zostać podważona niewiarygodnym wykonaniem. Dziennik ekonomiczny pozwala badać oba pytania bez przypisywania każdego wyniku najbardziej widocznemu komponentowi lub ostatniemu komunikatowi błędu.
Utrzymuj bota API Polymarket w granicach dowodów
Dobrze ograniczony bot wie, kiedy ma dość dowodów do działania, a kiedy tylko do badania. Trwały dziennik łączy jeden zamiar z próbami, zleceniami i transakcjami. Rezerwacje uwzględniają możliwą ekspozycję do rozstrzygnięcia niepewności.
Zacznij od wąskich uprawnień i pełnej historii odzyskiwania. Weryfikuj konfigurację konta aktualną dokumentacją, koordynuj uprawnienie wysyłania i testuj przerwy przed rozszerzaniem zakresu. Wyjaśniaj pauzy i utrzymuj obserwację potrzebną do ich rozstrzygnięcia.
Wynikiem jest program o zachowaniu odtwarzalnym przy zwykłej pracy i awarii. Nie zamienia niepewnych prognoz w pewne wyniki. Precyzuje twierdzenie operacyjne: bot powinien wykonywać tylko ograniczone działania, do których prób go upoważniono, a następnie ustalać rzeczywisty rezultat przed uznaniem konta za gotowe do następnej decyzji.