Trust Assumptions

A trust assumption here is any property Fusion does not enforce cryptographically or on-chain but which must still hold for the system to behave correctly end to end. The key split is between trustlessly enforced and operationally assumed: HTLC atomicity is enforced by the contracts, while liveness, routing, matching, proof delivery, RPC honesty, and deployment configuration depend on actors behaving as advertised. The rest of the page walks actor by actor through what each one is trusted to do.

Chains and RPCs

Fusion inherits the finality and liveness guarantees of every chain it settles on. If a source or destination chain stalls, censors transactions, or undergoes a deep reorganization past the point where HTLC locks were observed, the protocol degrades to the underlying chain's behavior, including the possibility that a previously observed lock is rolled back. The source-greater-than-destination timeout invariant protects against one-sided settlement under normal conditions, but it is not a defense against a chain that simply stops producing blocks within the refund window.

RPC providers sit in the same trust class as the chains themselves. The coordinator, refund monitor, and client all rely on RPC endpoints to return honest views of contract state, tx inclusion, and event logs. A compromised or lying RPC can cause the coordinator to misjudge HTLC state, delay refund monitoring, or show stale data to a user. That does not let an attacker steal funds, because on-chain settlement still requires a valid preimage or timeout, but it can degrade user experience and create confusing intermediate states.

On-chain contracts

The settlement rail itself — HTLCAtomicSwap, IntentValidator, SolverRegistry, SettlementVerifier — is where Fusion's trust-minimized core lives. These contracts enforce hashlock atomicity, the timeout invariant, permissionless withdraw and refund, replay protection through per-chain nonces, and the rule that markExecuting requires verified proofs. Nothing in the coordinator or solver path can bypass these checks; that is why the rest of the system can be operationally trusted rather than custodial.

What is still assumed at this layer is contract identity: that the address your client is talking to is in fact the audited, configured contract for the deployment you intend to use. Addresses drift between environments, and hardcoding them in a client is one of the easiest ways to end up settling against the wrong contract. The runtime exposes GET /api/config/htlc-addresses as the single source of truth; clients should fetch from that endpoint and reconcile before signing anything.

Beyond identity, the contracts are trusted to be the versions the documentation describes. Anyone operating a deployment is responsible for making sure the deployed bytecode matches what was reviewed.

The coordinator

The coordinator is an Express/TypeScript orchestration backend. It matches intents to solvers, drives the proof workflow, tracks lifecycle state, and emits WebSocket updates to clients. It is explicitly not a fund custodian: there is no code path through which the coordinator can move user funds. If the coordinator disappears, an in-flight swap falls back to the timeout-and-refund path enforced by the HTLC contracts.

What the coordinator is trusted to do is stay reachable, stay on the intended deployment profile, hold the correct contract addresses, and be wired to healthy solver and RPC endpoints. A misconfigured coordinator can route intents to the wrong place, fail to match solvers to liquidity, or leak operational surface that tighter configuration would have closed. None of that lets an attacker take funds; all of it can produce failed swaps, stuck intents, or degraded privacy.

For cross-family routes the coordinator's operational weight is heavier than for same-family routes. It drives any external chain sidecar the route requires, talks to the relevant proof server, consumes chain-specific indexers, and is responsible for address normalization across the different address forms each family uses. A coordinator that is healthy for same-family routes is not automatically healthy for cross-family ones.

Solvers

Solvers provide destination-side liquidity. They are bonded on SolverRegistry and carry reputation that the coordinator uses during matching, but economically the system still depends on at least one solver being online, holding inventory on the specific route, and configured with the right settlement address for the chain family in question. A quiet solver fleet does not put existing funds at risk, but it does mean new intents cannot complete until a solver fills them — they will eventually hit the refund path instead.

