od read-only Binance integrácie po prvý bezpečný live order lifecycle

Keď som začal skladať vlastný crypto execution layer, cieľ nebol napísať ďalšieho „bota“, ktorý niekam pošle market order a potom sa tvári, že trading je vyriešený. Cieľ bol iný: mať malú, auditovateľnú, event-sourced runtime vrstvu, ktorá vie pracovať s burzami bezpečne, opakovateľne a s jasnou hranicou medzi read-only operáciami, preflightom a skutočnou mutáciou na exchange.

Verzia 1.44 je prvý stabilizačný checkpoint po tom, čo sa podarilo uzavrieť kompletný Binance live lifecycle:

plan -> guarded submit -> readback -> open_orders verify -> guarded cancel -> post-cancel readback -> portfolio verify

Nie je to veľký order. Nie je to trading stratégia. Nie je to arbitrage engine. Je to niečo dôležitejšie: dôkaz, že runtime vie bezpečne prejsť cez prvú skutočnú mutation boundary na Binance a zároveň zostať pod kontrolou.

---

Čo je Crypto OS Layer

Crypto OS Layer je shell/Rust execution runtime pre crypto burzy. Nie je to len wrapper nad API. Je to vrstva, ktorá drží stav cez event log, vie robiť replay, snapshot, certifikáciu, recovery, idempotency a strict live gates.

Základná filozofia je jednoduchá:

read-only je lacné
preflight je povinný
live mutation je výnimka
každý side effect musí byť auditovaný

Runtime má dva backendy:

shell fallback
native Rust backend ce-ws

A dôležité je, že sa testuje parity medzi nimi. Stav vytvorený cez shell cestu musí projektovať rovnako ako stav cez native backend. Bez toho by event-sourcing model nebol dôveryhodný.

---

Stav pred 1.44

Coinmate cesta bola v projekte už dlhšie. Binance sa dopĺňala postupne a zámerne konzervatívne:

1.37  Binance fixture-first adapter
1.38  signed read-only fixture path
1.39  live read-only account snapshot + time guard
1.40  observability: open orders, trades, filters, portfolio snapshot
1.40.1 data_source isolation: live nesmie miešať fixture dáta
1.41  preflight-only order planner
1.41.1 structured planner UX errors
1.42  guarded tiny submit boundary
1.42.1 gate decision tree
1.43  guarded tiny cancel
1.43.1 cancel ACK identity hotfix
1.44  stabilizačný checkpoint

Táto postupnosť bola zámerná. Najprv sa muselo potvrdiť, že vieme čítať účet bez side effectov. Potom že vieme normalizovať order proti Binance filtrom. Potom že vieme zablokovať zlý order. Až potom malo zmysel prejsť k prvému reálnemu submitu.

---

Binance read-only vrstva

Pred akoukoľvek mutáciou musel runtime vedieť bezpečne čítať:

account snapshot
server time
open orders
order status
trades
exchangeInfo filters
portfolio snapshot

Snapshot účtu je redacted. To znamená, že neukazuje presné balances, ale vie povedať, ktoré aktíva sú non-zero a či je account endpoint čitateľný.

Príklad:

{
  "exchange": "binance",
  "status": "ok",
  "data_source": "live",
  "balance_count": 5,
  "nonzero_assets": ["BNB", "USDC", "LDINIT", "LDHYPER", "LDSIGN"],
  "live_side_effect": false,
  "credentials_redacted": true
}

Toto je dôležité: read-only príkazy musia explicitne niesť:

data_source=live
live_side_effect=false
credentials_redacted=true

V 1.40 sa našiel bug, kde portfolio snapshot miešal fixture open order do live výstupu. To bol dobrý príklad, prečo musí byť data_source explicitný. Od 1.40.1 platí, že live snapshot nesmie potichu použiť fixture fallback.

---

Time guard

Binance signed endpointy sú citlivé na čas. Preto runtime pred submit/cancel operáciou robí server-time guard:

{
  "exchange": "binance",
  "drift_ms": 134,
  "abs_drift_ms": 134,
  "recv_window_ms": 5000,
  "within_recv_window": true,
  "status": "pass",
  "guard": "recv_window"
}

Toto je malá vec, ale bez nej je live trading cez Binance API zbytočne krehký. Ak timestamp drift presiahne recvWindow, nechcem aby sa systém tváril, že je všetko v poriadku.

---

Order planner: preflight pred mutáciou

Pred prvým live submitom vznikol preflight planner:

ce exchange.binance.order.plan binance-main BTCUSDC buy quote 10 50000 ce_live_usdc_001

