AMM and CLAMM pool state as an oracle — the degen tier#
❌ REJECTED — 2026-09-05#
Decision: do not build this. The manipulation risk in §1 is too high.
An AMM pool price is a pure function of reserves that anyone can change with a swap, so it is atomically manipulable inside one transaction by any trader with capital — no privileged position, no setup. The three defences in §2 raise the cost but do not change the shape of the attack, and the failure mode is a trader being paid out of another trader's collateral on a price someone bought.
This document is retained deliberately. The proposal is attractive enough that it will be raised again; anyone re-proposing it should engage §1 and §2 directly rather than restart the analysis. §3's
depth()finding is reusable if AMM oracles are ever revisited.What would have to change for this to be reconsidered:
- PumpSwap (or the candidate AMM) shipping a genuine on-chain TWAP or observation ring, removing the single-transaction attack — see G1, which was never verified either way.
- Or a defence that makes manipulation unprofitable rather than merely expensive.
See §9 for what to do instead, which achieves much of the stated goal with no new risk.
Date: 2026-09-05
Original direction: support Pump.fun memes using PumpAMM pool state as the oracle, generalising to other AMMs and CLAMMs, as an explicitly high-risk user-acquisition tier.
Outcome: rejected on manipulation risk.
Related: 2026-09-05-user-selectable-oracles.md
1. The structural problem, stated first#
Pyth and Chainlink prices are aggregated off-chain across venues and signed. An AMM pool price is a pure function of that pool's current reserves, and anyone can change the reserves with a swap.
So a constant-product pool price is atomically manipulable inside one transaction:
1. swap — move the pool price to whatever you want
2. read — snapshot or resolve the market at that price
3. swap back
Cost: the round-trip fee and slippage. Gain: the entire losing side of the market. If open interest exceeds manipulation cost, the attack is profitable, atomic, and available to any trader — no privileged position required.
This is categorically worse than every risk in the preceding plans:
| Risk | Who can do it | Profits? | Atomic? |
|---|---|---|---|
| Frozen settlement mint | the mint issuer | no — symmetric loss | no |
| Corrupt referee (creator picks own feed) | the creator only | yes | no — and the program allowlist prevents it |
| AMM price manipulation | any trader with capital | yes | yes |
Everything below exists to make manipulation cost more than it pays.
PumpSwap specifics: program pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA,
constant-product with real reserves after bonding-curve graduation.
⚠️ I could not confirm from public docs whether PumpSwap exposes any TWAP, price accumulator or observation ring. This design therefore assumes spot-only. If an observation mechanism exists it is a bonus, not a prerequisite — verifying it against the IDL is task G1, and a design that depended on it would be built on an unverified assumption.
2. Three defences, all economic#
No cryptographic check makes an AMM price honest. The defence is to make the attack unprofitable, and to fail closed when it cannot be guaranteed.
2.1 Cap open interest against pool depth at creation#
MarketAccount.max_total_shares already exists, settable via
UPDATE_MARKET_CAP (0x2B). Reuse it: at creation, derive the cap from the
pool's depth so that the maximum possible payout is smaller than the cost of
moving the price far enough to change the outcome.
This is the single most important control, and it needs no new machinery.
2.2 Depth floor at resolution#
Liquidity can be withdrawn — PumpSwap LP is permissionless. So depth must be re-checked at resolution, not only at creation.
If the pool no longer meets the floor, the market does not resolve from this source and falls through to neutral expiry. That is a safe failure: collateral returns, nobody is paid on a manipulated price.
2.3 Multiple observations across the bounded window#
The unified oracle plan already establishes a bounded resolution window. For AMM sources, require N observations at distinct slots within it and take the median.
This forces an attacker to hold the manipulated price across multiple blocks rather than one transaction — during which arbitrageurs are paid to undo it. It converts an atomic, riskless attack into a sustained, capital-intensive one that leaks value on every block.
Cost: a small observation ring on the market account, and N crank transactions instead of one. The escalating closer reward (F-05/F-06) is the mechanism that pays for them.
3. Generalising to other AMMs and CLAMMs#
An adapter must supply four things:
| Capability | CPMM (PumpSwap) | CLAMM (Whirlpool, Raydium CLMM) |
|---|---|---|
program_id | for the owner check that binds the source | same |
pool_identity | pool account address → feed_identity | same |
price() | reserve ratio | derived from sqrt price |
depth() | reserves | ⚠️ liquidity within a price band, not TVL |
depth() is where a naive generalisation breaks. For a constant-product
pool, total reserves are a fair proxy for manipulation cost. For a concentrated
pool they are not: a CLAMM with large TVL parked far from the current tick offers
almost no resistance to moving the price through the active range. Using TVL
as the depth proxy on a CLAMM would produce a market that looks well-protected
and is not.
Therefore depth() is defined as "cost to move the price by X%", not "value in
the pool", and each adapter implements it in its own terms. That definition is
the interface contract; TVL is an implementation detail that happens to be
correct only for CPMMs.
This is also why adapters must be added deliberately, one at a time, with the depth model reviewed — not enabled as a class.
4. Tier isolation#
This is the degen tier, and isolation must be structural, not cosmetic.
| Rule | Reason |
|---|---|
| Degen markets must settle in a blessed mint | Answers the open question from the mint plan: at least one axis must be trustworthy. A market that is both meme-settled and meme-resolved has no anchor, and the attacker's capital and the payout become the same asset. |
| Degen markets may not be parlay constituents | Otherwise an attacker manipulates one cheap leg to force an entire parlay. Compounding a manipulable oracle into a multi-leg instrument multiplies the payoff while leaving the attack cost flat. |
| Never the default | Not pre-selected anywhere in creation flows. |
| A distinct trust dimension value, not another entry beside Pyth and Chainlink | The six-dimension display (§10.4 of the oracle plan) gains an explicit AmmPool modality whose resolution guarantee reads as materially weaker, in those words. |
| Separate product surface | Browsable as its own section, visibly distinct, with risk stated before a user can trade — not on a detail page they may never open. |
5. The reputational point, stated plainly#
The stated motivation is user acquisition, and that is a legitimate reason — Pump is among the most used platforms on Solana and Pyth and Chainlink genuinely do not cover these assets.
But the honest risk is not only financial. A manipulated degen market becomes "Seesaw got exploited" in public discourse regardless of how carefully it was tiered. Isolation therefore has to be legible to an outsider reading a post about it, not merely present in the code. That argues for the separate product surface in §4 and for the risk language being unmissable rather than compliant.
It also argues for shipping §2.1–2.3 in full rather than iterating toward them: a degen tier that launches without the depth cap is the version most likely to produce that headline.
6. Tasks#
| # | Task | Notes |
|---|---|---|
| G1 | Verify PumpSwap pool state against the IDL: reserve fields, decimals, and whether any observation/TWAP mechanism exists | Blocking. The whole design assumes spot-only. |
| G2 | Decide the depth model and the OI cap formula | Blocking; §2.1 is the primary control |
| G3 | Adapter interface per §3, with depth() defined as cost-to-move | The abstraction that lets other AMMs follow |
| G4 | PumpSwap adapter: owner check against pAMMBay…, pool identity, price from reserves, depth from reserves | |
| G5 | Observation ring on the market + median across the window (§2.3) | |
| G6 | Depth floor re-check at resolution, failing to neutral expiry (§2.2) | |
| G7 | OI cap derived from depth at creation, reusing max_total_shares (§2.1) | |
| G8 | Tier isolation rules (§4) enforced in the program where possible — blessed-mint requirement and parlay exclusion are both checkable on-chain | Not only UI |
| G9 | Trust display: AmmPool modality, weaker-guarantee language, separate surface (web, mobile, SDK) | |
| G10 | Docs: a degen-tier page stating the manipulation risk in plain terms | Per the "state what does not exist" convention |
7. Risks#
- §1 is the whole risk. If §2.1–2.3 are weakened for convenience, the tier becomes an attack surface with a payout function attached.
depth()on CLAMMs is subtly wrong if modelled as TVL (§3). This will look fine in testing and fail in production against a pool with out-of-range liquidity.- Permissionless LP withdrawal means depth at creation does not bind depth at resolution. §2.2 exists for this and must not be dropped as redundant.
- Meme token decimals and supply vary wildly; the normalisation discipline from the oracle plan applies with more force here.
- Reputational contagion (§5) is not mitigated by code.
8. Open#
- G1: does PumpSwap expose any observation or TWAP mechanism?
- G2: the depth-to-OI ratio, and whether it is global or per-adapter.
- How many observations, over how long a window?
- Should degen markets have a shorter maximum duration, on the grounds that a longer market gives an attacker more chances at the window?
- Is there a minimum pool age or graduation requirement, to exclude pools created solely to be manipulated?
9. What to do instead#
The stated goal was user acquisition through meme markets. Most of that is available without AMM oracles at all.
Pyth covers the large-cap Solana memes — the ones with the volume and the audience. Those markets can be built today on the Pyth Pull path already planned in the oracle work, with the full Rule A guarantee, no new trust tier, no new attack surface, and no separate product surface to build or explain.
What is genuinely lost is the long tail of freshly graduated pump.fun launches. And that loss is smaller than it looks, because of an alignment worth noticing:
The assets excluded are precisely the assets where the attack is cheapest.
A market on a thin, new pool is both the one Pyth does not cover and the one an attacker can move for a few thousand dollars. The coverage gap and the risk are the same set. Turning it down costs the segment that was never safely servable.
Recommendation: pursue meme markets on Pyth-covered assets as part of the existing oracle work, and treat long-tail pump.fun launches as out of scope until something in §"what would have to change" holds.