com_r35157_nenjim-hubd-impl_ref/docs/Evelyn.md

#

Evelyn
Documentation

Indholdsfortegnelse:

• 1. Introduktion formål og vision
  • 1.1 Tokens som vedvarende aktiv – selv efter systemnedbrud
• 2. Tokenøkonomi og finansiering
  • 2.1 Allokering af overskud
  • 2.2 Buybacks og burn
  • 2.3 Finansiering af udvikling
  • 2.4 Ansvarsplacering og overskud
  • 2.5 Neutralitet og ligestilling
  • 2.6 Vejen mod autonomi
• 3. Tradingmotorens filosofi - AFETS
  • 3.1 Ikke-spekulativ tilgang
  • 3.2 Søgning efter ligevægt
  • 3.3 Anti-fragilitet
• 4. Trekantmodellen - Longs, Shorts og Margin
• 5. Score-beregning – systemets beslutningsmotor
  • 5.1 Principper for score-beregning
  • 5.2 Beregning af score for åbning af positioner
  • 5.3 Straf for store positioner (penalty)
  • 5.4 Beregning af score for lukning af positioner
  • 5.5 Fleksibilitet og udvikling
• 6. Iteration og rebalancering
• 7. Likviditetsstyring og gearing
  • 7.1 Tærskler og dvale
• 8. Risici, fail-safes og antifragilitet
• 9. Udvikling, YouTrack-integration og offentlig gennemsigtighed
• 10. Fremtidige emner / TODO
• 11. Statusservice og referencepris

1. Introduktion formål og vision

Evelyn er et proprietært trading-plugin bygget oven på AssetAZ-platformen. Evelyn er ikke open source og er ikke designet til at blive kørt af andre. Ingen andre end udvikleren har, på nuværende tidspunkt, adgang til at bruge, køre eller analysere den. Evelyn eksisterer udelukkende som en privat og beskyttet komponent i et større, decentraliseret økosystem.

Der arbejdes hen imod, at Evelyn, med tiden, bliver en fuldt autonom enhed med egen kapital og kontrol, hvor ikke engang udvikleren har adgang til beslutningstagen eller de midlerne – kun mulighed for at interagere på lige fod med øvrige investorer.

Evelyn er ikke designet til at maksimere profit for ejeren i klassisk forstand. Evelyn er en blackbox, som eksterne investorer kan interagere med. Al profit, Evelyn genererer gennem bl.a. trading, kanaliseres tilbage i systemet: til egen drift (hosting, strøm og andre ressourcer), udvikling, polstring imod kriser, styrkelse af likviditet i trading pools samt tilbagekøb af de 'Evelyn IOU' tokens investorerne har købt. Den eneste kapital, der tilfalder Evelyn selv, er derfor kun den oprindelige likviditet skabt, da tokens blev solgt på det åbne marked – det, man kan betragte som hovedstolen på de gældsbeviser, Evelyns IOU tokens repræsenterer. Evelyn selv tjener ikke på trading, men bruger trading som et værktøj til at styrke systemet og servicere sine gældsforpligtelser. Når Evelyn senere har opbygget en stor egenkapital, vil den anvende en del af denne kapital til filantropisk støtte i samfundet.

Evelyn distribueres teknisk som enhver anden Nenjim-komponent, men er ikke offentligt registreret, hvilket gør den praktisk talt usynlig for andre brugere. Denne designbeslutning understøtter Evelyns rolle som en blackbox til kapitalopbygning og senere filantropisk støtte. Evelyn anvender AFETS-princippet for antifragilitet i sin tradingstrategi og sikrer løbende systemstabilitet ved at geninvestere profit i likviditetsstyrkelse, udvikling og opkøb af Evelyn IOU-tokens.

I fremtiden vil eksterne investorer, via tokens, kunne stemme om, hvilke projekter Evelyn skal støtte.

1.1 Tokens som vedvarende aktiv – selv efter systemnedbrud

En særlig egenskab ved Evelyns design er, at Evelyn tokens fortsætter med at eksistere og blive handlet på decentraliserede børser, selv hvis Evelyn selv ophører med at fungere – f.eks. på grund af likvidering af alle positioner eller markedsmæssige sammenbrud.

Det betyder, at investorers kapital ikke går tabt, selv hvis Evelyn som tradingmaskine fejler. Tokens kan stadig have værdi og kan handles frit. Det giver mulighed for, at tokens over tid bliver købt op igen – ikke nødvendigvis af Evelyn, men f.eks. af den oprindelige udvikler med anden indkomst, eller af markedet selv, hvis der opstår ny interesse.

