ALL ARTICLESJul 2, 2026
Basics

Chain Abstraction: Making Multi-Chain a UX Detail, Not a User Problem

Right now, using crypto across multiple chains requires the user to be the router. Which chain is this app on? Do I have gas on that chain? Do I need to bridge?...

Jul 2, 20263 min readby MorcaLabs

Right now, using crypto across multiple chains requires the user to be the router. Which chain is this app on? Do I have gas on that chain? Do I need to bridge? Which bridge? Will I get the wrapped version or native? Billions of dollars of TVL sits underutilized because the friction of moving it is higher than the yield differential.

Chain abstraction is the thesis that users shouldn't have to care about this. The application specifies the outcome; the infrastructure figures out which chain executes it.

The layers of chain abstraction

Full chain abstraction requires solving several independent problems:

*Gas abstraction*: The user should not need to hold each chain's native gas token to transact on that chain. Solutions: paymasters (ERC-4337) that accept USDC; Coinbase's Base paymaster; Tempo's native USDC gas; chains with zero-fee design (Plasma for USDT).

*Balance unification*: The user has USDC split across Ethereum, Arbitrum, and Solana. The application should see one unified balance, not three separate ones. Circle Gateway does this for USDC - non-custodial, one balance, <500ms settlement across all supported chains.

*Intent settlement*: When the user wants to swap, the intent solver finds the best route across all available chains and executes atomically. If ETH on Mainnet is cheaper than ETH on Arbitrum and the user is on Base, the solver bridges, swaps, and delivers - one operation, no manual routing.

*Cross-chain signing*: A session key or smart account authorization valid on one chain should ideally authorize the same agent on multiple chains through a single human signature. This requires cross-chain authority compilers - systems that translate one human mandate into chain-specific authorization objects.

NEAR's chain signatures

NEAR Protocol's chain signatures service is one of the most ambitious chain abstraction implementations. A NEAR account can hold signing authority for Bitcoin UTXOs, Ethereum addresses, Solana accounts, and Cosmos addresses simultaneously. When the user approves an action on NEAR, the NEAR MPC network collectively signs the transaction on the target chain without ever reconstructing the private key on any single machine.

This means your NEAR wallet can send Bitcoin without you holding BTC for gas, without a wrapped version of BTC, natively - because NEAR signs the Bitcoin transaction directly.

ERC-7683 cross-chain intents

On EVM chains, ERC-7683 standardizes cross-chain intents. You post an intent to Ethereum; a solver on Arbitrum fills it from inventory; settlement happens through the standardized cross-chain transfer mechanism. The user never chose which chain handled their order.

Botanary's approach

Botanary's SNAL (Stablecoin & Network Abstraction Layer) implements chain abstraction at the payment-settlement layer. Payer holds USDT on Tron; payee wants USDC on Base. The SNAL routing engine bridges, swaps, and settles - the agent submitting the payment specifies (amount, currency, destination) and the routing engine handles everything else.

The key invariant: atomic-or-revert. If any leg of the cross-chain route fails, the entire transaction reverts. No funds stranded mid-bridge.