Burn
You destroy your tokens on Solana. Public, permanent, and anyone can add up every burn ever made. This is the only thing about your position that stays visible.
SHIELDED ASSETS ON ZCASHVOL. 001 / IRONWOOD
$ZIRON
Burn publicly.
Hold privately.
From a burn on Solana to a shielded note on Zcash.
The burn is public. Your next move is not.
$ZIRON / 001SHIELDED NOTE
PUBLIC RAIL
Claim explorer
SIMULATED CHAINS / REAL VERIFIER
Loading $ZIRON protocol...
01 Burn feedsolana
slotsignatureamountclaim
02 Public recordszcash
heightopissuedrecordverdict
03 Public issuance
claimed burnsunclaimed burns
- burned on Solana
- --
- burns matched to claims
- --
- total ever issued
- --
- unclaimed burn units
- --
- accepted claims
- --
- genesis rate
- --
issued = sum(floor(burn × rate))CHECKINGclaim root
Merkle over accepted claims
Balances and circulating supply are not observable from this ledger.
01
What this is
Every Solana wallet is a public page. Anyone with your address can see what you hold, what you paid, and watch you sell in real time. $ZIRON is the door out of that, and it is open to any token.
Claim
You publish one 62-byte record on Zcash and mint yourself a shielded note worth the same amount. You do this yourself. There is no minter to trust, nobody who can redirect it and nobody who can refuse you.
Hold
Your balance now lives inside Zcash’s shielded pool. Not obscured, not mixed — cryptographically invisible. Sending it is spending it, which Zcash permits exactly once.
Prove
Your note carries the previous owner’s viewing key, which opens exactly one already-spent note. A buyer walks that chain back to the original burn themselves. No server, no index, no trust.
The split that makes it work
Public: that a burn happened, for how much, and the total ever issued. Anyone can compute supply exactly, from two public chains, without permission. Private: who holds what, every amount in circulation, and every whole transfer — which publishes nothing at all. Supply is auditable. Ownership is not. That combination is the product.
02
Why this is not another inscription
Other attempts write the asset onto Zcash’s transparent chain and have an indexer decide, by convention, which of two conflicting records counts. That is a database pretending to be a chain — on the one chain whose entire purpose is that nobody can read it. $ZIRON puts the asset inside the shielded pool.
| Inscription-as-NFT | $ZIRON | |
|---|---|---|
| Where the asset lives | A transparent inscription, in public | A shielded Ironwood note |
| Double-spend | Indexer convention, first seen wins | The nullifier set — consensus, not convention |
| Transfers | Undefined; the record sits where it landed | Spend the note; a whole transfer leaves no public trace |
| Amounts | Public | Inside an encrypted memo |
| Supply | Trust the indexer | Computable exactly by anyone, from two public chains |
| Who verifies | A server you have to believe | You do, over your own history, in time proportional to your own hops |
| Issuance | A minter key | Destruction. There is no issuer key in the design |
| Who can launch | Whoever runs it | Anyone, for any Solana mint, without asking |
The structural bet
Since NU6.3 (July 2026) new shielded value on Zcash lives in the Ironwood pool. Each of its actions carries exactly one spend and one output, and a created note’s rho is the nullifier of the note spent beside it.
So the note that replaced this note is fixed by the circuit. Not by an indexer, not by first-seen, not by anyone’s convention. That single property is what lets an asset live in the shielded pool at all.
A launchpad, not a token
Registration is permissionless: publish one record naming any Solana mint, fix an issuance rate, and that token has a private form. No gate, no allowlist, no approval.
Two people may register the same mint. They become different assets with separate supplies, and inflating one never touches the other. The earliest registration is canonical for discovery, so register before you announce.
Fifteen numbered rules
Every rejection cites one. A protocol whose failure modes are unnamed is one whose failure modes are unaudited — when two verifiers disagree, the argument has to be about a number.
The attack lab below runs six of them against a live ledger and shows the public verdict and the buyer’s verdict separately, because they check different things.
03
your note. your proof.
Private rail / demo viewing keys. A holder verifies their own lineage, back to the burn.
DECRYPTED DEMO CARRIER
--
note commitment...
Fixture keys only. No connected wallet. These amounts are not part of the public explorer.
04
the mechanism
Public destruction. Private possession. Two rails, one provenance.
- 01
genesis
A 49-byte record — up to 57 with a ticker — binds an asset to one Solana mint. Its issuance rate is fixed at genesis.
zcash / public - 02
burn
Destroy tokens on Solana. A 16-byte tagged hash of the signature identifies the burn. No Zcash recipient address is required on Solana.
solana / public - 03
claim
One 62-byte
zcash / publicCLAIMnames the asset, burn reference and shielded carrier commitment in the same transaction. One burn can be claimed once. - 04
send
Spend the carrier. Its same-action successor carries the provenance in a 512-byte encrypted memo. A whole transfer publishes no $ZIRON record.
ironwood / private - 05
verify
Walk spent viewing keys back to the burn. Check nullifiers, successor pairing and conservation. Splits of up to eight notes require a 38-byte plan commitment.
holder / client-side
no escrow
Issuance is backed by destruction, not tokens held by a custodian.
no minter
The burner creates their own claim and carrier. No issuer signature overrides a rule.
one successor
The note's rho binds the primary successor to the nullifier spent in the same action.
one split plan
The public PASS commitment prevents different recipients being shown conflicting divisions.
05
anatomy of a record
Four public opcodes. No record for a whole transfer.
PUBLIC RAIL / V1
fieldoffsetbytesvalue
06
the rule is the product
Fifteen rules, shared by the protocol and this page. Every refusal names its reason.
07
attack the protocol
A hostile burner or sender. Two independent verdicts: the public claim ledger, and the buyer who verifies.
Isolated simulation / standing by
public ledger--
holder verifier--
scenario issuance--
A public ledger cannot inspect an encrypted amount. It counts the burn's entitlement; the holder rejects an inflated memo. These scenarios run on isolated simulated chains and never broadcast.
08
the specification
$ZIRON//1 / shielded carrier notes / public claim ledger
public rail
0x01 | GENESIS | 49–57 B / mint and issuance rate |
0x02 | CLAIM | 62 B / burn and carrier commitment |
0x03 | CHECKPOINT | 46 B / claim count and root |
0x04 | PASS | 38 B / split-plan commitment |
One OP_RETURN output per transaction. Up to 80 bytes of pushed data in an 83-byte script.
issuance, not balances
issued = sum(floor(burn × rate))- One accepted claim per burn reference.
- Nullifiers bind spends; action pairing binds the primary successor.
- Split plans conserve the predecessor's amount.
- Public records require 10 Zcash confirmations and finalized Solana burns.
The claim root commits to issuance. It is not a list of live holders, balances, or destroyed carriers.
the privacy boundary
Public: burns, claims, total issued, and split commitments.
Private: who holds what, amounts in circulation, and whole transfers.
The cost: a recipient learns spent one-time viewing keys along their own lineage. Other lineages stay outside that proof.
the private rail
A carrier memo holds the asset ID, amount, predecessor transaction and 96-byte spent viewing key, plus the output plan.
65 bytes for a root carrier with one output. 193 bytes for a whole transfer. 473 bytes for eight outputs, padded to a 512-byte memo.
A whole transfer has no $ZIRON public marker. A split must commit to one plan through PASS.
Status, stated plainly
What this page runs: the shared protocol codec, claim indexer, rule table and lineage verifier — against two simulated chains, with the Ironwood cryptography replaced by the simulation adapter. Everything you click here is a protocol simulator, not a wallet, and nothing it does touches a network. That is what the SIM badge means.
What the repository contains, beyond this page: the Ironwood cryptography for real, as
orchard 0.15.5 driven through a Rust sidecar. A complete transfer builds, proves
against the NU6.3 circuit, signs and verifies in about 731 ms, and a full v6 transaction
carrying both rails assembles to 9,239 bytes with two Ironwood actions and one 62-byte
OP_RETURN. The Solana side reads live mainnet burns. Forty-five JavaScript tests and seven Rust
tests cover it, including a pinned set of vectors that make a wrong pool version fail loudly
rather than silently. The browser cannot reach any of this; it is a native binary.
Live on Solana: the pad launches a real coin on pump.fun. You connect a wallet, it builds the mint here, pump.fun builds the transaction, and your wallet signs and pays for it. That is a real mainnet transaction spending real SOL, and nothing in this page ever holds a key.
Not yet, on Zcash: no $ZIRON record has been published to a real Zcash chain, so no asset is registered and the explorer lists nothing. That step needs a transaction carrying an OP_RETURN alongside a shielded output, and no browser-reachable Zcash wallet can sign one — it needs a companion tool, which is being built. Until then the pad gives you the exact record to publish rather than pretending the round trip is finished.