Coordinator Overview

The coordinator is the orchestration service in Fusion.

It is an Express and TypeScript backend that handles:

• intent submission and validation
• solver matching
• proof workflow orchestration
• HTLC lifecycle tracking
• refund monitoring
• WebSocket status broadcasts
• route-specific session APIs for cross-family integrations

What the coordinator is not

The coordinator is not supposed to be the normal custodian of user funds.

That distinction matters. The public model is:

• users or route-specific flows create the source lock
• solvers create the destination lock
• contracts hold the funds during execution

The coordinator is still important, but its importance is operational and control-plane-oriented, not pooled-custody-oriented.

What the coordinator does in practice

Intake and validation

The backend validates intent schema, deadline, route direction, and chain support before queuing the route.

Matching

It matches eligible solvers to eligible intents.

Proof lifecycle

It tracks proof status and only advances the EVM contract path when the required proof state is ready.

HTLC orchestration

It observes source HTLC creation, helps trigger destination execution, and tracks the route state used by both REST and WebSocket clients.

Destination withdrawal

Coordinator-driven destination withdrawal helpers exist for gasless UX. Those helpers still send funds to the HTLC receiver, not to the coordinator.

Refund monitoring

The backend also tracks refund attempts and exposes refund-related fields in status responses when available.

Operational dependencies

The public operator story should stay honest about this layer.

Today the coordinator can depend on:

• chain RPC and WebSocket providers
• contract address configuration
• proof generation infrastructure
• solver availability
• chain-specific sidecars and proof servers for cross-family routes
• environment profile and secret configuration

Runtime profiles

Fusion supports multiple runtime profiles, selected via APP_PROFILE, ranging from relaxed testing configurations used for local development up to hardened production configurations for public-facing deployments. Stricter enforcement of security controls — callback authentication, secret management, endpoint gating — applies as you move toward production.

A public reader should not confuse "a hardening path exists" with "every deployment is already forced into that hardening path". If you are evaluating a coordinator deployment, verify the actual runtime profile and environment, not just the presence of a feature.

Extra work for cross-family routes

Cross-family routes put more operational weight on the coordinator than same-family routes do. Specifically:

• source-lock session management
• attestation handling
• chain-specific indexer and wallet readiness checks
• route-specific liveness handling

Those responsibilities are visible in the API surface and are part of why cross-family support carries more operational weight than the same-family corridor.

Public-safe takeaway

The coordinator is central to the protocol's current runtime behavior.

That does not mean Fusion collapses into "trust the coordinator with your assets." It means:

• the coordinator is the orchestrator
• the contracts remain the settlement rail
• the protocol still depends on a healthy operational backend

Related docs:

• Solver Overview
• Security Model
• Trust Assumptions
• API and WebSocket Overview