Denne adskillelse mellem token og motor gør, at Evelyn ikke skaber afhængighed, men i stedet definerer en langsigtet økonomisk kontrakt mellem projekt og investor, som potentielt kan indfries, selv hvis omstændighederne ændrer sig drastisk.

2. Tokenøkonomi og finansiering

Evelyn bruger en intern token kaldet 'Evelyn IOU' som sin primære finansieringsmekanisme. Denne token er en form for gældbevis, som Evelyn selv udsteder i de tilfælde, hvor der ikke er tilstrækkelig likviditet til at fortsætte handelsaktiviteterne. Tokens bliver udstedt “ud af den blå luft” og solgt på en decentraliseret børs. Provenuet fra salget bliver brugt direkte som handelskapital i systemet. Det er vigtigt at forstå, at 'Evelyn IOU' ikke giver krav på en fast tilbagebetaling – det er en markedsbaseret mekanisme, hvor investorerne forventer at kunne sælge deres tokens igen til en højere pris, efterhånden som Evelyn opnår overskud.

2.1 Allokering af overskud

Når Evelyn genererer overskud gennem sin tradingstrategi, bliver dette overskud automatisk allokeret i forskellige procentandele til følgende områder:

1. Geninvestering i nye positioner
2. Reduktion af gearing (hvis anvendt)
3. Afbetaling af gæld for tidligere tab
4. Tilførsel af likviditet i Evelyn IOU-tokenets pool
5. Betaling for udvikling og vedligehold, samt drift af systemet
6. Buyback og burn af tokens

Fordelingerne er hardcoded og justeres manuelt af udvikleren, når behovet opstår. Evelyn foretager ikke selv beslutninger om fordelingen. Det er et lukket kredsløb, hvor alt overskud anvendes til enten at styrke systemet, sikre tokenens pris eller muliggøre ny funktionalitet.

2.2 Buybacks og burn

En af de vigtigste mekanismer i Evelyn er det automatiske tilbagekøb og efterfølgende burn af 'Evelyn IOU' tokens. En fast procentdel af overskuddet anvendes på at købe tokens på markedet, når Evelyn Price Index er under nul, og brænde dem permanent. Det reducerer udbuddet, når den aktuelle EVE-pris er lavere end Evelyns referencepris.

Når et input ellers er klar til køb, læser burneren en frisk kanonisk EVE/USDT-pris fra TickerService og kalder den tilsvarende EvelynStatusService.getReferencePrice() med det aktuelle beslutningstidspunkt. Køb tillades kun ved aktuel pris < referencepris; lighed giver intet køb. Der bruges samme eksisterende maksimale prisalder som til burn-værdiansættelsen, uden nye prisindstillinger. Referencekurven beregnes af status-servicen; hverken den sidst gemte historikværdi eller grafens punkter bruges til købsbeslutningen.

Ved lighed, højere pris eller manglende, ugyldige, for gamle eller utilgængelige prisdata springes alle nye køb over i iterationen, og årsagen logges. Forløbet fortsætter til EVE-saldo og mulig burn efter de selvstændige burn-regler. En fejl i referenceopslaget blokerer derfor ikke burn, når dens egen friske værdiansættelse og øvrige krav er opfyldt. Priserne vurderes igen ved næste ellers berettigede iteration; et prisskip sætter ingen permanent suspension.

Med referencepris 15 USDT/EVE tillader 14,99 et ellers berettiget køb; 15,00 og 15,01 springer købet over. I alle tilfælde fortsætter EVE-burn-vurderingen.

Produktionsprocessen evelyn.iou-burner.prod accepterer følgende inputs i rækkefølge:

Token	Reserve	Minimum swap-input	Maksimum pr. iteration
USDT	0,1 USDT	0,05 USDT	0,25 USDT
SyrupUSDC	0,095 SyrupUSDC	0,045 SyrupUSDC	0,2 SyrupUSDC

Hub'en angiver reserver, minimumsbeløb og maksimummer som MoneyAmount. Reservelisten bestemmer accepterede valutaer og prioritet; minimumsbeløb og maksimummer matches efter valutaens kanoniske UUID uanset listernes rækkefølge, navn og symbol. Hver accepteret valuta skal have præcis ét positivt minimum og maksimum, og minimum må ikke overstige maksimum. Alle tre lister kopieres ved oprettelse af burneren; tre tomme lister tillader direkte EVE-burn.

Burneren vælger det mindste af saldo minus reserve og valutaens eget maksimum, afrundet ned til mintens præcision. Er dette faktiske beløb under valutaens minimum, springes inputtet over, og næste input undersøges i samme iteration. Lighed med minimum accepteres; der rundes aldrig op eller bruges af reserven for at nå minimum. For eksempel springes 0,000001 spendabel USDT over, så en SyrupUSDC-saldo på 0,502048 kan give et swap på 0,2 SyrupUSDC. Inputminimummer begrænser ikke burn af eksisterende EVE. Grænserne angives i tokens: SyrupUSDC er ikke lig med USDC, og 0,2 SyrupUSDC garanterer ikke en bestemt USD-værdi. Der kræves ingen inputtoken/USDC-pris eller nye Ticker-kilder og historikfiler.

Højst ét input forsøges vekslet pr. iteration, med en times pause efter hver afsluttet iteration. Jupiter vælger pool og rute til EVE. USDT har fortsat første prioritet, så en vedvarende spendabel USDT-saldo kan udsætte SyrupUSDC-veksling. Efter det mulige buyback, også når prisbetingelsen springer købet over, genlæses hele den synlige EVE-saldo, også ved direkte EVE-indbetalinger. Ejeren har valgt et produktionsminimum på 0,1 EVE pr. burn og en reserve på 0,01 EVE. Hub'en angiver begge som MoneyAmount med EVE's kanoniske UUID. Minimum skal være positivt, reserve skal være ikke-negativ; en reserve på nul er gyldig. Null-værdier og andre valutaer afvises ved oprettelse.

Burnbeløbet beregnes som max(EVE-saldo - EVE-reserve, 0), afrundet ned til EVE-mintens præcision. Der brændes kun, når dette faktiske beløb er positivt og mindst minimum. Når tærsklen nås, brændes hele det berettigede beløb over reserven; minimum er en tærskel, og der er intet burn-maksimum. Eventuelle afrundingsrester bliver i wallet'en sammen med reserven. Små buybacks fortsætter, når købspris og inputkrav tillader det, og samler EVE op mellem burns. Under tærsklen sker hverken burn eller burn-notifikation.

EVE-saldo	Produktionshandling	EVE tilbage efter succes
0,105	Ingen burn	0,105
0,11	Burn 0,1 EVE	0,01
0,135	Burn 0,125 EVE	0,01

Issue #93 bruger minimum 1 EVE og reserve 0,1 EVE som adfærdseksempler: 1,05 EVE giver ingen burn, 1,1 EVE giver burn af 1 EVE, og 1,35 EVE giver burn af 1,25 EVE. Produktionsværdierne ovenfor blev valgt særskilt den 2026-10-06.

Burn kræver stadig en frisk EVE/USDT-observation gennem det uændrede TickerService.getLatestPrice() og bekræftes ved FINALIZED før det eneste notifikationsforsøg. Pending burn og notifikationens EVE-beløb og dollarværdi bruger det faktisk indsendte burnbeløb uden reserven. Et pending burn afklares med sin oprindelige signatur uden ny tærskelvurdering eller genindsendelse. Inputgrænserne begrænser ikke EVE-burn.

Ved ukendt swap-resultat gemmes den oprindelige signatur, inputvaluta, beløb og validitetsoplysninger i processen. Senere iterationer undersøger samme signatur uden at gensende transaktionen. Bekræftet succes eller fejl ved mindst CONFIRMED frigiver mulig ny inputvurdering med frisklæste saldi; ethvert nyt køb skal stadig bestå den aktuelle prisbetingelse. Afklaringen er read-only og fortsætter også ved pris lig med eller over referenceprisen. Udløb frigiver kun et swap, når den oprindelige transaktions validitet er udløbet, og frisk finalized historik for signerens adresse med tilstrækkelig lokal dækning beviser, at den ikke blev udført. En begrænset historikside, der ikke dækker hele perioden, er fortsat uafklaret. Jupiter-udfyldte sponsorsignaturer kan afklares ved status, men bruges ikke til at bevise udløb af den lokalt signerede transaktion.

Mens et swap er uafklaret, fortsætter eksisterende EVE-burn. Et allerede ventende burn har førsteprioritet og afklares alene. Fejl bevist før indsendelse tillader et nyt forsøg i en senere iteration; mulig indsendelse uden troværdig signatur kræver manuel afklaring. Loggen viser valuta, beløb, signatur, fase/årsagsklasser og næste handling uden signerdata eller transaktionspayloads. Der findes ingen persistent journal: genstart mister pending swap/burn og suspensioner, så ukendte transaktioner skal afklares eksternt før genstart og genoptagelse.

