Bot handlowy Base: kompletny model działania

Bot handlowy Base: określ umowę operacyjną

Przed wyborem wskaźników opisz zwykłym językiem umowę operacyjną strategii. Wskaż portfel, zbiór kwalifikujących się tokenów, dozwolone ścieżki, maksymalną ekspozycję, zamierzony sposób utrzymywania pozycji i okoliczności wymagające wstrzymania. Stwierdzenia te stają się standardem oceny zachowania oprogramowania.

Reguła taka jak kupuj silne tokeny jest zbyt niejednoznaczna, aby odpowiedzialnie ją wdrożyć. Użyteczniejszy opis wskazuje, jakie obserwacje ustalają siłę, jak stare mogą być te obserwacje i ile kapitału decyzja może zarezerwować. Wskazuje także, co dzieje się przy braku wymaganej obserwacji.

Umowa powinna odróżniać obowiązkowe ograniczenia od preferencji. Strategia może ponownie rozważyć preferowaną cenę wejścia, natomiast limit ekspozycji konta nie powinien znikać dlatego, że sygnał staje się atrakcyjniejszy. Rozdzielenie ułatwia późniejsze diagnozowanie błędów: recenzenci mogą zapytać, czy błędna była reguła, czy proces wykonania naruszył instrukcje.

Zidentyfikuj sieć przed aktywem

Adres tokena ma znaczenie w konkretnej sieci. Ten sam znajomy symbol może opisywać niepowiązane kontrakty, a adres skopiowany z innego środowiska nie ustala rynku Base. Zachowuj identyfikator sieci obok każdego zapisu tokena, puli, ścieżki i transakcji.

Dokumentacja Base opisuje dostęp JSON-RPC i różne widoki stanu, w tym wstępnie potwierdzone Flashblocks. Punkt końcowy i żądany znacznik bloku należą więc do zapisu dowodów, zamiast być traktowane jak zamienna infrastruktura. Przegląd RPC Base.

Przy uruchomieniu porównaj tożsamość zgłaszaną przez punkt końcowy ze skonfigurowaną siecią. Niezgodność powinna blokować handel, zanim jakakolwiek obserwacja konta lub rynku wpłynie na decyzję. Ta sama zasada dotyczy środowisk testowych: udana próba z aktywami testowymi nie weryfikuje tokena produkcyjnego, dostępnej płynności ani rzeczywistego finansowania konta.

Traktuj odkrywanie jako tworzenie listy kandydatów

Źródło danych do odkrywania odpowiada na pytanie, które zdarzenia zasługują na uwagę. Nie odpowiada na pytanie, które aktywa należy kupić. Nowe kontrakty, zdarzenia pul, transfery i zwiększona aktywność mogą generować kandydatów bez ustalenia obsługiwanej ścieżki lub akceptowalnego profilu ryzyka.

Zapisuj powód dodania każdego kandydata do kolejki. Może to być zweryfikowane zdarzenie puli lub zmierzona zmiana aktywności w określonym oknie. Zachowanie powodu pozwala recenzentowi strategii odróżnić słabą regułę odkrywania od późniejszego problemu wyceny lub wykonania.

Kandydaci powinni wygasać, gdy ich dowody przestają być istotne. Token odkryty podczas awarii może nadal zasługiwać na badanie, lecz nie powinien po cichu być traktowany tak samo jak świeże zdarzenie. Artykuł o skanerze memecoinów Solany wyjaśnia ogólną różnicę między znajdowaniem kandydatów a zatwierdzaniem transakcji, choć szczegóły kont i wykonania są inne.

Buduj migawkę rynku z informacją o pochodzeniu

Dla każdej decyzji zbieraj obserwacje rzeczywiście dostępne w danej chwili. Uwzględnij tożsamość tokena, stan ścieżki, dowody płynności, istotną aktywność, zasoby portfela oraz czas lub blok związany z każdą pozycją. Zestaw pojedynczo wiarygodnych liczb może nadal wprowadzać w błąd, gdy obserwacje opisują różne momenty.

Reguły aktualności powinny odzwierciedlać podejmowaną decyzję. Opis tokena może pozostawać użyteczny dłużej niż kwotowanie ceny. Dane salda konta mogą wymagać natychmiastowego odświeżenia po transakcji, podczas gdy niezmieniony opis strategii tego nie wymaga. Przypisuj wymagania aktualności świadomie, zamiast stosować jeden uniwersalny czas ważności.

