zxr is a token on solana built around one rule, meant to live inside the program that owns its creator fees. every swap on pump.fun pays a creator fee. in this design that fee does not go to a person. it goes to a vault the program controls, and the program looks at exactly one thing: the direction of the trade that paid it. a fee from a buy is headed for zcash. a fee from a sell is headed for monero. the two paths never cross, never pool, and never return to the creator. no team allocation, no treasury the founders can touch, no fee switch, no upgrade key after setup. the mechanism is the whole economic content of the token, and this page walks through it from the moment a fee lands to the moment it leaves as another coin.
the split happens the instant a fee lands. the program keeps two counters for the mint, one for fees from buys and one for fees from sells. a keeper process calls the program for each swap, passing the direction from the pump.fun trade event, and the counter for that side grows by the fee. only two instructions ever read those counters, sweep and release, and each one zeroes its own counter when it fires. because every fee is attributed per swap, not per block or per interval, the running totals are an exact record of order flow since launch. a token that gets bought far more than it gets sold ends up with a big buy counter and a small sell counter, and that imbalance shows up on the reserve page as the order flow signature.
when the buy counter crosses the sweep threshold, the keeper sweeps. the buy side amount leaves the vault, goes to near intents as a swap from sol into native zec, and lands in one transparent zcash address: the reserve. that address is written into the program config at setup and can never change, so every sweep for the life of the token arrives in the same place. the address is public and so is its balance. anyone can open it on a zcash explorer and see every inbound transaction. the reserve only receives. nothing in the program can move zec, and the keeper never holds zcash keys, because the destination belongs to the config, not to an operator.
when a sell lands and its fee pushes the sell counter past the release threshold, that sell triggers a release. the sell side amount leaves the vault, goes to near intents as a swap from sol into native xmr, and once the monero arrives it is split across every eligible holder and sent to the subaddress each one registered. the trigger is the sell, not the clock. a week without sells is a week without releases. a hard dump produces a release the moment it crosses the line. the seller who triggered it is measured after the sell settles, so if they sold everything they hold nothing and receive nothing. leaving pays the ones who stayed, in a coin nobody can trace back to them.
a release is split pro rata by balance. at the slot where the trigger sell confirmed, the keeper reads every token account for the mint, drops wallets under the minimum holding, drops wallets without a valid registration, and pays each remaining wallet its balance divided by the sum of remaining balances, times the xmr delivered. the balance read is part of the release itself, not a scheduled snapshot. a wallet that bought in the same slot as the trigger counts. an unregistered wallet is not just skipped, it is removed from the denominator, so its share goes to the registered holders. bigger balance, bigger share. no cap, no tiers, no decay.
registration happens without this site. a holder sends any transaction from the wallet that holds the token, from any wallet app, with one memo instruction whose text is the prefix zxr:xmr: followed by a monero subaddress. a subaddress starts with 8 and is 95 characters long. the keeper watches memos from every wallet holding the mint, checks the format, and stores the wallet next to a hash of the subaddress. the subaddress itself never touches solana and is never stored here. a new memo from the same wallet replaces the old one. since it is a normal solana transaction signed by the holding wallet, nobody but the holder can register or redirect that share.
sol cannot become zec or xmr on solana. there is no bridge worth trusting to either chain, no wrapped version worth holding, and monero has no smart contracts to call at all. near intents handles it as a settlement network, not a bridge. the keeper posts an intent, an amount of sol and a destination on the other chain, and independent solvers compete to fill it with native zec or xmr from their own inventory while the sol sits in escrow until the fill is proven. the keeper never holds the destination coin along the way. every sweep and release leaves an intent hash in the program's records, 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. reserve balance divided by circulating supply is the zcash standing behind each token: reserve per token, shown with its dollar value and its ratio to market cap. it can only go up from buys, because buys add zcash and nothing removes it, and it rises when supply falls. it never drops from a sell, because sells feed monero and leave the reserve alone. so a holder reads two things side by side: what the market pays for the token, and what the reserve would back per token if the market disappeared. the gap is the market's own price for the mechanism.
one byte in the program says which side is winning. it compares the lifetime total swept to zcash with the lifetime total swept to monero and takes their difference over the larger of the two. zcash ahead by more than ten percent: accretive, buys outpace sells and the reserve grows faster than holders get paid. monero ahead by more than ten percent: distributive, sells outpace buys and holders get paid faster than the reserve grows. in between: balanced. it is recalculated inside the program on every recorded fee, so it belongs to the chain, not to this site.
this site holds no keys, posts no intents, takes no input and cannot be used to trade. once the program exists it would read market data from birdeye, the config account from a solana rpc, the reserve from a zcash explorer, and three tables the keeper writes: sweeps, releases and registrations. until then, every value stays at zero and every address reads not deployed. the mechanism is only as real as the links behind it.