Crypto Layer v1.22: z crypto skriptu na replay-safe runtime

Keď sa povie crypto bot, väčšina ľudí si predstaví jednoduchý flow:

strategy -> exchange API -> order

Toto je presne typ architektúry, ktorá funguje dovtedy, kým nenastane prvý reálny problém:

• request timeoutne,

• exchange odpovie neskoro,

• proces spadne medzi submitom a uložením stavu,

• príde partial fill,

• lokálny stav sa rozíde s exchange stavom,

• retry vytvorí duplicitný order,

• paralelný proces poškodí eventlog.

Preto som Crypto Layer nestaval ako obyčajný wrapper nad burzou. Aktuálna verzia 1.22 už funguje ako runtime-first systém postavený okolo eventov, replayu, snapshotov, idempotency a queue/writer modelu.

Inými slovami:

Crypto Layer už nie je len CLI pre crypto.
Je to replay-safe runtime foundation pre crypto execution.

---

Základná idea

Kľúčová architektonická zmena je, že exchange API nie je stred systému.

Stred systému je runtime truth:

events.jsonl -> reducer -> state.json -> validation -> certification

events.jsonl je source of truth. state.json je odvodený stav. Ak sa stav stratí, dá sa znovu postaviť z eventov. Ak si nie sme istí, či je stav správny, vieme ho certifikovať cez deterministic replay.

Toto je zásadný rozdiel oproti bežnému botovi, kde stav často žije iba v procese, v cache, alebo v ad-hoc JSON súbore.

---

Čo dnes funguje

Aktuálna séria releaseov uzavrela viacero runtime invariantov.

1. Event-sourced runtime

Runtime zapisuje business udalosti do append-only eventlogu:

events.jsonl

Z neho sa následne rebuildne stav:

state.json

To znamená, že stav nie je primárna pravda. Stav je projekcia.

Primárna pravda je história udalostí.

Toto umožňuje:

• rebuild,

• audit,

• replay,

• recovery,

• deterministické testovanie,

• snapshoty,

• validáciu integrity.

---

2. Runtime hardening

Vo verzii 1.15 sa riešili základné runtime chyby, ktoré by v dlhobežiacom systéme robili tiché problémy.

Opravené boli hlavne:

• duplicitné shell definície,

• daemon PID ownership,

• nepresný daemon stop status,

• slabé generovanie fill_id,

• false positive validácia pri snapshot/mock orderoch,

• hardening testy,

• zastaraná test dokumentácia.

Dôležitý princíp bol jednoduchý:

runtime nesmie ticho klamať

Ak status tvrdí, že proces je stopped, proces nesmie ďalej bežať. Ak shell obsahuje duplicitnú definíciu funkcie, testy to musia zachytiť. Ak validation niečo označí ako violation, musí to byť reálny problém, nie artefakt snapshotu.

---

3. Replay certification

Verzia 1.16 pridala deterministic replay certification.

Pribudli príkazy typu:

ce runtime.hash
ce runtime.certify

Runtime vie urobiť:

rebuild #1 -> state hash #1
rebuild #2 -> state hash #2
compare

Ak oba hashe sedia, systém vie povedať:

same events -> same state

Toto je veľmi dôležitý invariant. Bez neho je replay iba nádej. S hash certifikáciou je replay overiteľný fakt.

---

4. Snapshoty a delta replay

Vo verziách 1.16 a 1.19 pribudol snapshot/checkpoint model.

Snapshot obsahuje:

{
  "snapshot_id": "snap-...",
  "last_event_seq": 123,
  "state_hash": "...",
  "schema_version": 1
}

Verzia 1.19 uzavrela dôležitý invariant:

full replay == snapshot + delta replay

To znamená:

snapshot state + events after last_event_seq -> rovnaký state ako full replay

Toto je základ pre dlhodobejší runtime, kde eventlog môže rásť a full replay od nuly by časom začal byť drahý.

---

5. Execution idempotency

Verzia 1.17 riešila najnebezpečnejšiu obchodnú chybu: duplicitný submit.

V trading systéme je kritické, aby jeden intent náhodou nevytvoril dva reálne ordery.

Preto vznikol identity chain:

intent_id -> client_order_id -> idempotency_key -> side_effect_id -> exchange_order_id

Runtime blokuje duplicity podľa:

• intent_id,

• client_order_id,

• idempotency_key.

Invariant je:

same intent cannot duplicate real submit

Toto je rozdiel medzi systémom, ktorý iba volá API, a systémom, ktorý rozmýšľa nad execution safety.

---

6. Exchange uncertainty recovery

Verzia 1.18 riešila ďalší reálny problém:

submit request bol odoslaný, ale odpoveď timeoutla

V takom stave systém nesmie slepo skúsiť submit znova. To by mohlo vytvoriť duplicitný order.

Preto pribudol stav:

side_effect/unknown

A flow:

submit timeout -> unknown -> reconciliation/resolve

Kým existuje unknown submit pre rovnaký intent/client/idempotency key, retry je blokovaný.

Invariant:

unknown exchange result must not cause unsafe retry

Toto je production-grade behavior. Nie je to len error handling. Je to runtime safety model.

---

7. Queue ako serialized write path

Verzia 1.20 pridala runtime queue.

Predtým vedeli producers zapisovať priamo do eventlogu. To je jednoduché, ale pri paralelných producer procesoch, daemone, ingest slučke alebo recovery operáciách vzniká concurrency pressure.

Preto vznikol model:

producer -> queue/pending -> drain -> events.jsonl

Queue má adresáre:

queue/pending
queue/processing
queue/done
queue/failed

Test overuje, že paralelní producers nespôsobia:

• stratu eventov,

• duplicitné event IDs,

• poškodené seq,

• invalid JSON.

Invariant:

concurrent producers -> queue -> serialized writer -> monotonic events.jsonl

---

8. Writer daemon

Verzia 1.21 pridala writer daemon.

Queue už nebolo potrebné drainovať iba ručne. Writer daemon priebežne spracúva queue a zapisuje eventy do canonical eventlogu.

Flow:

queue -> writer daemon -> locked append -> events.jsonl

Writer vie:

• start,

• stop,

• status,

• heartbeat,

• batch drain,

• stale processing recovery,

• truthful stop status.

Dôležitý detail je recovery zaseknutých queue itemov:

processing -> pending -> drain -> done

To rieši situáciu, keď proces spadne uprostred spracovania queue itemu.

---

9. Queue producer mode

Verzia 1.22 uzavrela queue architektúru.

Pribudol write mode:

CE_RUNTIME_WRITE_MODE=direct
CE_RUNTIME_WRITE_MODE=queue

V direct režime command zapisuje priamo:

producer -> ce_emit_event -> events.jsonl

V queue režime command iba enqueueuje:

producer -> ce_emit_event -> queue/pending -> writer/drain -> events.jsonl

Dôležité je, že queued flow musí produkovať rovnaký výsledný stav ako direct flow.

Test potvrdzuje:

direct command flow == queued command flow

Konkrétne:

normalized_projection_equal: true

Toto znamená, že queue nie je iba transportná vrstva. Queue zachováva runtime semantiku.

---

Aktuálna release línia

Posledné verzie uzavreli základnú runtime chrbticu:

1.15 = runtime hardening
1.16 = replay certification
1.17 = execution idempotency
1.18 = exchange uncertainty recovery
1.19 = snapshot delta replay
1.20 = single writer runtime queue
1.21 = writer daemon drain mode
1.22 = queue producer mode

Aktuálny test suite:

{
  "status": "pass",
  "passed": 13,
  "failed": 0
}

Testy pokrývajú:

certification
daemon
hardening
idempotency
ingest
queue
reconciliation
recovery
runtime
snapshot
uncertainty
write_mode
writer

---

Čo je na tom dôležité

Najväčší posun nie je v tom, že systém vie zavolať exchange API.

Najväčší posun je v tom, že systém začína mať runtime vlastnosti:

truth
replay
certification
recovery
idempotency
serialization

To sú vlastnosti, ktoré oddeľujú skript od runtime systému.

Bežný crypto bot rieši hlavne otázku:

Aký order mám poslať?

Crypto Layer rieši najprv otázky:

Viem dokázať, čo sa stalo?
Viem rebuildnúť stav?
Viem zabrániť duplicitnému execution?
Viem bezpečne reagovať na timeout?
Viem serializovať zápisy?
Viem obnoviť runtime po páde?

Až nad tým dáva zmysel stavať stratégiu alebo AI rozhodovanie.

---

Súčasný stav projektu

Projekt by som dnes neopísal ako production trading bot.

Presnejší opis je:

replay-safe, snapshot-safe, idempotent, queue-capable crypto runtime foundation

To znamená, že execution substrate už má pevné základy, ale ešte nie je hotový celý trading systém.

Hotové alebo funkčné:

• eventlog ako source of truth,

• reducer-based state projection,

• deterministic replay certification,

• snapshot metadata,

• snapshot + delta replay,

• execution idempotency,

• unknown exchange result handling,

• runtime validation,

• reconciliation/recovery základ,

• queue primitive,

• writer daemon,

• queue producer mode,

• test suite s 13 passing testami.

Ešte zostáva:

• realtime ingest daemon,

• silnejšie dedupe pre polling/websocket ingest,

• exchange capability contract,

• risk engine,

• strategy layer,

• production-grade exchange reconciliation,

• dlhodobá observability/board vrstva,

• live execution hardening proti špecifickým edge-case burzy.

---

Kam ďalej

Najbližší prirodzený krok je realtime ingest daemon.

Teraz už existuje potrebný základ:

ingest producer -> queue mode -> writer daemon -> eventlog -> reducer -> state

Ďalší release by teda mal riešiť:

1. ingest daemon start/stop/status
2. cursor-safe polling loop
3. ingest events cez queue mode
4. writer daemon ako jediný commit path
5. dedupe podľa exchange order/fill/event ID
6. test.ingest_daemon
7. invariant: repeated polling does not duplicate fills/orders

Až potom dáva zmysel posúvať sa k vyšším vrstvám ako strategy engine alebo AI execution loop.

---

Záver

Crypto Layer sa za posledné verzie posunul z úrovne crypto tooling do úrovne runtime foundation.

Aktuálne najdôležitejšie invarianty sú:

runtime nesmie ticho klamať
same events -> same state
snapshot + delta == full replay
same intent cannot duplicate submit
unknown result blocks unsafe retry
concurrent producers do not corrupt eventlog
queued flow == direct flow

To je dobrý základ.

Nie preto, že systém už robí všetko.

Ale preto, že to, čo už robí, robí cez runtime model, ktorý je replayable, auditovateľný, testovaný a pripravený na daemon-first architektúru.

Toto je presne bod, kde sa crypto projekt prestáva správať ako sada skriptov a začína sa správať ako systém.