Skip to main content
This reference maps user-approved outcomes to the concrete discovery, RFQ, settlement, and recovery mechanisms used by Arkade Intents. It is not an integration tutorial. Application developers can start with Lightning or Arkade Assets.

Protocol at a Glance

Every swap executes a directional route between two endpoints. Each endpoint identifies an asset and the corridor where it settles, such as arkade:BTC, lightning:BTC, or onchain:BTC. Terms are always established quote-first; the route selects only the contract that enforces the commitment: The route selects the contract: both endpoints inside Arkade settle in one transaction; any other route uses an HTLC under a settlement profile. Markets and Execution owns the split.

Before Value Moves

  • Derive locally. Build the settlement contract from user-approved terms and wallet-owned data; anything a solver returns is comparison data — a mismatch stops the flow.
  • Persist first. Store the identifiers, terms, and recovery data before funding.
  • Reconcile from evidence. Recheck time-sensitive terms at commitment, and report a terminal result only from contract and destination-network evidence — a timeout means unknown.
The client package resolves the Emulator key from the Arkade operator; an optional emulatorPubkey override (33-byte compressed hex) remains for callers who need to pin a different co-signer key.

Discovery and Registries

Discovery tells an application which markets and solvers may be reachable; cards, indexes, advertisements, fees, and feeds remain advisory. Registries review solver cards and publish generated network indexes — they influence which solvers an application sees but never implement a route or control settlement. Read Discovery and Registries for solver-card fields, market indexes, application curation, and open-discovery policy.

Asset Swaps

Arkade-only exchanges settle both legs in one Arkade transaction; a compatible solver fills the funded contract. Read Arkade Asset Swaps for pricing, funding, the extension packet, and cancellation behavior.

RFQ and the Relay

Every route is quote-first; cross-corridor routes negotiate theirs over a relay as solver-signed, short-lived terms. An addressed request goes to one solver, encrypted to its key; a published request collects sealed bids from every solver watching the pair before closing with one. The relay delivers messages but does not select solvers, aggregate quotes, or touch funds. Read the RFQ Protocol for the quote lifecycle, kinds, encryption, and transport requirements.

Lifecycle States

Asset-swap contract states and RFQ wire states are different vocabularies. Applications translate those states into route-specific outcomes such as filled, paid, claimed, cancelled, or refunded. Read Lifecycle and Recovery.

Settlement Profiles

A profile defines who commits first, who funds Arkade, how timeouts are ordered, and which evidence completes or recovers one directed corridor route. Read Settlement Profiles for all four implemented BTC directions and their current timing bounds.

Roles and Trust Boundaries

One organization may perform several roles, but their trust boundaries remain separate. Markets and Execution defines the participants. Read Trust and Limitations for the guarantees and failure boundaries behind each role.

Implementation Status

Protocol, solver, client, and wallet work ship independently. The reference paths are beta and several client surfaces remain unreleased or manual. Read Implementation Status before choosing a route or advertising availability.

Draft Boundaries and Sources

The RFQ wire kinds remain provisional, signed bids are not bonded, corridor contracts currently carry BTC on both legs, and the production client transport is not turn-key. The focused reference pages link their primary specifications and implementations. When a draft and reference implementation disagree, implemented behavior takes precedence and the unresolved difference remains explicit.

Markets and Execution

One quote-first flow, and the settlement split behind it.

Implementation Status

Check each capability across protocol, solver, client, and product layers.