ZIRON

$ZIRON Launchpad for private assets. Coins launch on Solana; each burn settles to a shielded Ironwood note on Zcash. Verifiable supply, unobservable balances.

[ZIRON @ZIRON_CASH]

$ZIRON // https://t.co/E9TewqoFCz

B8WvjPmz1wJ9xPRKEkyWHFzPZoaqkKWCytgtFjhTpump

A launchpad for assets that settle privately.

Coins launch on Solana, where the market is. Each burn settles to a shielded note on Zcash's Ironwood pool, where amounts, senders and recipients are hidden by zero-knowledge proofs rather than by mixing. There is no anonymity set to degrade and no coordinator to compromise.

The architecture

A ZIRON is an Ironwood note carrying an encrypted memo that records what the note represents.

This matters more than it sounds. Native custom assets on Zcash require ZIP 227, which is not live and has no activation height. Every design that waits for it ships public receipts in the meantime and promises privacy later. ZIRON does not depend on it, because the capability needed was already shipped: Zcash moves private notes, and a note can carry a sealed memo. The asset layer lives in that memo, and the accounting lives on the public rails of two chains.

The result is an inversion of the normal arrangement. Total supply is exactly verifiable by anyone, recomputed from public Solana and Zcash data with no permission and no trust in the operator. Individual balances are not observable, including by us. The information is not withheld, it does not exist in readable form.

Binding, and why it is the hard part

A Solana burn is public. Citing one therefore proves nothing about having made it, and a claim can be made once. Without a binding, any observer can watch for a burn and claim it first, permanently, and the rightful burner has no recourse.

ZIRON solves this in the burn itself. The transaction names its recipient before it is signed, on Solana, immutably. Only that recipient can ever claim it. This is checked by every indexer independently, needs no signature scheme beyond what Solana already provides, and is enforced by the ledger rather than by a service.

The consequence is that the protocol has no privileged key. Nothing issues on your behalf, so nothing can decline to. We operate a relay that publishes claims for users who hold no ZEC, and that relay is structurally incapable of redirecting a claim: the destination is fixed in a transaction signed before the relay is involved. It can refuse to publish. It cannot take. When it refuses, the interface hands the user the exact bytes to publish themselves.

Sixteen rules define validity. Each is tested. None require trusting the operator.

[ZIRON @ZIRON_CASH]

Well over two billion dollars has been stolen from bridges, and every one of them worked exactly as designed right up until the day it didn't.

A bridge is a vault with a promise attached. Your tokens sit locked in a contract on one chain while a copy of them circulates on another, and the whole arrangement depends on that vault never being emptied by anyone but you. Multisigs, validator sets, oracles, guardians. Different words for the same thing, which is a small group of keys standing between a pile of money and everyone who wants it.

solana:B8WvjPmz1wJ9xPRKEkyWHFzPZoaqkKWCytgtFjhTpump has no vault, because there is nothing to put in one.

Moving to the private side means burning on Solana. The tokens are destroyed, not deposited. That burn is written to Solana and cannot be undone, and the claim it authorizes is published on Zcash as a permanent record. There is no contract holding a reserve, no pool of locked collateral, no wrapped supply that can wake up unbacked one morning. The two ledgers are the state. If you wanted to drain ZIRON you would first have to find something it holds, and it holds nothing.

This is also why we cannot freeze anything, reverse anything, or quietly take a cut in the middle. Not as a matter of principle. There is simply no place in the design where a hand could be inserted.

Most of what gets called a bridge is custody with better marketing. We would rather have nothing to guard.

[ZIRON @ZIRON_CASH]

Most private tokens aren't really private, and the difficult part was never the hiding.

Concealing a balance has been a solved problem for years. What nobody has managed is concealing balances while still proving how many of the thing exist. The moment holders are shielded, total supply stops being something you can check for yourself and turns into something you're told. Almost every private token that has shipped deals with this by putting an issuer in the middle, so you end up private from everyone except the one party in a position to actually rug you.

solana:B8WvjPmz1wJ9xPRKEkyWHFzPZoaqkKWCytgtFjhTpump is built to sidestep that rather than patch it afterwards.

Coins are issued on Solana, where supply is a number anyone can add up. Holding happens on Zcash, where a balance is nobody's business. Getting from one side to the other is a burn. You destroy the tokens on Solana and that destruction is what entitles you to claim on the Zcash side. Nothing is ever minted on the private side, so the public supply figure can only fall, and you can confirm it yourself without needing anything from us.

The burn memo specifies which Zcash address is permitted to claim, and it is fixed before the transaction is signed. There is no stage at which the credit could be pointed somewhere else, by an operator or by us.

An asset's ID is also a hash of the Zcash transaction that created it, rather than a row in a table we maintain. Tables can be quietly edited.

The tradeoff everyone assumes between privacy and auditability mostly disappears once you stop making both of them happen on the same chain.

[ZIRON @ZIRON_CASH]

