How $SQUEEZE works

$SQUEEZE is a meme coin on Robinhood Chain, priced in tokenized GME, whose creator tax is spent by a contract instead of a wallet. 2% of every trade accumulates in a chest. A trigger level descends toward the market on traded volume, and when price breaks the level with enough net buying behind it, the vault spends 50% of the chest on a buy — up to a hard ceiling of 1% of the pool's quote reserve, which is what keeps each fire small — and burns every token it receives. The vault has no owner, no admin function and no upgrade path — though it depends on two contracts that do, which chapter 08 sets out in full.

This paper is the mechanism in full. Every claim in it carries a drawer holding the formula and the code it came from, so you can check the argument without leaving the page. Read the chapters in order and you will know exactly what the contract does before you decide whether to buy anything.

In January 2021 the mechanism worked exactly as described. Then somebody turned the buy button off.

A squeeze is not complicated. Shorts have to buy back what they sold. If the float is thin and the buying is forced, price goes where it has to go. That ran for a few days on a stock everyone reading this can name, and it stopped for a reason that had nothing to do with supply, demand or conviction. The venue restricted buying.

Most people took a lesson about hedge funds. The more useful lesson is about architecture. The buying was working. The problem was that the buyer was a crowd of people routed through a button, and somebody owned the button.

The defect was never the buying. It was that a person held the switch.

$SQUEEZE replaces the crowd with a contract. Fees accumulate whether or not anyone is paying attention, and the contract buys when its conditions hold. Those conditions are arithmetic over public state, so anyone can evaluate them, and anyone can call the function that acts on them. The vault has no owner, no admin function, no pause and no upgrade path, and that includes for us.

It is not sovereign, and the honest version of this chapter says so here rather than eight chapters down. The vault buys with a GME token whose implementation can pause transfers and block addresses, and it earns through a venue that holds a timelocked power over where its own fees are routed. Neither of those is ours, neither is removable, and chapter 08 sets out exactly what each of them can do to the mechanism. What the 2021 button holder had that these two do not is the ability to stop the buying selectively, on the day it mattered, at their own discretion. That is the defect this replaces.

Everything after this chapter is the mechanism: where the money comes from, what decides when it moves, and what stops you from gaming it.

$SQUEEZE launches on Pons, on Robinhood Chain (chain 4663), priced in tokenized GME.

Pons is the chain's bonding-curve launchpad. A launch gets a fixed supply, a curve that prices the token from the first trade, and a creator-fee role that can point at a contract instead of a wallet. $SQUEEZE points it at the vault, which is the only reason any of the rest of this works.

Total supply is 1,000,000,000, fixed at creation. There is no mint function. Supply only ever goes down, and it goes down every time the vault fires.

Why the quote asset matters

Pricing in tokenized GME means the other leg of the pool is GME. Buying $SQUEEZE puts GME into that pool. The fees the vault collects arrive in GME, the chest is denominated in GME, and every squeeze spends GME. One contract accumulating tokenized GME in a pool, trade after trade, without anyone having to decide to do it.

address public immutable QUOTE;      // tokenized GME
address public immutable TOKEN;      // $SQUEEZE
address public immutable CURVE;      // this launch's Pons curve
address public immutable ESCROW;     // where creator fees accrue
address public immutable FOUNDERS;   // paid from the platform-fee leg
address public immutable FACTORY;    // holds the fee-recipient role
address public immutable SUCCESSOR;  // where retirement forwards to

2% of every trade on the curve is routed to the vault as creator tax. Buys pay it and sells pay it. Nobody has to remember to do it, and nobody can decide to stop it.

The vault never pushes for its money. Pons holds creator fees in an escrow contract and credits them to whoever holds the creator-fee-recipient role, which for $SQUEEZE is the vault itself. They sit there until a fire sweeps the curve and claims them. That is why the chest counts two things: what the vault is holding, and what is still in escrow with its name on it.

The chest is empty as you read this, which is what a vault looks like right after it fires. Nothing has been routed to it yet.

function chest() public view returns (uint256) {
    return _unowedQuote() + IPonsV2FeeEscrow(ESCROW).balanceOfToken(address(this), QUOTE);
}

The founders are not paid out of the tax

Pons charges a 1% platform fee on top of the 2% creator tax. Part of that platform fee reaches the creator as standard fee revenue, and that part is what the founders live on. On the terms this launch was created under, 100 bps fee with a 30% protocol share, buybacks off, 200 bps tax, it works out at 70 of every 270 basis points the vault is credited. That is 25.9% of each claim to the founders, and the whole 200 bps of tax stays in the chest.

