Zote standard

Draft 0.1, October 2026. A proposal for how any Zcash wallet or marketplace can recognise, protect, transfer and verify zotes, using the Ironwood pool as it is today.

Abstract

A zote is a non-fungible collectible represented by a single zero-value note in the Ironwood shielded pool. Ownership is control of the note's spending key. Each transfer creates exactly one successor note through Ironwood's action binding, so a zote can't be duplicated or sold twice. This document defines the memo format, issuance and transfer rules, an ownership proof, and what wallets must do to hold zotes safely.

Motivation

Zcash Shielded Assets are not active on mainnet, so Zcash collectibles today are records in marketplace databases. Zotes need no consensus change: they use notes, memos and the existing action structure. A shared standard lets any wallet display zotes and any marketplace trade them, instead of each project inventing its own.

Terms

  • Zote: a zero-value Ironwood note carrying a zote memo, valid under the rules below.
  • Vault: an address that holds exactly one zote and no other notes.
  • Hop: the number of transfers since mint. Mint is hop 0.
  • Issuer chain: the sequence of issuer transactions that mints a collection and ends with a seal.

The key words MUST, MUST NOT, SHOULD and MAY are used as in RFC 2119.

Memo format

ZEC-O1|<collection-id>|<item>|<hop>        zote note
ZEC-O1|<collection-id>|FINAL|0             seal note

Fields are UTF-8, separated by |. The memo is encrypted like any other memo; only the holder, and anyone they share the vault viewing key with, can read it. Future versions MAY append fields after the hop.

Issuance

  • Each mint MUST spend a note from the issuer's previous issuer-chain transaction, so the chain is connected.
  • Each zote MUST have value 0 and be sent to a fresh vault address.
  • The issuer MUST end the collection with a seal note sent to a provably unspendable address, with the memo encrypted to the issuer's outgoing viewing key so verifiers can read it.
  • The issuer SHOULD publish its full viewing key so anyone can count the collection.
  • Any zote memo in an issuer transaction after the seal is invalid.

Transfer

  • A transfer MUST spend the current zote note and create its successor in the same Ironwood action, with value 0 and the hop increased by exactly 1.
  • The successor MUST go to a fresh vault address.
  • Fees MUST be paid from other inputs in the same transaction, never from a vault.
  • A sale SHOULD be a single jointly built transaction (PCZT) containing both the zote transfer and the payment, with the seller signing last after checking the payment.

Ownership proof

The verifier issues a fresh random challenge. The holder returns the zote's transaction id, action index, note commitment, nullifier, the vault viewing key and a signature over:

zecathon-carrier-control-v1|<challenge>|<txid>|<action>|<cmx>|<nullifier>

made with the vault's spend-authorising key. The verifier MUST check that the signature is valid for that key, the note decrypts to a valid zote memo, the nullifier is not yet in the nullifier set (otherwise the result is SPENT), and every hop links back through same-action bindings to a sealed issuer chain. Results: VALID, HELD, SPENT or FAIL. The prefix is kept from the reference implementation and will be renamed zote-control-v1 in a later draft.

Wallet requirements

  • Wallets MUST NOT select zote notes as inputs for ordinary payments. Doing so destroys the zote.
  • Wallets SHOULD show zotes as collectibles: collection, item, hop.
  • Wallets SHOULD keep each zote in its own vault and offer "send zote" and "prove ownership" actions following the rules above.
  • Wallets MAY show the collection's verification status using two independent servers.

Privacy considerations

Chain observers learn nothing beyond the existence of shielded transactions. A proof reveals the vault's history, which is why a vault MUST hold one zote only. A buyer learns the zote's hop count and dates. The issuer's viewing key exposes mint-time vault addresses. Light-wallet servers see request metadata; clients SHOULD use Tor.

Security considerations

The network enforces uniqueness (a note can be spent once). The seal is enforced by verifiers, not consensus. Verifiers MUST reject unverifiable history rather than assume validity, and SHOULD require agreement between two independent servers. Unspendable seal addresses are derived from public hash bytes with no known key.

Reference implementation

Zollect's checker and sender tools, with the Lagos Lights collection live on mainnet. See the docs and the evidence. Design credit for carrier notes: Zarrier.