$ZIRON // https://t.co/E9TewqoFCz

B8WvjPmz1wJ9xPRKEkyWHFzPZoaqkKWCytgtFjhTpump

A launchpad for assets that settle privately.

Coins launch on Solana, where the market is. Each burn settles to a shielded note on Zcash's Ironwood pool, where amounts, senders and recipients are hidden by zero-knowledge proofs rather than by mixing. There is no anonymity set to degrade and no coordinator to compromise.

The architecture

A ZIRON is an Ironwood note carrying an encrypted memo that records what the note represents.

This matters more than it sounds. Native custom assets on Zcash require ZIP 227, which is not live and has no activation height. Every design that waits for it ships public receipts in the meantime and promises privacy later. ZIRON does not depend on it, because the capability needed was already shipped: Zcash moves private notes, and a note can carry a sealed memo. The asset layer lives in that memo, and the accounting lives on the public rails of two chains.

The result is an inversion of the normal arrangement. Total supply is exactly verifiable by anyone, recomputed from public Solana and Zcash data with no permission and no trust in the operator. Individual balances are not observable, including by us. The information is not withheld, it does not exist in readable form.

Binding, and why it is the hard part

A Solana burn is public. Citing one therefore proves nothing about having made it, and a claim can be made once. Without a binding, any observer can watch for a burn and claim it first, permanently, and the rightful burner has no recourse.

ZIRON solves this in the burn itself. The transaction names its recipient before it is signed, on Solana, immutably. Only that recipient can ever claim it. This is checked by every indexer independently, needs no signature scheme beyond what Solana already provides, and is enforced by the ledger rather than by a service.

The consequence is that the protocol has no privileged key. Nothing issues on your behalf, so nothing can decline to. We operate a relay that publishes claims for users who hold no ZEC, and that relay is structurally incapable of redirecting a claim: the destination is fixed in a transaction signed before the relay is involved. It can refuse to publish. It cannot take. When it refuses, the interface hands the user the exact bytes to publish themselves.

Sixteen rules define validity. Each is tested. None require trusting the operator.

[ZIRON @ZIRON_CASH]

A walkthrough of the protocol, end to end.

A coin is created on Solana. The first difference is what it's priced in: 169 assets, and we don't maintain that list. It's read from the QuoteControl account on chain at load, so it's whatever the program says it is. This one settles against ZEC // @Zcash

Your wallet signs. We hold no key and no balance.

At launch, 53 bytes go into an OP_RETURN on Zcash version, record type, the Solana mint, the ticker, decimals, ratio. One transaction, ZIP-317 minimum fee, permanent.

Then the part worth slowing down for: the asset's ID is a tagged hash of that Zcash transaction. Not a pointer to it. Not a field containing it. The identity of the asset is derived from the record of the asset, which means you cannot forge one without forging the other. There is nothing to keep honest — it's the same object twice.

To hold it privately you burn it on Solana. The memo names the Zcash address permitted to claim the credit, and it is fixed before the transaction is signed. Not after. Not by us.

Then you publish the claim. 50 bytes, on Zcash, after ten confirmations.

Every figure on a coin's page is computed from public data on two chains. If our server is wrong, the chains are still right.

Public issuance. Private ownership.

[ZIRON @ZIRON_CASH]

No key we hold can move a token that is not ours. Your wallet signs the burn and your wallet signs the launch. The one key we do control spends the relay's own coin, and its entire capability is to put a record on Zcash or decline to.

There is no pooled balance here and no account to drain.

https://t.co/E9Tewqpds7

[ZIRON @ZIRON_CASH]

All three are correct.

What we do is narrower and checkable. A coin is created on Solana. Its definition is written into one OP_RETURN in an ordinary transparent Zcash transaction, 53 bytes naming the mint, the ticker, the decimals and the issuance rate. The asset_id is the tagged hash of that transaction, so the record and the identity are the same object.

One from this morning, block 3,490,667, fee 15,000 zat, which is the ZIP-317 minimum for that shape:

170e33d21233299c2ecc561a4eeaa3c213df2c40f730d642ad33b40b9008da6c

vout 0 is nulldata. Decode it and you get opcode 1, GENESIS, the Solana mint AccTYcVcyeFoEqiXczX2bGcASyvUMUjfoBBmnzLiRx2f, ticker ZURG, six decimals, rate 1:1.

Our protocol works and it's transparent.

[Zcash 🛡️ @Zcash]

A few quick facts:

1. ZRC-20 is not a Zcash protocol standard.

2. Zcash Shielded Assets are still experimental on Testnet.

3. If you want censorship-resistant private money secured by Zcash consensus the asset is zcash:native

DYOR and stay safe 🛡️

[ZIRON @ZIRON_CASH]

Wallets moving value between Zcash's shielded pools do not send arbitrary amounts. ZIP 318 has them draw from a fixed ladder of denominations, so that one migration is indistinguishable from every other migration happening that day.

Amount is metadata. Any system that lets you choose a number is publishing one.