Solver misbehavior in the form of "lock then walk away" is absorbed by the HTLC structure: the user's funds refund after the source timeout, and the solver's own destination lock refunds after the destination timeout. Bonding and reputation raise the cost of that behavior, but the safety of an individual swap does not depend on it; those mechanisms exist to keep the overall fleet healthy over time, not to protect any single user.

The trusted property, then, is narrower than "solvers are honest". It is specifically that at least one solver on the route you care about has liquidity, is online, and is using settlement addresses that match the chain family — with the last point mattering most on chains where the canonical form differs from display forms.

Route-specific operational services

Different routes lean on different off-chain services, and the trust footprint grows with route complexity. Same-family routes depend essentially on RPC providers and the proof generator. Cross-family routes additionally depend on chain-specific sidecars, proof servers, indexers, and address-normalization logic. These are liveness dependencies, not safety dependencies: they can stall a swap, but they cannot redirect settlement.

Readiness checks exist for these subsystems, and the coordinator will refuse to match intents on routes whose dependencies report unhealthy. That protects users from entering a swap that cannot complete, but it also means "the system is up" is per-route, not global — a deployment can be fully healthy for same-family routes while being unable to serve a particular cross-family route because one of its dependencies is down, and that is the intended behavior rather than a bug to paper over.

Integrators relying on cross-family routes should treat the relevant sidecar, proof server, and indexer as first-class operational dependencies with their own monitoring and their own incident response, not as implementation details of the coordinator.

Runtime profile and configuration

Fusion ships with multiple runtime profiles — from relaxed testing configurations up to hardened production — and several security controls are deployment-dependent rather than always-on. Callback authentication, for example, is implemented as a reusable primitive but is only effective when the deployment has actually configured it. Relaxations intended for local testing must not survive into a shared or production deployment.

The assumption is straightforward: whoever runs the coordinator has matched the profile to the audience — callback authentication is on with real secrets, testing shortcuts are off, operator secrets are real values, and feature flags match the routes intended to be served. A coordinator running on a relaxed profile completing a swap is not evidence that the same swap would complete safely against a hardened deployment.

Users and wallets

The user signs EIP-712 typed-data intents with their own wallet. The authorization surface is narrow — a specific intent, with a specific nonce, for a specific route — but the wallet is still trusted to display what is being signed accurately, and the user is trusted to read it. Phishing, lookalike front-ends, and wallet UIs that rewrite addresses sit outside Fusion's control. Chains whose canonical address form differs from their display form raise the stakes here; front-ends integrating such chains should normalize aggressively and show both forms when in doubt.

What you are NOT assuming

Fusion's positioning is as much about what it does not ask you to trust as what it does. You are not assuming the coordinator takes custody of swap funds — there is no code path that lets it, no emergency drain, no privileged withdrawal, and no escape hatch that terminates in a coordinator-controlled address. If the coordinator disappears mid-swap, the HTLC structure falls through to refund on timeout; users are not queued behind an operator recovery process.

You are also not assuming a multisig can mint replacement assets on a destination chain — there is no wrapped-asset path in the core protocol — and not assuming a shared reserve pool backs every route. Each swap is individually collateralized by a real solver committing real inventory on the destination side, with hashlock linkage tying that commitment to the user's source lock. That is a materially different trust shape from pooled-custody bridges, and it is one of the reasons the assumptions above are limited to liveness and configuration rather than "please trust this committee with your funds".

Before you rely on this system

Before pointing production traffic at a Fusion deployment, integrators should explicitly verify:

• which route family they are using (same-family vs. cross-family) and which operational services that implies
• what contract addresses the runtime is actually serving, by fetching GET /api/config/htlc-addresses rather than hardcoding
• which runtime profile the coordinator is running on (testing, shared, or production) and whether that matches the audience they intend to serve
• that callback authentication and operator secrets are configured with real values, not placeholders carried over from a testing profile
• which chain each client actually targets, end to end, including that the wallet is connected to the expected network before the user signs

Related docs:

• Security Model
• Threat Model
• Supported Chains Overview