Threat Model

This threat model covers the surface Fusion enforces: a user signing an EIP-712 intent, a coordinator matching to a bonded solver, HTLCs on both chains, off-chain proof generation, refund monitoring, and — for Midnight routes — a sidecar plus proof server. The coordinator orchestrates; it never custodies funds.

Each threat is framed the same way: what an attacker could try to do, what the current design does to reduce that threat, and what risk still remains. A mitigation rarely eliminates a threat — it reshapes it, and the residual column is where the honest story lives. The diagram below is an attack-surface overview; the matrix that follows turns those vectors into concrete rows.

Threat and mitigation matrix

Threat	Current mitigation	Residual risk
Replay and signature misuse	EIP-712 typed data, per-chain nonces, deadlines, and supported-chain checks enforced by IntentValidator.	A user can still sign the wrong payload if client UX misrepresents the intent.
Partial completion across chains	Hashlock linkage plus a source timeout strictly greater than the destination timeout, with an explicit refund path on each side.	Bad timelock tuning or operational delay can erode the safety margin.
Unauthorized withdrawal	Authorization by preimage (standard) or verified settlement proof (shielded); calls are permissionless, but funds always go to the designated receiver or sender, never the caller.	Incorrect intent binding or address wiring at deployment time can still route funds to the wrong party.
Proof tampering	IntentValidator gates proof status and binds settlement-proof public signals to the intent id and solver address; backend preflight catches mismatches before submission.	Proof generation and callback paths depend on correct setup; a stale key substitutes for an attacker.
Solver misconduct	SolverRegistry enforces bonding, a 7-day withdrawal timelock, progressive slashing, reputation tracking, and an insurance-fund accumulator.	Current bond parameters are testnet-low; economic parameters must be retuned for mainnet-scale solver sets.
MEV and frontrunning	Intent-based flow, source-side commit-reveal, and solver-side matching reduce the exploitable surface for searchers.	MEV resistance is not immunity — market and block-production conditions still shape the real outcome.
Cross-family address and hash confusion	Cross-family routes use SHA-256, addresses are normalized server-side to their canonical form, and non-EVM destinations are gated behind explicit feature flags.	A client treating addresses from different chain families as interchangeable can still cause safety issues.

Threats that remain very real

1. Misconfiguration is the single biggest operational risk. Fusion exposes multiple address sources and multiple runtime profiles, and a technically correct design becomes a broken deployment the moment one of those is wired wrong — a mismatched validator, a swapped HTLC address, or a pointer at a stale contract.

2. Runtime profile drift is a close cousin. A deployment's security posture depends on which profile it is running under; a relaxed-configuration profile leaking into a public-facing deployment changes the threat model underneath the protocol without any code change at all.

3. Operational downtime breaks route progress even when the contract-level design is sound: a coordinator that is unreachable, a solver that has gone offline mid-swap, a stale or rate-limited RPC provider, or a failing chain-specific sidecar or indexer will each stall a route that the on-chain logic would otherwise happily settle.

4. Address-family confusion is a correctness risk that lives at the edges. Different chain families use different address shapes, and any integrator that normalizes them together — or copies one where the other was expected — creates a class of bugs that on-chain checks cannot fully rescue.

5. Economic parameters on testnet are deliberately soft. The current minimum bond and the size of the insurance accumulator are tuned for a testnet solver set, not for a mainnet adversary with capital; the solver economics have to be re-derived before that environment.

A living document

This threat model is not exhaustive, and it is not meant to be. It represents the team's current best effort at naming the threats the protocol actively reduces and the residual risks that remain visible today. As the ecosystem evolves — new chain families integrated, new route types enabled, new classes of adversary understood — this model will be extended to match. We expect to discover threats that are not on this page yet, and we treat that as a feature of the process rather than an embarrassment: a threat model that never changes is one that has stopped being honest. Readers who identify a class of risk that is not captured here are encouraged to surface it so it can be reviewed, named, and addressed.

Threats this model does not cover

Wallet phishing, malicious frontend distribution, chain-level compromise or L1 failure, private key compromise outside the protocol, and every class of economic attack against an under-collateralized or testnet-configured solver set are all out of scope here. Those risks are real, they just do not live inside the surface Fusion's design can enforce — they belong to the wallet, the distribution channel, the underlying chains, or the economic configuration of a deployment rather than to the protocol itself.

Summary

The closure story is strongest on the same-family core flow, where replay protection, HTLC-based atomicity, preimage authorization, and settlement-proof context binding compose into a coherent end-to-end defense. It is still maturing around cross-family routes — where external chain sidecars, address normalization, and shielded-route operational assumptions are the active frontier — and around solver economics, where today's bonding parameters are explicitly testnet-shaped and must be raised and re-argued before any mainnet-scale solver market can be trusted. This document is honest about that asymmetry on purpose: the parts that are solid are named as solid, and the parts that are not are named as not.

Related docs:

• Security Model
• Trust Assumptions
• Atomic Settlement Guarantee