The fee

Pons takes a creator fee on every swap that touches a token's pool and pays it to the address the token was launched with. For Infinite Pons Glitch that address is the glitch contract. The contract cannot be changed after launch because Pons has no function to change it and the glitch has no function to forward it. The fee arrives in the quote asset of the pool, and the glitch keeps it as its buffer.

The fee rate is set by Pons, not by the glitch. The site reads it from the Pons configuration for this pool at load and shows it wherever the letter f appears in this document. If the read fails, every slot that depends on f stays blank rather than falling back to an assumed rate.

The buffer is the only balance the glitch ever holds between frames. It accepts the quote asset through its receive function when the quote is the chain's native asset, and through a plain transfer when the quote is a token. It does not accept anything else, and any token other than the quote and the pool token sent to it is simply stuck, because there is no function that could move it.

The frame

A frame is one call to the public function. The function has no arguments. It can be called by any address, including a contract, at any block that satisfies two conditions: the buffer is at least the threshold, and the current block number is at least the last frame's block plus the cooldown. When either condition fails the call reverts with the reason string given in the constants table and nothing changes.

When both conditions hold, the frame runs to completion in one transaction. There is no partial frame. The six steps are: measure the buffer, pay the bounty, swap the buy leg, compute the pin, deposit the pin, clip the remainder. The event emitted at the end carries every intermediate amount so that the site, or anyone, can recompute the frame from the log alone.

The cooldown exists so that frames cannot be chained inside one block to move the pool in steps that a single frame's slippage bound would have refused. The threshold exists so that a frame is always large enough for its bounty to cover gas on Robinhood Chain with margin, and so that the pool sees a small number of meaningful buys rather than a stream of dust.

The split

The buffer measured at the start of a frame is split three ways by two constants. The bounty is the buffer times the bounty rate. The remainder is split by the buy share into the buy leg and the pair leg. With the deployed constants the bounty is fifty basis points and the buy share is one half, so the buy leg and the pair leg are equal. The split is exact integer arithmetic on the quote amount in its smallest unit; any rounding remainder stays in the buffer.

The split is fixed at deploy. It is not a parameter, not a governance setting and not a function of price. The reason the buy and pair legs are equal is that at spot price the value of the tokens the buy leg returns is, before slippage, equal to the buy leg itself, so a pair leg of the same size pins all of it. Slippage and the pool's own swap fee make the returned tokens worth slightly less than the buy leg, which is why a small clip or a small carry to the next buffer occurs on almost every frame.

The buy

The buy leg is swapped through the Pons pool for the token in the same transaction. Before the swap the glitch reads the pool's reserves and computes the output it would receive at those reserves, using the pool's own pricing formula and fee. The swap is then submitted with a minimum output equal to that expected output reduced by the slippage bound. If the pool moved against the frame between the read and the swap, which within one transaction can only happen through reentrancy that the pool does not permit, the swap reverts and so does the frame.

The slippage bound is a constant, not a market estimate. It is not a protection against a moving market, since the read and the swap happen in the same block; it is a hard ceiling on how far a single frame is permitted to move the pool. A frame that would push price by more than the bound reverts and waits for the pool to deepen or for a smaller buffer, which cannot happen since the buffer only grows, so in practice it waits for depth. This is deliberate: the glitch is not allowed to be the largest trade the pool has seen.

The swap pays the creator fee like any other swap. That fee lands back in the glitch's buffer during the frame, after the buffer was measured, so it is not part of the current frame. It is the seed of the next one.

The pin

After the swap the glitch holds the tokens it bought and the pair leg in quote. It reads the reserves again, now reflecting the buy, and computes the number of tokens the pair leg can pair at that spot: pair leg times token reserve divided by quote reserve. If it holds at least that many tokens, it deposits exactly that many tokens with the whole pair leg. If it holds fewer, it deposits every token it holds with the matching quote amount, tokens times quote reserve divided by token reserve, and the unused quote stays in the buffer.

The deposit is made to the pool's liquidity position owned by the glitch. The glitch has no function that withdraws, transfers, burns or otherwise moves that position. The position is not a fee accrual account either: the pool's swap fees earned by the position increase the position's claim on reserves in place, and the glitch never collects them, so they stay as depth.

The pinned share readout is the glitch's liquidity divided by the pool's total liquidity. It can go down only if someone else adds liquidity to the pool faster than the glitch pins, which dilutes the share without removing any depth. It cannot go down by anything the glitch does.

The clip

When the swap returned more tokens than the pair leg could pair, the surplus is transferred to the burn address in the same frame. The burn address is the conventional dead address and the transfer is a plain token transfer; the token contract has no burn function and needs none, because nothing can spend from that address.