Gdy obserwacje są sprzeczne, zachowuj widoczność tej sprzeczności. Jeżeli dwaj dostawcy nie zgadzają się co do transakcji lub salda, wybór wartości pozwalającej na kolejny zakup nie jest uzgadnianiem stanu. Strategia powinna mieć określony stan ograniczonego działania podczas badania dowodów.

Reguły strategii bota Base potrzebują jawnych danych wejściowych

Reguły strategii bota handlowego Base powinny być zapisane tak, aby inna osoba mogła odtworzyć decyzję z zachowanych danych wejściowych. Określ okna historyczne, obsługę brakujących danych, progi i jednostki porównań. Średnia krocząca obliczona z obserwacji transakcji nie musi być równoważna średniej obliczonej z cen pobieranych w równych odstępach.

Rozważ hipotetyczną regułę wymagającą aktywności powyżej progu i kwotowania mieszczącego się w maksymalnym wpływie na cenę. Warunek aktywności identyfikuje zainteresowanie; warunek kwotowania ogranicza wykonanie. Połączenie ich w jeden nieprzejrzysty wynik utrudnia zrozumienie, dlaczego propozycję przyjęto lub odrzucono.

Zachowuj również odrzucone propozycje. Strategia generująca wiele atrakcyjnych sygnałów, ale odrzucająca większość z powodów płynności lub zasobów, zachowuje się inaczej niż surowe wyniki jej wskaźnika. Ocena wyłącznie wykonanych transakcji ukrywałaby związek między częstotliwością sygnałów a praktyczną kwalifikacją do handlu.

Rezerwuj kapitał przed przygotowaniem transakcji

Wiele strategii może obserwować to samo dostępne saldo. Bez wspólnego mechanizmu rezerwacji każda może uznać, że cała kwota jest dostępna dla jej propozycji. Rezerwacje łączą zamiar strategii z ograniczonymi zasobami konta przed rozpoczęciem przygotowania transakcji.

Załóżmy, że fikcyjne konto ma 500 jednostek waluty wydatków, z czego 100 zarezerwowano na nierozstrzygnięty zakup, a kolejne 50 celowo pozostaje niedostępne dla strategii. Niezarezerwowana zdolność finansowania strategii wynosi 350 jednostek. Nowa propozycja na 400 jednostek powinna nie przejść kontroli budżetu, choć ostatnie zapisane saldo konta wynosi 500.

Rezerwacje potrzebują przypisania odpowiedzialności i warunków zwolnienia. Odrzucona, niepodpisana propozycja może szybko zwolnić przydział. Przesłana transakcja o niepewnym wyniku nie może bezpiecznie zrobić tego tylko dlatego, że przekroczono czas oczekiwania na odpowiedź. Jej wynik ekonomiczny musi zostać rozstrzygnięty, zanim te same zasoby zostaną przyrzeczone gdzie indziej.

Oddzielaj budżety gazu i inwestycji

Portfel potrzebuje zasobów na transakcje oprócz aktywów przeznaczonych na inwestycje. Wydanie niemal wszystkiego na wejście może pozostawić system bez możliwości wykonania planowanego wyjścia lub niezbędnej obsługi konta. Model budżetu powinien jawnie zachowywać rezerwę operacyjną.

Szacunki gazu są obserwacjami, a nie nieograniczonymi zgodami na wydawanie. Transakcja powinna mieć określoną politykę opłat, a zmiana wykraczająca poza tę politykę powinna powodować ponowną ocenę. Powtarzane nieudane próby również zużywają zasoby operacyjne i należą do zapisów kosztów strategii.

Budżet ryzyka bota Base powinien obejmować koszt przeprowadzenia całego cyklu pozycji w prawdopodobnych niekorzystnych warunkach. Nie wymaga to udawania, że można przewidzieć każdą przyszłą opłatę. Wymaga uznania, że wejście i późniejsze zarządzanie nim są powiązanymi obowiązkami, a nie niezależnymi kliknięciami przycisków.

Oceniaj rzeczywistą ścieżkę i kwotę

Udane kwotowanie dla małej transakcji nie dowodzi, że znacznie większa transakcja ma równoważne cechy wykonania. Oceniaj proponowaną kwotę na zamierzonej ścieżce, uwzględniając istotne zachowanie tokena i aktywa pośrednie. Zapisuj minimalną akceptowalną ilość otrzymaną i warunki wygaśnięcia propozycji.

Ścieżka może stać się nieodpowiednia między obserwacją a przesłaniem. Płynność może się zmienić, uprawnienia mogą się różnić, a konkurencyjna aktywność może zmienić oczekiwany wynik. Warstwa wykonawcza powinna ponownie sprawdzić istotne ograniczenia w chwili przygotowywania ostatecznego działania.

Oddzielaj kwotowania wyceny od kwotowań wykonania. Widok portfela może używać orientacyjnej ceny do raportowania, podczas gdy proponowana sprzedaż potrzebuje dowodów dotyczących wykonalnej wielkości. Poradnik automatyzacji handlu memecoinami rozwija szerszy związek między sygnałami strategii a pełnymi kosztami wejścia i wyjścia.

Bot Aerodrome w Base potrzebuje takiego porównania dla określonej wielkości między pulami stabilnymi, zmiennymi i skoncentrowanymi, uwzględniającego wszystkie aktywa pośrednie i pozostałe salda.

Precyzyjnie określaj autoryzację

Decyzja o podpisaniu powinna wiążąco określać działanie rzeczywiście zatwierdzone przez użytkownika lub politykę. Istotne pola obejmują sieć, docelowe kontrakty, adresy tokenów, ilości, limity wydatków i warunki wygaśnięcia. Niejasna zgoda na kontynuowanie handlu nie powinna po cichu upoważniać do niepowiązanych uprawnień lub odbiorców.

Zgody dotyczące tokenów zasługują na osobne traktowanie. Uprawnienie kontraktu do wydawania aktywa różni się od wymiany zmieniającej portfel. Aplikacja powinna wyjaśniać zakres zgody i zachowywać informacje wystarczające do jej przeglądu lub cofnięcia w odpowiednich okolicznościach.

Uprawnienie do podpisywania powinno pozostawać oddzielone od niezaufanych opisów rynku, wiadomości czatu i treści zewnętrznych. Te dane wejściowe mogą dostarczać podstaw do ograniczonej propozycji, lecz nie powinny móc zmieniać polityki uprawnień portfela. Granica jest szczególnie ważna, gdy metadane wyświetla się obok elementów sterujących działaniami.

Przedstawiaj przesłanie jako etap niepewności

Po przesłaniu podpisanej transakcji system może otrzymać hash, błąd lub żadnej wiarygodnej odpowiedzi. Żaden z tych wyników komunikacji sam nie opisuje ostatecznego portfela. Zapis transakcji potrzebuje stanu pozwalającego przedstawić pracę przesłaną, lecz nierozstrzygniętą.

Typowym przykładem jest przekroczenie czasu oczekiwania. Ponowienie żądania sieciowego może być właściwe w starannie określonym mechanizmie, lecz skonstruowanie nowego ekonomicznego zakupu bez sprawdzenia pierwszej próby może podwoić ekspozycję. Aplikacja musi zachowywać pierwotny zamiar i tożsamość jego transakcji.

Operator powinien widzieć, co wiadomo, a co pozostaje w toku. Użyteczny komunikat identyfikuje odpowiedni portfel, zarezerwowane zasoby i następny krok uzgadniania stanu. Nie powinien naprzemiennie oznajmiać sukcesu i porażki tylko dlatego, że różne części interfejsu otrzymały różne częściowe obserwacje.

Uzgadniaj salda, aby ustalić pozycję

Gdy dostępne są wystarczające dowody transakcji, porównaj oczekiwane skutki z rzeczywistymi zmianami aktywów i kosztami. Przyjęta transakcja nie oznacza automatycznie otrzymania oczekiwanej liczby tokenów. Nieobsługiwane zachowanie, różnice ścieżki lub błędy księgowania mogą sprawić, że rzeczywisty wynik różni się od propozycji.

Wyobraź sobie przykładowy zakup, na który wydano 80 jednostek oraz 0,20 jednostki przypisanego kosztu za 40 tokenów. Zapisany koszt nabycia wynosi 80,20 jednostki przy tej prostej konwencji księgowania. Jeżeli portfel otrzyma zamiast tego 38 tokenów, pozycja powinna używać tej rzeczywistej ilości, a nie ilości pierwotnie kwotowanej.

Zachowuj pierwotne oczekiwania obok rzeczywistych wartości. Różnica pomaga wyjaśnić jakość wykonania i ujawnia, czy założenia strategii pozostają wiarygodne. Uzgadnianie stanu to także etap, na którym nierozstrzygnięte rozbieżności stają się jawnymi problemami operacyjnymi zamiast niewidocznymi niedokładnościami wykresu.

Projektuj wyjścia równie starannie jak wejścia

Reguła wyjścia potrzebuje własnych wymagań aktualności danych wejściowych, obsługi ścieżki, kontroli salda i uprawnienia do wydawania. Token dostępny wcześniej do kupienia może później nie mieć tej samej dostępnej płynności. Wyświetlany zysk nie gwarantuje więc sprzedaży całej pozycji po tej wartości.

