Guide

Using TAP, from a ticker to a completed transfer

This page walks the whole path in order, with the payloads written out. You do not need to write JSON by hand to use TAP, but seeing what your wallet is about to inscribe is the only reliable way to know what you are signing.

The one idea to hold on to

A TAP transfer is not one action. It is two, and they can be days apart.

Inscribe a transfer

You create an inscription that says "1.25 of this ticker is now transferable". The amount leaves your available balance immediately, but it has not gone anywhere. It is parked in an inscription you own.
Send that inscription

You send the inscription to the destination address, like sending any other ordinal. That is the moment the balance arrives, and the moment the inscription is used up.

Between step one and step two, the transfer inscription is an ordinary ordinal sitting in an output. A wallet that does not know about ordinals can spend it as change or as a fee, and the parked balance goes with it. Use a wallet that keeps inscriptions in a separate address and never spends them accidentally.

The two step transfer

Step one splits the sender's holding. Step two completes the move and consumes the inscription.

Worked example: deploying a ticker

A deployment fixes the ticker, the supply cap and the per mint limit. Nothing about it can be changed afterwards.

{ "p": "tap","op": "token-deploy","tick": "signal","max": "21000000","lim": "1000"}

tick: The ticker, up to 32 UTF-16 code units. Compared after NFC normalisation and lower casing, so SIGNAL and signal are the same token.
max: The total supply cap, as an amount string.
lim: The most a single mint may claim.
prv: Optional. Naming a privilege authority inscription here is the decision that gives this ticker an authority. Leave it out and the ticker has none, permanently.

The Bitcoin Universe inscribe surface accepts a ticker of three characters or of five to thirty two characters, and requires max and lim to be above zero.

Worked example: minting

A mint claims an amount into the address that receives the inscription, within the deployment's per mint limit and remaining supply.

{"p":"tap","op":"token-mint","tick":"signal","amt":"1000"}

Two mints of 1000 against a lim of 1000 are both fine. One mint of 1001 is not an operation at all: it does not clamp to the limit, it simply does nothing.

Worked example: transferring

Step one, inscribe the transfer

{"p":"tap","op":"token-transfer","tick":"signal","amt":"1.25"}

Every character matters. The rules in specification section 3 are byte level: an extra field, a repeated field, a numeric amount instead of a string, or a stray byte order mark from a text editor all mean this is not a transfer, and the amount never becomes transferable.

An optional dta field can carry up to 512 UTF-8 bytes of free data alongside the transfer. It has no protocol meaning, and it does not change what the transfer does.

{"p":"tap","op":"token-transfer","tick":"signal","amt":"1.25","dta":"invoice 4192"}

Paste either of these into the payload validator to see the checks run.

Step two, send the inscription

Send the inscription created in step one to the destination address. Once that transaction confirms, the amount is credited to the destination and the inscription is used up. Sending it a second time moves an ordinal and nothing else.

If you send it back to the address that created it, the transfer settles there: the transferable balance returns to available and the inscription is consumed. That is the ordinary way to cancel a transfer you no longer want to make.

When a token has an authority

If a deployment named a privilege authority in prv, some operations on that ticker are authority bearing. The practical consequences are narrow but worth knowing:

Your ordinary transfer path is untouched. Nobody needs to approve a token-transfer you inscribe from your own balance, and nobody can reverse it.
Minting may be gated. When a deployment has an authority, the mint body can be produced by that authority rather than by you, which is how projects run allowlists, per address caps and timed mints without a contract.
An authorised batch send exists at protocol level. One authorised payload can move balances for a list of recipients.

Check before you hold. Look at whether a ticker's deployment carries prv, and if it does, understand what that key is entitled to do. An authority is a standing trust decision baked into the deployment, and there is no way to remove it later.

Bitcoin Universe's Bitcoin TAP indexer normalises deployments, mints, transfers and trades. It does not index authority bearing operations, so authority state is not available through Bitcoin Universe surfaces.

Mistakes that cost money

Spending a transfer inscription

The most common and the most expensive. Between step one and step two, the parked amount lives in an ordinal. A wallet without inscription awareness will happily use it as change.

Trusting an unconfirmed transfer

Bitcoin Universe's TAP source has no mempool feed. A transfer with no block height is pending, not done. Do not release goods against a pending TAP transfer.

Assuming a near miss ticker matches

Tickers can contain emoji, punctuation and lookalike letters, and normalisation only folds case and Unicode form. Two tickers that look identical on screen can be different tokens.

Reusing a spent transfer

Once a transfer inscription has been sent and credited, it is consumed. Sending it on again transfers an ordinal, not a balance.

What Bitcoin Universe supports

This matrix records what the Bitcoin Universe product code implements, taken from the protocol registry and its generated capability snapshot. It is not a statement that a surface is enabled in production, which the status pages report separately. No claim is made here about wallets or marketplaces outside Bitcoin Universe.

Action	Core	Wallet	Inscribe
View balances and activity	Yes	Yes	Not applicable
Deploy a ticker	Not applicable	Not applicable	Yes
Mint	Not applicable	Not applicable	Yes
Inscribe a transfer	Not applicable	Not applicable	Yes
Send and receive	Not applicable	Yes	Not applicable
List, reprice and unlist	Yes	Not applicable	Not applicable
Buy	Yes	Not applicable	Not applicable
Make, accept and cancel offers	Yes	Not applicable	Not applicable
Settle and reconcile	Yes	Not applicable	Not applicable
Sell	No	Not applicable	Not applicable
Authority bearing operations	No	No	No

The registry records sell as unsupported for TAP with this recorded reason: TAP has no executable offer workflow on this marketplace surface.

Everything in the Core column is behind the tapMarketplaceV1 feature gate.

Buying and selling

The Bitcoin Universe marketplace treats a TAP position as one live transfer inscription. Before a listing can exist, the authority behind the marketplace has to agree with the chain about that inscription on every one of these points at the same checkpoint:

the indexed row and the indexer's own reader agree on ticker, decimal scale, the inscription's amount, the address balance and the transferable balance;
the inscription content is unambiguous UTF-8 JSON for tap and token-transfer, with no duplicate and no unknown fields;
the ordinals view proves the current address, the sat offset, the complete output inventory, the tip and an unspent location;
Bitcoin Core independently proves the exact output, its script, its value, its confirmation count, its containing block and an unchanged best block;
the output holds exactly that one inscription, no runes, no special sats, and sat ranges that total exactly the output value;
an independent inventory producer proves complete coverage for all 29 marketplace protocols on that output, so nothing else is riding along on it.

Settlement then requires one Bitcoin confirmation, the consumed transfer inscription and the buyer's indexed balance. The listing side has no separate confirmation threshold. If the chain reorganises, the authority appends the observation and reopens or invalidates affected orders deterministically, preserving the funding, broadcast and settlement lineage.

Those checks exist because a TAP position and a rune, a rare sat or another protocol's token can all sit on the same output. A marketplace that only looks at one protocol can be made to sell more than it meant to.