Personal IndexEvery blockchain integration starts from the same custody requirements: build a transaction, get it signed, broadcast it, and know when it's actually final. What makes each one different is how much those steps disagree with each other across networks.
Account models diverge early
UTXO-based chains like Bitcoin track spendable outputs, not balances — a transaction consumes specific outputs and produces new ones. Account-based chains like EVM networks and Tron track a single mutable balance per address. Solana sits somewhere else again, with accounts as the fundamental unit and rent, not just fees, as a first-class concern. Stellar has its own account model with reserves and trustlines. Building custody infrastructure that treats these as interchangeable "wallets" early on causes friction later — the abstraction has to leave room for these differences rather than hide them entirely.
Fees are not a single number
Fee estimation ranges from "guess a gas price and a limit" on EVM chains to fee markets with priority fees, to fixed or near-fixed fee models elsewhere. Getting this wrong doesn't just mean overpaying — it means stuck transactions, replaced transactions, and support tickets.
Finality means different things
"Confirmed" on one chain and "confirmed" on another can imply very different guarantees about reversibility. Treating confirmation count or block depth as a portable concept across chains has caused more subtle bugs than almost anything else in this kind of system — the safe thing is to be explicit, per network, about what finality actually means before treating a transaction as settled.
The integration boundary that holds up
The integrations that have aged well are the ones where the chain-specific logic — transaction construction, fee estimation, broadcast, confirmation tracking — sits behind a narrow, consistent interface, and everything upstream (custody, policy, accounting) is written against that interface instead of against any one chain's quirks.