Zcash ordinals, explained

Zcash inherits Bitcoin's UTXO model, so every output can be ordered and numbered. A zOrdinal takes one zatoshi out of that sequence and binds content to it by creating a transparent transaction whose output carries an OP_RETURN envelope.

The inscription is identified as <txid>i<outputIndex>. Because the binding is a UTXO, ownership follows the chain: whoever can spend the inscribed output owns the ordinal, and moving it records provenance automatically.

Inscriptions live in the transparent pool. Shielding the inscribed output destroys the public linkage that makes an ordinal verifiable, so shielded envelopes remain an open research problem.

Zcash relays at most 83 bytes per data-carrier script (one OP_RETURN, a push opcode, and up to 80 payload bytes). The wire format is therefore abbreviated and payloads larger than one output are split automatically.

{"p":"zord","o":"in","t":"text/plain","h":"ab12","d":"<base64>"}

When the envelope does not fit, it is serialized once and then sliced across outputs. Each slice records the group id, its index, the total, and the base64 chunk:

{"g":"a1b2c3","i":0,"n":5,"d":"<base64 slice of the JSON>"}
{"g":"a1b2c3","i":1,"n":5,"d":"..."}

Concatenating the slices in order reproduces the original JSON exactly, which is then parsed normally. This keeps large content and large headers on the same code path.

Wire fields

A deploy inscription declares a ticker, a maximum supply and a per-mint limit. A mint inscription then credits the minting address, subject to those limits. First deploy wins, so a ticker cannot be hijacked.

{"p":"zrc-20","o":"deploy","tick":"ZORD","max":"21000000","lim":"1000"}
{"p":"zrc-20","o":"mint","tick":"ZORD","amt":"1000"}

Token state — minted amount, mint count and balances — is recomputed deterministically by the indexer from those envelopes alone.

Collections are declared once with a name, supply, metadata root CID and a royalty in basis points. Each mint registers a token id in the collection.

{"p":"zrc-721","o":"deploy","collection":"ZGODS","supply":"100","meta":"bafy…","royalty":"100"}
{"p":"zrc-721","o":"mint","collection":"ZGODS","id":"0"}

A list envelope names the inscription id and the asking price. The asset does not move — it stays in the seller's wallet, and the listing is simply a public, on-chain offer.

{"p":"zord","o":"ls","id":"<txid>i0","pr":"150000000","py":"t1…"}

A buy only settles when the transaction actually pays the asking price to the seller's payout address. Underpaid buys are ignored, so a purchase cannot be forged by broadcasting an intent without the payment.

The indexer checks the value sent to the payout address on every buy. Intent without payment does nothing.

Zcash wallets do not yet ship a WalletConnect-style dApp connection standard, so this marketplace connects in-app. You can generate a fresh BIP39 wallet, restore an existing phrase, or import a transparent WIF key.

Keys are derived at m/44'/133'/0'/0/i and never leave your device: the server only ever receives a signed transaction.

Only transparent (t-address) wallets are supported. Shielded-only wallets cannot currently sign inscription transactions.