Handelsalgoritm på Solana: följ en regel från början till slut

Ett räkneexempel för en handelsalgoritm på Solana behöver ett syfte

R1:s syfte är att producera ett granskningsbart förslag om partiell minskning av en position som redan förvaltas av arbetsflödet. Den upptäcker inte nya token, härleder inte handlares avsikter och väljer inte en hel portfölj. Den snäva omfattningen håller exemplet fokuserat på sambandet mellan observationer och en åtgärdstyp.

Algoritmen använder en fast tokenmint och en marknadstolkning som stöds. Den observerar offerter för försäljning av exakt 100 token till en namngiven noteringstillgång. Varje jämförelse använder samma riktning och belopp. En offert för köp av 100 token eller försäljning av ett annat belopp går inte in i jämförelsebasen som om den vore likvärdig.

Den äldre guiden till handelsbotars arkitektur på Solana skiljer observation, strategi, behörighetsgivning och avstämning åt. R1 följer dessa gränser. En regelutlösning är ett föreslaget beslut, medan kontoresultatet kräver belägg från senare steg.

Specificera observationspaketet

Varje observationspaket innehåller mintidentitet, noteringstillgång, inmatat belopp, förväntad mottagen mängd, observationstid, käll- eller ruttomfattning och tolkningsstatus. Det anger också vilka kostnader som redan återspeglas i den mottagna mängden. Paketet bör lagras innan det blir indata till regeln.

För R1 är den mottagna mängden en beloppsspecifik försäljningsoffert, inte ett allmänt tokenpris. Det knyter jämförelsen närmare den avsedda minskningsmängden samtidigt som genomförandeosäkerhet kvarstår. En offert är belägg för förhållanden vid en tidpunkt, inte en garanti för ett senare kontoresultat.

Paketet behöver en tydlig tillgänglighetstid. En offert som återfinns i historiken efter beslutsgränsen kan inte gå in i en återspelning som om den varit känd tidigare. Beläggskedjan för den enskilda algoritmen börjar med vad systemet faktiskt kunde granska när regeln kördes.

Definiera ett avslutat basfönster

R1 jämför den senaste kvalificerade offerten med den genomsnittliga mottagna mängden från tre föregående avslutade observationer valda enligt ett fast schema. Schemat och aktualitetspolicyn ingår i regelversionen. De väljs inte senare för att göra jämförelsebasen gynnsam.

Alla tre basobservationer måste uppfylla samma krav på identitet, belopp, riktning och stöd. Om en saknas eller är ogiltig avstår R1 i detta exempel. Den kortar inte tyst jämförelsebasen och ersätter inte det saknade värdet med den senaste offerten.

En mer komplex algoritm skulle kunna använda en annan beräkning, men specifikationen skulle behöva samma tydlighet. Poängen är inte att tre observationer bildar en stark prognosmodell. Poängen är att en liten fast beräkning gör indatagränsen lätt att granska och synliggör hur saknade data ändrar beslutet.

Lås granskningsrytmen för exemplet

Föreställ dig för denna specifikation granskningar var femte minut. En granskning 10:00 använder registrerade offertpaket från 09:45, 09:50 och 09:55 som jämförelsebas plus en separat senaste offert för den aktuella granskningen. Varje paket måste ha uppfyllt en aktualitetsgräns på en minut när det godkändes vid sin egen granskningstid; det senaste paketet måste fortfarande uppfylla gränsen vid det aktuella beslutet.

Intervallen är illustrativa inställningar, inte rekommenderade handelsfrekvenser. De gör exemplet reproducerbart och hindrar implementeringen från att välja de tre historiska observationer som råkar ge en bekväm jämförelsebas. Om ett schemalagt paket saknades gäller R1:s regel för saknade indata i stället för att den söker längre bak utan en uttrycklig versionsändring.

Ange utlösningsvillkoret på vanligt språk

R1 föreslår en minskning när den senaste kvalificerade mottagna mängden är minst 5 % över genomsnittet för de tre basobservationernas mottagna mängder. Tröskeln är endast illustrativ. Likhet kvalificerar enligt denna regel, och beräkningen använder registrerade värden utan avrundning före visningsformatering.

Villkoret beskriver en relativ förändring i den offererade likviden för samma mängd på 100 token. Det påstår inte att hela positionen kan säljas till den underförstådda kursen eller att ytterligare prisrörelse är förutsägbar. Det vore andra frågor som kräver andra belägg.

Guiden till handelssignaler på Solana förklarar varför en upptäckt eller prognos inte automatiskt är en ekonomisk fördel. R1:s utlösning är helt enkelt en definierad mappning från händelse till förslag. Dess användbarhet skulle kräva en separat utvärdering av utfall, kostnader och det alternativa beteende den ersätter.