Výstup potvrdil:

symbol: BTCUSDC
side: buy
order_type: limit
amount_kind: quote
requested_amount: 10
price: 50000
quantity: 0.0002
required_free_asset: USDC
required_free_amount: 10
min_notional_ok: true
balance_sufficient: true
risk_cap_ok: true
preflight_status: approved
mutation_executed: false

Planner používa live exchangeInfo filtre:

tickSize
stepSize
minQty
minNotional
symbol status
supported order types

A zároveň kontroluje risk cap:

BINANCE_TINY_LIVE_MAX_NOTIONAL

Preflight je read-only. Ak planner povie approved, ešte stále sa nič neposlalo na burzu. To je presne správna hranica.

---

Gate tree: mutácia musí byť vedomá

V 1.42.1 pribudol explicitný gate decision tree. Tiny submit musí prejsť cez:

confirm_token
env_gate
time_guard
preflight
submit

Bez env gate je submit zablokovaný aj so správnym tokenom:

{
  "exchange": "binance",
  "status": "blocked",
  "reason": "live_submit_env_gate_required",
  "gates": {
    "confirm_token": "pass",
    "env_gate": "fail",
    "time_guard": "not_checked",
    "preflight": "not_checked"
  },
  "live_side_effect": false,
  "mutation_executed": false
}

So zlým tokenom sa zastaví ešte skôr:

{
  "status": "blocked",
  "reason": "confirm_token_required",
  "gates": {
    "confirm_token": "fail",
    "env_gate": "not_checked",
    "time_guard": "not_checked",
    "preflight": "not_checked"
  },
  "mutation_executed": false
}

Toto je presne ten typ paranoje, ktorý chcem pri live tradingu. Nechcem, aby order odišiel len preto, že niekde zostal zapnutý nejaký flag alebo niekto spustil starý príkaz z histórie shellu.

---

Prvý reálny Binance tiny submit

Prvý live order bol úmyselne malý limit buy na páre BTCUSDC:

BINANCE_ENABLE_TINY_LIVE_SUBMIT=1 
BINANCE_TINY_LIVE_MAX_NOTIONAL=10 
ce exchange.binance.order.submit.tiny 
  binance-main BTCUSDC buy quote 10 50000 
  ce_live_usdc_001 
  BINANCE-TINY-LIVE-ce_live_usdc_001

Výsledok:

{
  "exchange": "binance",
  "status": "submitted",
  "data_source": "live",
  "preflight_status": "approved",
  "client_order_id": "ce_live_usdc_001",
  "gates": {
    "confirm_token": "pass",
    "env_gate": "pass",
    "time_guard": "pass",
    "preflight": "pass"
  },
  "order": {
    "status": "new",
    "exchange": "binance",
    "order_id": "9289068208",
    "client_order_id": "ce_live_usdc_001",
    "side": "buy",
    "type": "limit",
    "symbol": "BTCUSDC",
    "amount": "0.0002",
    "filled_base": "0.00000000",
    "filled_quote": "0.00000000",
    "price": "50000"
  },
  "live_side_effect": true,
  "mutation_attempted": true,
  "mutation_executed": true,
  "requires_reconciliation": false
}

Limit price bol zámerne ďaleko pod marketom, aby order zostal otvorený a nefillol sa okamžite. Cieľom nebolo obchodovať. Cieľom bolo otestovať životný cyklus.

Readback po submite potvrdil:

order.status: new
open_orders: 1
filled_base: 0
filled_quote: 0

---

Guarded cancel

Po úspešnom submite prišiel symetrický cancel flow. Ani cancel nemá byť neguardnutá mutácia.

Cancel command:

BINANCE_ENABLE_TINY_LIVE_CANCEL=1 
ce exchange.binance.order.cancel.tiny 
  binance-main BTCUSDC ce_live_usdc_001 client 
  BINANCE-TINY-CANCEL-ce_live_usdc_001

Gates:

confirm_token
env_gate
time_guard
pre_readback
cancel
post_readback

Výsledok:

{
  "exchange": "binance",
  "status": "cancelled",
  "symbol": "BTCUSDC",
  "order_ref": "ce_live_usdc_001",
  "ref_kind": "client",
  "gates": {
    "confirm_token": "pass",
    "env_gate": "pass",
    "time_guard": "pass",
    "pre_readback": "pass",
    "cancel": "pass",
    "post_readback": "pass"
  },
  "pre_cancel_readback": {
    "status": "new",
    "client_order_id": "ce_live_usdc_001",
    "order_id": "9289068208"
  },
  "post_cancel_readback": {
    "status": "canceled",
    "client_order_id": "ce_live_usdc_001",
    "order_id": "9289068208"
  },
  "open_orders_after": {
    "open_order_count": 0
  },
  "open_order_still_present": false,
  "live_side_effect": true,
  "mutation_attempted": true,
  "mutation_executed": true,
  "requires_reconciliation": false
}

Tým sa uzavrel prvý kompletný Binance live lifecycle.

---

Cancel ACK identity hotfix

Pri canceli sa objavil zaujímavý detail: Binance cancel ACK môže vrátiť iný client id field než pôvodný CE client id. Funkčne bol cancel v poriadku, ale audit normalizácia nesmie prepísať identitu orderu.

Preto vznikol 1.43.1 hotfix:

cancel_ack.client_order_id zachováva pôvodný CE client id
cancel_ack.orig_client_order_id
cancel_ack.cancel_client_order_id

Toto je typ veci, ktorá sa ukáže až pri reálnom live lifecycle. Fixture testy sú potrebné, ale realita exchange API má vždy detaily navyše.

---

1.44 ako stabilizačný checkpoint

Verzia 1.44 nepridáva ďalšiu agresívnu funkciu. Práve naopak. Je to stabilizačný release po úspešnom live lifecycle.

Obsahuje:

release notes
Binance live lifecycle runbook
changelog checkpoint
verziu 1.44
release verification

Zmysel 1.44 je povedať: tento stav je dobrý checkpoint. Tu sa oplatí zastaviť, zdokumentovať flow a až potom rozmýšľať, čo ďalej.

---

Test matrix

Runtime sa testuje na:

Linux shell
Linux native/Rust
Termux shell
Termux native/Rust

Kľúčové testy:

backend_parity
binance_live_readonly
binance_observability
binance_order_plan
binance_tiny_live_submit
binance_tiny_live_cancel
portfolio_snapshot
multi_exchange_readonly_snapshot
submit_atomic
cancel_atomic
recovery
reconciliation
release_verify

1.44 prešiel Linux shell/native. Termux 1.44 native test suite beží ako posledná validačná vrstva.

---

Čo funguje dnes

Aktuálny stav po 1.44:

Coinmate:
  live-capable path existuje

Binance:
  read-only live OK
  account snapshot OK
  open orders OK
  order status OK
  trades OK
  exchangeInfo filters OK
  order planner OK
  tiny live submit OK
  tiny live cancel OK

Runtime:
  event-sourced state
  shell/native backend parity
  snapshots
  replay certification
  recovery
  audit sanitizer
  idempotency model

Najdôležitejšie bezpečnostné pravidlá ostávajú:

Binance withdraw disabled
market submit disabled
live submit vyžaduje env gate + exact token + preflight
live cancel vyžaduje env gate + exact token + readback

---

Čo ešte nie je hotové

Toto stále nie je trading stratégia. Zámerne.

Chýba alebo ešte nie je povolené:

Binance market order live submit
Binance general live cancel mimo tiny flow
withdraw flow
portfolio-level risk engine
multi-exchange strategy
arbitrage
position sizing
long-running autonomous daemon pre trading

To je v poriadku. Execution layer má najprv bezpečne zvládnuť primitíva. Až potom má zmysel stavať stratégiu.

---

Čo ďalej

Ďalší rozumný smer nie je okamžite pridávať viac risku. Skôr:

post-live certification bundle
persistent live logbook artifact
stronger reconciliation event po submit/cancel
balance probe command
small portfolio risk policy
controlled repeated tiny lifecycle test

Až potom by som riešil všeobecnejší Binance order submit flow.

---

Záver

Crypto OS Layer 1.44 je prvý release, kde Binance integrácia prešla z read-only/preflight sveta do reálnej mutation boundary a späť.

Najdôležitejší výsledok nie je to, že sa podarilo poslať order. To vie každý API script.

Dôležitejšie je toto:

order bol naplánovaný
preflight bol schválený
submit bol explicitne odomknutý
time guard prešiel
order bol vytvorený
readback ho našiel
open orders ho ukázali
cancel bol explicitne odomknutý
cancel prešiel
post-readback ukázal canceled
open orders boli prázdne
portfolio snapshot sedel

To je rozdiel medzi skriptom a execution layerom.

Verzia 1.44 je preto dobrý checkpoint: malý live order, veľa guardov, jasný audit trail a nulová romantika okolo toho, čo znamená bezpečne poslať mutáciu na crypto exchange.