2.3 Finansiering af udvikling

Udvikling i Evelyn sker gennem en task-baseret model. Alle opgaver oprettes i IntelliJ YouTrack og bliver individuelt prissat i 'Evelyn IOU'. Når en opgave er funded – enten af Evelyn selv (via overskud) eller af en ekstern sponsor, påbegyndes arbejdet. Når opgaven er markeret som “Done”, udbetales den aftalte mængde tokens til udvikleren. Alle transaktioner er offentligt synlige via SolScan, hvilket sikrer gennemsigtighed og gør det muligt at verificere, at en opgave faktisk funded, gennemført og til sidst, betalt for.

Det betyder også, at eksterne investorer kan vælge at støtte specifikke funktioner, hvis de tror på Evelyns fremtid, selv i perioder hvor Evelyn ikke selv har midler. Det gør tokenen både til en investeringsenhed og et værktøj til at drive udvikling fremad.

2.4 Ansvarsplacering og overskud

Det er vigtigt at understrege, at al profit går til systemet og dets investorer – ikke til ejeren som personlig gevinst. Den eneste kapital, der kan betragtes som tilhørende ejeren, er den oprindelige likviditet, der blev tilført, da tokens blev solgt. Evelyn bruger alt efterfølgende overskud til at servicere sin egen gæld, styrke balancen og understøtte videreudvikling.

2.5 Neutralitet og ligestilling

Selvom Evelyn er udviklet og ejet af én person, er selve systemets økonomiske struktur designet til at være neutral. Hvis ejeren ønsker yderligere gevinst ud over den oprindelige hovedstol fra tokensalget, skal det ske ved at købe Evelyn IOU-tokens på lige fod med alle andre investorer. Der er ingen bagdør, ingen særbehandling og ingen skjulte fordele.

Systemet fungerer dermed næsten som et selvejende kredsløb, hvor udvikleren er en deltager på linje med alle andre. Det er ikke systemets opgave at betale sin ejer – det er systemets opgave at holde balancen, betale sin gæld og skabe værdi for markedet.

2.6 Vejen mod autonomi

Der er en overordnet ambition om, at Evelyn på sigt skal blive et fuldt selvforvaltende system, hvor ikke engang den oprindelige udvikler har adgang til dens kapital. Det betyder, at den handelskapital, Evelyn genererer eller modtager via tokensalg, ikke skal kunne trækkes ud af systemet af nogen – heller ikke ejeren.

Idealet er, at Evelyn på et tidspunkt fungerer som en økonomisk organisme med sin egen vilje. En enhed med egne midler, egne prioriteter og egne beslutninger – hvor adgang til ressourcer kun kan opnås gennem markedet eller gennem faktisk bidrag til systemet.

Udvikleren bliver i så fald ikke systemets ejer, men blot én deltager blandt andre, der kan tilbyde at løse opgaver eller investere i tokens. Det er en ny måde at tænke softwareejerskab på: ikke som besiddelse, men som fællesskab og udveksling.

3. Tradingmotorens filosofi - AFETS

Evelyn bygger hele sin handelsstrategi på det, der kaldes AFETS – Anti-Fragile Equilibrium Trading System. Systemet er konstrueret til ikke blot at tåle markedets svingninger, men at blive stærkere af dem. Det er en strategi, hvor målet ikke er spekulation eller profitmaksimering, men balancering. Evelyn forsøger ikke at forudsige fremtiden. Den handler udelukkende på, hvad der er sandt lige nu.

3.1 Ikke-spekulativ tilgang

I modsætning til traditionelle tradingbots, der forsøger at gætte fremtidige prisbevægelser ud fra mønstre, nyheder eller tekniske indikatorer, arbejder Evelyn retrospektivt. Den bygger sine beslutninger på observerede forhold i nuet – og aldrig på spekulation. Det gør den ekstremt robust over for chok, kriser og nyhedsdrevne spikes, fordi den ikke lader sig rive med af narrativer, der måske viser sig forkerte.

3.2 Søgning efter ligevægt

Hele grundideen i AFETS er at bevare en økonomisk ligevægt. Det betyder, at Evelyn hellere vil være stabil end aggressiv. Den ser det som en styrke at overleve, ikke at vinde stort. Det gør systemet egnet til lang levetid og kontinuerlig forbedring – og til at undgå store tab.

3.3 Anti-fragilitet

