Developer guide

Chain abstraction and unified balances

4 min read

Roadmap Chain abstraction — one aggregate balance per token, with the platform choosing which network settles — is the direction the platform is heading in, not a capability available today. One part of it already is: when no single network holds enough, the amount is sent as several same-chain transfers. See Splitting an amount below and EVM transfers.

The problem it solves

The same token exists on many networks. A user holding USDC on Arbitrum, on Base and on Tron does not hold three different assets — they hold one balance that happens to be spread across three ledgers.

Exposing that split to the person spending the money pushes an implementation detail into the product. It forces the user to know which network their money is on, to understand why a transfer failed when the total was clearly sufficient, and to move funds between networks before being allowed to spend them.

What changes

The platform keeps the per-network detail internally, because settlement always happens on a specific chain, and exposes an aggregate balance per token. A transfer is requested against that aggregate, and the platform decides which network settles it.

That decision is policy, not inference. The rule lives in the tenant's configuration — for example, the first network whose balance covers the whole amount, in a declared order — so the same request produces the same routing every time, and a conversational channel cannot end up choosing a network because a model preferred it.

Splitting an amount

Available today When no single network holds enough, the amount is settled as several transfers, each one within a single network — the one its balance already sits on. The quote states how many transfers there will be, which network each one uses and what each one costs, before the sender confirms.

No bridge takes part, and no third party charges for it. This is the cheap half of chain abstraction: it does not move value between networks, it spends value where it already is. What is still ahead is the other half — the aggregate balance and a transfer requested against it, without naming a network at all.

The full behaviour, and what it means for a consumer that has to render it, is in EVM transfers.

Reconciliation

An aggregate that nobody checks is a number, not a balance. The ledger reconciles the same token across networks as one position: the aggregate must equal the sum of the per-network balances actually observed on chain, and any discrepancy is named rather than absorbed into a total.

This is what makes the abstraction safe to expose. A unified view that can silently drift from the chains beneath it would be worse than no unified view at all.

Relationship to LI.FI routes

Chain abstraction is not the same thing as bridging. A LI.FI route moves value between networks and costs a fee; chain abstraction avoids the move where possible by settling from a network that already holds the funds. Bridging remains available when the destination requires a specific network.

Capabilities in this area

This area covers the capabilities below. The Roadmap states the current availability of each one.

  • Unified balance per token across networks — A user who holds the same token on several networks sees a single balance: the sum of all of them. The platform keeps track of how much sits on each network and returns the total.

  • Same-token reconciliation across networks — The ledger checks that the unified balance equals the sum of the balances observed on each network's chain. When the two do not match, it records the difference and identifies which network it comes from.

  • Automatic network selection per operation — Nobody is asked which network to use. When the requested one cannot fund the amount and another holding the same asset covers it whole, the quote is issued on that other network, and its network and asset representation may differ from the ones the request carried. The same request against the same balances always picks the same network.

  • Split the amount across networks when no single one covers it — When no single network holds enough, the amount is settled as several transfers, each one within a single network. The quote states how many transfers there will be, which network each one uses and what each one costs, before the sender confirms.

  • Abstracted balance exposed by API, SDK and channels — The unified balance is a field of the public API, has its type in the SDK, and is the number a conversational channel answers with when someone asks how much they have. The three surfaces read the same value.