What Is Fusion?

Fusion is a cross-chain settlement protocol built around intents, solver liquidity, and hash time-locked contracts (HTLCs) — the same primitive Bitcoin's Lightning Network uses to route payments trustlessly across channels, adapted here to settle atomically across chains.

At a high level:

• A user signs an intent that says what they want to swap.
• A solver agrees to fill that intent.
• HTLCs on the source and destination chains enforce the all-or-nothing settlement path.
• If the swap completes, both sides settle.
• If it does not, the refund path opens after the relevant timelocks expire.

Fusion is not a wrapped-asset bridge. The protocol does not mint a synthetic token on the destination chain and it is not designed around a shared custody pool. Fusion is solver-funded atomic settlement: the solver puts up the destination-side liquidity, the user's funds stay locked under HTLC on the source side, and either both sides settle or both refund.

The main pieces

User intent

Fusion starts with a signed intent. The public submit flow centers on:

• POST /api/intents/get-nonce
• POST /api/intents/get-domain
• POST /api/intents/submit

The signed payload covers chain IDs, token addresses, amount, minimum output, deadline, and nonce. See the intent schema reference.

Solver liquidity

Solvers are the actors that provide the destination-side liquidity. They do not need custody of user funds in the normal path. Instead, they lock their own funds on the destination side and later claim the source-side HTLC once the swap resolves. See solver overview.

Coordinator

The coordinator is the orchestration layer. It matches intents, tracks state, manages proof workflows, exposes APIs, and pushes status updates over WebSocket. It is important operationally, but it is not the custodian of user assets. See coordinator overview and security model.

HTLC settlement

HTLCs enforce the settlement path. Fusion's contracts expose standard withdraw and refund paths, plus a shielded withdrawal path for intents explicitly marked as shielded. See how Fusion works and atomic settlement guarantee.

What Fusion does and does not guarantee

Fusion is trying to guarantee route-level atomic settlement, not universal trustlessness across every supporting system.

What the design is aiming for:

• both sides complete, or the refund path opens
• no shared wrapped-asset reserve pool in the core path
• no normal coordinator custody of user assets

What the design does not eliminate:

• chain liveness risk
• operator misconfiguration
• testnet-only economic parameters
• route behavior that still depends on feature flags or operational services

Fusion has guardrails in place for each of these: HTLC timeouts contain chain stalls, permissionless withdraw/refund semantics contain misconfiguration, on-chain bonding and slashing give a retunable economic floor, and feature flags are themselves a defensive gate on unsafe paths.

Fusion narrows the trust surface compared with pooled bridge custody. It is a testnet system today.

Next: How Fusion Works, Supported Chains, and Security Model.