Konceptet om antifragilitet kommer fra Nassim Nicholas Taleb og beskriver systemer, der ikke bare er robuste, men som faktisk vokser af kaos og stress. Evelyn søger netop dette: at komme styrket ud af udsving i markedet. Når en ubalance opstår, bruger Evelyn muligheden for at lukke positioner med profit og styrke sin margin. Når tingene vender, er den klar til at tage det næste sving med endnu større stabilitet.

Evelyn vinder altså ikke ved at være den hurtigste eller smarteste, men ved at være den mest tålmodige og bedst balancerede. Det er ikke et system, der skal slå markedet – det er et system, der skal overleve og tilpasse sig det.

4. Trekantmodellen - Longs, Shorts og Margin

Evelyn opererer med en unik model, hvor dens samlede kapital opdeles i tre hovedkomponenter: long-positioner, short-positioner, og available margin. Disse tre komponenter udgør tilsammen en trekant, hvor hver side repræsenterer en tredjedel af den samlede værdi. Målet er, at hver af balance imellem de tre dele altid tilstrebes, så hver side af trekanten udgør cirka 33% af den samlede kapital.

Long-positionerne repræsenterer de handler, hvor Evelyn satser på, at værdien af et givent aktiv vil stige. Short-positionerne er de handler, hvor Evelyn forventer, at værdien vil falde. Available margin er den likvide kapital, som ikke er bundet i positioner, og som er klar til at blive brugt til nye handler eller til at genoprette balance, hvis det bliver nødvendigt.

Når der opstår ubalance i trekanten, for eksempel hvis long-positionerne stiger i værdi og dermed fylder mere end 33% af den samlede kapital, vil Evelyn iværksætte en rebalancering. Det gør den ved at lukke en del af de kontrakter fra en af de overrepræsenterede positioner og føre værdien tilbage til 'available margin'.

I næste iteration kan Evelyn så vurdere, om available margin nu er for høj og derved bruge noget af den til at åbne nye short-positioner for at genoprette balancen. Målet er altid at bringe alle tre komponenter tilbage til en ligelig fordeling.

Når short-positionerne stiger i værdi (og derved er i tab), kan Evelyn stå i en situation, hvor den har svært ved at lukke disse positioner uden at forværre ubalancen. For at håndtere dette, vil Evelyn typisk skiftevis lukke en long og en short i en form for “tiptoe”-mønster. Denne metode gør det muligt for Evelyn at balancere sine positioner over tid, uden at skabe pludselige, store udsving i systemet.

5. Score-beregning – systemets beslutningsmotor

Score-beregningen er hjertet i Evelyns beslutningsproces. Når Evelyn skal vælge, hvilke positioner der skal åbnes eller lukkes, bruger den en scorefunktion til at vurdere alle muligheder objektivt og konsekvent. Formålet er at vælge den position, der skaber mest balance og bedst forbedrer porteføljens risiko/profit-forhold.

5.1 Principper for score-beregning

• Evelyn vurderer altid alle kandidater (f.eks. alle mulige nye kontrakter, eller alle åbne positioner, der kan lukkes).
• For åbning af positioner bruges både markedsdata (pris, kontraktstørrelse, gearing mv.) og et strafsystem, så ingen positioner bliver for store i forhold til de andre.
• For lukning af positioner er scoren pt. simplere (procentuel gevinst/tab), men kan udvikles videre i fremtiden.

5.2 Beregning af score for åbning af positioner

Når en ny kontrakt skal vælges, samles alle relevante input i en record (se kode-eksempel i appendiks). Beregningen vurderer blandt andet:

• Hvilken profitforbedring opnås, hvis prisen udvikler sig fra nuværende til “efter trade”-niveau?
• Hvor stor er profitten i forhold til den kapital, der bruges?
• Hvor meget spredes risikoen ved at vælge denne position frem for at forstørre eksisterende?

Eksempel på scoring:

• Beregn forskel mellem nuværende og fremtidig pris for aktivet (alt efter om det er en long eller short)
• Udregn profit for denne prisændring
• Relativ profit (profit pr. dollar brugt)
• Summér til en endelig score: score = 1 + (relativ profit)

5.3 Straf for store positioner (penalty)

For at undgå, at Evelyn bygger uforholdsmæssigt store positioner i ét aktiv, justeres scoren nedad for de kandidater, hvor den nuværende position allerede er større end gennemsnittet. Straf-funktionen dæmper scoren med en faktor, der vokser med afvigelsen fra gennemsnittet:

• Hvis positionen > gennemsnittet, så:
• adjustedScore = rawScore / (1 + K * (ratio-1)^2)

