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: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, andsig, and the registry verifiessig. 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:0on mainnet, andslip44:1on every test network, such asarkade: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.
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 carriesversion, 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 kind38859, 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:
nameanddiscovery_pubkeymatch the listing;- the card carries markets (a pointer carries no markets);
sigverifies and the card passes the schema;- the event was published within 7200 seconds of now, in either direction.
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.
Ranking and Best Execution
A generated index sorts each pair’s markets byfee_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.