Appendix

A Terms B Operations C Notes and messages D Parameters E Rewards F Live indexers G Common address H On chain I Chapter notes J Names K Questions

This appendix is for looking things up, and you can skip it on a first read. It follows the archived live product and client; figures marked "public v1" come from v1 in the public code repository.

A　Terms

Each term says who makes it and where it lives: private keys and readable notes stay in a vault, never on chain; what goes in an envelope sits in the Bitcoin blocks for anyone to read; what an indexer keeps, anyone can recompute from the blocks.

B　What each operation checks and reveals

Privacy boundaries: what each step leaves behind

SHORD hides the link between a piece and its owner, and between one note and the next, not the Bitcoin transactions. The number is the one identifier that stays public: when #N was bought and by which paying address, and when and at what price it was listed. What SHORD can't prove either way is that today's seller is the last buyer, because a private send in between carries no number.

What keeps you private

• Pay out to a "private address", a fresh one per listing. "My connected wallet", or one typed address used again and again, groups every listing paid there as one person's.
• Send envelopes through the relay. Pay the miner fee yourself, and that wallet is tied to the envelope.
• Buy with BTC not tied to you. Buying and minting show the paying address with the number, and selling shows the payout address with it again; the two stay apart only when neither address is yours by name.
• Leave sale proceeds on the vault's Bitcoin page; withdraw to an address not tied to you, never straight to an exchange deposit.
• Claim only the base reward. A bonus shows the number and ties its pouch to the piece.

Three things to keep in mind

• Voting: public tags let anyone check the tally; when the note is spent later, the vote matches that spend (chapter 06).
• A piece sent to you privately: the sender knows the piece secret s. Until s is renewed (a sale, or an on-chain listing and claim), they can test your later spends, and match one only by guessing the address you send to (appendix I01).
• Inscribing a shielded name yourself: the paying wallet is tied to the name; when the site inscribes it, it uses an unrelated coin of the relay's.

C　Notes, proofs and on-chain messages

A note is written (assetId, tickets, ownerPk, rho, s). Here tickets means the relay credits the note carries, not the note itself. The spend circuit uses these relations:

ownerPk = Poseidon(sk)
inner   = Poseidon(ownerPk, rho, s)
cm      = Poseidon(assetId, tickets, inner)
nf      = Poseidon(sk, rho, 7)

A normal transfer keeps assetId and the piece secret s; the new randomness is rhoOut = Poseidon(nf, 11), and the sender's vault computes the new commitment cmOut and puts it in the envelope. In a mint, purchase or claim, the receiver's vault publishes only inner and a ciphertext, and the indexer completes the commitment from the public number and credits. Credits follow ticketsOut = ticketsIn - spend + buy. A receiving (shielded) address holds the owner key Poseidon(sk) and the view public key, and a normal ciphertext is 88 bytes.

The circuit's public inputs are root, nf, hbody, cmOut, spend, buy, mode, assetIdPub and ticketsPub. mode 0 is a transfer and mode 1 a public listing. hbody binds the proof to the message body. The indexer obtains root and computes hbody from the message and its own state; they aren't two fields copied as they are into the envelope.

A public v1 envelope header holds the SHORD marker, version, type and cid, 15 bytes in all. Transfers and listings carry a 256-byte proof; BUY and CLAIM have their own rules for checking, locks and return signatures. The live client adds more types: rewards 7 to 10, LIST3 11 and SPLIT 12, so the six public types don't cover everything that runs today.

D　Parameters and common mix-ups