Her er K en justerbar parameter, der bestemmer, hvor hårdt store positioner straffes.

5.4 Beregning af score for lukning af positioner

For at lukke positioner anvender Evelyn pt. en simpel score baseret på den procentuelle gevinst eller tab, positionen har. Listen af potentielt lukkede positioner sorteres på denne score, og den bedste vælges.

5.5 Fleksibilitet og udvikling

Alle scorefunktioner er implementeret, så de kan udskiftes, tunes og forbedres uden at bryde resten af systemet. Det gør det let at eksperimentere med nye logikker og justere for mere optimal risikospredning eller profitforbedring over tid.

6. Iteration og rebalancering

Evelyn arbejder i faste iterationer, hvor den med jævne mellemrum – for eksempel hver time – evaluerer sine positioner. I hver iteration summerer Evelyn værdien af alle longs, alle shorts og den available margin for at sikre, at de tre komponenter er i balance. Hvis for eksempel long-positionerne bliver for store i forhold til de to andre dele, vil Evelyn lukke nogle af disse positioner og føre værdien tilbage til den available margin. Dette sikrer, at der ikke opstår en skævvridning, som kan true systemets stabilitet.

Rebalanceringen foregår altid med forsigtighed for at undgå overreaktioner, og justeres i små skridt, så systemet altid er i stand til at absorbere markedsudsving uden at tabe balancen.

7. Likviditetsstyring og gearing

Evelyns likviditetsstyring er bygget op omkring klare tærskler og trin:

• Normalt drift: Systemet forsøger at holde available margin på ca. 33%. Det sker ved balancering mellem long-, short-positioner og likvide midler.
• Faldende tilgængeling margin: Hvis available margin falder under et defineret threshold (fx 10%), begynder Evelyn at øge gearingen på eksisterende positioner. Det frigør kapital, men bruges kun til at holde margin på minimum, ikke til at tage flere handler.
• Kritisk lav margin: Hvis gearing ikke kan øges yderligere, og marginen rammer 0%, vil Evelyn udstede nye 'Evelyn IOU' tokens som sidste udvej for at skaffe ekstern likviditet.

Når markedet normaliseres, nedbringer Evelyn langsomt gearingen over tid, finansieret af trading-overskud. Det betyder, at systemet efter en krise ikke straks går tilbage til spot-only, men gradvist heler balancen, lidt som et brækket ben, der får tid til at blive stærkt igen. Under hele processen prioriteres stabilitet over aggressivitet.

7.1 Tærskler og dvale

Hvis ubalancen bliver for ekstrem – eksempelvis hvis short-siden eller gearing dominerer – kan Evelyn gå i dvale (pause al trading). Dette sikrer, at systemet ikke vælter, men tålmodigt venter på bedre markedsforhold eller ny kapitaltilførsel.

8. Risici, fail-safes og antifragilitet

Evelyn er designet til at overleve og vokse af markedsstress, ikke blot at modstå det. Systemet har flere indbyggede mekanismer for at sikre antifragilitet:

• Fail-safe-mode: Hvis balancen mellem longs, shorts og margin bliver for skæv (fx hvis short-siden vokser for meget), kan Evelyn sætte sig selv på pause og stoppe al trading. Det sikrer, at systemet aldrig tvinges ud i ruinøse handler, men hellere venter tålmodigt på, at markedet vender, eller på at der tilføres ny margin.
• Tærskelbaseret gearing og tokensalg: Evelyn bruger gearing kun som midlertidigt værktøj, og kun til at holde marginen lige over det kritiske minimum. Kun hvis dette fejler, udstedes nye tokens.
• Tålmodighed over panik: Systemet undgår bevidst at tage hurtige, risikable beslutninger under stress – i stedet nedbringer det gearing og bygger langsomt balancen op igen.
• Antifragilitet: Når Evelyn oplever markedskaos, bliver den stærkere, fordi dens strategi bygger på at udnytte ubalancer og reinvestere gevinsterne i at reparere systemet.

9. Udvikling, YouTrack-integration og offentlig gennemsigtighed

Evelyns udviklingsmodel bygger på transparens og dokumenterede processer, selvom selve koden ikke er offentlig:

• YouTrack-integration: Alle udviklingsopgaver oprettes og prissættes i EVELYN-tokens i YouTrack. Når en opgave er funded (af Evelyn selv eller af eksterne), igangsættes arbejdet. Når den er færdig, udbetales tokens til udvikleren, og transaktionen logges med ID på SolScan.
• Offentlig revision: Enhver kan følge med i, hvilke opgaver der er funded, hvem der har modtaget betaling, og hvilken transaktion der ligger bag. Dermed er der fuld gennemsigtighed i systemets økonomi uden at afsløre den underliggende strategi.
• Funding af opgaver: Opgaver bliver kun udført, hvis de er funded. Investorer og udviklere kan selv gå ind og sponsorere opgaver, hvis de tror på systemet.

