← home

intent routing as stablecoins treasury infrastructure

how intent routing optimizes multi-chain treasury operations — and why it matters for the infrastructure companies that power them.

interoperability is a blockchain legacy issue

I think when most people hear "offchain" they think it means the real world. things that happen outside of blockchains entirely. a weather feed. a stock price. a bank transfer. stuff that has nothing to do with crypto.

but at its very essence, that's not what offchain means. offchain means outside of this chain. if a transaction didn't occur on ethereum, it is offchain to ethereum, even if it happened on base, solana, arbitrum, or any other blockchain. a USDC transfer that settles on base is as offchain to ethereum as a wire transfer from JPMorgan. ethereum has no way of knowing it happened.

this is the foundational problem. blockchains are inherently islands. they don't share state, they don't observe each other's transactions, and they have no native mechanism for cross-chain communication. every chain is a closed execution environment that only knows about events processed by its own validators.

this makes interoperability fundamentally an oracle problem, or more precisely, a messaging problem. any information that didn't originate on-chain needs to be attested to, relayed, and verified before that chain can act on it. it doesn't matter whether the information is coming from the physical world or another blockchain. the trust gap is the same. the chain cannot verify it natively. something external has to vouch for it.

this is the legacy issue that the entire cross-chain infrastructure industry exists to solve: how do you get chain A to trust that something happened on chain B?

existing solutions: real progress, unresolved friction

the first approach was lock-and-wrap: lock assets in a contract on the source chain, mint a synthetic "wrapped" version on the destination. structurally, this creates a honeypot. the ronin bridge ($625M), wormhole ($320M), and nomad ($190M) exploits are the predictable result of concentrating enormous value behind a single verification layer.

the next generation improved on this. some adopted burn-and-mint (burn on source, mint canonical on destination, no honeypot). others refined the model into hub-and-spoke architectures with stronger verification. notable implementations: circle CCTP, layerzero OFT, chainlink CCIP, and wormhole NTT.

these are materially better. but they still carry friction:

the security architecture improved. the execution experience, and the burden it places on the user, did not.

Diagram comparing three cross-chain bridge models: lock-and-wrap, lock-and-mint hub-and-spoke, and burn-and-mint
lock/wrap vs lock/mint (hub/spoke) vs burn/mint — how bridge security models evolved

intent routing: shifting the burden of execution

intent-based routing addresses these friction points by changing who bears the complexity of cross-chain execution.

what it is

in every model discussed above, the user bears the execution burden: gas provisioning, wait times, failure handling. intent routing removes that entirely. the user declares an outcome, and a competitive network figures out how to deliver it.

"1,000 USDC delivered on base, sourced from ethereum, within five minutes, under 30 basis points (0.3% fee)."

the design pattern is codified in ERC-7683, the cross-chain intents standard. an intent is a typed, structured message containing the source chain, destination chain, asset, amount, recipient, fee cap, and deadline. the user signs this once. that signature is the only commitment they make. the entire execution process, from routing to settlement, is offloaded.

how it works

an intent moves through four stages:

1. declaration. the user constructs and signs the intent. one signature. no gas provisioning, no provider selection, no multi-step approval flow.

2. solver competition. the signed intent enters a mempool where independent actors called solvers compete to fill it. solvers are market makers who maintain their own capital inventories across multiple chains. they evaluate the intent (can they fill it profitably given their current inventory, gas costs, and risk exposure?) and bid to execute it.

3. instant fill. the winning solver delivers the destination asset to the recipient from their own inventory. the user receives funds in seconds, not minutes. the solver fronts the liquidity.

4. settlement. after the fill, the solver is reimbursed from the user's source-chain funds via the settlement layer. this is where the underlying messaging protocols (CCTP, CCIP, etc.) do their work, but in the background, on the solver's timeline, not the user's.

the key insight: the user gets instant execution. the solver absorbs the latency. the slow, secure, institutional-grade messaging protocols still handle the actual cross-chain settlement, but asynchronously, decoupled from the user's experience.

solver competition is what drives the economics. different protocols implement different auction mechanisms. across protocol uses a relayer network with optimistic oracle windows. uniswapx runs dutch auctions where price decays until a filler accepts. eco routes runs permissionless solver competition per intent. the mechanism varies; the outcome is consistent: tighter fees and faster fills than any single user-dictated path could produce.

Diagram showing the four stages of intent routing: declaration, solver competition, instant fill, and settlement
how intent routing works — from user declaration to solver settlement

the rails and the runner

a common misconception is that intent routing competes with traditional cross-chain protocols. it doesn't. these are not rival solutions; they operate at different layers of the cross-chain stack.

