zmr is a token on solana with a single rule written into the program that owns its creator fees. every swap of the token on pump.fun pays a creator fee, and instead of that fee going to a person it goes to a vault the program controls. the program looks at one thing about each fee, the direction of the trade that produced it, and that one bit decides where the fee goes next. a fee from a buy is destined for zcash. a fee from a sell is destined for monero. the two paths never cross, never pool, and never come back to the creator. there is no team allocation, no treasury the founders can spend, no fee switch, and no upgrade key after initialization. the mechanism is the entire economic content of the token, and this page describes it from the fee arriving to the coin leaving.
the split is recorded at the moment the fee lands. the program keeps two counters for the mint, one for fees earned by buys and one for fees earned by sells, and a keeper process calls the program for each swap with the direction taken from the pump.fun trade event. the counter for that side grows by the fee amount. the counters are only ever read by two instructions, sweep and release, and each of those zeroes its own counter when it fires. because the direction is attributed per swap and not per block or per interval, the running totals are an exact record of order flow since launch. a token that has been bought far more than it has been sold will have a large buy counter and a small sell counter, and the shape of that imbalance is visible on the reserve page as the order flow signature.
when the buy counter crosses the sweep threshold, the keeper sweeps. a sweep takes the buy side amount out of the vault, submits it to near intents as a swap from sol into native zec, and delivers the zec to one transparent zcash address, the reserve. the reserve is written into the program config by the initialize instruction and can never be changed, so every sweep in the life of the token lands in the same place. the address is public and its balance is public. anyone can open it on a zcash explorer and see each inbound transaction, its amount and its confirmation, and the reserve page on this site reads that balance every second and shows it beside the sol that was swept to produce it. the reserve only receives. nothing in the program can move zec, and the keeper never holds the zcash keys, because the destination is an address that belongs to the program's config, not to any operator.
when a sell lands whose fee pushes the sell counter across the release threshold, that sell is the trigger for a release. a release takes the sell side amount out of the vault, submits it to near intents as a swap from sol into native xmr, and when the monero arrives it is split across every eligible holder and sent to the subaddress each of them registered. the trigger is the sell itself, not a time. a token that goes a week without a sell goes a week without a release, and a token that gets dumped hard produces a release the moment the dump crosses the line. the seller who triggered it is measured after the sell has settled, so if they sold everything they hold nothing and receive nothing, and the fee their sell paid is distributed to the people who did not sell. this is the whole point of the sell side: leaving pays the ones who stayed, in a coin nobody can trace back to them.
a release is split pro rata by balance. the keeper reads every token account for the mint at the slot in which the trigger sell was confirmed, drops any wallet below the minimum holding in the program config, drops any wallet without a valid registration, and pays each remaining wallet its balance divided by the sum of remaining balances, multiplied by the xmr delivered. the reading of balances is part of the release, done at the trigger slot, and is not a snapshot taken on a schedule. a wallet that bought in the same slot as the trigger is counted. a wallet that is not registered is not merely skipped, it is removed from the denominator, so its share flows to the registered holders. concentration is rewarded in the plain arithmetic sense that a larger balance is a larger share, and there is no cap, no tier and no decay applied on top of the ratio.
registration is done without this site. a holder sends any transaction from the wallet that holds the token, using any wallet app, containing one memo program instruction whose text is the prefix zmr:xmr: followed by a monero subaddress. a subaddress begins with the character 8 and is 95 characters long. the keeper watches memo instructions from every wallet holding the mint, validates the format, and stores the wallet together with a hash of the subaddress. the subaddress itself is never written to solana and never stored on this site. a second memo from the same wallet replaces the first. the memo is the only way to become eligible and the only way to change where payouts go, and since it is a normal solana transaction signed by the holding wallet, nobody but the holder can register or redirect a wallet's share.
sol cannot become zec or xmr on solana. there is no bridge to either chain and no wrapped version of either coin worth holding, and monero in particular has no smart contracts to hook into at all. near intents solves this as a settlement network rather than a bridge. the keeper posts an intent, an amount of sol and a destination address on the other chain, and independent solvers compete to fill it, delivering native zec or native xmr from their own inventory while the near side holds the sol in escrow until the fill is proven. the keeper never custodies the destination coin on the way through. every sweep and every release produces an intent hash, the hash is written back into the program's sweep or release record, and this site links each one to the intents explorer so the path from a solana fee to a zcash or monero balance can be followed end to end without trusting anyone.
the reserve gives the token a number that is not a price. the reserve balance divided by circulating supply is the amount of zcash standing behind each token, and it is shown on the reserve page as reserve per token together with its dollar value at the live zec price and its ratio to market cap. this number can only go up from buys, because every buy adds zcash and nothing removes it, and it goes up from burns or any other fall in supply. it never goes down from a sell, because sells feed the monero side and do not touch the reserve. a holder can therefore read two things at once: what the market currently pays for the token and what the reserve would be worth per token if the market did not exist. the gap between them is the market's own valuation of the mechanism.
the program keeps one byte that summarizes which side is leading. it compares the lifetime total swept to zcash against the lifetime total swept to monero and computes the lead as their difference over the larger of the two. when the lead exceeds ten percent in favor of zcash the state is accretive, buys are outpacing sells and the reserve is growing faster than holders are being paid. when the lead exceeds ten percent in favor of monero the state is distributive, sells are outpacing buys and holders are being paid faster than the reserve grows. between those bounds the state is balanced. the state is recomputed inside the program every time a fee is recorded, so it is a property of the chain and not of this site, and it is shown on the reserve page next to the two totals and the split bar that draws them.
this site holds no keys, submits no intents, takes no input, and cannot be used to trade. it reads the token's market data from birdeye, the program's config account from the solana rpc, and the reserve address from a zcash explorer, and it reads three tables the keeper writes: sweeps, releases and registrations. every value on every page is either read from one of those sources or computed from them by a formula written on the page where it appears, and where a source has not returned a value the slot for that value is empty rather than filled with a stand in. 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 address, and the releases page links every trigger signature and intent hash. the mechanism is exactly as real as those links, which is why they are on every page.