10. Fremtidige emner / TODO

• Bedre adgangsbegrænsning: Overvej, hvordan private plugins i Nenjim kan beskyttes bedre end “security by obscurity”.
• Automatisk tuning af allokeringsprocenter: Undersøg muligheder for at lade systemet lære og tilpasse sin interne kapitalallokering over tid (AI-drevet tuning).
• Flere tradingstrategier: Udvid Evelyn med mulighed for at tilføje alternative, konkurrerende scoring-algoritmer.
• Bedre penalty-funktioner ved close: Implementer og test mere avanceret straflogik for lukning af positioner.
• Ekstra fail-safes: Tilføj flere automatiske stopmekanismer for at undgå at systemet “vipper omkuld” i ekstreme markedsbevægelser.
• Open API for ekstern integration: Gør det muligt at tilføje eksterne datafeeds, udveksle signaler med andre systemer, eller automatisere funding-opgaver.

11. Statusservice og referencepris

Evelyn er navnet på det samlede system. com.r35157.evelyn.service.status.EvelynStatusService indsamler og persisterer statusindeks for én navngiven instans og giver consumers adgang til den samme referencepris, som Evelyn Price Index bruger. Referenceimplementeringen er EvelynStatusServiceImpl under com.r35157.evelyn.service.status.impl.ref. Hub'en ejer fortsat startup af de enkelte processer.

AssetPrice getReferencePrice(Instant timestamp) beregner prisen for det angivne tidspunkt:

Start:          2026-07-31T22:00:00Z
Startpris:      15.00 USDT pr. EVE
Årlig faktor:   1.20
Årslængde:      31,536,000 sekunder
referencePrice = 15.00 × 1.20^(elapsedSeconds / 31,536,000)

Resultatet indeholder det kanoniske EVE/USDT-tradingpar, så quote-valutaen er eksplicit. Prisen er 15 ved start og 18 efter ét 365-dages år. Statusindekset bruger ((actualPrice / referencePrice) - 1) × 10 med samme samplingtidspunkt og samme beregning og konstanter. Den eksisterende konvention om at behandle USDT som USD i indekset bevares.

Referenceprisen beregnes ved hvert kald uden tickeropslag, historikadgang, workers eller ændring af historikken. Kaldet virker før sampling starter og mens den er stoppet, også uden provisionerede historikfiler. null afvises med NullPointerException, og tidspunkter før kurvens start afvises med IllegalArgumentException.

Production og Test bevarer separate navne, historikker, livscyklusser og Mission Control-charts. Historikfilerne ligger fortsat i data/evelyn/<instance-name>/status.log med formatversion 1. Sampling sker fortsat med cirka ét minuts fast forsinkelse, og et punkt persisteres før publicering i et immutable snapshot. stop() rydder kun hukommelsen og beholder navnereservationen, restart genindlæser filen, og close() frigiver navnet efter sikker terminering. EvelynStatusIndexPoint bliver i sin eksisterende package med alle seks indeksfelter; kun Evelyn Price Index beregnes og vises, mens de øvrige fem felter fortsat er nul. Legacy-rebalancering er fortsat inaktiv.

12. Perps-service og Mission Control

EvelynPerpsService udleverer et immutable PerpsSnapshot gennem det parameterløse getPositionsSnapshot(). Læsning foretager ingen integrationskald. Hub'en starter separate processer evelyn.perps.prod og evelyn.perps.test, hver med sin eksisterende wallet-liste: seks PROD-adresser og én TEST-adresse fra issue #98. Begge får en fælles read-only JupiterPerpsOverview og en fælles PhoenixPerpsService; sidstnævnte er registreret som phoenix.perps.default. De eksisterende Jupiter-services til handel og alarmer beholder deres afhængigheder og cache.

Servicen læser asynkront ved start og venter 60 sekunder efter hvert fuldført gennemløb. Runder overlapper ikke og afhænger ikke af EMC's synlighed. Jupiter-overblikket bruger ét REST-opslag pr. wallet. Phoenix bruger trader-state, metadata og én mark price pr. unikt åbent marked. Begge har 10 sekunders request-timeout; Phoenix bevarer fælles pacing og 429-cooldown. En fuld opdatering tager opslagstid plus pausen, ikke nødvendigvis ét minut. Implementeringens close() afbryder worker'en; consumer-API'et har kun læsning.

