monex is an autonomous buyer attached to one pump.fun coin. It is funded only by that coin's creator fees. It holds half of what it claims as Monero and half as an encrypted SOL treasury, and it converts Monero gains and fee thresholds into buys of the coin under a set of constraints borrowed from how Monero itself handles money. It has no timer, no operator switch, no sell path. It is a program and a keeper. The program enforces the rules; the keeper only submits transactions that the program will accept.
When monex claims creator fees, the SOL is split in half. The first half is sent out through NEAR intents with Monero as the destination asset, and arrives in the position wallet on the Monero network. The second half is deposited into the treasury, a Token-2022 account carrying the confidential transfer extension, as units pegged one to one with lamports. The position is the engine that creates rung events. The treasury is the pool that buys are paid from. Tail fills and rung gains are both paid from the treasury; the Monero is never sold.
The position wallet has an entry price, the volume weighted Monero price at which it was built. Rung n is the price entry × (1 + 0.025 × n). When the Monero price, read from a public aggregator, crosses rung n for the first time, the program accepts a rung event that marks rung n as crossed and books position × 0.025 as a gain, expressed in SOL at the treasury's current rate, and adds it to the queue. Rungs are stored as a bitmask, so a rung can only be crossed once. There is no event for the price going down.
Monero's tail emission issues 0.6 XMR per block forever, so the chain never loses its security budget. monex keeps a tail accumulator of raw fees claimed. Every time it passes 0.6 SOL, it resets by 0.6 SOL and adds a minimum buy to the queue. This is the only path with no conditions beyond fees existing, and it is why monex never fully goes away while the coin trades.
The program counts distinct wallets that have traded the coin since the last monex fill. The keeper proves each new wallet by submitting the trade signature; the program checks the signer against its set. At sixteen, the gate opens. monex then has one fill available. The sixteen member signatures are stored in the rings account with the fill signature so the window can be reconstructed by anyone.
Before the fill, the keeper submits a commit instruction with sha256(amount_lamports as 8 little endian bytes, then the 32 byte mint, then a 16 byte nonce). The program stores the hash and the slot. The fill instruction must reference the commit. After the fill, the keeper submits the reveal with the amount and nonce; the program recomputes the hash and refuses a mismatch. This site recomputes it a second time in the browser and shows the verified mark only from its own result.
The program maintains a rolling window of the last hundred trade sizes in SOL and their median. A fill larger than the median is split: the median amount is bought and kept, the excess is bought and burned in the same transaction via a Token-2022 burn. The burned amount is recorded in the fill. This mirrors the block size penalty in Monero, where a block larger than the median forfeits part of its reward.
Rather than swapping SOL to the coin directly, the keeper builds a route SOL → pool A → pool B → coin. A and B are chosen from a published pool list by taking bytes 0 and 1 of the previous fill's signature modulo the list length. The program checks the route against the entropy in the fill instruction and refuses any other route. All three hop signatures are stored in the paths account.
Every fill creates a lot. A block is fifty trades of the coin, counted by the program from the trade proofs the keeper submits. Each lot is locked until its acquisition block plus ten. Locked lots cannot be moved by any instruction, including churn.
When a sell larger than the current median is proven to the program, it enters churning mode. The keeper derives the next vault from the vault index plus one, moves every unlocked lot into it, and closes the old vault. The program refuses to close a vault that still holds a locked lot; those lots wait for the next churn after their block.
Each fill is bundled with three buys of the same SOL size on three other coins chosen by bytes 2, 3, and 4 of the previous fill signature against a published list of coins. The program stores the three signatures. In the next round, the three positions are sold back and the unwind signatures are stored with the net lamport change of the set. The decoys are never held across more than one round.
| readout | source | refresh |
|---|---|---|
| value | Birdeye price × on chain supply | every second |
| value chart | Birdeye one minute history, then live points | once on load, then every second |
| recent trades | Birdeye seed, then RPC log subscription | once on load, then on every trade |
| program state | RPC account subscriptions | on every change |
| monero price | public aggregator through an edge function | every second from a ten second cache |
| monero position | view only wallet through an edge function | on load and on every rung or fill |
| treasury | auditor decryption through an edge function | on load and on every rung, tail, or fill |
| events | database realtime | on every event |
The program is an Anchor program deployed to Solana mainnet under the name monex. It publishes its IDL on chain, carries a verified build tied to its source repository, and embeds a security file with the same name, which is what makes explorers show the word monex on the program page instead of an address. The program id is printed in the program accounts table on the live page.
| program |
It will never sell the coin. It will never hold a decoy past one round. It will never act without a key image. It will never fire with fewer than sixteen other wallets in its window. It will never buy above the median without burning the excess. It will never move a locked lot. It will never run on a clock.