Beräkna utlösningen för hand

Anta att de fiktiva basobservationernas mottagna mängder är femtio, femtiotvå och femtioen noteringsenheter. Genomsnittet är femtioen. Den senaste mottagna mängden är femtiofyra. Den relativa ökningen är tre dividerat med femtioen, ungefär 5,88 %, så den numeriska utlösningen uppfylls under R1:s tröskel på 5 %.

Beräkningen bör lagras med indatavärdenas identifierare. En granskare kan då återskapa den utan att behöva den aktuella marknadssidan. Om ett indatavärde senare rättas ska det ursprungliga beslutet bevaras och skillnaden i den rättade beräkningen registreras i stället för att det tidigare resultatet tyst skrivs om.

Aritmetiken bevisar inte att den föreslagna försäljningen är fördelaktig. Den fastställer bara att de registrerade observationerna uppfyller det angivna utlösningsvillkoret. Nästa steg kontrollerar om positionen finns, mängden är tillgänglig, offerten förblir aktuell och åtgärden passar kontopolicyn.

Regelgranskning av en handelsalgoritm på Solana omfattar kvalificering

R1 verkar bara på en förvaltad position med minst 300 tillgängliga token före den föreslagna minskningen på 100 token. Exemplet lämnar alltså minst 200 token efter en framgångsrik minskning. Mängdregeln är illustrativ och hör till strategidefinitionen, inte en universell dimensioneringsrekommendation.

Regeln kräver också token- och marknadstolkning som stöds, en fullständig jämförelsebas, en aktuell senaste observation och frånvaro av en olöst minskningsavsikt som reserverar samma innehav. Om något krav inte uppfylls anger resultatet skälet till avstående i stället för att returnera ett missvisande nollpoängsvärde.

Regelgranskning av en handelsalgoritm på Solana bör verifiera dessa krav innan tröskelberäkningen granskas. Ett matematiskt korrekt resultat på 5,88 % kan inte kompensera för fel mint, inaktuella belägg eller otillgängligt innehav. Kvalificeringen avgör om beräkningen är meningsfull för den avsedda åtgärden.

Låt förslaget stanna innanför befogenhetsgränsen

När R1 utlöses skapar den ett förslag att minska positionen med 100 token. Förslaget innehåller regelversion, beläggsreferenser, mängd, aktuell offertkontext och förfallotid. Det signerar eller skickar inte in en transaktion på egen hand.

Ett separat behörighetssteg kontrollerar kontopolicy och aktuellt tillstånd. Kontot kan avvisa förslaget för att en annan åtgärd har reserverat innehav, befogenhet inte finns tillgänglig eller den föreslagna rutten faller utanför omfattningen. Avslaget är ett giltigt utfall även när R1:s observationsregel uppfylldes.

Guiden till handelssystem på Solana förklarar beständigt ansvar för dessa poster. Att hålla förslag och behörighetsgivning åtskilda låter en granskare skilja strategins avstående från kontots avslag. Utfallen pekar mot olika förbättringar och bör inte slås ihop i ett allmänt antal uteblivna affärer.

Kontrollera offerten igen före ett försök

Offerten som utlöste R1 kan förfalla innan åtgärden är redo att skickas in. Arbetsflödet bör hämta aktuella belägg och tillämpa en angiven policy för väsentliga ändringar. En gammal utlösning fastställer inte att den ursprungligen observerade mottagna mängden fortfarande finns tillgänglig.

Om den nya offerten inte längre uppfyller förslagets villkor kan åtgärden avvisas eller återföras för omvärdering. Policyn bör förklara om det ursprungliga utlösningsvillkoret fortfarande måste gälla eller om en separat godkänd genomförandegräns styr försöket. Exemplet lämnar inte valet till en ad hoc-bedömning av en arbetare.

Bevara den utlösande offerten och den senare genomförandeofferten separat. Skillnaden är användbara belägg för fördröjning och genomförbarhet. Att ersätta den ursprungliga offerten med den senare skulle göra det svårare att förklara varför algoritmen utlöstes från början.

Reservera innehav för minskningen som fått behörighet

Anta att kontot har 500 tillgängliga token när förslaget på 100 token får behörighet. Arbetsflödet reserverar den föreslagna mängden så att en annan försäljningsregel inte självständigt kan anta att alla 500 fortfarande finns tillgängliga. Om åtgärden slutförs som avsett återstår 400 token innan hänsyn tas till orelaterade kontoändringar.

Reservationen består under försökets olösta period enligt avstämningspolicyn. Den kan frigöras när ett förslag som inte skickats in förfaller eller när belägg med stöd fastställer ett utfall som tillåter frigöring. Schemaläggaren bör inte frigöra den bara för att ännu ett intervall börjar.

