Atomic Settlement Guarantee

Fusion's core claim is simple:

the settlement path is designed so that either both sides complete, or the refund path opens.

That claim comes from HTLC structure, not from trust in a bridge custodian.

A brief history of HTLCs

Hash time-locked contracts originated in Bitcoin's Lightning Network as the primitive that makes trustless off-chain payment channels possible. In Lightning, a payment from Alice to Bob through several intermediate hops is secured by having every hop lock its forwarded value against the hash of a secret that only Bob knows. When Bob reveals the secret to claim his incoming payment, each upstream hop sees the preimage in flight and uses the same secret to claim its own incoming lock. Either the secret is revealed — in which case every hop is paid — or the timelocks expire and every hop gets its funds back. No hop ever has to trust another hop with custody.

Fusion applies the same primitive across chains instead of across payment-channel hops. The source and destination HTLCs are two locks on different ledgers, bound by a single hashlock; revealing the preimage to unlock one provably enables the counterparty to unlock the other. The user is Alice, the solver is Bob, and the chains themselves are the intermediaries. The safety argument is identical: either the preimage is revealed and both sides settle, or the timelocks expire and both sides refund. No coordinator, solver, or front-end can intercept funds, because the authorization material is the preimage itself — not msg.sender, not a signature from a trusted party, not a flag in an off-chain database.

What changes is the scope. Lightning HTLCs operate inside a single chain's channel state and are resolved by that chain's script engine. Cross-chain HTLCs operate on two separate ledgers that do not share a consensus boundary, which is why Fusion also needs per-chain validators, a cross-family hash-function policy (SHA-256 for routes that cross chain families), and a solver model to front destination-side liquidity — Lightning gets those for free from its channel topology. The guarantee itself, though, is the same guarantee Lightning was designed to give: atomic settlement without a trusted custodian.

A natural question is why Fusion uses HTLCs at all rather than a more modern primitive like adaptor signatures, which are considered the state of the art for atomic swaps on Bitcoin because they leak less on-chain metadata. The practical answer is that adaptor signatures are structurally incompatible with Ethereum's account model and precompile set, and the alternatives on Ethereum today converge on ZK-enhanced HTLCs or intent-based architectures — which is exactly the design Fusion implements. For the full argument, see Why Adaptor Signatures Are Difficult.

What creates the atomic link

The source and destination HTLCs are linked by the same hashlock.

• In a standard route, revealing the preimage on the destination side gives the solver what it needs to claim the source side.
• If the destination side never resolves, the source side eventually reaches its refund window.
• The source-side timeout must be longer than the destination-side timeout, otherwise the solver could lose the race to refund.

This is the reason the docs keep coming back to hashlocks and timelocks. They are the mechanism behind the guarantee.

What the guarantee covers

Covered by design:

• source and destination HTLC linkage
• permissionless withdrawal with the right authorization material
• refund availability after timeout
• route-local settlement rather than a pooled reserve model

Not covered by the phrase "atomic settlement" alone:

• chain outages
• RPC failures
• off-chain service downtime
• bad deployment config
• incorrect address wiring between environments
• production-grade economic security

That second list matters. The protocol can have a sound HTLC shape and still fail operationally if its surrounding services are misconfigured.

What Fusion enforces today

The contracts enforce several real guardrails:

• IntentValidator uses EIP-712 signatures and per-chain nonces.
• markExecuting is proof-gated in the contract.
• HTLCAtomicSwap exposes explicit withdraw and refund paths.
• shielded withdrawals require the intent to be marked shielded and the settlement proof to be verified.
• permissionless withdraw/refund still send funds to the designated receiver or sender rather than the caller.

Those are meaningful properties. They are also narrower than "the whole system is trustless."

Why route-local failure matters

Fusion's architecture is intentionally different from a shared wrapped-asset reserve model.

If a particular route fails:

• the problem is supposed to stay tied to that route's HTLCs and counterparties
• it should not become an infinite mint authority event
• it should not turn into a pooled reserve drain across unrelated users

That does not mean the route is risk-free. It means the failure surface is meant to stay local instead of becoming systemic.

Current caveats

• The strongest, clearest version of the atomic story is the EVM-to-EVM testnet corridor.
• Cross-family and shielded routes add route-specific behavior, feature flags, external chain sidecars, and proof dependencies.
• Runtime contract addresses can drift between environments. Discover them at runtime via GET /api/config/htlc-addresses and reconcile before depending on a public guarantee.

The practical reading

If you are evaluating Fusion today, the safe interpretation is:

• the protocol delivers HTLC-based atomic settlement
• the implementation supports that model end-to-end
• it is a testnet system today

This docs set keeps the guarantee specific and bounded rather than marketing-heavy.

Related docs:

• How Fusion Works
• Standard vs Shielded Routes
• Threat Model
• Chains and Timelocks