Every numbered rule below is enforced by code that Bitcoin Universe runs, or is recorded in the payload builders and protocol registry that Bitcoin Universe maintains. Where TAP defines behaviour that Bitcoin Universe does not implement, this document says so rather than restating rules it cannot check.
1. Scope and conformance
SC-1This document specifies the TAP profile that Bitcoin Universe indexes: protocol tag tap, chain Bitcoin, network mainnet, carried by Ordinal inscriptions.
SC-2An implementation conforms when it accepts every payload this document marks as valid and rejects every payload it marks as invalid, at the same point in the pipeline.
SC-3TAP is defined upstream in the Trac ecosystem. Rules here that carry the label Universe are decisions taken by Bitcoin Universe's indexer, not properties of TAP itself.
SC-4The rules in section 3 are stated at byte level because Bitcoin Universe's marketplace authority must prove, from inscription content alone, that a given inscription is a TAP token-transfer. Other operations are specified at field level.
SC-5A payload that fails any rule is not an operation. Nothing moves, and the chain records no error. There is no partial application and no repair.
2. Carrier and transaction anatomy
CA-1A TAP operation is the body of an Ordinal inscription. The inscription's envelope, ordering and numbering follow the Ordinals conventions, which this document does not restate.
CA-2Bitcoin Universe's inscribe flow writes TAP payloads with the content type text/plain;charset=utf-8, committed in a taproot script path reveal.
CA-3An inscription is identified by <txid>i<index> where the txid is 64 lower case hexadecimal characters and the index is a decimal integer with no leading zero.
CA-4The address that controls the output holding an inscription is the address that holds it. A TAP balance follows the address, and a pending transfer follows the specific inscription and its output.
CA-5Universe Addresses are Bitcoin mainnet only. A mixed case Bech32 string is rejected outright. Addresses supplied by users are never rewritten between networks.
CA-6An inscription whose inscription number is negative is a cursed inscription. Its ticker is placed in a separate namespace, described in rule TK-6.
3. Payload encoding
These rules define the exact content contract for a TAP token-transfer. They are a direct statement of the parser used by Bitcoin Universe's TAP indexer.
EN-1The content must be at least one byte and no more than the configured maximum content size.
EN-2The content must not begin with a UTF-8 byte order mark. A leading EF BB BF is a rejection, not something to strip.
EN-3The content must decode as UTF-8 with no replacement. Any invalid sequence is a rejection.
EN-4The content must be exactly one JSON object. Whitespace, meaning space, tab, carriage return and line feed, is permitted before it, after it and between its tokens.
EN-5The object must not be empty.
EN-6Every key and every value must be a JSON string. Numbers, booleans, nulls, arrays and nested objects are all rejections.
EN-7No key may appear more than once.
EN-8The permitted key set is exactly p, op, tick, amt and dta. Any other key is a rejection, including keys that other TAP operations use.
EN-9The keys p, op, tick and amt are required.
EN-10A JSON string must not contain an unescaped character below U+0020.
EN-11A trailing comma before the closing brace is a rejection.
EN-12Any data after the closing brace, other than the whitespace of rule EN-4, is a rejection.
EN-13p must equal tap exactly. op must equal token-transfer exactly. Both comparisons are case sensitive and are made before any normalisation.
EN-14dta is optional free data. When present it must be at most 512 UTF-8 bytes. It carries no protocol meaning.
The parser reads the object itself rather than handing the text to a general JSON reader. That is deliberate: two payloads that a permissive reader would treat as equal, for instance one with a duplicate key, must not be able to produce the same transfer.
4. Tickers
TK-1A ticker is compared after Unicode NFC normalisation and lower casing. TÄP, täp and the decomposed spelling of either are the same ticker.
TK-2A ticker must be at least one and at most 32 UTF-16 code units. Characters outside the Basic Multilingual Plane, including most emoji, count as two code units each, so a ticker of emoji is limited to 16 of them.
TK-3A ticker must be at most 128 UTF-8 bytes.
TK-4In token-transfer content, the ticker as written must already equal its NFC lower case form. A ticker that only becomes valid after normalisation is a rejection.
TK-5A ticker must contain no character in the Unicode categories \p{C} (control, format, surrogate, private use, unassigned) or \p{Z} (space and other separators).
TK-6When the inscription number is negative and the normalised ticker does not already begin with -, the indexed ticker becomes that ticker with a single leading -. Cursed inscriptions therefore cannot collide with the tickers of ordinary inscriptions.
TK-7Universe The Bitcoin Universe inscribe surface accepts a ticker of exactly 3 characters, or of 5 to 32 characters, when deploying. Four character tickers are not offered there. This is a product rule, not an indexing rule: a four character TAP ticker deployed elsewhere still indexes.
5. Decimals and amounts
AM-1A deployment may declare a decimal scale. The accepted range is an integer from 0 to 18. An absent or empty value means 0.
AM-2A declared scale outside 0 to 18, or one that is not an integer, is a rejection of the deployment.
AM-3An amount must be a JSON string with no surrounding whitespace. A JSON number is a rejection, even when it would round trip.
AM-4An amount must match ^(0|[1-9]\d*)(?:\.(\d+))?$. No sign, no exponent, no thousands separator, no leading zero on the integer part, no bare decimal point.
AM-5The fractional part must be no longer than the deployment's decimal scale.
AM-6The atomic value is formed by right padding the fractional part to the decimal scale, concatenating it to the integer part and stripping leading zeros. The conversion is a string operation. Floating point arithmetic is never used.
AM-7The atomic value must be at most 78 decimal digits.
AM-8A balance may never be negative. A holder record that reports a negative balance is a rejection of that record.
Worked conversions, taken from the indexer's own test suite.
Amount as written
Decimal scale
Atomic value
1.25
4
12500
1
8
100000000
0
8
0
0
0
0
01
0
rejected by rule AM-4
1.001
2
rejected by rule AM-5
6. Operations
OP-1Every TAP payload carries p equal to tap and an op naming the operation.
OP-2An unrecognised op is ignored. It does not invalidate the token and it does not consume anything.
OP-3An operation is authority bearing when it can only take effect with a signature from the privilege authority that the ticker's deployment named. Ordinary operations stand on their own content.
OP-4The dmt- family is carried on the tap protocol tag but describes Digital Matter Theory assets. It is a distinct asset family with its own indexing.
Per operation field requirements. Rows shaded gold are authority bearing. Required fields are listed first, optional fields in brackets.
Operation
Fields
Authority
Indexed by Bitcoin Universe
token-deploy
p, op, tick, max, lim [prv, dec]
Optional, through prv
Yes, as a deployment
token-mint
p, op, tick, amt [prv, dta]
Optional, set by the deployment
Yes, as a mint
token-transfer
p, op, tick, amt [dta]
None
Yes, as a transfer
token-send
p, op, items, where each item carries tick, amt, address
Required
No
dmt-deploy
p, op, tick, elem, prv, dt [id, prj]
Required
Recorded, not normalised
dmt-mint
p, op, tick, plus the deployment block reference
None
Recorded, not normalised
token-deployOrdinary unless it names an authority
Creates a ticker. max is the supply cap and lim is the maximum amount a single mint may claim. Both are amount strings under section 5.
When prv is present it holds the inscription id of a privilege authority inscription. From that point the ticker has an authority, and privileged operations on it must be authorised by that authority. A deployment with no prv has no authority and no privileged operations.
Ticker rules TK-1 to TK-5 apply. Bitcoin Universe's inscribe surface additionally applies rule TK-7 and requires max and lim to be greater than zero.
token-mintOrdinary unless the deployment named an authority
Mints amt of tick to the address that receives the inscription, subject to the deployment's lim and remaining supply.
When the deployment named an authority, the mint body is produced by that authority rather than by the minter, and carries a prv object that includes the authority's salt. This is how a project keeps control of who may mint and on what terms while the mint stays a normal inscription.
token-transferOrdinary
Step one of the two step transfer. Inscribing it moves amt out of the inscriber's available balance and into a transferable balance bound to the new inscription. Sending that inscription to another address completes the transfer.
This is the only operation whose content contract is stated at byte level, in section 3. It is also the only TAP operation that Bitcoin Universe's marketplace authority will accept as proof of a listable position.
A single payload that moves balances for a list of items, each naming a ticker, an amount and a destination address. It is the operation that makes TAP different in kind from a plain inscribed token: one authorised payload can settle many movements without one transfer inscription per movement.
Bitcoin Universe's Bitcoin TAP indexer does not index token-send. The operation appears in the organisation's code only as an unsigned draft payload on the Dogecoin variant of TAP. Treat the field list above as the shape observed in that code, not as a complete authorisation contract, and use the upstream Trac documentation for the signing rules.
dmt-deployAuthority required
A Digital Matter Theory deployment carried on the tap tag. elem names the element, dt the data type and prv the privilege authority inscription. id and prj are optional identifiers.
A Digital Matter Theory mint, recognised by the deployment block it references. Bitcoin Universe indexes DMT with a separate service. Its TAP indexer records these rows as consumed source offsets so that nothing is silently skipped, and does not normalise them into TAP assets or events.
7. Authority model
Delegated authority is TAP's distinguishing idea, and it is worth being precise about what it does and does not give you.
The authority is named once, at deployment. Everything after that is a question of whether a given operation body traces back to it.
AU-1A ticker has an authority only if its deployment named one in prv. There is no way to add an authority to a ticker that was deployed without one.
AU-2The authority is identified by an inscription. That inscription holds the public key against which authorised bodies are checked.
AU-3An authorised operation body is produced by the authority, not by the party submitting it. It carries a salt so that one authorisation cannot be replayed as another.
AU-4An authority bearing operation with no valid authorisation is not an operation. It is ignored under rule SC-5, exactly like a malformed payload.
AU-5Authority is scoped to the ticker whose deployment named it. It confers nothing on any other ticker.
AU-6Ordinary operations are unaffected. A holder's own token-transfer never consults the authority, and an authority cannot block or reverse it.
AU-7Universe Bitcoin Universe's Bitcoin TAP indexer does not index authority bearing operations. It normalises deployments, mints, transfers and trades. Products that need authority semantics must obtain them from an indexer that implements them.
What an authority is worth trusting with. Naming an authority is a decision to trust a key with whatever privileged operations the protocol allows for that ticker, for as long as the ticker exists. Before holding a token whose deployment carries prv, look at what that authority can do, and remember that the ordinary transfer path in rule AU-6 is the part nobody else controls.
8. State model and transitions
Every TAP indexer keeps three things per ticker: the deployment terms, a balance per address, and the set of live transfer inscriptions with the amount each one carries.
ST-1A deployment establishes the ticker, its supply cap, its per mint limit and its decimal scale. A second deployment of an existing ticker has no effect.
ST-2A mint increases the minter's available balance and the minted supply, up to the deployment's limits.
ST-3Inscribing a token-transfer moves the amount from the inscriber's available balance to a transferable balance bound to that inscription. The inscriber's total holding does not change.
ST-4A token-transfer for more than the inscriber's available balance has no effect. It does not partially apply and it does not queue.
ST-5Sending a live transfer inscription to an address credits that address with the amount and consumes the inscription.
ST-6A consumed transfer inscription is spent for protocol purposes. Sending it again moves an ordinal and no balance.
ST-7Sending a live transfer inscription back to the address that created it settles the transfer at that same address. The transferable balance returns to available, and the inscription is consumed.
ST-8Balances are per address and per ticker. There is no protocol level account, allowance or approval.
9. Invalidity conditions
A payload is not a TAP operation when any of the following holds. This list is the practical reject set an implementation should test against; the test vectors page gives a worked case for each group.
Group
Condition
Rule
Encoding
Byte order mark present
EN-2
Encoding
Not valid UTF-8
EN-3
Encoding
Not a single JSON object, or the object is empty
EN-4, EN-5
Encoding
A value is a number, boolean, null, array or object
EN-6
Encoding
A key repeats
EN-7
Encoding
An unknown key is present
EN-8
Encoding
A required key is missing
EN-9
Encoding
Unescaped control character inside a string
EN-10
Encoding
Trailing comma, or data after the closing brace
EN-11, EN-12
Identity
p is not tap, or op does not match the contract being applied
EN-13
Identity
dta longer than 512 UTF-8 bytes
EN-14
Ticker
Empty, over 32 UTF-16 code units, or over 128 UTF-8 bytes
TK-2, TK-3
Ticker
Not already in NFC lower case form, in transfer content
TK-4
Ticker
Contains a Unicode control, format or separator character
TK-5
Amount
Not a string, or carries surrounding whitespace
AM-3
Amount
Leading zero, sign, exponent or separator
AM-4
Amount
More fractional digits than the decimal scale
AM-5
Amount
Atomic value longer than 78 digits
AM-7
Deployment
Declared decimal scale outside 0 to 18
AM-2
State
Transfer amount above the available balance
ST-4
State
Reuse of a consumed transfer inscription
ST-6
Authority
Authority bearing operation with no valid authorisation
AU-4
10. Bitcoin Universe indexing decisions
These are choices made by Bitcoin Universe's indexer. They are not properties of TAP, and another conforming indexer may reasonably differ.
UN-1Source coverage is reported as partial, with this recorded reason: The Universe-operated TAP writer provides confirmed indexed state and authenticated block digests but no pending mempool feed. Tail checks detect confirmed replacements visible in writer lists.
UN-2Activity for a ticker with no known deployment is held back until the deployment stream has been read to its current length. If the deployment is still absent, the row is quarantined rather than scaled with a guessed decimal scale. A later deployment rewinds and retries it.
UN-3When deployment metadata changes, affected activity is invalidated and rewound before the new decimal scale is applied.
UN-4Rows that carry a block height are recorded as confirmed. Rows without block evidence stay pending. This is not a claim of complete pending coverage.
UN-5Trade rows map to a listing, unlisting, offer, accepted offer or sale when the source action gives that evidence. An unknown trade action maps to a listing and keeps the raw action alongside it.
UN-6The dmt- family is recorded as consumed source offsets and is not normalised into TAP assets or events.
UN-7A raw source record is capped at 256 KiB. An oversized row keeps its SHA-256 fingerprint and byte count, is quarantined, and is never guessed at.
UN-8The service pins its source identity, chain, network, writer version and writer revision, and stores an identity hash in its database. A database created for another source cannot be opened.
Continue to the reference for confirmation, mempool and reorg semantics in full, or to the test vectors for payloads you can run against your own implementation.