Run Fusion

Solver Overview

How solvers fit into Fusion — the model and responsibilities. Onboarding is a partnership process at this stage, not a self-service integration.

Solvers are the destination-side liquidity providers in Fusion.

Their job is not to custody user funds. Their job is to:

accept matched intents
lock destination-side liquidity
monitor settlement progress
claim the source side after the route resolves
manage chain-specific settlement addresses where needed

What exists today

In place and in production paths:

on-chain SolverRegistry
backend solver matching logic
a MockSolver reference implementation for internal testing paths
a solver CLI with register, status, balance, htlc-monitor, htlc-withdraw, and htlc-refund commands

Still maturing for real operators:

public real-solver guidance is still high level
economic parameters are still testnet-oriented
some route families still rely on coordinator-side shortcuts or feature flags

The minimum solver responsibilities

A real solver should be able to:

keep funded balances on the routes it serves
publish or configure the correct settlement address per chain family
react when an intent is matched
create the destination HTLC
monitor for preimage reveal or settlement-proof completion
claim the source HTLC
handle refunds and retries where appropriate

Solvers can configure chain-specific settlement addresses — including separate canonical-form addresses for non-EVM chain families whose address shape differs from 20-byte EVM.

Bonding and reputation

Important current caveat: SolverRegistry's current MINIMUM_BOND is intentionally low for testnet:

current value: 0.01 ether
this will be raised before mainnet

The registry also includes:

a 7-day withdrawal timelock
reputation tracking
progressive slashing percentages
an insurance-fund accumulator

Those mechanisms are real and on-chain, but the present values are not a claim of production-ready economic security.

Solver trust boundary

A solver can fail to fill, misprice, or go offline. The protocol tries to contain that with HTLC structure and bond/reputation logic, but a solver is still an active counterparty in the route.

The safe public framing is:

a solver is not a custodian
a solver is still a required actor for route fulfillment
the current system has guardrails, not final mainnet economics

See trust assumptions and threat model.

Cross-family routes

If a solver serves cross-family routes, it takes on extra operational surface:

chain-specific address handling and normalization
sidecar or adapter readiness per chain
chain-specific indexer and proof-server dependencies
route-direction constraints

That extra surface is why cross-family routes carry more operational weight than same-family ones.

Who should use this page

This page is for:

teams evaluating whether to run a solver
integrators who want to understand solver obligations
reviewers checking whether Fusion depends on pooled liquidity or route-local fills

If you need the wire format and chain data, continue with: