Skip to main content
Discovery tells an application which markets and solvers may be available. It does not reserve inventory, bind a price, or implement settlement. Applications may combine curated registries, pinned solver cards, and their own eligibility or ranking policy.

Solver Cards

A solver card is one JSON document per solver and Arkade network. It advertises the markets the solver serves and, when needed, how to request live terms. This example card is valid against the card schema, and its signature verifies:
The two markets are the two shapes. The first settles both sides through Arkade and its sides carry different assets, so it names a price feed and needs no rendezvous. The second puts its quote side on Lightning through the id bolt11:bitcoin/slip44:0. Both of its sides are BTC, so it names no feed: fee_bps is the whole spread. A corridor market makes the signed discovery_pubkey, transports, and sig mandatory — without them a client has no identity to seal a request to and no relay to send it on. The registry enforces these rules on every card:
  • A card with a corridor market must carry discovery_pubkey, transports, and sig, and the registry verifies sig. A card whose markets all settle through Arkade can omit them.
  • The two sides of a market must have different ids. When exactly one side settles through Arkade, that side must be the base side.
  • Each id names its network, and BTC’s SLIP-44 code depends on it: arkade:bitcoin/slip44:0 on mainnet, and slip44:1 on every test network, such as arkade:mutinynet/slip44:1. A card filed under one network must name only that network.
  • A market whose two sides carry the same asset must omit the feed fields.
For a market whose endpoints both use arkade, the card advises the pricing formula: which spot feed to read and what spread a fill charges. It remains advisory: it guarantees neither inventory nor that a fill executes.

Registries

A registry is a Git repository of solver cards plus validation and publishing automation. Solvers submit cards through pull requests. The registry validates them and generates one market index per network. Each network’s index carries version, network, generated_at (Unix seconds, set by the publishing job), the source commit, and a flat markets list in which each entry names its solver. Its solvers list holds every card that has a discovery_pubkey. The reference registry publishes https://arkade-os.github.io/solver-registry/<network>.json for bitcoin, signet, mutinynet, and regtest, and the swap client follows it by default. Currently (2026-10-31) the mainnet index lists no solvers, so an application on mainnet discovers no markets from it without a pinned card. The discovery client treats an index older than 7 days as stale. It warns, holds back the markets that index snapshotted, and still accepts a listed solver’s fresh card over its relays. After 28 days a stale index vouches for no solver.

Cards over Nostr

A solver also publishes its signed card on its relays as an addressable Nostr event of kind 38859, with a d tag naming the network. For each solver an index lists, the discovery client fetches that card and uses its markets in place of the index snapshot. It accepts the card only when:
  • name and discovery_pubkey match the listing;
  • the card carries markets (a pointer carries no markets);
  • sig verifies and the card passes the schema;
  • the event was published within 7200 seconds of now, in either direction.
A pointer card in a registry lists only the solver’s identity and relays, so its markets always come from the card on Nostr. A solver can then change its terms without a registry pull request. Registry review is a listing gate, not a settlement trust anchor. A merged card can become stale, and an index cannot move funds.

Application Curation

No registry is mandatory. An application can:
  • follow one or more public or private registries;
  • pin a solver card directly;
  • filter by route, size, issuer policy, jurisdiction, or reputation;
  • re-rank solvers using fill history or other product-owned data;
  • remove solvers without changing the settlement protocol.
When combining registries, isolate failures, validate every index, remove byte-identical duplicates, and keep source attribution. A solver omitted from one registry remains reachable through another registry or a pinned card.

Ranking and Best Execution

A generated index sorts each pair’s markets by fee_bps, then by solver name. That order is a static proxy, not a ranking: a market with a flat fee can cost more at small sizes than a market with a higher fee_bps. Price freshness, routing capacity, inventory, reliability, and application policy also affect execution quality.

Trust Model

Treat cards, indexes, advertisements, and price feeds as advisory. For corridor RFQ, verify the signed rendezvous and every signed quote. On every route, derive the settlement contract locally before value moves.

Sources