what zxr is

zxr is a token on solana whose creator fees never come back to the creator. every fee leaves solana as one of two privacy coins, and which one depends only on the direction of the trade that paid it. a buy pays a fee that becomes zcash. a sell pays a fee that becomes monero. the zcash is kept. the monero is given away. that is the whole design.

there is no schedule. no timer, no epoch, no snapshot hour, no day boundary. the mechanism reacts to trades and fee balances and nothing else. if nobody trades, nothing moves.

the two fee paths

pump.fun pays a creator fee on every swap to a fee recipient. for zxr that recipient is the fee vault, a program owned account nobody can sign for. per swap, the program records whether it was a buy or a sell and how much fee came with it. those two running totals are all the state the split needs.

the buy total is sol waiting to become zcash. the sell total is sol waiting to become monero. they never mix. heavy buying with no sells grows the zcash side and leaves the monero side at zero. a sell with no buys does the opposite.

solanazcashmonero swap on pump.funcreator feefee vault buy side countersell side counter zcash reservemonero release buysellsweep at thresholdrelease on trigger sellnear intents

sweep, the buy side

a sweep turns the buy side total into zcash. it fires when the buy side total in the vault crosses the sweep threshold, a value set in the program config and shown on the program page. the keeper, the only signer the program accepts for this instruction, claims the buy side amount, submits it to near intents as a swap from sol into native zec with the transparent reserve address as destination, and writes the intent hash back into the program. when the zec lands in the reserve, the sweep is done.

the mechanism never spends the reserve. it only receives. keeping it in a transparent address means the size of the backing is a public fact, not a promise.

release, the sell side

a release turns the sell side total into monero and hands it out. it fires on a sell, never on a clock. when a sell's fee pushes the sell side total past 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 each one's registered subaddress. the trigger signature, sell size, sol swept, intent hash, xmr delivered and recipient count all go into the release record.

the seller who triggers a release is not a recipient. eligibility is measured after the sell settles, so only what the seller still holds counts, and a wallet that sold everything gets nothing.

weighting

each release is split pro rata by balance among eligible holders. eligible means holding at least the minimum in the program config and having a valid registration. a holder's share of a release:

share_i = xmr_delivered × balance_i ÷ Σ balance_j over all eligible j

balances are read at the slot where the trigger sell confirmed. the read is part of the release, not a separate snapshot. a wallet that bought in the same slot and sits above the minimum is included.

registration

there is no form. a holder registers a monero subaddress by sending a transaction from the holding wallet, from any wallet app, with one memo instruction containing exactly:

zxr:xmr:<subaddress>

where <subaddress> is a monero subaddress: it starts with 8 and is 95 characters long. the rest of the transaction can be anything, a zero lamport transfer to yourself is enough. the keeper indexes memos from every wallet holding the token, validates the format, and stores only a hash of the subaddress next to the wallet. the subaddress itself never touches solana and never touches this site. a later memo from the same wallet replaces the earlier one.

a wallet without a valid registration is not eligible and is left out of the denominator. its share goes to everyone who did register.

why the payout is monero

monero subaddresses cannot be linked on chain. two payments to two subaddresses cannot be tied to the same wallet or the same sender. a holder can confirm their own payment with the published transaction proof and their own view key. nobody else can see that they were paid, how much, or that it had anything to do with this token.

why the reserve is zcash

zcash has transparent addresses, and a transparent address is a public balance. the reserve is supposed to be seen. anyone can open it on an explorer and check that the sol swept turned into the zec the reserve holds. if the config also carries a viewing key, it lets anyone audit shielded transfers into the reserve as well.

settlement

sol cannot turn into zec or xmr on solana. no bridge to either chain, no wrapped version worth holding. near intents is a settlement layer: a swap is posted as an intent, independent solvers compete to fill it with native coins on the destination chain, and the sol stays in escrow until the fill is proven. the keeper uses it like an api: get a quote, deposit the sol, get an intent hash, and the destination receives the coin. every intent hash gets published, so a fee can be traced from solana to its zcash or monero balance.

states

one state byte in the program says which side is leading. the program rewrites it on every fee event.

stateconditionmeaning
accretivetotal swept to zcash exceeds total swept to monero by more than ten percentbuy fees outpace sell fees. the reserve grows faster than releases pay out.
distributivetotal swept to monero exceeds total swept to zcash by more than ten percentsell fees outpace buy fees. holders get paid faster than the reserve grows.
balancedneither side leads by more than ten percentorder flow is roughly even.

what the site does not do

it holds no keys, posts no intents, takes no input and cannot be used to trade. once live it would read birdeye for market data, a solana rpc for the config account and a zcash explorer for the reserve, plus the keeper's tables for sweeps, releases and registrations. it would compute nothing that cannot be derived from those sources.

parameters

parametervalueunit
sweep threshold0sol
release threshold0sol
minimum holding0tokens
total swept to zcash0sol
total swept to monero0sol
sweep count0sweeps
release count0releases

verification

everything above should be checkable without trusting a page. once the program is deployed, the program page lists the program id, config account, fee vault and keeper with explorer links, the reserve page links the zcash address, and the releases page links every trigger and proof. a mechanism is only as real as those links.