Den äldre guiden till samordning av vinsthemtagning och stoppförlust på Solana diskuterar konkurrerande försäljningsvillkor. R1 är en möjlig källa till ett minskningsförslag. Dess implementering måste samarbeta med alla andra källor genom den gemensamma positionsposten i stället för att hantera innehav isolerat.

Registrera inskickningen som ett försök

Genomförandekomponenten registrerar avsikten som fått behörighet och det resulterande transaktionsförsöket. Den behåller identiteten och tidsuppgifterna som behövs för att följa utfallet. Ett framgångsrikt inskickningssvar är inte i sig en avstämd försäljning; Solanas dokumentation för sendTransaction gör skillnaden uttrycklig. Solanas inskickningsdokumentation.

Om svaret är osäkert bör arbetsflödet undersöka det befintliga försöket. Det bör inte köra R1 igen och skapa en ny försäljningsavsikt bara för att den tidigare begäran inte returnerade en bekväm slutstatus. Det ursprungliga förslaget och dess reserverade innehav förblir en del av kontotillståndet.

Åtskillnaden förbättrar också research. Ett utlöst förslag, ett förslag som fått behörighet och en slutförd minskning är olika antal. Algoritmens operativa genomförbarhet kan bedömas först när posten bevarar övergångarna och skälen till att vissa förslag aldrig blir kontoändringar.

Stäm av positionen efter utfallet

När transaktionsutfallet fastställts enligt den valda policyn ska kontoeffekten jämföras med avsikten. Registrera den minskade mängden, likviden, kostnaderna och det återstående förvaltade innehavet. Om resultatet skiljer sig från förväntan ska avvikelsen bevaras och lösas innan beroende åtgärder antar ett rent tillstånd.

Positionen bör inte markeras som helt stängd efter en minskning på 100 token från 500. Den förblir öppen med den avstämda mängden. En status för slutfört försök och en status för stängd position beskriver olika objekt och bör förbli åtskilda i gränssnitt och export.

Den återstående positionen påverkar också nästa R1-utvärdering. Regeln bör använda aktuellt tillgängligt innehav, inklusive andra reservationer och externa ändringar. Att kopiera den ursprungliga mängden på 500 token till varje framtida förslag skulle bryta mot just det kvalificeringsvillkor som specifikationen fastställde.

Definiera när regeln får utlösas igen

Utan en policy för återaktivering kan R1 utfärda ännu en minskning varje gång den observerar samma bestående förhållande. Avgör om algoritmen tillåter upprepade minskningar, väntar på att förhållandet upphör eller kräver en ny basepisod innan ännu ett förslag kan öppnas.

I denna illustrativa specifikation får en utlösningsepisod bara ha en öppen minskningsavsikt. Efter att avsikten lösts kräver R1 en aktuell, fullständig granskning vars senaste mottagna mängd ligger högst 2 % över sin kvalificerade jämförelsebas innan ännu en episod kan börja. Återställningen stänger det gamla förhållandet; en senare granskning måste åter uppfylla öppningströskeln på 5 % för att skapa en ny episod. Kraven på innehav och befogenhet gäller fortfarande oberoende.

Det hindrar upprepade observationer från att bli oavsiktliga staplar av försäljningsavsikter. Det definierar också researchenheten: en episod har ett öppningsvillkor, ett förslagsutfall och en stängning eller återställning. Antalet aviseringar och observationer kan då skiljas från antalet faktiska algoritmbeslut.

Testa ett fall med ofullständig jämförelsebas

Ta bort den mittersta basobservationen och behåll den senaste mottagna mängden på femtiofyra. Enligt R1 är det förväntade resultatet avstående eftersom den nödvändiga jämförelsebasen med tre observationer är ofullständig. Systemet bör inte ta genomsnittet av femtio och femtioen och påstå att den ursprungliga regeln fortfarande kördes.

Posten bör namnge den saknade inmatade uppgiften och behålla den senaste giltiga observationen för senare research. När den saknade observationen kommer kan systemet återskapa den tidigare beräkningen, men det är ett retrospektivt resultat. Det blir inte en signal som fanns tillgänglig i verklig drift vid den ursprungliga beslutstiden.

Fallet testar informationsgränsen snarare än aritmetiken. Ett program kan beräkna ett genomsnitt korrekt samtidigt som det bryter mot regeln genom att använda en ofullständig eller sen datamängd. Meningsfull validering kontrollerar att indata var kvalificerade innan det numeriska resultatet kontrolleras.

Testa ett fall med gammal offert och ändrat innehav

Behåll sedan jämförelsebasen fullständig men gör den senaste offerten äldre än R1:s aktualitetsgräns. Det förväntade resultatet är avstående eller att förslaget förfaller, beroende på steg. En nyrenderad skärm bör inte förnya den underliggande offertens ålder.

