πάντα ῥεῖ — everything flows.Diarrhoea, from the Greek diárrhoia: “a flowing through”. Rhea is the part of the word that does the work. This paper is about making memecoins flow through a market instead of out of it.
Abstract
pump.fun solved launching. What it leaves to others is depth: a graduated coin's pool starts at the migration seed and grows only when someone adds to it. Rhea points the one fee stream a launcher controls, the creator fee, at a per-coin vault and spends it on the coin's own market: curve buys before graduation, burned liquidity after, a capped buy-only dip reserve, and a 10% common pool.
This paper specifies that routing as the code implements it on 12 October 2026, the checks that bound every transaction before it can be signed, and the evidence behind them. That evidence is local: unit fixtures and a local validator running byte-identical copies of the mainnet pump.fun programs. Rhea is not launch-ready. Rhea's routing is not armed: no operator wallet exists and no creator fee has been routed.
Shallow water splashes
I. Depth is the ceiling
A memecoin's chart is drawn by its pool. For a constant-product pool holding R SOL, a buy of b SOL moves the price by roughly b / (R + b). A 5 SOL buy moves a 20 SOL pool by 20%. The same buy moves a 250 SOL pool by 2%.1
Thin pools turn ordinary flow into wicks. Every buyer pays for it in slippage, and the first real seller sets the top. Traders respond rationally: buy fast, sell faster, never hold. Depth is what lets a coin absorb its own exits.
One 5 SOL order barely tilts a deep pool and detonates a shallow one. Price impact = b / (R + b), where R is the pool's SOL reserve.
Swipe or scroll sideways to compare all five pools →
Single-sided constant-product estimate before fees and tick rounding. logo via DexScreener. Reference depths carry no coin identity.
The same formula as Fig. 1, on round numbers. Depth, not the size of the buy, decides whether a trade is a ripple or a wick.
| Pool R | 1 SOL buy | 5 SOL buy | 20 SOL buy |
|---|---|---|---|
| 20 SOL | 4.76% | 20.00% | 50.00% |
| 85 SOL | 1.16% | 5.56% | 19.05% |
| 250 SOL | 0.40% | 1.96% | 7.41% |
| 1,000 SOL | 0.10% | 0.50% | 1.96% |
Before fees and rounding. Pools with virtual reserves (Section V) price against real + virtual.
The fees drain out, not back in
II. Launching is solved. Depth is not.
pump.fun made launching free, instant and fair. Anyone can create a coin. A bonding curve discovers the price, graduation to a PumpSwap pool is automatic, and fee sharing makes the creator's cut a programmable stream. Rhea is built entirely on top of it.2
Liquidity was never the launchpad's job. Before graduation there is no pool at all: the curve is a formula. After graduation, depth starts from the migration seed. On PumpSwap's lowest market-cap tier (0–420 SOL), 0.02% of each trade goes to the pool. Higher tiers send 0.20%.2
The AMMs pump.fun replaced made the opposite choice. Raydium's AMM v4 keeps 0.22% of its 0.25% swap fee in the pool, and in 2024, 92.8% of Raydium's fees went to liquidity providers. Every trade left those pools a little deeper. On today's rails that compounding no longer happens by default.34
On the curve, 0% of each trade reaches liquidity. On PumpSwap's lowest market-cap tier, 0.02% does.
| Stage | Total | Protocol | Creator | Pool (LPs) |
|---|---|---|---|---|
| Bonding curve | 1.25% | 0.95% | 0.30% | 0% |
| PumpSwap · 0–420 SOL | 1.25% | 0.93% | 0.30% | 0.02% |
| PumpSwap · 420–1,470 SOL | 1.20% | 0.05% | 0.95% | 0.20% |
| PumpSwap · 1,470–2,460 SOL | 1.15% | 0.05% | 0.90% | 0.20% |
| PumpSwap · 2,460–3,440 SOL | 1.10% | 0.05% | 0.85% | 0.20% |
| PumpSwap · … scales down … | … | … | … | … |
| PumpSwap · 98k+ SOL | 0.30% | 0.05% | 0.05% | 0.20% |
Intermediate tiers between 3,440 and 98k SOL are not all published. The creator column is what fee sharing routes to a Rhea vault.
Of every $100K traded on the curve, 0 reaches the pool by design; on PumpSwap's lowest tier (under 420 SOL of market cap), $20 does.
Derived from published fee schedules; illustrative split per $100K of trade volume, not live on-chain data.
The one pipe a launcher controls
III. The fee Rhea routes
The creator fee is the one stream a launcher controls: 0.30% of every curve trade, and 0.30% on PumpSwap's lowest tier. Above 420 SOL of market cap the creator rate is higher (0.95%), then steps down to 0.05% at the top tier (Table 2). The models in this paper use the lowest tier as the conservative default for graduated coins.25
Rhea uses pump.fun's own fee sharing. At launch the creator signs a configuration that makes the coin's Rhea vault the sole shareholder of its creator fees, at 10,000 basis points. There is no new venue, no transfer hook and no custom token program. A Rhea coin is an ordinary pump.fun token, tradable everywhere pump.fun tokens trade.6
On the current Pump Fees program that configuration is final. On a local validator running byte-identical copies of the mainnet programs, Rhea's configure transaction left the sharing config with adminRevoked = true, and Rhea's separate lock step reported ALREADY_IMMUTABLE. Once configured, nobody, neither the creator nor Rhea, can repoint the fee. A finalized mainnet readback of a real Rhea configure is still required before this is a launch fact.7
Three launch transactions and one sign-in message. Nothing after launch asks for a signature from the creator.
| Step | Who signs | What it does | Status |
|---|---|---|---|
| Sign in | creator | One message that states it does not authorize any transaction | implemented · not hosted |
| Create | creator first; Rhea co-signs only the new mint | Pump create_v2: a Token-2022 mint, mint and freeze authority null | disabled |
| Configure | creator | Fee sharing: the coin's Rhea vault becomes sole shareholder, 10,000 bps | disabled |
| Lock | creator, only if still needed | Makes the route immutable. On the current program it already is after Configure | disabled |
| Everything after | nobody: the coin's vault pays | Claims, curve and pool buys, LP deposit and burn, skims, payouts | disabled · no operator signer |
Today every launch route answers 503 PREPARATION_DISABLED or EXECUTION_INTEGRATION_INCOMPLETE. Rhea never asks for token approvals or batch signatures.
Metering the flow
IV. Claims and the split
Creator fees accrue in pump.fun's creator vaults: one for the bonding curve, one for PumpSwap after graduation. Rhea's claim worker moves them to the coin's vault with pump.fun's canonical claim instructions. On the local fork, a curve-stage claim credited 149,833 lamports of trader-generated fees and a PumpSwap-stage claim credited 853,537,844 lamports, each for a 5,000-lamport network fee.78
Only what the finalized claim actually moved counts as revenue: the exact SOL credited from those vaults, read from the transaction's own balances, minus the claim's own network fee. Seed balances and donations are not revenue. If a claim collects less than its fee, or fails, the shortfall is charged to separate operating SOL, which is funded from outside and never counted as revenue.8
The net receipt is split once, in integer lamports, by the coin's stage in a finalized snapshot taken at or after the claim's slot. A replay keeps its original split, and a later graduation cannot re-split old fees.9
Each finalized claim is split once, by the coin's stage at the claim's slot. Default policy: 0% creator share, a fixed 10% to the common pool, then 50/50.
stage curve
before graduation
stage graduation-pending
curve complete, not yet migrated
At migration, unspent curve-buy budget joins it. Stockpiled tokens + graduation SOL → LP deposit → LP burned.
stage pumpswap
after graduation
Exact integer lamports in code; rounding goes to the coin's own working capital. Creator share is an open parameter (default 0%). LP is burned because burn is the only LP disposal implemented; lock versus burn is an open owner decision. Burned LP is not a price floor.
The 10% common-pool share is fixed in code: the policy refuses to load any other value. The creator share is an open parameter, default 0%. The 50/50 splits are policy defaults. Integer division rounds down, and the remainder stays in the coin's own working capital.9
| Stage | Creator | Pool | Curve buy | Grad. SOL | LP | Dip |
|---|---|---|---|---|---|---|
curvebefore graduation | 0 | 0.100 | 0.450 | 0.450 | 0 | 0 |
graduation-pendingcurve complete, not yet migrated | 0 | 0.100 | 0 | 0.900 | 0 | 0 |
pumpswapafter graduation | 0 | 0.100 | 0 | 0 | 0.450 | 0.450 |
Flushed, not withdrawable
V. Depth: graduation, deposit, burn
Graduation is pump.fun's, not Rhea's. When the curve completes, anyone can call migrate_v2 and the coin moves into its canonical PumpSwap pool. On the fork a trader-signed migrate_v2 did exactly that, and the new pool's coin creator was the sharing config, so PumpSwap-stage creator fees keep flowing along the same route.7
Before graduation, half of the working capital buys the coin on its own curve and the other half is held as SOL. At graduation any unspent curve-buy budget moves into that graduation SOL. Rhea then deposits the stockpiled tokens and the held SOL into the pool and burns the LP tokens it receives.10
After graduation, the LP half buys the missing token side from the pool (never more than half of the budget), deposits both sides and burns the LP. Burning is the only LP disposal the code implements, so nobody can withdraw that liquidity, Rhea included. Whether the product should lock instead of burn is an open owner decision; no lock rail is integrated.1011
Burned liquidity is permanent. It is not a price floor. It stays in the pool and moves with the price: when holders sell, the pool's SOL side shrinks as in any other pool. What changes is the accrual rate. On the lowest tier the pool keeps 0.02% of volume. Rhea's LP half of the 0.30% creator fee adds 0.30% × 0.90 × 0.50 = 0.135% of volume, about 6.75 times the native rate at that tier.29
Right after a real migrate_v2 on the fork, the pool held 67.41 SOL of real quote and 17.58 SOL of virtual quote. PumpSwap prices against both: 84.99 SOL.
- 287 B
pool account at migration (pinned SDK layout 300 B)
- first trade
pays to resize the pool; Rhea refuses to be this trade (
INSTRUCTION_NOT_ALLOWLISTED) - 301 B
after any trader's first trade; Rhea's pool buys proceed
One pool from one run. Trader volume was synthetic and the seed reflects the current programs' migration, not a market. Rhea's impact check now counts virtual reserves (fe779f9).
Pools created by migrate_v2 carry virtual quote reserves, and PumpSwap prices against real plus virtual. Rhea's impact check first used real reserves only, so on a migrated pool even a 0.1 SOL buy read as more than 5% impact and was refused. It now uses both.7
One case is still refused. A pool fresh from migration is 287 bytes, and its first trade pays to resize it to 301. Rhea's debit proof does not model that payer-funded resize, so Rhea will not be the first trader after a migration. Once anyone else has traded, Rhea's buys proceed.7
The plunger, and who may use it
VI. The dip agent
The other half of a graduated coin's working capital arms a dip reserve. A model may propose when and how much to buy. Deterministic code, which the model cannot override, decides what is permissible, and the only transaction it can build is a buy of the coin on its own canonical pool.12
Each proposal starts from a finalized read of that pool: three to thirty recent reserve samples, the last one no older than the configured maximum age (the code allows at most 120 s). The model sees only that chart and a JSON contract. It must answer {act, lamports, reason} in at most 4,096 characters. Anything else, a timeout included, means no action.1213
The size is the smallest of four things: the model's request, the per-call cap, what is left of a rolling 24-hour cap counted on finalized execution time, and the reserve above its floor, less the transaction overhead. The transaction must then simulate cleanly and pass the debit proof (Section VIII). Bought tokens are held by the vault, separate from LP inventory.12
Every decision is recorded in the operator journal with its reason and a hash of the raw model answer. There is no public decision feed yet; today's public feed carries finalized receipts only. No model has been called. The reasons on the example desk come from the engine's deterministic stub.1214
The model proposes; this list disposes. ‘Code’ rules are hard-wired. ‘Limits file’ values are operator settings that do not exist yet; the engine's simulation values are shown in brackets.
| Rule | Bound | Set in | Otherwise |
|---|---|---|---|
| Direction | buy own mint on its canonical pool only | code | no sell builder exists |
| Stage | graduated (PumpSwap), verified routing | code | refused |
| Liveness | proven alive: ≥ 0.05 SOL claimed fees / 72 h | code default | unknown = refused |
| Observation | finalized, 3–30 samples, age ≤ configured max (≤ 120 s) | code | refused |
| Model answer | strict JSON, ≤ 4,096 chars, reason ≤ 500 | code | no action |
| Model input / output | ≤ 8,192 bytes in · ≤ 256 tokens out | code | refused |
| Timeout | configured, ≤ 30 s (8 s in the engine) | code · engine | no action, call stays charged |
| One call per window | window pinned to chain block time | code | earlier decision returned |
| Model budget | per-day call-cost budget | limits file | refused |
| Cooldown | configured (30 min in the engine) | limits file · engine | refused |
| Per call | configured (0.5 SOL in the engine) | limits file · engine | clipped |
| Per 24 h, rolling | configured (2 SOL in the engine); unresolved work counts | limits file · engine | clipped or refused |
| Reserve floor | configured (0.1 SOL in the engine) never spent | limits file · engine | clipped or refused |
| Minimum buy | configured (0.01 SOL in the engine) | limits file · engine | refused |
| Overhead | ≥ 12,164,120 lamports (proven floor) | code | startup refused |
| Execution bounds | slippage ≤ 3% · price impact ≤ 5% | code ceiling | policy refused |
| Simulation + debit proof | exact transaction simulates; worst case fits reservation | code | rolled back |
No model provider has been called or priced. Production limits are refused at startup if the overhead is below the proven floor.
The shared main
VII. The common pool
10% of every claim moves, intact, from the coin's vault to one dedicated pool vault. Each epoch (24 hours in the engine), the pool is frozen against a complete activity window: 20% goes to $RHEA's own loop, and 80% is weighted across eligible coins by the creator fees each claimed in that window.5915
A coin is eligible only on positive evidence: verified routing, proven alive, and fees claimed in the window. The market reader proves a coin alive from at least 0.05 SOL of finalized claimed fees over 72 hours. Low fees cannot prove a coin dead without complete trade indexing, so a coin whose liveness is unknown draws nothing. Ineligible coins keep their custody; nothing is swept.13
Shares are computed by a deterministic largest-remainder method in lamports and frozen as obligations. Payouts go out in bounded, receipt-checked chunks, and a failed payout goes back to unpaid. A coin's share arrives as LP or graduation capital, never as fresh creator fees, so it is not skimmed twice. If no coin is eligible, the 80% stays unallocated inside that epoch rather than rolling into the next.15
A 10 SOL pool. $RHEA takes its fixed 20%; the other 8 SOL follows claimed fees among coins proven alive.
| Recipient | Evidence | Claimed in window | Share |
|---|---|---|---|
| $RHEA loop | fixed 20% of the epoch | — | 2.000 |
| Coin A | alive, verified | 3.000 | 6.000 |
| Coin B | alive, verified | 1.000 | 2.000 |
| Coin C | liveness not proven | 0.200 | 0 |
| Coin D | alive, nothing claimed | 0 | 0 |
Coins and amounts are invented to exercise the code; no coin exists. If no coin were eligible, the 8 SOL would stay unallocated inside the epoch.
Nothing drains past its reservation
VIII. Proving every debit before signing
Every transaction a Rhea vault would pay for is proven before it can be signed. The prover decodes the exact unsigned message, not the builder's description of it, and computes the largest possible debit to every operator account: signature and priority fees, rent for every account the transaction may create, transfers, pump.fun maximum-input amounts and Token-2022 transfer fees.16
That worst case must fit the durable reservation made for the work, inside the same database transaction. If it does not, both the operation and its reservation roll back and the refusal is logged. Broadcast, signed-byte ingestion and signing admission all demand the stored proof for that exact message digest.16
The prover fails closed. An unknown program or instruction, an extra signer, an operator account in an unexpected role, an unresolved address lookup table or a changed program layout each refuse the proof.16
Configured caps are refused at startup if they sit below what the proof needs. The floors are composed in code from finalized rent and the prover's own constants (Table 7). A priority fee raises every floor by exactly the prover's charge.17
The smallest overhead each action can need in the worst case. A configured cap below its floor never starts.
| Action | SPL base | Widest layout | Cap it binds |
|---|---|---|---|
| Curve buy | 4,779,560 | 4,897,880 | spend overhead |
| Pool / dip buy | 12,045,800 | 12,164,120 | spend overhead · dip overhead |
| LP deposit | 4,083,560 | 4,201,880 | spend overhead |
| LP burn | 5,000 | 5,000 | spend overhead |
| Claim | 4,083,560 | 4,083,560 | claim fee cap |
| Native transfer | 5,000 | 5,000 | claim fee cap (pool worker) |
‘Widest’ is the 182-byte Token-2022 token account the prover admits. Legacy-curve resize rent is charged per coin by the proof, not in the floor. 1 SOL = 1,000,000,000 lamports.
The bounds were then checked against real program execution on a local validator running clones of mainnet's Pump, Pump Fees, PumpSwap and Mayhem programs, including a real Rhea create → graduation → migrate_v2 lifecycle. All 28 operator-paid cases stayed within their bound, and the 3 expected refusals refused. The first run caught two real gaps: the live programs allocate a 137-byte volume accumulator where the pinned SDK says 90, and legacy curves are resized at the buyer's expense. The model was fixed. This is local evidence, not a public-network receipt.7
28 of 28 operator-paid transactions debited no more than the bound proven before signing. A full bar is a bound with zero slack. ✕ marks cases where the pre-fork model would have been exceeded (4).
Programs hash-matched to mainnet: Pump a4b32d32…, Pump Fees 73c679c8…, PumpSwap a8d05e69…, Mayhem a87fa9f8…. Expected refusals: UNSUPPORTED_MINT_EXTENSION, kit refusal, INSTRUCTION_NOT_ALLOWLISTED (3/3). A program upgrade invalidates this evidence. Row labels are plain language; hover a row for the harness label.
Checking for leaks
IX. Ledger, recovery, reconciliation
Rhea's journal is a single-host SQLite database. Every unit of work has an immutable ID. The exact signed bytes are stored before sending, a retry rebroadcasts the same signature rather than signing again, and each coin can have only one unresolved operation at a time.18
Reconciliation is read-only. It reads each vault's finalized SOL and token balances and compares them with what the journal implies. Each line comes out MATCH, EXPLAINED (by a named, signed but unsettled reservation) or UNEXPLAINED. Unexplained drift, a surplus as much as a shortfall, adds a readiness blocker, halts preparation and blocks signing admission. The ledger is never credited to make the numbers agree.19
What does not exist yet: a scheduled reconciliation run, remote alerting, a ledger rebuild from chain, and any evidence against a live RPC provider.11
Who holds the valve key
X. Custody and the operator
Each coin gets its own vault and its own mint key, both derived from one sealed operator seed at a coin-specific index. The vault is the sole fee shareholder and the payer of every Rhea transaction for that coin. The common pool has a separate, dedicated vault. The creator's wallet signs only the launch steps in Table 3.615
This is a trust surface, and it should be read as one. Whoever holds the operator seed controls every coin's vault. The caps, proofs and reconciliation above bound what Rhea's workers will do. They do not bound a key holder acting outside them. Isolated custody, off-host recovery and published vault addresses are prerequisites to launch, and none of them exist today.11
Until then the backend refuses to arm. An execution flag stops it at startup, signing admission throws even with a valid proof, and the code contains no operator signer.1620
XI. Status and limits
Rhea is NOT launch-ready. Of 16 safety gates, 12 pass locally, 2 are open (custody and teardown) and 2 do not apply. None has launch evidence. A local pass is narrower than a launch pass: it proves code against fixtures and a local fork, not money moving on a public network.11
12 of 16 gates pass locally, 2 are open, 2 do not apply, 0 have launch evidence.
| What | Result | Kind |
|---|---|---|
| Backend unit and fixture suite | 61 / 61 | fixtures |
| HTTP transport over loopback | 13 / 13 | loopback; zero sends |
| Local-validator debit bound | 28 / 28 within bound · 3 / 3 refusals | local fork |
| Engine simulation | 39 / 39 | simulation |
| Funded public-network canary | 0 run | none |
- 01Durable idempotent work unitspass · local
- 02Mint-derived token programpass · local
- 03Chain / constants / identitypass · local
- 04Worker exclusion / supervisionpass · local
- 05Ambiguous confirmationpass · local
- 06Final capspass · local
- 07Fail closedpass · local
- 08Chain ↔ ledger both directionspass · local
- 09Custody and backupopen
- 10Config read-sitespass · local
- 11Unproven legs stay darkpass · local
- 12Canonical fee claimspass · local
- 13Teardownopen
- 14Price-based outcome payoutsn/a
- 15Settlement → payout handoffn/a
- 16Enumerable allocation recipientspass · local
Fixtures, a loopback transport and a local fork. None of it is a funded lifecycle.
In plain language, from AUDIT.md's remaining gaps. Each one blocks launch.
| Operator custody | No production keys exist. No isolated custody, off-host recovery or published vault addresses. |
|---|---|
| Public-network receipts | No funded transaction on any public network. Every money path still needs a separately authorized, funded canary; the local fork is not a receipt. |
| First trade after migration | Rhea refuses to be the first trade on a freshly migrated pool, because the payer-funded pool resize is not modelled. |
| Reconciliation in production | No scheduled run, no remote alert, no ledger rebuild from chain, no live-RPC evidence. |
| Teardown | Open. No final-claim and sweep contract, no bound sweep destination, no dust-tested teardown. |
| Activity indexing | Not built. The common pool cannot freeze an epoch yet, and low-fee coins cannot be proven dead. What happens to an empty epoch is undecided. |
| Fee-route readback | Mainnet readback that a real Rhea configure leaves the route immutable. |
| LP policy | Lock versus burn is undecided. Burn is the only LP path in code. |
| Dip agent | No model has been called or priced. Dip limits, spend and claim caps are unconfigured. |
| Transaction coverage | Lookup-table (v0) messages are refused, compute-unit pricing is not wired to runtime, and transfer-fee base mints are unsupported. |
| Launch surface | No hosted backend, monitoring, wallet-extension signing or independent review. |
Beyond the code, the market limits stay. Fees scale with volume, so a coin nobody trades funds nothing. A capped, buy-only reserve can slow a drawdown but cannot reverse one, and determined selling will clear it. Burned liquidity is not a floor. Agent errors are capped, not eliminated.
Memecoins are high-risk, speculative and legally uncertain in many jurisdictions. Nothing here is investment advice, and nothing here is live.
Liquidity that compounds, built where coins already launch.
The manifesto makes the case in six short beats. The app docs show what you would sign, what is stored and what is capped. The example desk replays the engine on invented coins.
Glossary · the plumbing, translated
Every pun on this site sits on a mechanism. Here is the mechanism.
- Liquid
- A pool deep enough that ordinary flow moves the price a little. A 5 SOL buy into a 250 SOL pool: about 2%. §I · Table 1
- Solid / constipated
- A thin pool. The same 5 SOL buy into a 20 SOL pool moves the price about 20%. Wicks, not ranges. §I · Table 1
- Flow
- Trading volume. Creator fees scale with it, so a coin nobody trades funds nothing. §III · §XI
- Drain
- Fees that leave the market: on the curve 0% of each trade reaches liquidity; on PumpSwap's lowest tier 0.02% does. §II · Table 2
- Sediment
- The curve-buy stockpile: before graduation half the working capital buys the coin and the vault holds it. §V · Table 4
- Flush
- Deposit then burn: tokens and SOL go into the PumpSwap pool and the LP tokens Rhea receives are burned. §V
- Flushed LP
- Burned LP. Nobody can withdraw it, Rhea included. It is not a floor: its SOL side shrinks when holders sell. §V · §XI
- Plunger
- The dip reserve: capped, buy-only, own canonical pool only. A model proposes; deterministic code decides what is permissible. §VI · Table 5
- The runs
- A sell cascade. A capped reserve can slow a drawdown but cannot reverse one; determined selling clears it. §XI
- Regularity
- A range instead of a wick: depth absorbs a big day. Not a forecast for any coin. §I
- The main
- The common pool: 10% of every claim. Each epoch $RHEA takes a fixed 20%; 80% goes to coins proven alive, by fees claimed. §VII · Table 6
- Dry
- A coin that can't be proven alive (under 0.05 SOL of finalized claimed fees in 72 h). It draws nothing from the main. §VII
- Backflow
- A debit larger than what was reserved for the work. The debit proof refuses to sign it; reconciliation flags any drift. §VIII · §IX
- Leak
- UNEXPLAINED drift between a vault's finalized balances and the journal. It blocks signing; the ledger is never credited to hide it. §IX
- Valve key
- The sealed operator seed. Whoever holds it controls every coin's vault. A trust surface, stated as one. §X
Figures & tables
- Fig. 1The same 5 SOL buy, different plumbingSOURCED
- Table 1Price impact by pool depthCOMPUTED
- Table 2pump.fun fee scheduleSOURCED
- Fig. 2Where 1.25% drainsSOURCED
- Table 3What the creator signsFROM CODE
- Fig. 3Where one claimed SOL flowsFROM CODE
- Table 4Split by stage, per 1 SOL claimedFROM CODE
- Fig. 4A freshly migrated poolLOCAL VALIDATOR
- Table 5Dip-agent guardrailsFROM CODE
- Table 6One common-pool epochFROM CODE
- Table 7Proven cap floorsFROM CODE
- Fig. 5Observed debit against the proven boundLOCAL VALIDATOR
- Table 8Evidence so farAUDIT
- Table 9What is still missingAUDIT