zmr is a token on solana whose creator fees never come back to the creator. every fee earned is routed out of solana into one of two privacy coins, and which coin depends only on the direction of the trade that earned it. a buy earns a fee that becomes zcash. a sell earns a fee that becomes monero. the zcash is held. the monero is given away. that is the entire design, and every number on this site is a readout of it happening.
there is no schedule. nothing runs on a timer, an epoch, a snapshot hour or a day boundary. the mechanism reacts to trades and to fee balances, and to nothing else. if nobody trades, nothing moves.
pump.fun pays a creator fee on every swap of the token to a fee recipient. for zmr that recipient is the fee vault, a program owned account that no person can sign for. the program records, per swap, whether the swap was a buy or a sell and how much fee arrived with it. those two running totals are the only state the split needs.
the buy total is the amount of sol waiting to become zcash. the sell total is the amount of sol waiting to become monero. they are never mixed. a large buy volume with no sells grows the zcash side and leaves the monero side at zero. a sell with no buys does the opposite.
a sweep converts the buy side total into zcash. it fires when the buy side total in the fee vault crosses the sweep threshold, a value set in the program config account and readable on the program page. the keeper, which is the only signer the program accepts for this instruction, claims the buy side amount from the vault, submits it to near intents as a swap from sol into native zec with the reserve transparent address as the destination, and writes the resulting intent hash back into the program. when the zec arrives at the reserve address the sweep is complete. the reserve address, its balance and every inbound transaction are visible on any zcash explorer, and the reserve page reads them live.
the reserve is never spent by the mechanism. it only receives. the point of holding it in a transparent address is that the size of the backing behind the token is a public fact, not a claim.
a release converts the sell side total into monero and hands it out. it fires on a sell, not on a clock. when a sell lands whose fee pushes the sell side total across the release threshold, that sell is the trigger. the keeper claims the sell side amount, submits it to near intents as a swap from sol into native xmr, and when the xmr arrives it is split across every eligible holder and sent to the monero subaddress each of them registered. the trigger signature, the size of the triggering sell, the sol swept, the intent hash, the xmr delivered and the number of recipients are written to the release record and shown on the releases page.
the seller who triggers the release is not a recipient. eligibility is measured after the sell has settled, so the seller's remaining balance, if any, is what counts, and a wallet that sold everything holds nothing and gets nothing.
each release is split pro rata by balance among eligible holders. eligible means the wallet holds at least the minimum holding written in the program config, and the wallet has a valid registration. the formula for a holder's share of a release is:
balances are read from the token accounts at the slot in which the triggering sell was confirmed. the reading is part of the release, not a separate scheduled snapshot. a wallet that bought in the same slot as the trigger and is above the minimum is included.
the site has no form. a holder registers a monero subaddress by sending a transaction from the holding wallet, using any wallet app, that contains one memo program instruction with this exact text:
where <subaddress> is a monero subaddress, which begins with the character 8 and is 95 characters long. the transaction can otherwise be anything, a zero lamport transfer to yourself is enough. the keeper indexes memo instructions from every wallet that holds the token, validates the subaddress format, and stores only a hash of the subaddress alongside the wallet. the subaddress itself is never written to solana and never stored on this site. a later memo from the same wallet replaces the earlier one.
a wallet without a valid registration is not eligible and its balance is excluded from the denominator. its share goes to everyone who did register.
monero subaddresses are unlinkable on chain. two payments to two subaddresses cannot be shown to belong to the same wallet, and cannot be shown to come from the same source. a holder who receives a release can prove to themselves that they were paid, using the transaction proof the keeper publishes for each release and their own view key, and nobody else can see that they were paid, how much, or that the payment was connected to this token.
zcash has transparent addresses, and a transparent address is a public balance. the reserve is meant to be seen. anyone can open the address on an explorer and check that the sol swept on the reserve page turned into the zec the reserve holds. if the program config also carries a viewing key, the reserve page shows it, and it lets anyone audit inbound shielded transfers to the reserve as well.
sol cannot be turned into zec or xmr on solana. there is no bridge to either chain and no wrapped version worth holding. near intents is a settlement layer where a swap is posted as an intent and independent solvers compete to fill it, delivering native coins on the destination chain from their own inventory while the near side holds the sol in escrow until the fill is proven. the keeper uses it as an api: request a quote, deposit the sol, receive an intent hash, and the destination address receives the coin. every intent hash is published on this site so the path from a solana fee to a zcash or monero balance can be followed end to end.
the program keeps one state byte that describes which side is currently leading. it is written by the program on every fee event and shown on the reserve page.
| state | condition | meaning |
|---|---|---|
| accretive | total swept to zcash exceeds total swept to monero by more than ten percent | buy fees are outpacing sell fees. the reserve is growing faster than releases are paying out. |
| distributive | total swept to monero exceeds total swept to zcash by more than ten percent | sell fees are outpacing buy fees. holders are being paid faster than the reserve is growing. |
| balanced | neither side leads by more than ten percent | order flow is roughly symmetric. |
the site does not hold keys, does not submit intents, does not take input, and cannot be used to trade. it reads three sources: birdeye for market data on the token, the solana rpc for the program config account, and a zcash explorer for the reserve address. it reads three tables written by the keeper: sweeps, releases and registrations. it computes nothing that is not derivable from those sources, and where a source has not returned a value the slot for that value is empty.
every parameter below is read live from the program config account. none of them are constants in the site.
| parameter | value | unit |
|---|---|---|
| sweep threshold | sol | |
| release threshold | sol | |
| minimum holding | tokens | |
| total swept to zcash | sol | |
| total swept to monero | sol | |
| sweep count | sweeps | |
| release count | releases |
everything above can be checked without trusting this page. the program page lists the program id, the config account, the fee vault and the keeper signer with explorer links. the reserve page links the zcash reserve address. the releases page links every trigger signature and every transaction proof. the mechanism is only as real as those links, which is why they are the last thing on every page.