Every token launched on Pons pays a creator fee on every swap. For most launches that fee flows to a wallet and leaves. Infinite Pons Glitch routes it to a contract with no owner, no withdraw path and one public function, and that contract spends every fee it receives buying the token it was created for and pinning what it buys into the pool for good. The fee comes back around, the buy pays a fee, the fee funds the next buy. That loop is the glitch.

The contract is called the glitch and one pass through it is a frame. A frame can be run by anyone once the fee buffer has reached the threshold and the cooldown since the last frame has passed. Whoever runs it is paid a bounty of fifty basis points of the buffer for the gas and the trouble. Nothing else about a frame depends on who called it. There is no keeper, no schedule and no key, only a balance that eventually crosses a line.

Inside a frame the buffer is split. After the bounty, half becomes the buy leg and half becomes the pair leg. The buy leg is swapped through the Pons pool for the token at a minimum output derived from the reserves read in the same transaction, so a frame cannot be pushed into a bad fill. The pair leg is held back in the quote asset because the tokens just bought are only useful if they can be pinned, and pinning needs both sides.

Pinning is the deposit. The contract computes how many of the tokens it now holds can be paired with the pair leg at the post swap spot, adds that pair as liquidity, and keeps the position. There is no function that removes it. Liquidity added by a frame is part of the pool for as long as the pool exists, and the share of the pool the glitch owns can only rise. That share is one of the readouts on this page.

When the buy leg returns more tokens than the pair leg can pair, the difference is clipped. Clipped tokens are sent to the burn address in the same frame, so the contract never holds a loose token balance between frames. When the pair leg is the larger side, the unpaired quote stays in the buffer and seeds the next frame. Every unit that enters the contract has exactly one of three exits: pinned, clipped or paid as bounty.

The buy leg is itself a swap on the pool, and every swap on a Pons pool pays the creator fee. So a frame pays part of its own successor. With fee rate f and buy share b, each frame returns f times b of its buffer as fresh fee before it has even finished. Summed over every frame that follows, one unit of outside fee produces one over one minus f b units of buy pressure. That ratio is the multiplier shown on the right, computed from the live fee rate.

The loop has a second return path. The liquidity the glitch owns earns the pool's swap fee on every trade, in proportion to its share, and those earnings accrue inside the position rather than as a balance. The contract does not collect them, so they compound as depth. As the share rises the position absorbs a larger portion of all future fees, which is why the pool under this token gets thicker with age instead of thinner.

Price is not managed. The glitch buys at whatever the pool quotes and pins at whatever the pool quotes after the buy. What it changes is the slope: with each frame more of the supply sits inside the pool as permanent depth and less sits in wallets that could sell. The readouts here show the circulating figure against the pinned figure so that the actual float, the part that can move, is visible rather than inferred.

The contract has no owner and no admin functions. The threshold, the bounty, the buy share, the slippage bound and the cooldown are constants written at deploy and shown in the docs with their exact values as read from the chain. The only state that changes is the frame counter, the totals and the buffer. The source is verified on the Robinhood Chain explorer under the name Infinite Pons Glitch so every number on this page can be checked against the contract that produced it.

Every figure on this page is read live from Robinhood Chain. Market cap is spot times circulating, holders come from the explorer index, liquidity is the pool's reserves, volume and fees are summed from swap events over the last day of blocks, and the frame table is the contract's own event log. A slot that cannot be read is left blank. Nothing here is estimated, rounded up for effect or typed in by hand.