Files
zeekayandHanzo Dev 9eed4281e9 feat(chain): real EVM backend, and fix two ways it could lose money
Blue built the on-chain half (evmchain.go, evmmarket.go): keys derived from the
deploy mnemonic at m/9000'/<networkId>'/<envId>'/<index>, signed transactions,
receipts awaited, balances read from chain, and Earn driving the deployed Liquid
contracts so the LTV ceiling is enforced on chain rather than re-derived here.
An account has ONE address holding the coin and every token — per-asset
addresses only made sense while each asset pretended to be its own chain.

Red then attacked it and found two real defects; its tests are kept as the
regression suite:

- Two customers could share a private key. Claiming a chainIndex was a read of
  the maximum followed by a write, so accounts opened at the same moment took
  the same number — the same derivation path, address and balance. A partial
  unique index on chainIndex now settles the race and the loser retries.
- A chain outage was a bank outage. The dial happens under the singleton lock,
  so every caller queued behind its own 15s timeout: three concurrent requests
  took 45s. A failed dial is now remembered briefly, so one caller pays the
  timeout and the rest are refused immediately — the answer they were getting
  anyway.

Also: a send that failed recorded no reason, which cost hours to diagnose, so
the cause now reaches the log while the caller still learns only that it failed.
And a chain that publishes no base fee gets a legacy transaction instead of an
EIP-1559 one — both are real transactions, and assuming only the second strands
the bank on chains it can otherwise serve.

Verified against a local Lux C-Chain (96369): the derived address matches
`cast wallet address` at the same path, balances read, and a transfer signs and
broadcasts. That node's RPC implements neither eth_getTransactionReceipt nor
eth_getTransactionByHash, so the send cannot be confirmed there — and the bank
refuses rather than reporting a hash it cannot verify.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-25 11:24:42 -07:00

Symbolic link
1 line
17 B
Plaintext