577 lines
38 KiB
Markdown
577 lines
38 KiB
Markdown
#<center><H1>Evelyn<br>Documentation</H1></center>
|
||
|
||
**Indholdsfortegnelse:**
|
||
<!-- TOC -->
|
||
* [1. Introduktion formål og vision](#1-introduktion-formål-og-vision)
|
||
* [1.1 Tokens som vedvarende aktiv – selv efter systemnedbrud](#11-tokens-som-vedvarende-aktiv--selv-efter-systemnedbrud)
|
||
* [2. Tokenøkonomi og finansiering](#2-tokenøkonomi-og-finansiering)
|
||
* [2.1 Allokering af overskud](#21-allokering-af-overskud)
|
||
* [2.2 Buybacks og burn](#22-buybacks-og-burn)
|
||
* [2.3 Finansiering af udvikling](#23-finansiering-af-udvikling)
|
||
* [2.4 Ansvarsplacering og overskud](#24-ansvarsplacering-og-overskud)
|
||
* [2.5 Neutralitet og ligestilling](#25-neutralitet-og-ligestilling)
|
||
* [2.6 Vejen mod autonomi](#26-vejen-mod-autonomi)
|
||
* [3. Tradingmotorens filosofi - AFETS](#3-tradingmotorens-filosofi---afets)
|
||
* [3.1 Ikke-spekulativ tilgang](#31-ikke-spekulativ-tilgang)
|
||
* [3.2 Søgning efter ligevægt](#32-søgning-efter-ligevægt)
|
||
* [3.3 Anti-fragilitet](#33-anti-fragilitet)
|
||
* [4. Trekantmodellen - Longs, Shorts og Margin](#4-trekantmodellen---longs-shorts-og-margin)
|
||
* [5. Score-beregning – systemets beslutningsmotor](#5-score-beregning--systemets-beslutningsmotor)
|
||
* [5.1 Principper for score-beregning](#51-principper-for-score-beregning)
|
||
* [5.2 Beregning af score for åbning af positioner](#52-beregning-af-score-for-åbning-af-positioner)
|
||
* [5.3 Straf for store positioner (penalty)](#53-straf-for-store-positioner-penalty)
|
||
* [5.4 Beregning af score for lukning af positioner](#54-beregning-af-score-for-lukning-af-positioner)
|
||
* [5.5 Fleksibilitet og udvikling](#55-fleksibilitet-og-udvikling)
|
||
* [6. Iteration og rebalancering](#6-iteration-og-rebalancering)
|
||
* [7. Likviditetsstyring og gearing](#7-likviditetsstyring-og-gearing)
|
||
* [7.1 Tærskler og dvale](#71-tærskler-og-dvale)
|
||
* [8. Risici, fail-safes og antifragilitet](#8-risici-fail-safes-og-antifragilitet)
|
||
* [9. Udvikling, YouTrack-integration og offentlig gennemsigtighed](#9-udvikling-youtrack-integration-og-offentlig-gennemsigtighed)
|
||
* [10. Fremtidige emner / TODO](#10-fremtidige-emner--todo)
|
||
* [11. Statusservice og referencepris](#11-statusservice-og-referencepris)
|
||
<!-- TOC -->
|
||
|
||
## 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
|
||
1) Reduktion af gearing (hvis anvendt)
|
||
1) Afbetaling af gæld for tidligere tab
|
||
1) Tilførsel af likviditet i Evelyn IOU-tokenets pool
|
||
1) Betaling for udvikling og vedligehold, samt drift af systemet
|
||
1) 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:
|
||
|
||
```text
|
||
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, én mark price pr.
|
||
unikt åbent marked, ét TWAP-opslag, når der er positioner, og et risikolæs pr. synlig
|
||
konto. Lokal trader-adresseafledning bruger den eksisterende Solana-afhængighed.
|
||
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 | Risk | Direction | Margin | Collateral | Leverage | Exposure | Value | uPnL | TWAP**
|
||
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; kun ændrede rækkeværdier eller børn opdateres, også når risikodata
|
||
ældes i et ellers uændret snapshot. Vinduesstart er 1100 × 600,
|
||
og smallere vinduer kan scrolle vandret, når kolonnernes minimumsbredder kræver det.
|
||
|
||
TWAP vises kun på en eksisterende Phoenix-position, når ordren selv har et faktisk
|
||
fill og resterende delordrer. Ufyldte ordrer opretter ingen rækker og vises heller
|
||
ikke på en position, som allerede fandtes. Progressbaren måler udførte delordrer;
|
||
teksten er estimeret resterende tid fra seneste TWAP-observation, fx `≈ 28:32:10`
|
||
eller `≈ 128:32:10`, uden timerollover eller live-nedtælling. Tooltip viser
|
||
`Estimated completion`, totalstørrelse, næste delordrestørrelse, fyldt mængde og
|
||
observationstid. Restordrer kan være mindre. Dollarstørrelser bruger samme Phoenix-
|
||
markpris som positionen og kræver ikke Ticker-priser; uden markpris bevares mængderne,
|
||
mens berørte dollarværdier og totaler bliver utilgængelige. En TWAP-læsefejl beholder
|
||
hele venue-observationen og viser `Retained` i cellen. Se
|
||
[TWAP-beregninger og begrænsninger](PhoenixPerps.md#twap-observations) for slots,
|
||
forfaldne tidsplaner og prisestimater.
|
||
|
||
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 —. Risk viser særskilt
|
||
vedligeholdelsesmarginens udnyttelse; det er ikke samlet initial-marginudnyttelse eller fri købekraft.
|
||
|
||
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](JupiterPerpsOverview.md) og [Phoenix-integrationen](PhoenixPerps.md)
|
||
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.
|
||
|
||
### Risiko i Perps
|
||
|
||
Risk står ved positionsnavnet og bruger tekst og en statusprik, mens Long/Short-
|
||
baggrundene bevares. På isolerede positioner vises rapporteret likvideringsafstand:
|
||
|
||
```text
|
||
Long: 100 × (venue-referencepris − likvideringspris) / venue-referencepris
|
||
Short: 100 × (likvideringspris − venue-referencepris) / venue-referencepris
|
||
```
|
||
|
||
Ejeren valgte 24. oktober 2026 **neutral positiv afstand og rød ved nået/overskredet
|
||
grænse**. Der er ingen generelle grøn/gul/rød-grænser pr. marked. Positiv uPnL eller
|
||
lav leverage tildeler ikke en sikkerhedsstatus. Negativ afstand bevarer fortegnet;
|
||
det er en observeret grænseoverskridelse, ikke bevis for gennemført likvidering.
|
||
Manglende, nul og negative sentinel-priser er ukendte, ikke uendelig sikkerhed.
|
||
Tooltip viser venue-priser, præcis afstand, eventuel rapporteret tier og observationstid.
|
||
|
||
Phoenix' egne tiers bruger grøn **OK**, gul **At risk**, orange **Cancellable** og
|
||
rød **Liquidatable**, **Backstop** eller **High risk**. En selvstændigt gyldig
|
||
kontoklasse kan bruges, selv om en positiv likvideringspris mangler. På Cross-kontoen:
|
||
|
||
```text
|
||
MM utilization = 100 × maintenance margin / positiv effective collateral
|
||
USD headroom = effective collateral − maintenance margin
|
||
```
|
||
|
||
MM er marginudnyttelse, ikke likvideringssandsynlighed eller en prisafstand. Phoenix'
|
||
præcise tier styrer likvideringsstatus; visningsafrunding bruges ikke til klassifikation.
|
||
Ved ikke-positiv effektiv sikkerhed er procenten utilgængelig. En kendt tom konto
|
||
uden vedligeholdelseskrav vises som **No positions**; det lover ikke noget om fremtidige
|
||
ordrefills. Manglende nødvendige data eller modstridende
|
||
Safe-data må ikke vises grønt. Cross-positioner viser **Shared** med konto-ID i tooltip,
|
||
og kontoens risiko tælles kun én gang uanset antallet af positioner.
|
||
|
||
Grupper viser værste kendte risiko og antal ukendte/forældede scopes uden gennemsnit
|
||
af afstande eller MM-procenter. En neutral afstand gør ikke hele gruppen grøn; **Distance
|
||
only** angiver, at der ikke er tildelt en sikkerhedsklasse. Før første succes er en
|
||
venue ukendt. En tidligere tom venue kan også blive forældet, selv om dens overskrift
|
||
er skjult. Kendt kritisk risiko forbliver rød med usikkerhedsmarkering efter fejl/aldring.
|
||
|
||
Risikodata bliver **Stale** ved fem minutter fra ældste nødvendige observation,
|
||
straks ved venue- eller snapshot-læsefejl eller ved et fremtidigt tidsstempel. Også
|
||
et fejlet `getPositionsSnapshot()` genviser den beholdte observation med fejlstatus.
|
||
Fem minutter er en grænse
|
||
for datakvalitet, ikke en garanti for sikkerhed i perioden. Langsomme normale runder
|
||
kan derfor give Stale. Den eksisterende tresekunders UI-polling genvurderer alder,
|
||
også når servicen returnerer samme snapshot, uden en ny timer eller flere venue-kald.
|
||
Forældet eller ufuldstændig ikke-kritisk risiko får ingen grøn statusprik.
|
||
Tidsstempler er modtagelsestider; API-lag og separate pris-/kontolæs begrænser aktualiteten.
|
||
Visningen viser senest observeret risiko og er ikke en livealarm. Datakilderne er
|
||
beskrevet i [Jupiter-overblikket](JupiterPerpsOverview.md) og
|
||
[Phoenix-risikolæsningen](PhoenixPerps.md#venue-reported-account-risk).
|
||
|
||
Den kanoniske systembeskrivelse findes i
|
||
[Evelyn: services og status](../../r35157_docs/projects/evelyn/README.md#evelynperpsservice).
|