A trade succeeds on the dashboard. The route resolver shows three green checkmarks. You go to spend the destination asset and it isn't there. Two legs settled. The third reverted thirty seconds after the second one confirmed. Your inventory now sits on the middle chain, in the middle asset, with no automatic path back.
This is the default failure mode of cross-chain multi-leg trades. The aggregator is not lying when it shows three green checkmarks for three executed legs. It's just that "executed" and "atomic across the route" are different properties, and most cross-chain routing today only guarantees the first.
Atomic per-leg vs atomic per-route
On a single chain, L1 aggregators like 1inch, ParaSwap, and Matcha are atomic. The router builds a multi-pool path inside one transaction. Either the whole transaction succeeds and you receive the destination asset, or the whole transaction reverts and you keep the source asset minus gas. There is no in-between state, because the EVM gives you transaction-level atomicity for free as long as everything happens inside one block.
Cross-chain is where the property breaks. Bridge a position from Bitcoin to an EVM chain, swap on the EVM chain, bridge again to Sui — that's three transactions on three different state machines. Each transaction is atomic with respect to its own chain. The route as a whole is not atomic with respect to anything. The bridge gives you a wrapped asset, the aggregator finds the right swap, the second bridge runs out of liquidity at the destination side, and you end the trade holding wrapped ETH on the wrong chain, sixty seconds into a journey that was supposed to deliver SUI.
Cross-chain aggregators — Across, Squid, LiFi, deBridge, and the intent-based variants that have rolled out over the past year — do real work routing this kind of trade. They split the route into segments, pick liquidity at each hop, surface estimated slippage. They will retry. They will surface errors. They do not, with a few experimental exceptions, give you a single conditional commitment that says "all three legs unwind together or none of them happen."
That's the gap multi-leg atomic settlement is built for.
What multi-leg atomic actually means
The mechanism is older than the name. A hashed timelock contract (HTLC) conditions an asset transfer on the reveal of a preimage to a known hash. Lock funds against H(s). Anyone who can present s within the timeout unlocks the funds. Past the timeout, the original sender refunds.
A multi-leg HTLC route reuses the same preimage s across every leg. Leg 1 is locked by the source on Chain A against H(s). Leg 2 is locked by an intermediary on Chain B against the same H(s). Leg 3 is locked by another intermediary on Chain C against the same H(s). The taker on Chain C reveals s to unlock leg 3. The intermediaries observe the reveal on Chain C, present s on Chain B and Chain A, and unlock their legs in reverse.
The atomicity claim is structural. The taker only reveals s if leg 3 — the leg that delivers the destination asset — is fully locked and ready. If any leg up the chain is unfunded or under-funded, the secret never enters the system. Every locked leg refunds at timeout. The source keeps the source asset. The intermediaries keep theirs. Nothing settles partial.
The failure mode of sequential routing — mid-flight residue — is structurally impossible here. The route either reveals s end to end, or it never reveals at all.
A worked example: BTC → ETH → SUI
The sequential version, with a competent cross-chain aggregator:
- Send BTC to a bridge address. Wait for Bitcoin confirmations. Receive wBTC or similar on Chain B.
- Swap wBTC for ETH on a Chain B DEX. Atomic on Chain B.
- Send ETH to a second bridge. Wait for Chain B confirmations. Receive bridged ETH or SUI on Chain C.
Three independent atomicity boundaries. Three independent failure modes. If step 3's liquidity has shifted between step 1 and step 3 — and over a ten-minute Bitcoin confirmation cycle it can shift a lot — the trade strands you on Chain B. Your aggregator surfaces a "failed final hop" error. You now own wBTC or ETH on a chain you didn't want to hold inventory on. Recovery is manual.
The atomic version, with multi-leg HTLC:
- Source locks BTC on Bitcoin against
H(s), timelock T1. - Intermediary locks ETH on Chain B against the same
H(s), timelock T2 < T1. - Intermediary locks SUI on Chain C against the same
H(s), timelock T3 < T2. - Taker on Chain C reveals
sto claim SUI. Watcher observes. Intermediary on Chain B claims ETH usings. Source-side intermediary claims BTC usingsfrom Chain A.
If step 3 can't be funded — liquidity gone, intermediary unwilling to take the risk, anything — the secret never reveals. Steps 1 and 2 refund at their timelocks. The source still has BTC. Nothing strands.
The timelock ordering matters. Longer timelock further up the chain ensures the source has time to refund even if downstream intermediaries claim slowly. This is well-trodden ground in the atomic-swap literature; we follow the standard ordering.
What this costs
Multi-leg atomic settlement is not free. It buys atomicity by adding two costs:
- Latency, because the taker has to wait for every leg to be locked before revealing. On chains with longer block times (Bitcoin), the worst-case lock-wait is significant. For agents doing inventory rebalancing, this is usually acceptable; for high-frequency arbitrage, it isn't.
- Liquidity-side counterparty selection, because every hop point needs an intermediary willing to lock the correct asset. The hashlock primitive doesn't conjure liquidity. The Hashlock RFQ pool aggregates makers willing to quote on multi-leg routes, but the depth of that pool at each hop is the real-world bottleneck.
There are also routes where sequential is the right tool. Single-chain multi-pool swaps already have transaction-level atomicity for free. Hops where the rollback cost is trivial (low-value, deep-liquidity, fast chains end-to-end) don't need a multi-leg HTLC to be safe. We don't claim atomic settlement is the answer to every routing problem. We claim it's the answer to the specific failure mode where a partially-executed cross-chain route leaves you with mid-flight residue.
Why this matters for agents
Human traders catch sequential failures by looking at their wallet. Agents catch them by inventory reconciliation, which usually means a delay between the failure and the discovery of the failure. By the time an autonomous trading loop notices it has the wrong asset on the wrong chain, the price has moved, the route has changed, and the recovery path is more expensive than the original trade.
The agents that move money across chains today — rebalancers, arbitrage bots, treasury managers — already use cross-chain aggregators. They get the route, they get the speed, they accept the failure mode because the alternative was a custodial bridge with worse failure modes. Atomic multi-leg settlement is the alternative that doesn't require custody.
The MCP integration sits underneath all of this. The Hashlock MCP server exposes one tool for cross-chain RFQs that returns either a multi-leg quote with end-to-end atomicity or a refusal. The agent doesn't have to reason about leg-level state. It asks for a route, gets a quote, executes it, and either has the destination asset or has the source asset back. There is no third outcome to handle.
Where we sit
Aggregators find the path. We don't compete with them on routing — 1inch on L1 routing and the cross-chain intent layers on Base and elsewhere are doing the right work, and we use what's been published. We sit underneath, on the settlement-shape question: does the whole route atomically commit or unwind? That's a different primitive, and it stacks cleanly with aggregator routing rather than replacing it.
The hashlock-tech/mcp package on npm (scoped) exposes the multi-leg settlement primitive as one of six agent-facing tools. Source is open on GitHub at Hashlock-Tech/hashlock-mcp. Full protocol spec including the multi-leg timelock proof: papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722.
A real question, not a rhetorical one
For agent route designers reading this: should a 3-chain trade be a single atomic operation, or a series of best-effort segments with rollback guidance? Both have defenders. Atomic adds latency and liquidity coupling. Sequential adds residue handling and recovery code. Which posture do you ship in production?
Reply below or open an issue on the repo. Genuinely interested in how teams running agents at scale think about this trade-off.
hashlock.markets · Hashlock-Tech/hashlock-mcp · Full protocol spec: papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722
Top comments (0)