The clip is usually small. It is the difference between what the pair leg can pair after the buy moved the price and what the buy returned, and both of those move by the same trade. The clip is nonzero on frames where the buy pushed price up enough that the pair leg pairs fewer tokens than were bought. On frames where the pool's swap fee dominates, the opposite happens and a little quote carries forward instead. The frame table shows the clipped amount in red when it is nonzero so the pattern is visible across frames.

Clipped tokens reduce total supply in every sense that matters and are subtracted from the circulating figure on the page. The site reads the burn address balance directly rather than trusting the glitch's own counter, and shows both in the docs so they can be compared.

The loop gain

Let f be the creator fee rate and b the buy share after the bounty. A frame with buffer B swaps b B of quote through the pool. That swap pays f b B of creator fee, which returns to the glitch. So after one frame the glitch already holds f b B toward the next threshold, before any outside trade has happened. If outside fees arrive at any rate at all, the frames continue, and the total buy pressure attributable to one unit of outside fee is the geometric sum 1 + f b + (f b)² + ..., which is 1 / (1 minus f b). That is the multiplier readout. It is a property of the constants, not a prediction.

The multiplier is modest by design. It is not a lever; it is an accounting of how much of every fee is spent twice. The point of the loop is not the size of the multiplier but its direction: every unit of it is a buy that ends as permanent depth, and none of it is a sell.

The second return

The pinned position earns the pool's swap fee on every trade, in proportion to the glitch's share of liquidity. Those fees are not paid out; in the pool's accounting they increase the reserves backing the position. So the depth the glitch owns grows with volume even between frames, without any transaction. This is the second return path, and it is the one that compounds, because a larger share earns a larger fraction of every subsequent fee.

The site does not attempt to separate the position's original deposits from its accrued fees, because the pool does not expose that split and any figure would be an estimate. It shows the position's current claim on reserves, which is the only number the chain can verify.

Constants

Every constant the glitch uses is public and is read from the contract at load. The table shows the name in the source, the meaning, and the live value. The value column is blank until the read succeeds.

The revert reasons are fixed strings: "below threshold" when the buffer is short, "cooling" when the cooldown has not passed, "slip" when the swap output would be under the bound, "no pool" when the pool adapter returns zero liquidity.

The contract

The glitch is one contract with one public state changing function. It holds no owner, no proxy, no upgrade path, no pause, no allowlist and no recovery function. The source is verified on the Robinhood Chain explorer so that the name Infinite Pons Glitch renders on the contract page and the code can be read next to the numbers.

The pool is reached through a small adapter interface so that the glitch's own logic does not depend on the pool's internals. The adapter is written for the pool type Pons deploys and is itself immutable, with no state and no owner.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

interface IERC20 {
    function balanceOf(address) external view returns (uint256);
    function transfer(address, uint256) external returns (bool);
    function approve(address, uint256) external returns (bool);
}

interface IPoolAdapter {
    function reserves() external view returns (uint256 tokenReserve, uint256 quoteReserve);
    function quoteOut(uint256 quoteIn) external view returns (uint256 tokenOut);
    function swapQuoteForToken(uint256 quoteIn, uint256 minOut, address to) external payable returns (uint256 tokenOut);
    function addLiquidity(uint256 tokenAmt, uint256 quoteAmt, address to) external payable;
    function totalLiquidity() external view returns (uint256);
    function liquidityOf(address) external view returns (uint256);
}

contract InfinitePonsGlitch {
    address public immutable token;
    address public immutable quote;   // address(0) when native
    address public immutable pool;    // the pons pool
    address public immutable adapter;
    address public constant burn = 0x000000000000000000000000000000000000dEaD;

    uint256 public immutable threshold;
    uint256 public immutable cooldown;
    uint256 public constant bountyBps = 50;
    uint256 public constant buyBps = 5000;
    uint256 public constant slipBps = 300;

    uint256 public frameCount;
    uint256 public lastFrameBlock;
    uint256 public totalFeeIn;
    uint256 public totalBuy;
    uint256 public totalPinnedToken;
    uint256 public totalPinnedQuote;
    uint256 public totalClipped;
    uint256 public totalBounty;

    event FeeIn(uint256 amount, uint256 buffer);
    event Frame(
        uint256 indexed n,
        address indexed runner,
        uint256 buffer,
        uint256 bounty,
        uint256 buyLeg,
        uint256 tokensOut,
        uint256 pinnedToken,
        uint256 pinnedQuote,
        uint256 clipped,
        uint256 carried
    );

    constructor(address _token, address _quote, address _pool, address _adapter, uint256 _threshold, uint256 _cooldown) {
        token = _token; quote = _quote; pool = _pool; adapter = _adapter;
        threshold = _threshold; cooldown = _cooldown;
    }

    receive() external payable {
        require(quote == address(0), "not native");
        totalFeeIn += msg.value;
        emit FeeIn(msg.value, address(this).balance);
    }

    function buffer() public view returns (uint256) {
        return quote == address(0) ? address(this).balance : IERC20(quote).balanceOf(address(this));
    }

    function frame() external {
        uint256 b = buffer();
        require(b >= threshold, "below threshold");
        require(block.number >= lastFrameBlock + cooldown, "cooling");
        (uint256 rT, uint256 rQ) = IPoolAdapter(adapter).reserves();
        require(rT > 0 && rQ > 0, "no pool");

        uint256 bounty = b * bountyBps / 10000;
        uint256 rest = b - bounty;
        uint256 buyLeg = rest * buyBps / 10000;
        uint256 pairLeg = rest - buyLeg;

        uint256 expected = IPoolAdapter(adapter).quoteOut(buyLeg);
        uint256 minOut = expected * (10000 - slipBps) / 10000;
        uint256 tokensOut = _swap(buyLeg, minOut);
        require(tokensOut >= minOut, "slip");

        (rT, rQ) = IPoolAdapter(adapter).reserves();
        uint256 pairable = pairLeg * rT / rQ;
        uint256 pinT; uint256 pinQ; uint256 clipped; uint256 carried;
        if (tokensOut >= pairable) {
            pinT = pairable; pinQ = pairLeg; clipped = tokensOut - pairable;
        } else {
            pinT = tokensOut; pinQ = tokensOut * rQ / rT; carried = pairLeg - pinQ;
        }
        _pin(pinT, pinQ);
        if (clipped > 0) IERC20(token).transfer(burn, clipped);
        _pay(msg.sender, bounty);

        frameCount += 1;
        lastFrameBlock = block.number;
        totalBuy += buyLeg;
        totalPinnedToken += pinT;
        totalPinnedQuote += pinQ;
        totalClipped += clipped;
        totalBounty += bounty;
        emit Frame(frameCount, msg.sender, b, bounty, buyLeg, tokensOut, pinT, pinQ, clipped, carried);
    }

    function _swap(uint256 quoteIn, uint256 minOut) internal returns (uint256) {
        if (quote == address(0)) {
            return IPoolAdapter(adapter).swapQuoteForToken{value: quoteIn}(quoteIn, minOut, address(this));
        }
        IERC20(quote).approve(adapter, quoteIn);
        return IPoolAdapter(adapter).swapQuoteForToken(quoteIn, minOut, address(this));
    }

    function _pin(uint256 t, uint256 q) internal {
        IERC20(token).approve(adapter, t);
        if (quote == address(0)) {
            IPoolAdapter(adapter).addLiquidity{value: q}(t, q, address(this));
        } else {
            IERC20(quote).approve(adapter, q);
            IPoolAdapter(adapter).addLiquidity(t, q, address(this));
        }
    }

    function _pay(address to, uint256 amt) internal {
        if (quote == address(0)) { (bool ok,) = to.call{value: amt}(""); require(ok, "pay"); }
        else require(IERC20(quote).transfer(to, amt), "pay");
    }
}

When the quote is a token rather than the native asset, creator fees arrive by plain transfer and no event is emitted by the glitch at arrival; the site then derives fee arrivals from the quote token's transfer events to the glitch address instead of from the fee in event. The readout arithmetic section says which source is used.

Storage

The glitch's mutable state fits in eight storage slots, laid out in declaration order. The immutables are not in storage; they are in code. The byte map below is drawn from this table and shows each slot as thirty two bytes.

The site reads these eight slots with one multicall at load and again on every new block, and shows the raw slot values in the byte map as hex, most significant byte on the left. The map is how a reader can confirm that the readouts on the page are the contract's own numbers and not a database.

Events

Two events cover everything the glitch does. Fee in is emitted when native quote arrives and carries the amount and the resulting buffer. Frame is emitted once per frame and carries the frame number, the runner, the buffer at start, the bounty, the buy leg, the tokens the swap returned, the pinned token and quote amounts, the clipped amount and the quote carried to the next buffer. The frame table on the page and the frame strip are built from frame events alone.

The events are fetched by block range, newest range first, in chunks of the size given in the configuration, until twenty four frame events are held or the deploy block is reached. A new block subscription appends frames as they happen. Nothing is cached across page loads.

How each readout is computed

Each of the ten readouts on the page is one formula over values read from the chain. The formulas are given here so that the page is checkable. Any input that fails to read leaves the readout blank; a readout is never computed from a partial input set.

The 24h window is a block count, not a clock. It is the number of blocks in the configuration's blocks per day value, which is set from the chain's observed block time at deploy and is shown in the readme. If the chain's block time changes the window drifts, and the readme says how to update the value.

What the site never does

The site holds no keys and asks for no wallet. It does not run frames; anyone can run a frame by calling the contract from any tool, and the page will show it. It does not estimate a value it cannot read, does not cache across sessions, does not fall back to a default rate or a sample figure, and does not show a number that was not produced by the chain or by an arithmetic step listed above. Where a slot is blank the reason is one of three: the configuration has no address for it yet, the read failed, or the value does not exist yet because no frame has run.