• Anchor window for transfers and listings: the last 100 blocks in public v1, and earlier than the current block; an off-chain LIST3 listing lasts at most 4,032 blocks. What goes stale is the proof for one operation; the note itself doesn't expire.
• Only 3,333 numbers exist, but a commitment also mixes in the owner's key, the random ρ and the piece secret s, so hashing each number guesses no commitment after a private send.
• The record tree is 20 levels deep, up to 1,048,576 leaves. Every mint, private transfer, purchase and claim adds a leaf (a listing doesn't), so it counts transactions, not users or pieces.
• Old-style listing escape: a 1,008-block relative timelock, about 7 days. NAKA's live listing locks are all 330 sats, though old LIST validation mainly checks the lock script.
• NAKA's base fees: 15,000 sats to mint and 3,000 to inscribe. A sale costs a 2% platform fee, at least 1,000 sats, paid by the buyer on top of the price, with no resale royalty. The site bundles 3 relay credits (7,500 sats) with each mint by default; miner fees are extra.
• Mining: a few nodes or pools don't relay large OP_RETURNs (the team mentioned it in a public voice chat); Bitcoin Core 30 relaxed that default, and the official relay's thousands of envelopes have all confirmed.
• The public protocol supports 2-of-3 co-signing for a collection; NAKA uses a single platform signature now (appendix H).
• Checkpoints bind engine, rules and keys, which makes recovery safer; the SHA-256 seal at the end catches a damaged or edited file.
• Trusted setup: Groth16 proving keys are made with one-time random numbers that are discarded afterwards. NAKA's were made by the team alone: spend.zkey records a single phase-2 contribution named "proto", holder.zkey one named "local dev (pre-ceremony)". The official status document states the extent: whoever kept those numbers could add a note under an existing piece number, but could never take a piece out of anyone's vault, and real notes still spend. The public code has a multi-party ceremony ready, planned for the next collection, safe as long as one contributor destroys their randomness; the new verification key's hash goes into that collection's parent. NAKA's verification key is pinned in the indexer code. The "key of ours" the founder says the next update removes is the platform's signing key, unrelated to these numbers (appendix K).

• Encryption and proof are two separate things, and the easiest pair to mix up. Encryption lets the recipient find and read the notes written to it; the proof lets anyone judge that a transfer is valid without seeing any secret. The proof doesn't cover the ciphertext: the circuit doesn't check a private send's ciphertext (official status document); the sender's vault writes it by the rules, and the site's vault writes it correctly.

Where the pieces come from. Every component SHORD uses has a public paper or standard; the table lists them. It shows the established cryptography SHORD builds on; SHORD's own circuits and code have no public third-party audit report yet.

E　Rewards and holding

The on-chain plan: start anchor 971,700; week 1 is blocks 971,701 to 972,708; a nominal 266,640 SHNAKAS a week for 78 weeks; claims close at block 1,102,740. The denominator counts all 3,333 catalogue numbers, and weights change every block. Personal eligibility, accrual, amounts already claimed and the final circulating supply each need their own count.

The 78 weekly pools plus three fixed pouches of 80 at the start total 20,798,160. Listed and unminted pieces take a share nobody can claim, so it is never issued; the site says “whatever is never claimed is never issued” (How mining works).

The public holder circuit proves that a note is in the record tree, deduplicated per event. Two things to know when using it. First, it doesn't check that the note is unspent: the tree only grows, so after a sale the old leaf is still there, and the former holder can still prove with the newest root; the protocol document's "verifiers accept only the last 6 blocks' roots" limits how old a root may be, and old leaves stay inside new roots. Second, deduplication is per piece: the tag ctxNf = Poseidon(s, context, 13) comes from the piece secret s, which a private send keeps, so only one of sender and receiver can use it; a sale renews s, so seller and buyer can each prove once. The site's voting uses not this circuit but the spend circuit; see appendix B.

With different claimant accounts in context, a copied proof stops working; deduplication is split across those contexts too, so it doesn't mean each piece can be used only once across a whole event.

F　How live indexers stay consistent

Align network, collection, rules version, verification key, start height and block hash, then compare state. An indexer checks messages in chain order, each type its own way: transfers and listings for the anchored root, the nullifier and the proof, purchases for spending the lock and paying correctly, claims for the return-key signature. Commitments, spent markers, listings and rewards are kept separately. Reaching the same height is only where comparison starts; you also need to know what a digest covers. Public v1 leaves out ciphertexts, payout scripts and locks, so matching digests mean the covered parts match. The live interface also has a separate rewards digest. The site's status interface gives the height and digest but no block hash; the public API Ord Dropz hosts gives both. On 3 November 2026 the two digests matched at block 974,394, but Ord Dropz runs both, so that isn't independent verification.

What an indexer keeps on its machine: every leaf of the record tree, the root and leaf count after every block, the nullifiers it has seen, the mints, the listings and their locks, and the accept or reject record of every envelope. Proofs aren't kept; the originals are in the blocks. It doesn't know which piece a note is after a private transfer, or whose a note is. A checkpoint stores verified intermediate state, and a restart continues from it. On a reorg, the indexer goes back to the shared history and replays. Incremental sync continues from a cursor, and wallets scan locally to recognize their ciphertexts. naka-sigil's public material shows how it reads the official API, cross-checks heights, validates reward tables and drops data after a reorg.

The live rules are newer than the public repository. This guide explains them from the live collection data, state, client and on-chain records. A full independent replay needs the matching rules and parameters; count differences from an older version can't settle questions about the live mechanism.

G　The shared address and the evidence

bc1prykz5vxt6lgr2tu56np35slhvlc77s7hlajr3qucsrkqwhvp48mq5grvgr

This address holds NAKA's inscribed child pieces and the 21 million SHNAKAS sent here at the etching; pieces from Trollbox and other SHORD collections sit here too. The parent inscription isn't here, and it isn't the balance address of anyone's private notes.

How it was checked: the NUMS construction was recomputed. In all 26 of NAKA's child inscription transactions, the number of outputs to this address equals the number of inscriptions in the transaction, 3,327 in total. In the SHNAKAS etching, the Runestone's premine of 21 million points at output 1 and was unspent when read on 28 October 2026. This is a count of outputs, not a sat-by-sat Ordinals replay.

The signature warning applies only to how the official unlock message is derived. It doesn't carry over to other signatures or to vault keys created separately. Raw responses, hashes and the full scope of checks are under Sources.

H　What lives on chain, and what you can do yourself

People often ask how much of their assets and the ledger lives on chain, and what they can do without the site's servers. The answers below come from the public code at 3cdbdfdf and the official client saved on 28 October 2026.

What you must keep safe is the wallet, or the 24 words. The web vault comes from your wallet: the site asks the wallet for an ECDSA signature on the fixed message and says "The same wallet always opens the same vault." That holds when the wallet signs the same bytes every time: the signing libraries Bitcoin wallets use sign deterministically (RFC 6979), and only an identical signature gives the same seed. So keep the wallet's own recovery phrase, and remember which payment address you connected with. On the phone app it's the 24 words, which are the vault's seed; a web vault can be imported into the app and written down the same way.

Keeping data on chain is a trade-off. Transactions are larger, and a few pools skip OP_RETURN outputs above 83 bytes, so a transaction waits for another pool. Ciphertexts stay on chain, so keep the view key as safe as the spend key: it can read the notes written to you, though it can't move them.

I　Technical notes, chapter by chapter

The full version of the technical notes under each chapter's card: why the design is this way, and what the protocol does when something goes wrong.

00　Start here｜What SHORD is, and what you actually hold

Bitcoin doesn't know SHORD. To it, an envelope is just data (OP_RETURN in public v1; the current client can also put it in a tapscript): miners include it without reading it. Which envelopes are valid, and what the record tree looks like, is decided by indexers checking each one against SHORD's rules. So Bitcoin can confirm a transaction that SHORD still rejects.

Everything in an envelope is public, but never a readable note. A private transfer carries only fingerprints, a nullifier, a ciphertext and a proof; mints, purchases and listings also show what they must, such as the number, price and payout script. The indexer column is all computed from the blocks, so no indexer needs trusting. Checking for yourself takes matching rules and parameters and the full block data, ideally from your own Bitcoin node.

Who computes a commitment depends on the action. In a private transfer the sender's vault computes it and puts it in the envelope, and the proof shows it holds the same piece as the old note. In a mint, purchase or claim the receiver builds the new note, the envelope carries only inner and a ciphertext, and the indexer completes the commitment from the public number and credits.

Proofs are Groth16: an indexer checks them with public verification parameters fixed in the code and the envelope's data, never a private key. Their trusted setup is covered in appendix D.

01　Vault｜What holding rests on, where the keys come from

The site asks the wallet for an ECDSA signature on the fixed message: UniSat's signMessage in ecdsa mode, Xverse's ECDSA protocol, both with the payment address you connected. Seed = SHA-256("shord/seed/v1" ‖ signature). The message is VAULT_KEY_MESSAGE in the site's engine, four lines: "Ord Dropz shielded vault key v1", "Signing this unlocks your Shielded Ordinals vault on Ord Dropz.", "ONLY sign this on ord dropz. Anyone with this signature can move your shielded pieces.", "It does not move any bitcoin.". The last line means the wallet you connected; the vault's own BTC addresses come from the seed too, and whoever has the signature can take that BTC.

The seed gives the spend key and the view key. Each listing's return key and sale-proceeds address come from the seed and that listing's nullifier. The vault's own BTC addresses are numbered, and listing coins and bonus claims have keys of their own. All of it is deterministic: given the same signature (the site says the same wallet always opens the same vault), signing again on a new device brings it all back, and sale-proceeds addresses can be matched against the sales record.

The view key and the spend key are separate: the view key alone shows the notes sent to you but can't move them. The web vault's signature gives both, which is why it amounts to the whole vault.

The shielded address shord1… is one more thing the seed gives: after shord1 come 128 hex characters, 64 bytes decoded, the first 32 the owner key ownerPk = Poseidon(sk), the last 32 the view key (x25519). It is used only when someone else builds a note for you: in a private send of a piece or a SHNAKAS pouch, the sender puts ownerPk into the new note's inner fingerprint, inner = Poseidon(ownerPk, ρ′, s), and computes the commitment, so only the holder of the matching sk can later prove "this is mine"; then encrypts the ciphertext to your view key with a one-time key, so your vault can read it. Notes from a mint, purchase, claim or reward are built by your own vault with your own keys and need no address. The owner key is a one-way hash of the spend key, so publishing it reveals nothing of sk; the view key is separate, so handing it over lets someone read but not spend. The address is public, and a name (appendix J) points at it. Privacy doesn't come from hiding it: every note's commitment mixes in fresh randomness, so pieces sent to one address leave commitments with nothing in common, and each ciphertext uses a fresh one-time key, so nobody can tell which view key it was written to. The sender is the exception: a private send keeps the piece secret s. When you next spend the note, your nullifier is published in the envelope, and the next note's ρ = Poseidon(nullifier, 11) comes from it (the circuit requires both). The sender never needs your nullifier: it takes each envelope's published nullifier and new commitment, adds s, the number and an address it guesses, and checks for a match. So when you claim a base reward, or send the piece privately to an address it knows, it can match the commitment, until a sale, or an on-chain listing taken back, gives the piece a new s (appendix K).

The phone app's 24 words are the 32-byte vault seed plus a checksum byte. A web vault can be imported into the app and its 24 words written down.

The prepaid relays the site sells (appendix A) don't come from the seed: the browser makes the secret and the site blind-signs it, so they live only in the browser that bought them, and the same vault on a phone has none.

02　Issuing｜Rules in the parent, and who gets the mint money

The rules are a JSON object in the parent inscription's content (p = shord, v = 1 or 2): supply, the file tree root artRoot and content type, mint price, platform mint fee, inscription fee, sale fee, relay credit price, three payout scripts, the permit key gateKey and the listing-lock key lockKey, with optional 2-of-3 co-signers and a proof-parameter hash. An indexer is pinned to one parent and reads the rules from its reveal transaction; the collection id cid in every envelope header is the first 8 bytes of the hash of the parent's id, and envelopes for other collections are ignored.

Checking a mint: the number is within supply and unminted; the payment is summed per payout script and each script gets at least what the rules demand; the transaction spends one permit coin, a P2TR(gateKey) output. Only the platform can sign that coin, so minting depends on it; a MINTN batch takes at most 20 in public v1, minted numbers are skipped and nothing is refunded. The new note is built by the minter, the envelope carries only inner and a ciphertext, and the indexer computes the commitment from the public number and credit count.

The art files: the parent holds no image, only artRoot. After a mint the platform inscribes the file as a child of the parent (ord's rule: the inscribing transaction spends the parent and names it in the parent tag), with the piece number in its metadata; for one number the earliest child counts. Whether a file matches artRoot can be checked only with the manifest of every piece, which isn't published yet; piece #0's child carries no number, and the public code pins its Merkle path. The parent is parked at NUMS only after the last child is inscribed; on 28 October 2026 it wasn't at the NUMS address (appendix G).

The split: in NAKA's rules mintPrice 15,000 goes to the artist script, mintFee is 0, inscribeFee 3,000 and ticketPrice 2,500 go to the relay script, saleFeeBps 200 with saleFeeMin 1,000 goes to the platform script, and there is no royalty. The artist script and the platform script are the same script (archived collection.json). Rules v2 add a resale royalty to the artist script, at most 10%; a v1 indexer can't read a v2 parent, and NAKA is v1, so no royalty will be added to it.

03　Storage｜Where the art is, and what you bought

The commitment is computed in two layers: ownerPk = Poseidon(sk), inner = Poseidon(ownerPk, ρ, s), cm = Poseidon(piece, credits, inner). Two layers serve mints, purchases and claims: the piece and credits are public then anyway, so the receiver hands over only inner and the indexer completes cm without a proof.

In a mint, purchase or claim, ρ and s are fresh random values. In a private transfer the new ρ′ comes from the old note's nullifier (chapter 04) and s stays the same. Each change of hands changes the owner key or ρ, so the commitment is completely different. s, the piece secret, is replaced on a sale, mint or claim; holder proofs use it to stop double counting (appendix E).

The record tree is 20 levels deep, up to 1,048,576 leaves, and indexers record its root after every block. To spend a note, the proof cites a root from the last 100 blocks to show "my note is in this tree" without saying which leaf.

Relay credits are inside the commitment too, so normally nobody can see how many you have left. But the number bought at a mint or purchase is public, and a listing shows the note's remaining credits. Each spend, the circuit checks that new credits equal old credits minus those spent plus those bought, and never go below zero.

04　Transfer｜A private send, and what the chain shows

Why not simply mark the old note as spent? On chain a note is only a leaf in the tree. If a spend named its leaf, anyone could tie the spend to the transaction that created that leaf and follow the piece from buyer to buyer.

The nullifier is a second fingerprint of the same note: nf = Poseidon(sk, ρ, 7). A note has exactly one, and an indexer rejects any nullifier it has seen, which stops double spends. Nobody can match it to a leaf; the proof shows it belongs to some note in the tree that the spender owns.

Why use the spend key? In a private transfer the new note's ρ′ = Poseidon(nf, 11) comes from the old note's nullifier, which is public, so anyone can work it out, the sender most of all, having written the note. If the nullifier came from ρ alone, anyone could compute the new note's nullifier in advance, wait for it on chain and string the piece's moves together. Mixing in the spend key, which only the holder has, stops that (the circuit's comment: "only the owner can compute it"). The 7 and the 11 just keep the uses apart. Because ρ′ is fixed by the old note, a sender also can't forge two notes with the same nullifier.

Can a nullifier be grabbed? The envelope sits in the mempool for anyone to read, nullifier and proof included. But a nullifier isn't a key, only a public tag: the proof's public inputs hold it, the new commitment and the body hash hbody (ciphertext, credits and the rest), so changing any of them breaks the proof, and a new proof needs the spend key. All anyone can do is put the same envelope, unchanged, into a transaction of their own with a higher fee and get it mined first. The result is the same: the old note is spent, the new one is the receiver's, and the later copy fails on its nullifier. A listing envelope is no different: price, payout script and return key are in hbody, so racing it only lists the seller's piece on the seller's terms, with the racer paying for the lock. A purchase envelope has no proof, but its transaction must spend the listing lock, and the platform signs only the purchase it has checked.

You can send without a relay: set the credits spent to 0 and pay the miner fee yourself. The cost is that the paying BTC is public: anyone can see which wallet sent a SHORD transaction, though not which note or to whom. Paying from BTC unlinked to you removes that link; the site's own "self send" uses the wallet you connected. A relay pays for you and puts the envelopes it has gathered into one transaction in random order; the official relay's status reports a five-minute window (batchWindowMs = 300000); the public relayer code defaults to ten minutes and sends each batch at a random 0.5 to 1.5 times the window, and whether the official relay draws the same way isn't public. A relayed transaction is paid from the relay's own wallet, so the credit fees it takes in become the miner fees and listing locks it pays for others (it moved to a new wallet on 29 October; see 08 in this appendix). The project's October long post on X has a section called "CREDITS GONE": "Same update kills relay credits. No more buying tickets to do private actions. Your vault's own bitcoin pays the network fee, same as any wallet. Old credits still work if you have them, nobody loses anything. Prepaid relays stay as an option for people who want the extra privacy. The platform never pays for anything, which is what keeps it honest." What goes is the per-piece sale of credits; the relay and prepaid relays stay, and the vault's own BTC pays the network fee by default. In the 28 October archive NAKA's config still had creditsOff false, so credits were still on; the site's config on 3 November is the same, every market listing shows its credits, and each SHNAKAS pouch carries one. Paying the network fee from the vault's BTC puts that input in the envelope's transaction; a vault's BTC mostly comes from listing payouts, whose addresses are written in the listings, so for more privacy use the relay or prepaid relays.

The relay credits written into notes are a prepaid fee to the official relay. They travel with the piece: on a send or a sale they go with the note to the next owner, so a seller's unused credits end up with the buyer. The BTC is paid to the relay when you buy them; the note counts broadcasts, redeemed by the official relay. Anyone can run the public relay code, paying the miner fee themselves to relay for others. Prepaid relays: appendix A.

05　Trading｜What a listing reveals, and the platform's role

The listing lock is a P2TR output with two ways to spend it. The platform's lockKey uses the key path, at any time. The seller's return key uses the script path, once the lock has 1,008 confirmations. The return key is derived from the seed and this listing's nullifier, so only the seller can compute it.

With every block, an indexer checks which coins each transaction spends, whether or not it carries a SHORD envelope. When a listing lock is spent, it looks for a valid purchase in the same transaction: the right payments and this very lock. If there is one, it's a sale and the buyer gets the new note. If not, the listing becomes "closed": the piece has no note for now, and only the seller can take it back.

So when the lock is spent in a transaction without a valid purchase, the listing closes, and the piece waits for the seller to sign a CLAIM with the return key, which turns it into a new note for the seller; only the seller can make that signature. Every lock the official relay builds holds 330 sats. The money never passes through the platform either: a purchase pays the seller's address directly.

The lock holds no nullifier: it is a P2TR output whose internal key is the platform's lockKey and whose script leaf is "1,008-block relative timelock + the seller's return key". The listing record is filed under the listing's nullifier and keeps the number, credits, price, payout script, return key and the lock's position. A claim envelope carries the inner fingerprint and ciphertext of the seller's new note, signed over its whole body with the return key; the indexer checks the signature and completes the commitment from the record's public number and credits. The return key comes from the seed and this listing's nullifier, so the platform can't compute it.

What the platform's signature covers: the public code's co-signer signs a listing lock with SIGHASH_DEFAULT, which commits to every input and output of the transaction, checks the transaction on its own indexer first, and remembers what it has signed so it won't sign a second sale of the same piece. NAKA uses a single platform signature, made on the platform's server; whatever the signature type, a lock can be spent only once on Bitcoin, so only one purchase can stand.

The platform's signature is used in two places: signing a purchase, and spending the lock for a cancel. Neither brings the piece to the platform: if the lock is spent without a sale, the listing closes and the seller claims; if no cancel is signed, the seller waits until the lock has 1,008 confirmations, spends it alone and claims in the same transaction. In a normal cancel the platform's spend and the seller's claim share one transaction, and the listing goes straight to "claimed".

A purchase carries no anchor and no proof, so it can't expire in the mempool. A cancel is the spending of that lock.

The payout address can be of any type. The site's "Another address" option hands the address you type to a Bitcoin node interface (validate-address) and takes the output script back, so anything the node accepts works; the public protocol document's size table for the listing envelope uses P2WPKH (bc1q, 381 bytes) and P2TR (bc1p, 393 bytes) as its examples. The envelope format only requires a seller script of 1 to 80 bytes, and the indexer adds one check: the price must clear that script's dust line (330 sats for P2TR; 294 for any v0 script, bc1q and P2WSH alike; 546 for the rest); at the sale, payments are summed per script. As of 29 October 2026 (height 973,703) the site's state held 5,233 listings: 4,622 paying a bc1p, 311 a 3… P2SH and 300 a bc1q, none a P2WSH or a legacy 1… address, and all three kinds have sold. A typed address ties the listing to it just as the connected wallet does, and the site warns when one address serves several listings, since anyone can group them as one seller's; the "private address" is a fresh P2TR derived from the seed and this listing's nullifier, which only the vault can compute.

06　Proving｜Holding proofs, and what each one gives away

The site's vote (archived client) uses the spend circuit, not the holder circuit: eligible notes are picked at the round's snapshot height, held at the snapshot even if spent later; the proof's hbody binds "ordz-vote-v1", the collection, the topic, the round and the choice; the choice and the proof's public inputs go to the voting service, and those inputs include this note's nullifier. The site's script on 3 November still does this, and adds one tag: tag = Poseidon(nullifier, SHA-256("ordz-vote-tag-v1" ‖ topic ‖ round)), one per note per round. The service de-duplicates on it and lists every vote's tag, choice and time in a "public tag log". The vote page says the service "sees a one-time tag per Naka per round, never the piece or the vault", and at voting time that holds: before a note is spent, its nullifier matches nothing on chain. Public tags let anyone check the tally, with one trade-off: once a note is spent, its nullifier is in an envelope on chain, and computing the tag from it shows how that note voted; a listing's nullifier sits beside its piece number, so for those the piece is known too. Checked on 3 November against the site's ledger at height 974,323: of 1,463 votes in round 1's public log, 888 can be computed from nullifiers already public, 38 of them from listings with their numbers; in round 2, 82 of 774, 8 with numbers (counts only, no pieces recorded; script tools/vote_tag_check.mjs). The code that checks eligibility, de-duplicates and tallies runs on the voting service's server; its public records can be checked like this: round 2's public tag log has 774 votes, their count per choice matches the topic's totals and no tag repeats; the 82 votes that match a public nullifier were all spent after the snapshot block 973,899, so they were eligible; the other 692 have nullifiers still off chain and the proofs aren't published, so by design they can't be checked (script tools/vote_round_check.mjs, archive of 3 November).

The vote page is the Naka Council. It is choosing the next collection to launch, in brackets whose winners meet in a final. Every Naka held at the snapshot block is one vote, whoever holds it now; one bought after the snapshot votes in the next round. Naka votes can be against too, and one option is "none of these for now".

Since 2 November Snickets can vote too (appendix I07), against as well as for, and without a Naka. No proof is involved: the vault signs a request with its Snickets key, naming topic, round, choice, for or against, the number of votes and the price, which the platform quotes; the page puts one vote at "what a base Naka earns in a week, live", and Snickets spent on votes are gone for good. Snickets votes have a public log too, with votes, direction and price but no key; Snickets are kept on the platform's books by key, so one vault's burns, spots and votes sit in one account.

A reward claim (the archived client's buildReward) also uses the spend circuit, with the week's eligibility root and the original note as inputs, and the reward envelope it builds (type REWARD) goes into a Bitcoin transaction: the original note's nullifier, a new commitment, a proof and the ciphertext of the pouch. It spends the original note, gives you a new NAKA note and adds a reward note; the indexer adds the new NAKA note to the week's eligibility tree, which is why chapter 07 still counts the week. A batch claim (REWARD2) takes up to 200 at once, and the new notes it gives back carry no ciphertext of their own, each derived from the previous note. Bonus claims (BONUS, BONUS2) write the number in the clear and use a signature, not a proof. A nullifier that has claimed can't claim again; after a sale you can still claim, late, the weeks held in full before it.

The public code's Holder circuit: public inputs are the root, an event id context and the mark ctxNf = Poseidon(s, context, 13); the circuit only checks that the leaf is in the tree and computes ctxNf, and never looks at the nullifier. The tree only grows, so a sold note can still prove, as appendix E says. The protocol document's "accept only the last 6 blocks' roots" limits how old a root may be; old leaves stay inside new roots, so it doesn't replace a check that the note is unspent. De-duplication holds within one context; with another purpose or claimant the same note proves again. v1 published the nullifier, so the note could be recognised the day it was listed; v2 keeps it private, an improvement; this "v2" is the circuit's second version, unrelated to rules v2 in a parent inscription.

What each use hands over, side by side:

07　Mining｜Holding a NAKA mines SHNAKAS; why a transfer breaks the week

Week w is blocks S_w + 1 to S_w + 1,008, starting from S_1 = 971,700, 1,008 blocks a week. A note counts for a week when the block that created it is no later than the week's start and the block that spent it is later than the week's end, or it hasn't been spent.

A transfer, or a send to yourself, spends the old note and creates a new one; a listing spends the old note, and the cancel (CLAIM) creates the new one. Either way the old note doesn't last to the end of the week and the new one didn't exist at its start, so the week counts for neither. The new note from a normal reward claim is the exception: the indexer adds it to that week's eligibility tree (the week's carry in the site's state), so the week still counts. A bonus envelope only signs and issues a pouch; it spends no note and creates none.

The weight rules are in the on-chain SHNAKAS rules inscription: a base of 100%; a trait whose floor reaches 1.25, 1.5, 2 or 3 times the collection floor adds 25%, 50%, 75% or 100%; numbers 0–9, 10–99 and 100–999 add 200%, 100% or 50%, the highest only; a cap of 400%. Floors count only listings of 546 sats or more with one of five payout script types. A trait with no listing adds 100% if it has at least 20 pieces, and is rated from its sales record if it has fewer (62 and 106 traits in the 27 October snapshot). Every input is a listing or a sale in the ledger, so any indexer can compute the same weights block by block; the weight table the site hands its client only saves each one the work. On 27 October the project said the other collections move to instant listings and Nakas stay as they are, so NAKA's listings stay on chain and anyone can still run these numbers (NAKA's off-chain listings were still switched off in the site's config on 3 November). The "Shielded #" on the site's market and Staking pages is a global number that starts at 0 with NAKA, so it equals the piece number, and "Shielded numbers under 1K, 100 and 10" is this number bonus.

Each week's 266,640 is shared by weight across all 3,333 numbers. Shares for the weeks a piece is listed or unminted go unclaimed; full weeks held before a listing can still be claimed. A base claim needs no number, only proof that you held a note for the whole week in the eligibility tree. A bonus claim shows the number and the holding. In the site's vault the page is called Staking: nothing to lock or sign, and a piece received or bought counts from the following week. One claim settles every week so far, so the fee is per claim, not per week, and no relay credit is used. The confirmation for showing a piece spells it out: the number goes on chain for good, so anyone sees that this piece claimed and how much; those SHNAKAS stay linked to the piece, even after you sell them; it shows the piece wasn't listed, sold or sent from the first claimed week; the wallet paying the fee is on the transaction, and if you minted or bought the piece with your main wallet and haven't sent it privately since, these claims can be linked to that wallet; showing several pieces close together hints they share a holder.

Rewards are pouches in the SHORD ledger, not runes sent to your wallet. How pouches come about, why an unclaimable share isn't a burn, and how the totals add up are on the How mining works page.

Claimed SHNAKAS sit in the vault as pouches; a pouch's number and size are public, its holder isn't. A pouch can be sent whole, or split into 2 to 16 smaller ones, paid with your own bitcoin. The protocol lets a split write some of the new pouches straight to others, but the vault's Split keeps them all for you, and giving one away takes a second send; only burning into Snickets and depositing into Naka Lounge do it in one step. The project says the pouch market opens on 6 November: list, buy, and sweep up to 10 at once. A pouch can also be burned into Snickets, one for one, arriving two blocks later, for GTD spots in new collections and for votes (appendix I06). Burned SHNAKAS can't be spent by anyone, and Snickets are kept on the platform's books, not on chain.

By the site's text and SHNAKAS config on 3 November, splitting, sending and burning pouches are open to everyone, while listing and buying go first to a few testers with an access code, opening fully on 6 November. Pouches list instantly (listings3 is on): nothing is on chain until a sale, and price changes and cancels are immediate; a vault's first listing makes one 330-sat listing coin from its BTC. Buyers compare the price per token and get the whole pouch; the platform fee is 2%, at least 330 sats. A burn takes whole tokens from one pouch, with the fee paid from the vault's BTC, not relayed. A GTD spot is one spot, one code, one mint: the code looks like GTD-XXXX-XXXX-XXXX-XXXX, works from any wallet, and anyone holding it can use it. The confirmation says Snickets aren't returned if you don't mint, while the "My GTD codes" note says a code unused by the end of its phase gives its Snickets back; the two texts differ, so go by the site's word at the time.

Naka Lounge (play.ord-dropz.xyz) is the project's limited-time No-Limit Hold'em, with SHNAKAS as chips. The lounge is a vault of its own, apart from yours: deposited SHNAKAS go to its shielded address and it holds them (the page calls it the box), and it sends cash-outs back itself. Your vault connects as the player account: the lounge gets a player account worked out from the vault, plus the vault's shielded address and its BTC address; by the vault's own words cash-outs go only to that shielded address, and the lounge can't move anything in the vault. A deposit is a split: the amount comes off one pouch and goes to the lounge's shielded address, the same transaction paying a little of the vault's BTC to the lounge's fee address, including the fee for a later cash-out. The split is recognisable on chain: the pouch numbers and amounts are public, and the payment to the lounge was 3,330 sats in all 21 deposits up to 3 November, so it reads as a lounge deposit, though not whose. The page shows what the box holds against what it owes. The project says every card is locked in before the deal and checked on your device, and that the rake (5% of hands that see a flop, at most 2 big blinds) is saved and burned. While you play, the lounge holds those SHNAKAS, and a withdrawal sends them back to your shielded address.

Burning into Snickets sends the whole pouch privately to a burn address, or one of the pouches of a split: after shord1 comes SHA-256("Shielded Ordinals SNICKETS burn v1" ‖ 0 ‖ Snickets public key), first byte zeroed, as the owner key, then your own view key. A normal owner key is Poseidon(sk); this number comes from no one's sk, and spending it would take a Poseidon preimage, so a burned pouch can't be spent. The vault then signs a request to the platform with the envelope's hash and what opens the burned part (for a whole pouch its number, credits and s; for one pouch of a split, that pouch's ρ and s), and the Snickets arrive two blocks later; the platform checks and books them on its server. The Snickets key comes from the seed (SHA-256("shord/snickets" ‖ seed)) and signs balance checks, burns, GTD codes and votes; one vault always has the same one.

08　Verification｜Who keeps the ledger, and can you check it?

How a private send is checked (public code, indexer.mjs): first the root it anchors to must be from the last 100 blocks and older than this one, then its nullifier must be unseen, then the proof must verify. Only then are the nullifier recorded and the new commitment and ciphertext taken in; if any check fails the envelope is logged as refused and the ledger doesn't change. After each block the indexer saves that block's root and leaf count.

Digest v1 is a SHA-256 over a fixed summary of the state: the tree root, the leaf count, the sorted nullifiers, the minted numbers, and each listing's nullifier, state, number, credits and price. It leaves out ciphertexts, txids, payout scripts and lock positions, so a matching digest means only those parts match.

Checkpoints: now and then an indexer saves its whole state to a file with the hashes of its rules and verification key and the last 12 block hashes, then seals it. On loading it rebuilds the tree, checks every block's root and the digest, and uses the file only if those 12 blocks are still on the best chain. If anything fails, it falls back to an older file or replays from the start.

Reorgs: when blocks at the tip are replaced, the indexer goes back to the latest checkpoint still on the best chain, or replays from the start if there is none, and keeps serving the old state until it reaches the tip again.

What happens when rules differ? The public code rejects message types it doesn't know, so those notes never enter its tree. From that block on its roots differ from the official ones, and any later transfer or listing proof that cites a root from after the split fails for it. So compare rules versions before digests.

Checking the relay: until 29 October the official relay's address matched in three places. The parent inscription's relayerPayoutScript is 5120be2563233bb4feb149c3a6111f67a2ec5061991921d97406c78ca48614fefe43, which decodes to bc1phcjkxgemknltzjwr5cg37eaza3gxrxgey8vhgpk83jjgv987leps3t3cuy; the site's status interface gives the same relayer.address; and every transaction that address sends has one shape: its own change as input, one OP_RETURN starting with SHORD (PUSHDATA2, two to four hundred-odd bytes), a 330 sats lock paid to a fresh address when it is a listing, and the rest back to itself as change. On 29 October 2026 it had 5,517 transactions and a balance of about 0.018 BTC; the 1.27 BTC it has received includes its own change, so it isn't net income. That day (blocks 973,769 to 973,777) it moved its whole balance, in a few transactions, to bc1pr5vsx…5hcp73 (first fe200a20…, last 83409f79…), and has held nothing and sent nothing since; the status interface's relayer.address became the new wallet, whose transactions keep the old shape: its own coin in, one OP_RETURN starting with SHORD, a 330 sats lock for a listing. The payout script in the rules is in the parent inscription, can't change, and is still the old address.

J　Shielded names

A shielded name points a memorable name, ending in .naka or .shield, at a shielded address (shord1…). Type bob.naka when sending, and the wallet looks up the address and writes the note to it as usual. The protocol doesn't require the wallet to show you that address; to check it yourself, use the lookups in the table below. The envelope still carries what the address gives; no name appears on chain. Names are metadata outside the protocol: indexers never look at them when accepting a transfer or a listing. What follows rests on src/v1/names.mjs in the public code at 3cdbdfdf, docs/API.md and the site's interface.

K　Common questions

The questions asked most in discussions and in the community, by topic. Each answer gives the conclusion first; the chapter or appendix in brackets has the detail.

Pieces and the vault

Privacy

Trading and listings

How to get these details: the site shows no s, and none of the API routes its pages use signs for a user or exports a proof. The way that works goes through the vault's seed: the site's engine (the script the vault page itself downloads, open to anyone) has the functions that turn a seed into every key and open, one by one, the notes the public ledger holds for you. On their own computer the seller takes the vault's 24 recovery words to get the keys, loads the site's public ledger (/state for NAKA, /rewards/rune/state for SHNAKAS) and scans their notes, spent ones included; the old note whose nullifier equals the one in that transfer's envelope gives the number, the credits and s to hand over, the credits adjusted by what the transfer spent and bought. The escrow recomputes the new commitment with the Poseidon of the public repository, with none of the seller's keys.

This step uses the 24 recovery words, so take great care: the words are the whole vault: leak them once and the pieces and the vault's BTC can be taken, and they can't be changed, only replaced by a new vault and moving everything over one by one. If it has to be done: only on a computer you control, offline if you can; never type the words into a web page, a form, a chat or a tool someone else gave you; let no one, escrow included, do it for you, and hand over only these details. The web vault's unlock signature is the same: any web page can ask your wallet to sign that unlock message, and signing it hands over the vault, so sign it nowhere but the official site. Without full confidence, route through the escrow as below, or rely on the new note appearing in the buyer's vault.

Three things to know. First, these details don't cover whether the ciphertext is right: the circuit doesn't check it, and the buyer's vault finds the note by opening it. The site's client always encrypts correctly; against a deliberately broken one, these details give the buyer all the data needed to spend the note, but the site's vault only lists notes whose ciphertext opens and the archived pages have no import, so it would take a tool of one's own. Second, a SHNAKAS pouch sent straight to the other side in a split leaves the seller's engine without that pouch's ρ and s, so the details can't be given afterwards; with an escrow, split to yourself to the agreed amount first, then send that whole pouch privately. Third, once s is handed over, the escrow can follow the piece as the seller can, until s is renewed (previous question). The other way is to route through the escrow: the seller sends to the escrow's shielded address, the escrow sees it in their own vault and passes it on once paid; one more send, and the escrow knows s just the same. No zero-knowledge proof that keeps s back exists today; it would need a new circuit. The site's "prove" button proves you hold some piece of the collection, not which, and doesn't check it's unspent, so it doesn't help here. Wait a few confirmations before releasing the money, in case of a reorg (appendix I04).

The relay

Mining and weights

Shielded names

Security limits

Decentralisation and checking

Terms