Återställ sedan en aktuell offert samtidigt som tillgängligt innehav minskas under 300 genom en kontrollerad extern ändring. Det numeriska utlösningsvillkoret kan fortfarande gälla, men positionen kvalificerar inte. Posten bör identifiera mängdvillkoret i stället för att låtsas att signalen försvann för att marknaden ändrades.

Fallen visar varför observationsregler och kontotillstånd måste förbli kopplade. Samma marknadspaket kan ge olika tillåtna utfall när innehav eller befogenhet ändras. Det är inte inkonsekvens; det är det avsedda beteendet hos ett fullständigt algoritmflöde med uttryckliga förutsättningar.

Jämför R1 med ett definierat alternativ

För att utvärdera R1:s användbarhet ska ett basbeteende väljas under samma antaganden om konto, observation och kostnader. Alternativet kan vara en schemalagd fast minskning eller ingen minskning fram till en senare i förväg angiven granskning. Valet bör passa researchfrågan och undvika efterklokhet.

Guiden till handelsalgoritmer på Solana utvecklar rättvisa jämförelser mellan regler. R1 bör inte få mer gynnsamma offerter, större budget eller en annan försäljningshorisont än alternativet om inte skillnaden uttryckligen ingår i studien.

Jämförelsen bör omfatta föreslagna men inte genomförda minskningar, återstående innehav och kostnader. Att bara titta på slutförda minskningar kan dölja fall där regeln utlöstes men åtgärden inte var genomförbar. En fullständig kontobana är mer informativ än en samling isolerade framgångsexempel.

Lås regeln före en senare granskning

Den slutliga R1-specifikationen omfattar universum, offertbelopp, val av jämförelsebas, tröskel, kvalificering, förfall, återaktivering, överlämning till behörighetsgivning och utfallsredovisning. Lås hela definitionen innan en senare utvärderingsperiod granskas. Att ändra bara en dold förutsättning kan ändra resultatet väsentligt.

Den äldre guiden till researchflöden på Solana förklarar varför tidsgränser och fasta regler spelar roll. Om den senare perioden avslöjar ett fel eller ett oattraktivt resultat ska revisionen dokumenteras som R2 och de belägg som användes för att välja den identifieras.

En regel som reviderats efter att ett utvärderingsfönster granskats bör inte behålla påståendet att samma fönster oberoende validerade den reviderade versionen. Posten kan fortfarande vara värdefulla utvecklingsbelägg. Ärlig versionshantering bevarar vad researchen lärde utan att få den slutliga regeln att verka vald i förväg.

Dela upp utfallsgranskningen

Granska om R1 fick fullständiga belägg, beräknade utlösningen korrekt, producerade det avsedda förslaget, klarade behörighetskontrollen, nådde ett fastställt försöksutfall och stämde av positionen. Ett fel vid varje steg betyder olika saker. En korrekt formel fastställer inte ett korrekt fullständigt arbetsflöde.

Bedöm sedan den ekonomiska frågan separat: vad ändrade minskningen jämfört med det definierade alternativet, efter kostnader och under samma kontobana? Svaret kan vara gynnsamt, ogynnsamt eller osäkert. Att algoritmen kan tolkas garanterar inte dess värde.

En användbar rapport kan därför säga att implementeringen motsvarade specifikationen medan strategin misslyckades med sitt researchmål. Den kan också identifiera ett driftfel innan något ekonomiskt påstående görs. Att hålla slutsatserna åtskilda riktar förbättring mot det steg som beläggen faktiskt pekar ut.

Bevara ett fullständigt exempel för framtida ändringar

Behåll offertsekvensen femtio, femtiotvå, femtioen och femtiofyra med dess förväntade beräkning på 5,88 % och relaterade kvalificeringsfall. Lägg till posterna för förslag, behörighetsgivning, försök och avstämning från en kontrollerad körning. Det skapar en kompakt referens för senare implementeringsändringar.

Referensen bör omfatta utfall utan åtgärd såväl som det framgångsrika förloppet. Framtida versioner kan kontrolleras mot avsedda skillnader samtidigt som de gränser som bör förbli stabila bevaras. En regressionsgranskning är mest användbar när den verifierar meningsfullt beteende i stället för att bara spegla den senaste implementeringen.

En handelsalgoritm på Solana blir granskningsbar när hela kedjan är uttrycklig. En enkel regel kan visa disciplinen: observerade belägg går in i en fast beräkning, kvalificering begränsar användningen, befogenhet styr åtgärden och kontoavstämning fastställer följden. Samma tydlighet förblir värdefull när den slutliga algoritmen är mer komplex.