TAPProtocol documentation

Bitcoin mainnet, inscribed tokens

TAP: inscribed tokens that can delegate authority

TAP is an inscribed token protocol from the Trac ecosystem. It keeps the familiar deploy, mint and two step transfer of an inscribed token, and adds something those protocols do not have: a token can name an authority, and some operations only count when that authority has signed for them.

  • Chain Bitcoin
  • Network mainnet
  • Protocol tag tap
  • Carrier Ordinal inscriptions
  • Lifecycle Experimental
  • Document version 2.0.0

What TAP is

A TAP token lives entirely in Ordinal inscriptions. There is no contract and no sidechain. Every action is a small JSON object inscribed on a satoshi, tagged with "p": "tap". Indexers read those inscriptions in block order and agree on the resulting balances.

TAP did not originate at Bitcoin Universe. It comes from the Trac ecosystem, and this site documents the protocol as the ecosystem uses it, with every rule on this site traced to code that Bitcoin Universe runs. Where an indexing decision is specific to Bitcoin Universe rather than to TAP itself, it is labelled as such.

Two properties separate TAP from the inscribed token protocols it grew out of:

Authority in one picture

Most of what happens on a TAP token is ordinary: anybody holding a balance can transfer it, and anybody can mint while a mint is open. A smaller set of operations is authority bearing. Throughout this site, ordinary operations are drawn in indigo and authority bearing operations in gold.

Ordinary and authority bearing paths to indexed TAP state Two paths lead to the same indexed token state. On the ordinary path a holder inscribes a token-transfer and sends the inscription, and the indexer accepts it on the strength of the inscription content and its current location. On the authority path a deployment names a privilege authority inscription, that authority signs an operation body, and only then does the indexer treat the operation as effective. Ordinary elements are drawn in indigo, authority bearing elements in gold. ORDINARY PATH Holder holds a balance token-transfer inscribed, then sent AUTHORITY PATH Deployment prv names authority Token authority signs the operation body Indexed token state balances, transferables, holders agreed by every TAP indexer An operation that fails any content rule is not an operation at all. Nothing moves, and no error is recorded on chain.
Ordinary operations stand on their own content and location. Authority bearing operations additionally need a signature from the authority the deployment named.

Who this is for

Token holders

You need to know that a TAP transfer takes two steps, and that the inscription created by step one is spendable like any other ordinal. The guide walks it through.

Application developers

You need the exact payload contract and the indexer's confirmation and reorg behaviour. Start with the specification and the reference.

Indexer implementers

You need reject conditions you can test. The test vectors are taken from the test suite of Bitcoin Universe's own TAP indexer.

Protocol facts

Values pinned by Bitcoin Universe's TAP indexer and protocol registry.
OriginThe Trac ecosystem. TAP is an upstream protocol that Bitcoin Universe indexes, not a Bitcoin Universe invention.
Chain and networkBitcoin, mainnet. The indexer refuses to start against any other network.
Protocol tag"p": "tap", exact and lower case.
CarrierOrdinal inscriptions. Bitcoin Universe's inscribe flow writes TAP payloads as text/plain;charset=utf-8.
Ownership modelHybrid: balances are held per address, and a pending transfer is bound to a specific inscription and its output.
Address rolesPayment and ordinals.
Ticker limitsUp to 32 UTF-16 code units and 128 UTF-8 bytes, in NFC lower case form, with no Unicode control, format or separator characters.
Decimal scaleThe indexer accepts a declared scale of 0 to 18 and converts by string padding, never by floating point arithmetic.
Source coveragepartial. Confirmed state is complete; there is no mempool feed.
MarketplaceFeature gated behind tapMarketplaceV1, executed in app, settling at one Bitcoin confirmation.

Operations at a glance

The full table with per operation field requirements is in the specification. This is the shape of it.

Rows shaded gold are authority bearing.
OperationDoesAuthority
token-deployCreates a ticker with a supply cap and a per mint limitOptional, through prv
token-mintMints into an address under the deployment's termsOptional, set by the deployment
token-transferStep one of a transfer, makes an amount transferableNone
token-sendMoves balances for a list of items in one payloadRequired
dmt-deployDigital Matter Theory deployment on the tap tagRequired
dmt-mintDigital Matter Theory mint on the tap tagNone

Support in Bitcoin Universe

Bitcoin Universe runs a TAP indexer and exposes TAP in three product surfaces. The table records what the product code implements. It is not a promise that a surface is switched on in production, which the status pages report separately.

Recorded in the Bitcoin Universe protocol registry and its generated capability snapshot.
SurfaceActions
Coreview, discover, view collection, view activity, view transaction, list, update listing, unlist, buy, make offer, accept offer, cancel offer, settle, reconcile
Walletview, send, receive
Inscribedeploy, mint, transfer

One marketplace action is not supported. The registry records sell as unsupported for TAP with this recorded reason:

TAP has no executable offer workflow on this marketplace surface.

Where to start

Reporting a problem

If you find a flaw in this documentation, or a way that a Bitcoin Universe TAP surface can be made to disagree with the chain, report it privately through GitHub private vulnerability reporting rather than in a public issue. SECURITY.md has the details.