Częściowe wyjścia pozostawiają dalsze obowiązki. Jeżeli zamierzona sprzedaż zamyka tylko część pozycji, pozostała ilość, koszty i przyszła polityka muszą pozostawać aktywne. Oznaczenie strategii jako zakończonej dlatego, że jedna transakcja się powiodła, może pozostawić ekspozycję bez opieki.

Oddzielaj anulowanie od likwidacji pozycji. Wstrzymanie nowych propozycji lub anulowanie nierozstrzygniętego procesu nie musi sprzedawać istniejących aktywów. Interfejs sterowania powinien dokładnie wyjaśniać, jakie działania zachodzą, jakie pozycje pozostają i jakie dalsze decyzje wymagają autoryzacji człowieka lub polityki.

Odtwarzanie pracy bota Base zaczyna się przed awarią

Odtwarzanie pracy bota Base zależy od zapisów utworzonych przed awarią. Trwale zachowuj decyzje, rezerwacje, tożsamości podpisanych transakcji i obserwowane wyniki. Program pamiętający tylko bieżący ekran nie może odtworzyć niedokończonej pracy po restarcie.

Przy odtwarzaniu najpierw ustal, co wydarzyło się podczas nieobecności procesu. Odśwież istotny stan portfela, zbadaj nierozstrzygnięte transakcje i porównaj obserwacje z ostatnimi utrwalonymi zapisami. Nowe decyzje strategii powinny zaczekać, aż uzgodnienie ustali spójny punkt początkowy.

Odtwarzanie potrzebuje także granicy. Jeżeli system nie może automatycznie rozwiązać niespójności, powinien wyjaśniać, jakich dowodów brakuje, i pozostawać w ograniczonym trybie. Zgadywanie, że stara transakcja się nie powiodła, ponieważ niewygodnie ją zbadać, nie jest niezawodną polityką restartu.

Mierz pełny wynik

Raportowanie wyników powinno odróżniać zrealizowane wyniki handlu, pozostałe aktywa, koszty operacyjne oraz wpłaty lub wypłaty. Łączenie kategorii może sprawić, że transfer gotówki będzie wyglądał na zyskowną transakcję, albo ukryć kosztowną serię nieudanych prób.

W prostym przykładowym wyjściu sprzedaż 20 z wcześniejszych 40 tokenów za 44 jednostki przy koszcie wyjścia 0,10 jednostki daje 43,90 jednostki wpływów. Przypisanie połowy kosztu nabycia 80,20 daje 40,10, pozostawiając zrealizowany wynik 3,80 jednostki. Druga połowa pozostaje w posiadanych aktywach, a nie w zrealizowanym zysku.

Ta konwencja księgowania jest przykładem edukacyjnym, a nie poradą podatkową. Ważne operacyjnie jest to, że raport potrafi wyjaśnić swoje ilości, ceny i sposób traktowania kosztów. Atrakcyjna suma bez odtwarzalnej drogi do rzeczywistych transakcji jest słabym dowodem przy ocenie strategii.

Testuj granice przed rozszerzeniem zakresu

Użyteczna próba obejmuje nieaktualne dane, zduplikowane zdarzenia, niewystarczające środki, odrzucone ścieżki, zmienione salda i przerwane odpowiedzi. Przypadki te sprawdzają, czy umowa operacyjna pozostaje egzekwowalna, gdy znika nieskomplikowana ścieżka. Powinny być zaplanowane, a nie odkrywane dopiero po kosztownym incydencie.

Używaj zapisanych scenariuszy i przyszłej obserwacji do różnych celów. Odtwarzanie historii sprawdza deterministyczną interpretację znanych zdarzeń. Przyszłe działanie w trybie obserwacyjnym sprawdza zachowanie systemu przy napływie nowych dowodów, z rzeczywistymi opóźnieniami i niepewnością. Żadne z nich nie dowodzi automatycznie, że wykonanie z rzeczywistymi środkami odtworzy tę samą ekonomikę.

Rozszerzaj zakres dopiero po określeniu, jakie dowody pozwalają przejść dalej. Więcej rynków i więcej równoczesnych strategii zwielokrotnia wymagania koordynacji. Jasny opis tego, co przetestowano, jest użyteczniejszy od szerokiej deklaracji, że oprogramowanie raz zadziałało.

Prowadź dzienny zapis działania

Codzienny przegląd może być zwięzły i nadal znaczący. Zapisuj, które strategie kwalifikowały się do działania, które źródła danych były aktualne, ile kapitału pozostawało zarezerwowane i czy jakaś rozbieżność transakcji lub salda wymagała uwagi. Dzięki temu brak aktywności staje się równie zrozumiały jak aktywność.