traditional cross-chain protocols (layerzero OFT, chainlink CCIP, wormhole NTT, circle CCTP) are general message passing (GMP) layers. they solve the hard cryptographic and consensus problem of proving that state changed on chain A so that chain B can react. they are the "rails": highly secure, but fundamentally bound by the consensus speeds and block times of the networks they connect.

intent routing (codified by ERC-7683) is the execution layer that sits on top of these rails.

in a traditional bridge transaction, the user interacts directly with the rails: initiate, wait, receive. the latency is theirs to absorb.

intent routing removes that entirely. the user interacts with a solver, who fronts capital on the destination chain and delivers funds in seconds. the solver then absorbs the latency — using the underlying messaging rails to rebalance their inventories asynchronously, in the background.

this is a division of labor, not a competition. intent routing needs the messaging rails. solvers can't rebalance without them. and the messaging protocols benefit because solver rebalancing generates consistent, high-volume cross-chain traffic that flows through these rails.

Diagram showing the two-layer architecture: messaging rails below providing secure settlement, and the intent execution layer above providing fast user-facing fills
the two-layer stack — messaging rails handle settlement, the execution layer handles the user experience

from standard to infrastructure

this division of labor also explains why the standard took time to reach production. ERC-7683 was co-authored by uniswap labs and across in may 2024, but standardizing a message interface is only the first step. building off-chain solver networks (handling inventory hedging, reorg risks, and gas fee optimization) and coordinating shared filler networks across competing dApps required significant engineering effort beyond the spec itself.

the standard reached its inflection point in 2025/2026, driven by two forces:

the solver network is production infrastructure now, not a whitepaper. the question is no longer whether intent routing works — it's where it creates the most leverage. the clearest answer is treasury operations.

application: multi-chain treasury management

the operational reality for a company running stablecoin treasury across multiple chains is straightforward: money flows in on various chains from customer activity, and it needs to be consolidated, redistributed, or held, all without the treasury team manually babysitting bridge transactions.

intent routing doesn't change what treasury operations need to do. it changes how the execution layer works underneath them.

gas fee elimination

in a traditional multi-chain treasury setup, the company must maintain native gas reserves on every chain where it operates. ETH on ethereum. ETH on base. ETH on arbitrum. ETH on optimism. TRX on tron. these reserves need to be monitored, topped up, and accounted for: idle capital that exists solely to pay for the right to move the company's own stablecoins.

in an intent-based model, the solver pays the gas. the solver pays the destination-chain execution cost. the solver pays the source-chain settlement cost. the operator's cost is the intent fee, a competitive basis-point spread that solver competition drives down.

for a company scaling from five to fifteen supported chains, this eliminates an entire operational workflow: the monitoring, the top-ups, the accounting, the risk of failed transactions due to insufficient gas on an obscure L2 at 3am.

consolidation

when an operational wallet's balance exceeds a defined ceiling (say, 80,000 USDC on arbitrum), the surplus should be swept back to the master wallet on the company's primary chain.

traditionally, this requires the treasury system to check balances, select a provider, ensure sufficient gas, approve the token, submit the transaction, wait for attestation, and verify arrival. each step is a potential failure point.

with intent routing, the treasury system constructs an intent: "move 30,000 USDC from arbitrum operational wallet to ethereum master wallet, under 15 basis points, within 10 minutes." signs it. broadcasts it. a solver fills it. the operator never touches a bridge, never provisions gas on the source chain, and never monitors attestation windows.

rebalancing

when an operational wallet falls below its floor threshold (say, the base wallet drops to 4,000 USDC against a 10,000 floor), it needs to be topped up from the master wallet or from another operational wallet with surplus.

the same model applies in reverse. the treasury system creates an intent: "deliver 16,000 USDC to base operational wallet from ethereum master wallet, under 20 basis points." the solver competes, fills, and settles. the operator's base wallet is back within its operating band.

designing for operators: product considerations

the final piece is making this configurable and safe for real operators. this spans several product areas. intent policy is the most visible, but it's not the only surface that matters.

intent policy management

a treasury operator should not need to manually create intents. the system should generate them automatically based on policy, the same way existing auto-sweep systems work, but with the execution layer replaced by intent routing.

an intent policy would define:

per-wallet thresholds

intent constraints

automation rules

Intent Policy Configuration Widget Design
intent policy configuration dashboard design mockup

monitoring and observability

policy alone isn't enough if operators can't see what's happening. the product needs:

Monitoring Dashboard Widget Design
monitoring dashboard widget design mockup

emergency controls

automated systems need kill switches:

Emergency Controls Widget Design
emergency controls widget design mockup

sources