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

Standard vs Shielded Routes

The current difference between preimage-revealing routes and settlement-proof-based shielded routes.

Fusion has two route styles:

  • Standard routes: the destination withdrawal is authorized by revealing the preimage.
  • Shielded routes: the destination withdrawal can be authorized by a verified settlement proof instead of revealing the preimage in a public EVM transaction.

The difference matters for privacy, hash-function choice, and operational complexity.

Standard route Shielded route 1. Lock source + destination HTLCs with the same hashlock H = sha256(preimage) 2. Receiver calls withdraw(htlcId, preimage) on the destination chain → PREIMAGE PUBLIC ON DESTINATION CHAIN 3. Solver reads preimage from dest logs, calls withdraw(htlcId, preimage) on source → PREIMAGE PUBLIC ON SOURCE CHAIN TOO 1. Lock source + destination HTLCs with the same hashlock H = sha256(preimage) 2. Off-chain ZK settlement proof: proves sha256(preimage) == H, then verified → PREIMAGE NEVER LEAVES THE PROVER 3. withdrawWithSettlementProof(htlcId) on both source and destination → NO PREIMAGE IN ANY EVM TRANSACTION Hash policy: standard same-family routes use chain-native (keccak256 on EVM); cross-family and all shielded routes use sha256.
Side-by-side comparison of where the preimage appears in each route style.

Quick comparison

Route type Destination withdrawal Where the secret appears Hash policy
Standard withdraw(htlcId, preimage) Public on the chain where withdrawal happens Same-family uses chain-native default; cross-family uses sha256
Shielded withdrawWithSettlementProof(htlcId) on EVM Settlement proof stands in for public preimage reveal on the EVM side sha256 for shielded intents on all routes

Standard routes

Standard routes are easier to reason about:

  • the hashlock is known on both chains
  • the receiver reveals the preimage when claiming funds
  • the solver learns the same preimage and uses it to claim the source-side HTLC

This is the classic HTLC pattern and it is the clearest path to understanding Fusion's atomic settlement guarantee.

Shielded routes

Shielded routes are more subtle.

The HTLCAtomicSwap contract includes a withdrawWithSettlementProof path for intents that are explicitly marked shielded in IntentValidator. The shielded path enforces these properties:

  • the intent must be marked shielded
  • the settlement proof must already be verified
  • the withdrawal emits HTLCWithdrawn with a zero preimage value for that path
  • the function is still permissionless in the sense that funds go to the HTLC receiver, not the caller

That is real privacy machinery, but it does not make every route fully private end-to-end on its own.

Cross-family routes change the picture

When a route crosses chain families, source and destination do not share the same assumptions, and a few things shift:

  • address formats differ across families (EVM uses 20-byte addresses; other families use their own canonical forms that must be normalized server-side)
  • cross-family routes use sha256 so both sides can verify the hashlock with the same function
  • cross-family source flows use session APIs and chain-specific wallet signing instead of the standard public EVM flow
  • non-EVM destinations are gated behind explicit feature flags rather than enabled by default

The direction restriction exists because preimage visibility is a safety issue, not just a UX issue. See supported chains overview and trust assumptions.

When to use which model

Choose the standard route when you want:

  • the simplest integration
  • the clearest operational model
  • the least experimental path Fusion currently exposes

Choose the shielded route only when you are prepared for:

  • extra proof dependencies
  • route-specific behavior
  • more careful testing around chain family and operational setup

What not to assume

Do not assume:

  • every route supports shielded settlement today
  • every client helper and server event is already aligned for shielded flows
  • a shielded route removes all operational dependencies

The safe reading is narrower: shielded settlement machinery is real and working, but it is still part of the protocol's experimental surface.

Related docs: