A coin market whose reserve is native Monero.

Monero has no smart contracts and no token standard. p/ treats that as the design constraint rather than a blocker. Every state transition is a Monero transaction; if it did not settle on Monero it did not happen. The rules below are fixed, published and replayable.

01 · Two sides

A p/ coin has a Solana surface: a token created on pump.fun by the launcher's own wallet, liquid and composable, tradeable anywhere Solana tokens trade. And it has a Monero reserve: a dedicated curve wallet, generated for the coin at launch, whose address and private view key are published in the same minute. XMR sent to that wallet is the input to a bonding curve; the registry of who holds what on that curve is derived from the wallet's transactions. Nothing is bridged between the two sides. The Solana token trades on its market; the Monero curve trades on its own, in native XMR.

02 · The curve

Constant product on virtual reserves, the pump.fun shape with XMR as the quote asset. The token side is pump.fun's exactly; 30 XMR virtual is p/'s own parameter.

1,000,000,000 supply1,073,000,000 virtual tokens793,100,000 on the curve206,900,000 for the pool30 XMR virtual1% fee
k = 30 × 10¹² piconero × 1,073 × 10¹² grains = 3.219 × 10²⁸. All arithmetic in integers: XMR in piconero, tokens in grains, division floors. Worked example: the first buy of 1 XMR pays 0.01 XMR in fee, moves the virtual XMR reserve to 30.99, the virtual token reserve to k ÷ 30.99 × 10¹² = 1,038,722,168,441,432 grains, and returns 34,277,831.558568 tokens. The curve closes when the 793,100,000 tokens are sold, which happens when about 85 XMR of real reserve has accumulated.

03 · Buying

Monero hides the sender of a transaction, so a buy has to carry its own payout instruction. p/ uses the one field every Monero wallet can set: the 8-byte payment id of an integrated address. The coin page takes the Monero address your tokens should be paid to and hands you the curve wallet's integrated address whose payment id is the first 8 bytes of keccak("p/payout:" + your address). Send any amount at or above 0.01 XMR from any wallet.

Ten confirmations later, Monero's own spend lock, the registry applies the buy at the curve state of that block. Buys in the same block are ordered by transaction hash, which the chain fixes and every node sees. A transfer under the minimum, or with no readable payment id, is not credited: the first is refunded to its address minus the network fee, the second is held and never spent.

The spec this is built from puts the payout address in tx_extra directly. No shipping wallet lets a user set tx_extra, so p/ uses the integrated-address fallback the spec describes. The registry publishes the list of payout addresses, so anyone can recompute each payment id and confirm who a buy belongs to. There is no slippage floor in this version: the curve moves only with confirmed buys, and the quote on the coin page is the exact curve.

04 · The registry and its root

The registry is an ordered list of events and the state that results from folding them: virtual and real reserves, positions keyed by payout address, fees accrued, phase. Each event is encoded canonically (operation, Monero height, transaction hash, index, amount, payload) and chained: root = blake2b-256(previous root ‖ event). The genesis event fixes the coin's address, view key, constants, creator address and starting height, so two coins never share a root and the constants cannot be changed later.

The whole log is served at /api/registry?c=…. The verifier replays it in your browser and, with a node, checks every event against the chain.

05 · Selling

A sell is authorized by a message your wallet signs with the spend key of your payout address: p/xmr|sell|address|grains|min out|registry height. Every Monero wallet can sign a message and any wallet can verify one against the address, so no key is ever transmitted. The registry height inside the line ties the signature to exactly one state: if a buy confirms between your signing and the settlement, you sign again.

The curve wallet pays XMR to your address for the tokens at the curve's price, less the 1% fee, less the Monero network fee, and records the sell as an event whose payload commits to the hash of your authorization and to the network fee. The payout's transaction key is published so you, or anyone, can confirm the amount reached your address with check_tx_key.

06 · Anchors and proofs

After events have been applied, the curve wallet pays itself a small transaction to an integrated address whose payment id is the first 8 bytes of the current root, and publishes the height it commits to. The claim is now on chain, inside a transaction only the spend key could make, and cannot be quietly rewritten. With each anchor the wallet also publishes a reserve proof, which any Monero wallet checks with check_reserve_proof, showing the wallet controls at least the stated balance. Anchors are triggered by events, never by a timer.

07 · Graduation

The buy that sells the last of the 793,100,000 curve tokens takes only what those tokens cost and refunds the rest. The registry then moves to the pool phase: the real XMR reserve and the 206,900,000 reserved tokens become a constant-product pool with its own k, and buying and selling continue against it with the same formulas and the same fee.

In this version the pool stays in the same wallet under the same operator key. The spec's 2-of-3 multisig pool wallet needs a second operator machine; it is the next step, not a claim made here.

08 · Launching

The launch page creates the token on pump.fun from your Solana wallet, with an optional dev buy, exactly as pump.fun does it; you are its creator and its creator fees are yours. It then asks p/ to open the coin: the server generates a fresh Monero wallet, stores its spend key encrypted, publishes the address and view key, records the genesis at the current Monero height, and begins reading the chain. Half of the 1% curve fee accrues to the Monero address you give and is paid out whenever it reaches 0.01 XMR.

09 · What you are trusting

Anyone can check, without trusting anyone: every XMR that entered a curve wallet, the payout address on each buy, the root in each anchor, that the published log replays to that root, and that the wallet still holds the reserve it claims. The operator is trusted for one thing: to settle valid sells promptly. The chain cannot force a payment; it can only expose an authorization that was not honored, which is why sells and payout keys are published. The operator also holds the spend key of every curve wallet on a single server, reads the chain through a public node, and can be offline; buys still count because they are derived from the chain, and sells queue until the wallet returns.

Coins can go to zero. Only put in what you can lose.