Skip to docs content
Fusion Docs
Book a Call
Home
What Is Fusion?How Fusion WorksStandard vs Shielded RoutesAtomic Settlement Guarantee
QuickstartWallet App Integration
Solver OverviewCoordinator Overview
Supported Chains Overview
Security ModelTrust AssumptionsThreat Model
Intent SchemaChains and TimelocksAPI and WebSocket OverviewWebSocket Events
Whitepaper and Research
Home
Build with Fusion

Wallet App Integration

Wallet-side UX patterns an app integrator still needs to handle.

Dual-wallet UX

Same-family swaps need one wallet. Cross-family swaps need two — an EVM wallet for the EVM leg and the chain's native wallet for the non-EVM leg (Lace for Midnight today). Surface both connections explicitly, validate each is on the expected network, and disable cross-family routes when the second wallet is missing. Collapsing this into a single "connect wallet" button is the most common cause of failed integrations.

Canonical vs display addresses

Fusion's submit and settlement flows require the canonical address form, not the display form. Using the display form passes local validation but fails settlement or routes to the wrong recipient. For Midnight this means values like shieldedCoinPublicKey, not Bech32-style strings. Normalize aggressively; show both forms in the signing prompt when in doubt.

Route and feature-flag gating

Route support is manifest-driven. The canonical source of truth is the shared route-manifest.ts, which the coordinator loads at startup and the frontend imports at build time. Operators can disable individual routes at runtime via the backend's DISABLED_ROUTES env-var override. Same-chain non-EVM routes are explicitly rejected. Integrators should consume the manifest (or the /api/quote response's supported/routeId fields) rather than rely on a static list in their UI.

Signing prompt

The prompt must show, at minimum:

  • source and destination chain names (not just IDs)
  • source and destination token symbols (not just addresses)
  • amount and minimum received in token units
  • recipient in the destination chain's canonical form
  • deadline as a human-readable time

Wallet UIs vary in what they surface for EIP-712. Render these yourself.

Validate before going live

  • address width and canonical form per chain family
  • route direction and feature-flag state from GET /api/chains
  • which wallet is connected to which side
  • which chain each wallet actually targets
  • whether you are pointed at the public submit path or an internal shortcut

Related docs: