Security Model
The current security layers in Fusion, with a distinction between code-level controls and deployment-dependent hardening.
A cross-chain settlement protocol should never ask users to trust a pool. Fusion replaces pooled custody with per-route HTLCs funded by the solver on the destination side, authorized by a user-signed intent on the source side, and bound together by a single hashlock. A failure of one route does not spread to another, and a failure of the coordinator does not move funds — it only stalls matching until refund timelocks elapse.
The layers below are ordered from the outermost gate an attacker must pass to the innermost. Each layer enforces something concrete, mitigates a specific attack class, and leaves specific residual risk.
Layer 1: Intent authorization
The outermost layer is the boundary between "a signed user instruction" and "everything else." Fusion uses EIP-712 typed-data signatures over the intent payload, combined with per-chain nonce tracking and an explicit deadline. The signature is verified against the intent owner, the nonce is consumed in the order the contract observes, and the deadline short-circuits any attempt to replay an old intent through a stale submission channel. Supported-chain checks ensure an intent addressed to one chain cannot be lifted and replayed on another.
The attack class this layer mitigates is forgery and replay. A coordinator that tried to synthesize an intent a user never signed would fail signature verification; a solver that tried to resubmit a previously-consumed intent would hit the nonce wall; a participant that tried to smuggle a long-dormant intent back into the pipeline would fail the deadline.
What this layer does not cover is the semantics of what the user signed. EIP-712 proves authorization; it does not prove that the user understood the rate, the destination, or the route. That responsibility lives in the client and in the intent schema, not in the signature check.
Layer 2: Proof gating
Before an intent can move from matched to executing, IntentValidator requires the expected proof set to be verified on chain. markExecuting is blocked until that gate passes. For shielded routes, this extends further: the settlement proof (Groth16, produced by a roughly 29k-constraint SHA256 circuit) is verified by SettlementVerifier, and its public signals are context-bound — pubSignals[1..2] must match the intent id high/low words, and pubSignals[7] must match the solver address. A proof valid in isolation but generated for a different intent or solver is rejected.
This layer mitigates two attack classes: premature execution (a matched intent cannot be driven into executing without verified proofs) and proof reuse on shielded routes (context binding prevents a valid settlement proof from being replayed against a different intent or solver, even if its public signals are observable).
What remains outside this layer is the soundness of what the proofs assert. The gate enforces that the proofs exist and bind to the right context; it relies on the circuit and the verifier contract to enforce the underlying cryptographic claim. An error in the verification key, a mismatch between the deployed verifier and the trusted setup, or a circuit bug is a concern for the proof system, not the gating logic.
Layer 3: HTLC settlement
HTLCAtomicSwap is where funds actually move, and it is deliberately the narrowest contract in the system. It exposes three settlement-relevant operations:
withdraw(htlcId, preimage)releases locked funds to the designated receiver if the preimage matches the hashlock before the timelock expires.refund(htlcId)returns locked funds to the designated sender if the timelock has elapsed without a valid withdrawal.withdrawWithSettlementProof(htlcId)releases funds on shielded routes by verifying a Groth16 proof instead of revealing a preimage on chain.
Critically, withdraw and refund are permissionless in the sense that anyone can call them — but funds always go to the designated receiver or sender recorded at lock time, never to the caller. The preimage (or the settlement proof) is the authorization; msg.sender is not.
This layer mitigates the two worst failure modes in cross-chain movement: redirection and stranding. Redirection is ruled out by the designated-recipient semantics. Stranding is ruled out by the symmetric refund path — if the withdrawal window closes without a valid secret, funds return to the originator and no one can override that. What this layer does not cover is liveness — the HTLC guarantees that funds either move to the intended recipient or return to the sender, but it cannot guarantee that the happy path completes within the solver's liquidity horizon, or that block production is fast enough to hit the intended timelock.
Layer 4: Solver constraints
Solvers front destination-side liquidity and are the only participants with a direct economic relationship to the protocol. SolverRegistry enforces that relationship with on-chain bonding, a 7-day withdrawal timelock on bond removal, reputation tracking, progressive slashing percentages, and an insurance-fund accumulator that collects slashed amounts. The minimum bond is intentionally low for testnet — 0.01 ETH — and is expected to be raised for mainnet; the mechanism is what matters, not the current parameter.
The attack class this layer addresses is solver-side griefing. A bonded solver that fails to honor commitments can be slashed; repeated bad behavior degrades reputation and ultimately removes the solver from matching. The withdrawal timelock is what makes slashing meaningful — an exiting solver cannot pull its bond out of range of a pending claim.
What this layer does not cover is anything about honest solver incentives being sufficient on their own. Bonds and slashing are a floor; they raise the cost of misbehavior but do not guarantee that honest matching is always the most profitable action at every moment. Even a maximally-bonded solver cannot redirect funds, because the HTLC does not let anyone redirect funds — Layer 3 still holds.
Layer 5: Operational controls
The operational layer runs in the coordinator process, not on chain. It includes rate limiting on submit endpoints, callback authentication for solver and oracle messages, proof-bundle validation that sanity-checks payloads before they hit the chain, chain readiness and health checks that refuse to route traffic onto an unhealthy RPC, and a refund monitor with cross-chain adapter support that drives refund on the correct chain when a timelock expires — including on cross-family routes.
This layer mitigates abuse and misconfiguration rather than cryptographic attack. Rate limiting blunts flooding; callback authentication prevents spoofed messages from driving state transitions; readiness checks prevent the coordinator from committing to routes it cannot complete; the refund monitor ensures timed-out routes actually get refunded rather than drifting in an intermediate state.
This is also the layer where public claims have to be most careful. Callback-secret enforcement in particular is transitional in some environments: the machinery is present and hardened deployments are expected to configure it, but the correct statement is that the mechanism exists and must be verified per deployment — not that every deployment enforces it uniformly. Nothing at this layer custodies funds, so a failure here delays or degrades routing; it does not authorize a transfer that the on-chain layers would otherwise reject.
What the model explicitly avoids
Fusion's design rejects three patterns that define the risk profile of pooled-bridge architectures. There is no pooled custody — locked funds live in per-route HTLCs, not in a shared vault. There is no destination-side wrapped-asset mint authority in the core settlement path — settlement moves real balances through HTLCs, not synthetic claims against a mint key. And there is no hidden emergency-owner drain path over active HTLC funds; reintroducing such a path would require a visible, auditable change to the settlement contract rather than a silent operational lever.
What operators and integrators must verify
The security model is trust-minimized and route-aware, but it is not self-configuring. A deployment that routes against the wrong HTLCAtomicSwap address, or that pairs an IntentValidator with a SettlementVerifier whose verification key does not match the deployed proving artifacts, or that runs without callback authentication configured, can present as operational while silently weakening one of the layers above. Operators and integrators should verify deployed contract addresses for every supported chain, confirm the runtime profile matches the intended environment, confirm callback authentication is enforced rather than merely available, and confirm any chain-specific dependencies a route needs (proof servers, indexers, RPC proxies) are healthy before treating cross-family or shielded routes as production-ready.
Related docs: