Skip to docs content
Fusion Docs
Book a Call
Home
What Is Fusion?How Fusion WorksStandard vs Shielded RoutesAtomic Settlement Guarantee
QuickstartWallet App Integration
Solver OverviewCoordinator Overview
Supported Chains Overview
Security ModelTrust AssumptionsThreat Model
Intent SchemaChains and TimelocksAPI and WebSocket OverviewWebSocket Events
Whitepaper and Research
Home
Introduction

How Fusion Works

Follow the current Fusion flow from signed intent to settlement or refund.

Fusion's current flow is best understood as a sequence:

  1. A user prepares and signs an intent.
  2. The coordinator accepts the intent and starts matching.
  3. Proofs are generated or marked ready for the route.
  4. A solver is matched.
  5. The source side is locked.
  6. The destination side is locked with the same hashlock.
  7. The destination side is withdrawn, or a shielded settlement proof is used.
  8. The source side is claimed, or both sides move to refunds if the route times out.
User wallet Coordinator Source HTLC Destination HTLC Solver 1 submit signed intent 2 validate + verify proofs 3 match solver 4 lock source (hashlock H, timeout T_s) 5 lock destination (same H, timeout T_d < T_s) 6 withdraw(preimage) on destination → preimage now public 7 withdraw(preimage) on source → solver claims funds Refund branch — only if step 6 never happens before timeouts: solver refund (after T_d) user refund (after T_s)
Standard EVM-to-EVM lifecycle. Accent arrows are on-chain calls; muted arrows are coordinator messages; dashed arrows are the refund path that opens only on timeout.

That same pattern holds across all routes, but a few steps change depending on whether the route is:

  • same-family (both endpoints on the same chain family)
  • cross-family (endpoints on different chain families, e.g. EVM ↔ non-EVM)
  • standard or shielded

See standard vs shielded routes.

Step 1: The user signs an intent

For the public EVM flow, the user gets:

  • a nonce from POST /api/intents/get-nonce
  • the EIP-712 domain from POST /api/intents/get-domain

The user then signs the CrossChainIntent typed data and submits it through POST /api/intents/submit.

For cross-family source routes, Fusion accepts the intent through an off-chain coordinator path and later waits for a user-provided source-lock attestation.

Step 2: The coordinator validates and queues the intent

The backend validates:

  • schema shape
  • address format
  • source and destination chain support
  • deadline
  • route direction restrictions

For example, non-EVM destinations are gated by explicit feature flags and are not enabled by default. See supported chains overview.

Step 3: Proofs move toward verified

There is more than one proof path today:

  • Same-family EVM flows use the IntentValidator contract and tracked proof state.
  • Some cross-family routes bypass the on-chain proof callback and are marked ready through the coordinator's off-chain orchestration.

In the EVM-source contract path, IntentValidator tracks proof status and gates markExecuting until the required proofs are verified.

Step 4: A solver is matched

Once the intent is valid and a solver is available, the coordinator matches the solver to the intent. The matched solver is then expected to provide the destination-side liquidity and settlement address for the relevant chain family.

Step 5: The source side is locked

This is where the route starts to split:

  • Same-family EVM source: the user can lock funds directly or use the Permit2-assisted source-lock path.
  • Cross-family source: source-lock session endpoints orchestrate the deploy and lock transactions, which the user signs through the source chain's wallet integration.

For cross-family source flows, the intent may sit in waiting_for_source_lock until the source lock is attested.

Step 6: The destination side is locked

After the source-side lock is observed, the solver creates the destination HTLC using the same hashlock. The exact hash function depends on the route:

  • same-family standard routes can use the chain-native default
  • cross-family routes use sha256
  • shielded routes use sha256 even on EVM-to-EVM

See chains and timelocks.

Step 7: The destination side resolves

There are two current patterns:

  • Standard: the receiver calls withdraw(htlcId, preimage), revealing the preimage on-chain.
  • Shielded: the receiver calls withdrawWithSettlementProof(htlcId) on EVM, using a verified settlement proof instead of revealing the preimage in the public EVM transaction.

On non-EVM chains, the standard withdraw path publishes the revealed preimage to the chain's public ledger state so the counterparty side can observe and claim.

Step 8: The source side resolves

After the destination side resolves:

  • the solver claims the source HTLC with the same preimage in standard routes, or
  • the shielded claim path is used after settlement-proof verification where supported

If a leg does not complete in time, the relevant refund path opens instead. The source-side timeout must be longer than the destination-side timeout or the whole model breaks.

Real-time tracking

The backend exposes:

  • GET /api/intents/:intentId
  • Socket.IO subscriptions such as subscribe:intent

This is how clients track statuses like:

  • proofs_pending
  • proofs_verified
  • matched
  • waiting_for_source_lock
  • executing
  • completed
  • failed

See API and WebSocket overview and websocket events.

Next: Standard vs Shielded Routes and Atomic Settlement Guarantee.