Snapshot'et adskiller isolerede positioner fra Cross-konti med egne balancer. Pengebeløb er præcise USD-decimaler, og null betyder utilgængelig. Før første succes indeholder hver konfigureret wallet/venue en ukendt scope, ingen syntetiske positioner. Succes publiceres pr. wallet/venue; en fejl beholder den kombinations sidste observation og oprindelige succes-tidspunkt. Andre wallets/venues forsøges stadig. Et gyldigt tomt svar rydder den pågældende scope og kan totalisere nul; HTTP-/formatfejl kan ikke. En gyldig Cross-konto med kapital bevares, selv om dens sidste position lukkes.

EMC viser Position | Direction | Margin | Collateral | Leverage | Exposure | Value | uPnL under den synlige rod Perpetual Contracts. Isolerede positioner har wallet → venue → position; Phoenix Cross har wallet → venue → Cross → position. Positionens konto-ID bestemmer identitet og tilhørsforhold, aldrig instrumentteksten. Wallets følger den hidtidige konfiguration med Jupiter før Phoenix. En venue uden positioner eller Cross-konti skjules og vises igen, når der kommer indhold. Skjulte venues indgår fortsat i snapshot og totaler; deres læsestatus findes på wallet-rækkens tooltip. En Cross-konto med kapital holder derfor Phoenix synlig, selv uden åbne positioner. Eksisterende foldestatus, markering og rækkeobjekter bevares; uændrede snapshots opdaterer ikke træet. Vinduesstart er 1100 × 600, og smallere vinduer kan scrolle vandret, når kolonnernes minimumsbredder kræver det.

Exposure er brutto: 100 USD Long + 100 USD Short giver 200 USD. Dollar-uPnL summeres med fortegn. Collateral/Value tæller hver isoleret position og hver delt Cross-konto én gang, inklusive ubrugt kapital på de inkluderede Cross-konti. Cross-positionernes marginkrav lægges ikke til faktisk kontokapital. Mangler en nødvendig del, er netop feltets total utilgængelig; en delsum præsenteres aldrig som total. Ingen summering eller gennemsnitsberegning af leverage eller PnL-procenter. Totalerne afhænger ikke af foldning.

Isoleret leverage er Exposure / positiv Collateral; uPnL-procent er 100 × pris-uPnL / positiv Collateral. På Cross-positioner er Collateral et initialt marginkrav i USD, ikke særskilt ejet kapital. Cross-gruppens leverage er bruttoeksponering / udiskonteret equity før estimerede exitgebyrer. Cross-positionernes leverage og ROI-procent er utilgængelige, fordi Phoenix-konventionerne ikke er verificeret; dollar-uPnL vises. Cross-positioners Value er ikke entydigt defineret og vises som —. Kontoudnyttelse er ikke implementeret.

Value er et estimat ved referencepriser, ikke et eksekverbart tilbud. Phoenix medregner collateral, pris-uPnL og signed uafregnet funding og fratrækker estimerede takergebyrer med kontoens fee override. Slippage, price impact, swaps, netværksgebyrer og kontorent indgår ikke. Ukendt spot-collateral gør de berørte værdiansættelser utilgængelige. Jupiter Value er foreløbig utilgængelig, fordi API'ets netværdi trækker åbningsgebyrer fra igen, og collateral-/profitloft-semantikken ikke er fuldt verificeret. Se Jupiter-overblikket og Phoenix-integrationen for datakilder, enheder og beregninger.

Beløb har tusindtalsseparator og to decimaler, leverage × og pris-uPnL et synligt fortegn. Positiv uPnL er grøn, negativ rød, afrundet nul neutral uden negativt nul. De svage Long/Short-baggrunde bevares; grupper har tydeligere skrift og ingen retningsfarve. Tooltips forklarer definitioner, manglende værdier og sidste succesfulde læsetidspunkt. Efter fejl markeres en synlig venue som retained; læsestatus for skjulte venues findes på wallet-rækkens tooltip. Gamle tal beskrives ikke som nye.

EMC spørger hver miljøservice straks ved åbning og hvert tredje sekund uden at blokere JavaFX-tråden. Skjul/luk stopper kun EMC-polling. Der er ingen sample-data, Refresh-knap, handel, signering, kontoaktivering eller automatisk genstart af Hub'en i denne læsevej. Den kanoniske systembeskrivelse findes i Evelyn: services og status.