So "every cent of the 2% goes to the squeeze" is not a slogan. It is arithmetic, and you can check it against the chain.

The split is read, not written down

Here is the part worth reading twice. The founder share is not a constant in the source. The constructor works it out by reading this launch's own curve.

Pons freezes its fee policy per launch, and the two inputs that decide the creator's standard leg, protocolFeeShareBps and buybackBurnBps, are snapshots of a policy the protocol can update at any time. A hardcoded 25.9% would have been right on the day it was typed and silently wrong if the policy moved before launch day. Reading it captures exactly the snapshot Pons captured, and freezes it in an immutable. The fire path cannot pay a rate that drifted underneath it.

// Read from this launch's own curve at construction: once with a zero
// tax to isolate the standard leg, once with the real tax for the total.
FOUNDER_SHARE = (standardBps * WAD) / totalBps;

// On the terms verified live on 2026-09-17:
//   standardBps = 70, totalBps = 270  ->  25.925...%

A fire books the founder cut. It does not pay it

The amount accrues to founderOwed and leaves later, through a separate payFounders() that anyone can call. That reads like plumbing and it is load-bearing. GME is a beacon proxy whose implementation can block addresses and pause transfers. If a fire had to pay the founders before it could burn, one blocked address would take the burn down with it. It cannot. The burn does not depend on the founders getting paid.

There is a price the market has to break before the vault will spend anything. It is not fixed, and it is not on a clock. It falls toward the market as the market trades.

The level descends against traded volume, not elapsed time. The contract measures volume the only way it can trust, by watching its own fee odometer, and one unit on that clock means volume equal to the pool's quote reserve. At normal pressure the level gives up 5% of itself per unit. No trading, no descent. A dead market leaves the line exactly where it was.

Right now price is above the level, so the line is broken and gate one is open.

A fat chest pulls harder

Descent is multiplied by pressure, which is how full the chest is against what it would normally hold at this pool size. The reference ratio is 1.3% of the reserve. A chest at twice that pulls the line down twice as fast, up to a ceiling of 5x. The longer the vault goes without firing, the more eagerly it lowers its own bar.

Two clamps keep that from becoming a collapse. Pressure stops at 5, so a fee spike cannot drop the floor out. And a single observation can never remove more than 1% of the level, which is one third of the 3% a fire ratchets it up by. That ratio is the point: the volume clock arrives in lumps rather than smoothly, and without a cap a single fat observation could erase a fresh margin and hand the vault a break nobody bought.

uint256 fraction = (((baseDescent * pressureWad) / WAD) * dClock) / WAD;
if (fraction > MAX_DROP_FRACTION) fraction = MAX_DROP_FRACTION;

uint256 drop = (level * fraction) / WAD;
return level - drop;

After a fire it ratchets back up

A fire moves the price. The level is then reset to the price the buy produced plus 3%, which is what stops the vault from firing twice on the same break and draining itself in one block. Then it starts descending again, and the whole thing repeats.

Breaking the line is not enough on its own. There has to be real buying behind the break, and the contract measures that itself rather than taking the price's word for it.

Charge is net flow. Buys add to it, sells subtract from it, and it floors at zero, so a long stretch of selling leaves it empty rather than negative. It decays on the same volume clock the level descends on: half of it is gone after traded volume equal to half the pool's reserve. A seven day wall-clock constant sits underneath as a floor, so a market that stops trading entirely still drains eventually.

The threshold is zero while the pool is empty, which is the only state where this gate is free.

Wash trading cannot fake it

This is the part that decides whether the mechanism is real. Net flow is not read off fee revenue, because fee revenue counts both sides of a round trip. It is measured from the curve's own reserves through an exact constant-product integral, so a buy and the sell that undoes it cancel to zero. Not approximately. Exactly.

Trade against yourself all day. The charge does not move.

Flash loans die at the block boundary

The break has to survive a block. The contract records the block in which price first went above the level, and a fire requires the current block to be strictly later than that one. A flash loan lives and dies inside a single transaction, so it can push price over the line and it can never hold it there long enough to count.

// tauV = 0.721348 = 0.5 / ln(2), which is what makes the half-life
// exactly half a reserve of traded volume rather than an arbitrary number.
uint256 volumeTerm = FixedPointMathLib.divWad(dClock, tauV);
uint256 timeTerm = FixedPointMathLib.divWad(dSeconds * WAD, tauT * WAD);

int256 factor = FixedPointMathLib.expWad(-int256(volumeTerm + timeTerm));
return FixedPointMathLib.mulWad(charge, uint256(factor));

uint256 chestTerm = (deployable() * K) / WAD;
uint256 reserveTerm = (realQ * M) / WAD;
uint256 bar = chestTerm > reserveTerm ? chestTerm : reserveTerm;

if (realQ == 0) return bar;
uint256 ceiling = (realQ * MAX_THRESHOLD_FRACTION) / WAD;
return bar > ceiling ? ceiling : bar;

Four gates. All four have to hold in the same block, and anyone at all can be the one who calls it.

The function is poke(), it takes no arguments, and it is permissionless. If the gates hold it fires, and whoever called it takes 0.5% of the deployment as a bounty. That bounty is the entire reason the mechanism does not need us. It pays a stranger to do the work, out of money that was going to be spent anyway.

if (brokeAtBlock == 0 || price() < level)  return (false, 1); // the break
if (charge < threshold())                  return (false, 2); // the buying
if (block.number <= brokeAtBlock)          return (false, 3); // one block
if (_chestInWad() <= GAS_FLOOR)            return (false, 4); // worth the gas

Gate four is the unglamorous one and it earns its place. Below the gas floor a fire costs more to execute than it deploys, so the contract declines to waste the chest on dust.

What a fire actually does

The order matters more than any single step, so here it is in the order the contract runs it.

1. Sweep the curve, best effort. A refusal is recorded and never fatal.
2. Claim from escrow, and book the claim against the odometer so cumulative fees stay monotonic.
3. Shut both gates before any value moves. Charge goes to zero and the break record is cleared while the vault still holds everything, so a reentrant poke finds gate one already closed instead of firing twice on one break.
4. Book the founder cut. Book, not pay.
5. Take 50% — that is F — of everything the vault holds that is not owed to the founders. Not 50% of this claim: 50% of the whole banked pot.
6. Cap that at 1% of the pool's quote reserve, whichever is smaller.
7. Pay the caller's 0.5% bounty out of the capped deployment. The cap comes first deliberately: paying the bounty before it would pay a stranger a percentage of money that never left the vault, and would floor the fill against a size the vault is not buying.
8. Buy with what is left, on the curve, with a floor under the fill.
9. Send the vault's whole token balance to the burn address, not just what this buy returned.
10. Re-shut the gates, ratchet the level to the new price plus 3%, re-baseline.

Sending the whole balance, rather than the buy's output, is what makes "the vault holds no $SQUEEZE" true by construction rather than by policy. There is no accounting to trust. The balance is zero after every fire because the contract empties it.

And the 50% is taken over everything remaining, not just this claim. Fees banked by earlier fires — and whatever the ceiling held back from one — are what give the mechanism depth, so a vault that has been accumulating through a quiet stretch fires harder when the market finally gives it a break. The half F leaves behind is not held back from the burn either: it is what keeps the vault above its own gas floor, and it buys and burns on the next fire instead of this one.

There is a ceiling on that. No single fire may put more than 1% of the pool's quote reserve into the market, whatever the chest holds. That ceiling is why the price move from a squeeze is measured in fractions of a per cent rather than in double digits, and it is deliberate: chapter 08 shows that forcing a trigger only starts to pay once a deployment passes roughly 3% of the pool. The cap keeps every fire on the safe side of that line by construction rather than by luck. What the cap holds back is not lost. It stays in the chest for the next one.

The buy happens on the curve

Not through a router, and not through any third-party venue. An earlier revision of this contract bought through a swap router interface whose selector is absent from the deployed Pons bytecode, which would have bricked the buy path permanently on a contract with no admin. The venue is the curve the vault is the creator of, and the identity between the thing it earns fees from and the thing it buys on is the point.

The fill has a floor. _minOut quotes the trade constant-product against current reserves, net of what the venue charges, less a 2% slippage band. Quoting it fee-free would overstate the fill by about 3%, which is more than the entire band, and the vault would revert its own buy at every pool size forever.

Every number the mechanism uses, what it does, and why it is that value. All of them are immutable and set at construction.

Those values are read out of the same module the rest of this site reads, so the table cannot drift away from what the page is running.

What frozen actually means here

No owner. No admin function. No setter for any value above. No proxy and no upgrade path. Six mutating entry points, every one permissionless and reentrancy-guarded. The only thing anyone can do to this contract from outside is ask it to look at the market and act on what it sees. That is a statement about this contract and not about the system it sits in; chapter 08 is where the rest of the system is accounted for.

uint256 public immutable F = 0.50e18;
uint256 public immutable K = 3e18;
uint256 public immutable M = 0.04e18;
uint256 public immutable MAX_DEPLOY_FRACTION = 0.01e18;
uint256 public immutable MAX_THRESHOLD_FRACTION = 0.08e18;
uint256 public immutable TAU_V = 0.721348e18;   // 0.5 / ln(2)
uint256 public immutable TAU_T = 7 days;
uint256 public immutable BASE_DESCENT = 0.05e18;
uint256 public immutable RESET_MARGIN = 0.03e18;
uint256 public immutable NORMAL_RATIO = 0.013e18;

The obvious attack is to force a trigger: push price through the level, let the vault buy into your bags, sell into the pump. Here is why the arithmetic does not work.

A forced trigger or a sandwich only pays when the vault's deployment is large relative to the pool it is buying into. The scale-invariant form is the one to keep, because it holds at every pool size:

Note what that defence rests on. Part of it is Pons charging 300 bps, which is the venue's decision and not ours. The exposure to watch is a long drawdown: fees bank while the pool's quote leg shrinks, and both sides of that ratio move the wrong way together.

The cheaper attacks do not work either

• Wash trading. Net flow is measured from the curve's reserves through an exact constant-product integral, not from fee revenue. A buy and the sell that undoes it cancel exactly, so volume you generate against yourself builds no charge at all.
• Flash loans. The break has to survive a block boundary. A flash loan cannot hold a position across one.
• Sandwiching the vault's own buy. The fill has a floor, quoted net of what the venue charges and then cut by 2%. A fill under the floor reverts the whole fire.
• Reentering mid-buy. Every entry point is guarded, including the read-only-looking one. That is deliberate: observe() is exactly the call a hostile venue would make in the middle of the vault's purchase, to have its own in-flight buy counted as organic inflow while the gates still held their pre-fire values.
• Bricking the burn through the founder leg. A fire books the founder cut and never transfers it, so a blocked address, a paused token or a transfer that returns false cannot take the burn down with it.

What we do not control, stated plainly

Tokenized GME is a beacon proxy. Its implementation exposes pause, mint, burn and role checks, all verified on chain. A paused quote asset halts the fire path. No contract we write changes that, and "no admin key" describes this vault, not the asset it is priced in.

Pons sets its own fee policy, and part of the attack margin above depends on it. It also holds a standing power over fee routing: its owner can move the creator-fee-recipient role through a timelocked call that anyone may then execute. Its own source describes that as a standing protocol power rather than a narrow lost-key recovery. If the role moves before anyone calls retire(), retirement reverts permanently and the quote and tokens left in the vault are stranded, with only the founders' booked debt still payable.

And anyone can gift GME to the vault, which raises the threshold permanently at three times the size of the gift. It is self-funded and self-defeating, since the capital burns if the vault ever fires, but it is a cheap lever a stranger holds and you should know it exists.

The honest summary is narrower than "no admin key" sounds. This vault has no admin. Two contracts it depends on do.

Every mechanism has a hand it cannot see. These are ours.

Three phases, in the order they unlock. No dates, because a date would be a guess and this paper does not guess.

Curve phase, now

Everything in chapters 03 through 06 is live. Fees accrue to the chest, the level descends on traded volume, and the vault fires on the break, buying on the curve it earns its fees from. Anyone can poke it and collect the bounty.

Graduation, and what it costs

Say this part plainly, because inference would flatter it. Every read the vault makes goes to the bonding curve. When the curve graduates, the vault goes blind and stops firing. As built, this is a curve-phase mechanism with a defined ending, not a whole-life one.

The ending is retire(). Like everything else here it is permissionless, and it is impossible before graduation by a hard revert rather than a silent return, because firing it early would sign away a working mechanism. It claims whatever is still owed out of escrow, forwards what remains to an address fixed at construction, and hands the creator-fee-recipient role on. The founders' booked debt stays behind, so payFounders() still works afterwards. What it hands off to is the part that still has to be built.

After the handoff

Nothing. There is no designed successor mechanism, and this paper is not going to describe one as though there were. retire() forwards to an address fixed at construction; what that address does with what it receives is a decision nobody has made yet, and it will be described here when it exists and not before.

XTelegram (not up yet)Chart (not up yet)Explorer (not up yet)

$SQUEEZE is a meme coin with no intrinsic value. The mechanism described here does nothing in a downtrend except accumulate, and it never defends price. Nothing on this page is financial advice, and nothing on it is a claim about any security.