https://t.co/E9TewqoFCz

[ZIRON @ZIRON_CASH]

We compute Ironwood note commitments, nullifiers and incoming viewing keys directly, against the pool as it exists on mainnet today rather than against a testnet approximation.

Knowing how a note is constructed is not the same as being able to spend one, and the difference between those two is most of the engineering.

https://t.co/E9Tewqpds7

[ZIRON @ZIRON_CASH]

A claim cites a burn_ref, and a burn_ref is a hash. Hashes do not run backwards.

So resolving one means indexing that mint's entire burn history on Solana and looking the reference up. There is no shortcut and skipping it does not produce a smaller ledger. It produces one where every claim is refused and issued supply is permanently zero.

https://t.co/E9Tewqpds7

[ZIRON @ZIRON_CASH]

A burn that no claim ever cites does not appear in our ledger at all. The registry counts destruction only where a claim points at it, because what it measures is issuance.

Tokens can leave Solana here without anything arriving anywhere. That is a choice the holder makes, and it stays theirs.

https://t.co/E9TewqoFCz

[ZIRON @ZIRON_CASH]

Pricing a market in tokenised Apple does not move Apple. The quote asset is the denomination a curve is priced in, not cargo that travels anywhere.

What changes hands is the coin. What lands on Zcash is the record defining it, and the claim any holder can make against that record.

https://t.co/E9TewqoFCz

[ZIRON @ZIRON_CASH]

NU7 is consensus branch 0x77190AD8. It shortens Zcash block spacing to 25 seconds and stops nodes accepting version 4 transactions.

It contains no new transaction formats, which means shielded assets are not in this upgrade. Worth knowing before anyone plans around them.

https://t.co/E9TewqoFCz

[ZIRON @ZIRON_CASH]

An asset definition here is 53 bytes. The Solana mint it points at, its decimals, its issuance rate, its flags and its ticker, in one OP_RETURN, permanent.

https://t.co/vCNtVcqdvd

[ZIRON @ZIRON_CASH]

We sign Zcash transactions in JavaScript. No zcashd, no Rust, no wasm, running in a browser tab.

How we check it is the part worth describing. We take a real transaction off mainnet, rebuild it from our own code byte for byte, recompute its txid, and verify the signature that is already on chain against our own implementation. Any disagreement anywhere and the test fails.

The one we pin against is fbbea305cc67a8a172304741e22fb923cbd275178775dd94c5449353e5e0f0bc, at block 3,490,609.

https://t.co/E9TewqoFCz

[ZIRON @ZIRON_CASH]

Something about Ironwood most people have not noticed. From transaction version 6, shielded anchors are authorizing data rather than effecting data, so signatures no longer commit to them.

A transaction can be fully signed before anyone knows which block it will be anchored to.

https://t.co/E9Tewqpds7

[ZIRON @ZIRON_CASH]

Our figures ignore a registration until it is ten blocks deep, roughly a quarter of an hour. The record is permanently on chain that entire time. We would rather publish a number late than publish one a reorganisation could quietly revise.

https://t.co/vCNtVcqLkL

[ZIRON @ZIRON_CASH]

A burn names the Zcash address permitted to claim it, in the memo, before it is signed. The relay can publish that record or decline to. It has no way to write a different recipient into a transaction that was already signed before it arrived.

https://t.co/vCNtVcqdvd

[ZIRON @ZIRON_CASH]

The relay pays the Zcash fee so launching costs no ZEC, and it has no wallet in the usual sense. It holds exactly one unspent output at a time, and the change from each registration becomes the input to the next.

Which makes it auditable by arithmetic. One registration left 2,132,800 zat and the next left 2,117,800. The difference is a single ZIP-317 minimum fee, and the whole sequence sits on chain for anyone who wants to walk it.

https://t.co/E9Tewqpds7

[ZIRON @ZIRON_CASH]

The asset_id of a coin here is the tagged hash of the Zcash transaction that registers it. The identity and the record are the same object.

https://t.co/vCNtVcqdvd

[ZIRON @ZIRON_CASH]

Coins launched on https://t.co/E9TewqoFCz can now be priced in something other than SOL.

There are 100+ quote assets available, including tokenised $Apple, $Tesla, $NVIDIA, $Amazon, $Broadcom, $Coinbase etc, alongside $Bitcoin, solana:moJA7YR7ZfCsfAnjQwR94zjmn886ik9KchMjBnrpump and $Zcash itself.

What this makes possible is narrower and more interesting than it first sounds. A market can be denominated in a tokenised equity while its issuance record lives in a Zcash block and its holders settle into the shielded pool when they burn. The price reference is a stock. The settlement asset is Zcash.

The instruction is assembled by us rather than requested from a hosted builder, because the hosted one accepts a quote asset and silently ignores it, returning an ordinary SOL launch with no error.

Every account is derived and pinned against real transactions, and each launch is simulated against the chain before a wallet is asked to sign it.