Zmiany zasługują na własny zapis. Jeżeli zmieniła się reguła, dostawca, założenie dotyczące kontraktu lub wersja oprogramowania, wskaż, kiedy zaczęło się nowe zachowanie. Mieszanie wyników istotnie różnych konfiguracji może zaciemnić przyczynę poprawy lub pogorszenia.

Pełny zapis operacyjny obejmuje także decyzje o zatrzymaniu. Strategia może pozostawać wstrzymana, ponieważ dane są niepełne lub badanie nie wspiera już jej założeń. Traktowanie tego wstrzymania jako uzasadnionego wyniku pomaga zapobiegać sytuacji, w której presja na handel przeważa nad warunkami pierwotnej autoryzacji automatyzacji.

Praktyczny arkusz oceny

Dla każdego proponowanego procesu Base zapisz sześć krótkich odpowiedzi: co obserwuje, jaką regułę ocenia, jakie zasoby rezerwuje, co może podpisać, jak potwierdza wyniki i jak odtwarza pracę. Jeżeli jedna odpowiedź jest niejasna, ta część systemu potrzebuje dalszej pracy przed próbą bez nadzoru.

Następnie prześledź jedną hipotetyczną transakcję od początku do końca. Uwzględnij odrzucone alternatywy, początkowe kwotowanie, ostateczną transakcję, rzeczywiste salda, wszystkie istotne koszty i scenariusz częściowego wyjścia. Zapytaj, czy drugi recenzent może dojść do tych samych wniosków wyłącznie na podstawie zachowanych zapisów.

Celem arkusza jest umożliwienie kontroli automatyzacji. Bota Base łatwiej ocenić, gdy każde działanie ma osobę odpowiedzialną, każda liczba ma źródło, a każde nierozstrzygnięte zdarzenie ma określony następny krok. Cechy te wspierają zdyscyplinowane eksperymentowanie nawet wtedy, gdy konkretny pomysł handlowy okazuje się nierentowny.

Częste pytania operacyjne

Czy jeden portfel może uruchamiać kilka reguł?

Może to być częścią projektu, lecz wspólne korzystanie z aktywów wymaga wspólnego rejestru zasobów. Jeżeli dwie reguły mogą niezależnie wydawać te same aktywa lub zmieniać tę samą pozycję, trzeba oceniać ich łączne zachowanie. Nadanie strategiom różnych nazw nie izoluje ich skutków ekonomicznych. Kontroler na poziomie konta musi rozumieć oczekujące działania, zarezerwowane środki i to, która reguła odpowiada za zarządzanie każdą pozostałą pozycją.

Czy udana symulacja ustala gotowość?

Symulacja może dostarczać dowodów dotyczących konkretnego proponowanego działania względem konkretnego stanu. Nie ustala, że późniejszy stan będzie identyczny, że przesłana transakcja dotrze w tej samej kolejności lub że ogólna strategia jest rentowna. Zachowaj symulowane dane wejściowe i wynik, a następnie osobno oceń przesłanie, uzgadnianie stanu i odtwarzanie pracy. Każdy test powinien wspierać konkretne twierdzenie, zamiast być naciągany do ogólnej deklaracji gotowości całego bota.

Co operator powinien widzieć, gdy nic nie jest handlowane?

Brak aktywności powinien mieć wyjaśnienie. Interfejs może odróżniać brak kwalifikującego się rynku, niewystarczające aktualne dowody, wyczerpany budżet, nierozstrzygniętą wcześniejszą pracę i celowo wstrzymaną strategię. Warunki te wymagają różnych odpowiedzi. Bez tego rozróżnienia użytkownicy mogą rozluźniać kontrole tylko dlatego, że nie potrafią ustalić, czy system działa normalnie. Dziennik decyzji powinien czynić powstrzymanie się od działania równie zrozumiałym jak zakończony zakup.

Kiedy pozycja przestaje być obowiązkiem bota?

Strategia pozostaje odpowiedzialna, aż określone obowiązki zostaną rozstrzygnięte lub jawnie przekazane. Może to oznaczać zamknięcie posiadanych aktywów, przekazanie ich innemu uprawnionemu procesowi zarządzania lub udokumentowanie przejęcia ręcznej kontroli przez użytkownika. Samo zatrzymanie procesu nie usuwa nierozstrzygniętych transakcji ani sald aktywów. Jasny zapis przekazania zapobiega traktowaniu istniejącego aktywa przy następnym uruchomieniu jako niewyjaśnionego nowego zasobu.