Understand what
grows underneath.
wXMR-paired coins, transparent fee allocation and reserves that belong to each token.
The complete real launch, buy, sell, fee settlement, burn payout and Creator reward cycle is verified. The live keeper has also collected fees, published a holder snapshot and paid 0.000003885382 wXMR to a holder without a holder signature. Public coin creation, trading and reserve redemption are available. Platform buyback execution awaits the official token and its canonical wXMR pool.
Your token. Your wXMR reserve.
Trading fees grow this token’s reserve. Burn tokens to redeem your proportional share.
XMR ROOTS has been adapted for wXMR-paired tokens on Solana, using pump.fun curves and PumpSwap after graduation. The model gives every registered token its own reserve, rewards budget and fee-allocation records.
Plant
Create a token paired with wXMR and choose its reward mode.
Grow
Collect creator fees and settle them into five separate allocations.
Harvest
Burn tokens for a proportional share of that token’s wXMR reserve.
These mechanics are implemented in the new wXMR program. The earlier HYPE program and its records remain separate. Launches, trades, fee settlements and reserve payouts are verified on Solana mainnet.
Monero represented on Solana.
The quote asset is wXMR, a Solana SPL token with 12 decimals. Pump lists this exact mint as a supported Monero pair asset, with wxmr.io as its listing provider. A Solana wallet such as Phantom signs Solana transactions; network fees are paid in SOL.
wXMR is not native XMR. Its provider offers a bridge between Solana and Monero and reports 1:1 backing. XMR ROOTS has not independently audited that backing, bridge custody or solvency. A token’s inclusion on Pump’s list does not constitute a security audit or a Monero Project endorsement.
Trading, reserve balances and wXMR payouts on Solana do not inherit Monero’s native privacy. Converting a wXMR payout to native XMR requires a separate bridge operation, with its own fees, processing and availability.
From an idea to a wXMR pair.
- Prepare your token.
Choose its name, ticker, square image and public description. Preview its identity before publishing metadata.
- Choose the reward mode.
Creator mode pays the connected launch wallet. Holder mode uses periodic snapshots and claim proofs. Either mode receives the same 20% fee allocation.
- Create your token.
Click Create token. The site uploads metadata, verifies the deployed program and simulates the launch automatically, then opens your wallet. Keep SOL available for account rent and network fees.
- Confirm in your wallet.
Check the transaction and its costs, then approve it in Phantom or Solflare. The launch creates the pump.fun token and registers its reserve atomically. No second confirmation on the site is required.
Token creation and any first purchase are separate transactions. Your wallet confirms each action.
Plant a coinA quote you review. A trade you sign.
The trading flow reads a registered token’s pump.fun curve or canonical PumpSwap pool, calculates a wXMR quote and simulates the transaction before requesting a wallet signature. Buy, sell and reserve redemption are distinct actions.
Liquidity, price movement and other transactions affect execution. Slippage limits constrain the accepted transaction; they do not guarantee a quoted price or prevent every market risk.
The 2% creator fee applies to buys and sells. Venue fees, account rent and Solana network fees remain separate. Trading uses the verified wXMR program on Solana mainnet.
2% creator fees,
split five ways.
A reserve for each token. Rewards for its community. Budgets for growth.
The deployed wXMR program enforces this allocation when collected creator fees are settled. The legacy HYPE program remains separate. Creation, buying, selling, fee allocation, reserve redemption and reward payments have verified mainnet receipts.
| Destination | Of creator fees | Of trade volume |
|---|---|---|
| Per-token wXMR reserve | 30% | 0.60% |
| Platform-token buyback & burn | 20% | 0.40% |
| Development, security, infrastructure & listings | 15% | 0.30% |
| Creator / holder rewards | 20% | 0.40% |
| Long-term treasury & growth | 15% | 0.30% |
| Total | 100% | 2.00% |
Development and long-term growth each receive 15% of creator fees. Both belong to the project treasury: together, 30% of creator fees or 0.60% of illustrative trade volume. These are project funds before expenses, not an automatic personal payout.
Try a trade volume
Illustrative USDIllustrative amounts under the fee model. This is not a live price conversion, revenue forecast or a live protocol balance. Venue and network fees are excluded.
At $100 of illustrative trading volume, the creator fee is $2: $0.60 for the reserve, $0.40 for buybacks, $0.30 for development, $0.40 for rewards and $0.30 for long-term treasury. At $1 million, the fee is $20,000 and the two treasury budgets total $6,000.
Wallet buys and sells use a compact transaction. Creator fees accumulate in the coin’s Pump vault until a separate Collect & allocate fees transaction, or the keeper, settles them. Reserve and reward balances update after settlement. The dedicated keeper is active and its first automatic holder payout is verified.
Burn your token. Redeem its reserve.
Redemption pays a proportional share of the available wXMR reserve when a holder permanently burns tokens. Both steps must execute in the same Solana transaction, or neither succeeds.
reserve × tokens burned ÷ total token supply before burnBurning 1% of the pre-burn total supply would redeem approximately 1% of the available reserve, subject to integer rounding. Total mint supply includes tokens in curves and pools; it is not just the holder’s wallet balance.
The reserve does not guarantee recovery of a purchase price or create a guaranteed market-price floor. An empty reserve cannot fund a payout. Receiving native XMR on Monero is a separate bridge withdrawal after receiving wXMR.
One budget. Two reward modes.
Creator mode
The 20% rewards allocation accrues to the creator recipient recorded at launch. Payout instructions must preserve that recipient.
Holder mode
The keeper publishes a finalized holder snapshot, then submits each recipient’s claim proof and pays wXMR directly from the token vault. Holders do not sign to receive an automatic payout.
Snapshot correctness depends on its publisher. A proof verifies the published allocation, not whether the publisher chose fair eligibility rules. Eligibility and exclusions must be disclosed in each manifest. Holding a token does not guarantee a reward amount or payment schedule.
The implementation includes fixed published epochs, duplicate-claim prevention and a 180-day claim window. The first automatic holder payout was verified on mainnet: 0.000003885382 wXMR to one wallet. Read the finalized payout evidence.
The operating keeper publishes a new epoch when a token’s reward budget reaches 0.001 wXMR, at most once an hour per token. This is a wXMR threshold, not a fixed USD threshold. Holdings are aggregated per eligible wallet; curve, pool and vault owners, frozen accounts and delegated accounts are excluded. There is no USD holding minimum. The keeper pays SOL network fees and any required recipient account rent from its separate operating wallet, within its spending limits. It does not deduct a rent charge from the recipient’s wXMR allocation.
Available budgets, snapshot rules, the 0.001 wXMR trigger and keeper funding determine when a payment can execute.
Real budgets. Verifiable burns.
The program allocates 20% of creator fees to buy the selected platform token, then burn the acquired tokens atomically. Execution will require a configured platform mint, a canonical wXMR PumpSwap pool, available budget and adequate liquidity.
Configuration, pool migration, liquidity, funding and execution limits can delay spending. Only confirmed transactions prove a completed purchase and burn.
The old global limit of 0.25 HYPE per five minutes belongs to the legacy HYPE program. It is not a promised XMR limit. wXMR uses 12 decimals, with native amounts, caps, output floors and queue reporting bound to that asset. The adapted build sets a global cap of 0.01 wXMR per transaction, a five-minute cooldown and an onchain output floor: 2.88 wXMR/day maximum theoretical throughput.
The keeper serves the protocol.
The active wXMR keeper collects and settles fees, publishes holder snapshots and delivers fixed claims. Its first three automatic transactions are verified on mainnet. Platform buybacks remain pending the official platform token and its graduated canonical wXMR pool. The keeper uses a separate dedicated wallet and an operating spending cap of 0.01 SOL per day.
Owner controls
Review deployment and configuration, select the platform token, and grant, rotate or revoke a dedicated keeper.
Keeper limits
Operate within token budgets and explicit permissions. Snapshot accuracy remains dependent on the keeper and its data sources.
The project treasury and token reserves have separate purposes. wXMR adds the bridge provider’s custody and redemption assumptions. Solana program custody does not remove the external bridge dependency.
The wXMR program is deployed.
The real cycles are verified.
The new wXMR mainnet program is 9RSfkTWckTiuCQTae86bgqZWumcLcj4fzDLxi9qNoVeM. Its bytecode matches the verified 152,616-byte build. The immutable operator and treasury are Cx64…6biQ, the 75-address lookup table is frozen, and the dedicated keeper is delegated. The earlier HYPE program remains separate.
The deployed program and client enforce the exact wXMR mint, 12-decimal accounting and explicit buyback limits. Installation and the full real Creator cycle are verified. The isolated keeper is active with dry-run disabled; automatic fee collection, snapshot publication and a positive holder payout have also been verified. These first receipts cover one holder wallet. Public creation, trading and redemption are enabled. Buyback allocations accrue onchain while the official platform token and its canonical pool are configured.
No independent security audit or independently verified bridge solvency is claimed. Activity must distinguish legacy HYPE records from future wXMR records and must never relabel legacy amounts as XMR.