Protocol support matrix
This is the most important page on this site. It answers one question for each protocol Core knows about: can I actually do this, or can I only look at it?
Every value below is generated at build time from MARKETPLACE_PROTOCOL_REGISTRY
in the Core protocol registry. Nothing on this page is written by hand, so it
cannot drift away from what the application enforces.
- Enabled
- 9Switched on in the shipped build.
- Feature-gated
- 13Implemented, switched off unless an operator enables the gate. One of those is confined to testnet.
- Read-only
- 7You can see them. You cannot trade them.
- Support buy
- 19/29List: 20. Delist: 19.
- Support sell
- 0/29Not one. `sell` means an executable offer workflow, and none is deployed.
- Enforce freshness
- 2/29CAT-20 and Rare Sats, and neither can trade. Freshness elsewhere is checked per mutation rather than against a numeric ceiling.
- Reconcile after a reorg
- 16/29The other 13 have no local order state to roll back.
- Settle at 1 confirmation
- 16/29The default. Operators may configure a deeper requirement. No protocol sets a minimum confirmation depth for a listing.
- Actions tracked
- 13Per protocol, each either supported with a mode or unsupported with a reason.
The three things that gate an action
Section titled “The three things that gate an action”A protocol row saying Yes is necessary but not sufficient. Three separate
gates stand between you and an executed trade, and all three must agree.
Gate 1 is the matrix below. Gate 2 is the feature-gate column. Gate 3 is live and changes minute to minute; the health contract reports it.
An action that is blocked at gate 2 or gate 3 is a safety decision. It is not evidence that a market is empty or that an asset does not exist.
The matrix
Section titled “The matrix”Yes means the Core registry declares that Core can execute the action for
that protocol. No means it does not. Follow a protocol name for the exact
reason behind every No on its row, plus its indexer, freshness, confirmation,
and reorg policy.
| Protocol | Chain | Availability | View | View collection | View activity | List | Update listing | Delist | Buy | Make offer | Accept offer | Cancel offer | Sell | Settle | Reconcile |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Bitcoin Stampsstamps | bitcoin | Enabled | Yes | Yes | Yes | Yes | No | Yes | Yes | No | No | No | No | No | No |
SRC-20src20 | bitcoin | Enabled | Yes | Yes | Yes | Yes | No | Yes | Yes | No | No | Yes | No | Yes | No |
Ordinalsordinals | bitcoin | Enabled | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
Runesrunes | bitcoin | Read-only | Yes | Yes | Yes | No | No | No | No | No | No | No | No | No | No |
Runes (Native)runes_native | bitcoin | Read-only | Yes | Yes | Yes | No | No | No | No | No | No | No | No | No | No |
BRC-20brc20 | bitcoin | Enabled | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No | No | No | Yes | No |
ARC-20arc20 | bitcoin | Enabled | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
Atomicals NFTsatomicals_nft | bitcoin | Enabled | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
Realmsrealms | bitcoin | Enabled | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
Subrealmssubrealms | bitcoin | Enabled | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
Alkanesalkanes | bitcoin | Read-only | Yes | Yes | Yes | No | No | No | No | No | No | No | No | No | No |
Mezcalmezcal | bitcoin | Read-only | Yes | Yes | Yes | No | No | No | No | No | No | No | No | No | No |
TAPtap | bitcoin | Feature-gatedtapMarketplaceV1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
DMTdmt | bitcoin | Feature-gateddmtMarketplaceV1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
TAP on Dogetap_doge | dogecoin | Feature-gateddogecoinMarketplaceV1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
DUST-20dust20 | bitcoin | Read-only | Yes | Yes | Yes | No | No | No | No | No | No | No | No | No | No |
OP-20op_return | bitcoin | Read-only | Yes | Yes | Yes | No | No | No | No | No | No | No | No | No | No |
OP Namesop_names | bitcoin | Read-only | Yes | Yes | Yes | No | No | No | No | No | No | No | No | No | No |
OP Inscriptionsop_inscriptions | bitcoin | Enabled | Yes | Yes | Yes | Yes | No | Yes | Yes | No | No | No | No | Yes | Yes |
OP_DROPop_drop | bitcoin | Feature-gatedopDropTrading | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
DROPSdrops | bitcoin | Feature-gateddropsMarketplaceV1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
CAT-20cat20 | bitcoin | Gated, testnet onlycat20FractalTrade | Yes | Yes | Yes | No | No | No | No | No | No | No | No | No | No |
Bitmapbitmap | bitcoin | Feature-gatedbitmapMarketplaceV1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
UNATunat | bitcoin | Feature-gatedunatMarketplaceV1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
Bitcoin Namesnames | bitcoin | Feature-gatednamesMarketplaceV1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
Doginalsdoginals | dogecoin | Feature-gateddogecoinMarketplaceV1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
DRC-20drc20 | dogecoin | Feature-gateddogecoinMarketplaceV1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
Rare Satsrare_sats | bitcoin | Feature-gatedrareSats | Yes | Yes | Yes | No | No | No | No | No | No | No | No | No | No |
Ordexordex | bitcoin | Feature-gatedordex | Yes | Yes | No | Yes | No | No | No | No | No | No | No | No | No |
Reading a row
Section titled “Reading a row”| Column | What it tells you |
|---|---|
| Availability | Enabled is switched on in the shipped build. Feature-gated is implemented but switched off unless an operator turns it on. Read-only means you can see it but you cannot trade it. Gated, testnet only means it is behind a gate and confined to a test network. |
| Feature gate | The name of the switch an operator must turn on. If a row shows one, treat the whole row as unavailable until you can see it working. |
| View, view collection, view activity | Reading. Available for every protocol except Ordex activity, which Ordex does not implement. |
| List, update listing, delist | The seller side. Update listing is separate from list because several protocols require a cancel and a relist rather than an atomic edit. |
| Buy | The buyer side. |
| Make offer, accept offer, cancel offer | The bid side of an order book, where one exists. |
| Sell | A specific executable offer workflow. No protocol in the registry supports it. See below. |
| Settle | Whether Core records a confirmed settlement itself, rather than delegating that to an external provider. |
| Reconcile | Whether Core reconciles its own order state after a dropped, replaced, or reorganised transaction. |
Sell is unavailable everywhere, and that is the honest answer
Section titled “Sell is unavailable everywhere, and that is the honest answer”Zero of the 29 protocols support the sell action. Nearly every one gives the
same reason, in the registry’s own words: the protocol has no executable offer
workflow on this marketplace surface.
This is worth stating plainly because “sell” appears in ordinary trading
vocabulary and a reader could reasonably assume it works. In this registry
sell is a specific thing: an executable offer-acceptance workflow. Selling in
the ordinary sense is done through list, which 20 protocols support, and
through accept-offer, which 15 support.
Where the honest edges are
Section titled “Where the honest edges are”Four rows deserve reading before anything else, because each is a case where code exists and capability does not.
| Protocol | What exists | What that does not give you |
|---|---|---|
| Ordex | A validated PSBT routing layer, and a public ask order book | Ordex explicitly does not fund, sign, or broadcast settlement. buy is No. Buying happens in your own wallet, and the Ordex page explains the four steps. |
| Rare Sats | A complete local execution path in a development and test simulator | Production trading requires an external marketplace. Nothing about the simulator makes a mainnet trade possible. |
| CAT-20 | Fractal testnet reads and a trade preview | There is no CAT-20 signer and no broadcaster. A preview is not an authorisation. |
| OP-20 and OP Names | Listings and history stay viewable | The legacy mutation path is retired and fails closed with HTTP 410. The registry notes that the current interface can reach a broadcast step before registration fails, which is exactly why buy is not declared supported. |
Checking this yourself
Section titled “Checking this yourself”The matrix is generated from a sanitized snapshot of the registry, published by the Bitcoin Universe documentation platform and pinned to an exact Core commit. Its provenance block travels with the data:
{ "repository": "bitcoinuniverseio/core", "sourcePath": "backend/packages/ecosystem-contracts/lib/protocols.js", "sourceCommit": "15dd03b5986a0a7ceba2b1a1ed30f3888ae4712c", "generatedBy": "packages/ecosystem-registry/bin/generate-capability-snapshot.mjs"}The snapshot itself is committed to this repository at
src/data/capability-snapshot.json.
A check in this repository’s continuous integration regenerates every protocol
page from it and fails if the published pages and the snapshot disagree.
- How to read a protocol row, for what each registry value means in practice.
- Confirmation and reorg policy, for what happens after you sign.
- Indexer sources of truth, for which index answers which question.