mirror of
https://github.com/luxfi/bank.git
synced 2026-10-30 17:02:07 +00:00
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]>