freefloat

Memo No. 002 · 7 September 2026

How the PONS burn actually works

The PONS buyback is not a revenue-linked TWAP. It is a fixed-clip schedule that fires every 15 minutes through a permissionless poke() on one contract, and the clip sizes are set by the operator. Everything below was read from Robinhood Chain transaction receipts on 7 September 2026. Nothing is taken from Pons documentation or press.

The one fact that matters

A single contract executes every burn: the buyback splitter at 0x5795d2…c324. Every 900 seconds a keeper calls poke(). In that one transaction the contract wraps a fixed ETH clip, sells a fixed clip of each fee asset it holds for WETH, swaps all of the WETH into PONS on the PONS/WETH 1% pool, and sends the PONS to the dead address. The splitter never holds PONS.

On 6 September the tick never stopped, but its size was halved at 16:59 UTC while price fell from 0.90 to 0.77, then raised fivefold at 20:59 UTC after 24 configuration calls from the deployer's wallet. The founder's "twapping" post came three hours after that. Holders should read burn per tick, not burn per day, and should know that the schedule is a decision someone makes.

The mechanism, step by step

1. Fees from Pons v2 launches land in the splitter as ETH and "pair assets", the tokens launches are quoted in. At 04:13 UTC on 7 Sep it held 683 ETH, 509,500 USDG, 9,381 GME, 17,120 DJT, 831 SPCX, 74 GLD and a dozen smaller tokenised stocks.
2. A keeper EOA (0x0DAdfA92…) calls poke() (selector 0x18178358) every 15 minutes. The function has no access control. A JIT-liquidity bot (0x9f7607c4…, contract 0xbecd8da6…) sometimes calls it first inside its own bundle, minting concentrated liquidity on the PONS pool so the buyback fills against it and the bot keeps the 1% fee.
3. Inside the transaction: wrap 2.5 ETH to WETH; for each pair asset, approve the swap router and sell the configured clip for WETH on that asset's own pool.
4. Each WETH leg is swapped to PONS on pool 0x10cc6b…26ba (token0 WETH, token1 PONS, 1% fee), recipient the splitter.
5. Each leg's PONS is transferred to 0x…dEaD in the same transaction. A normal tick has about 17 burn logs.
6. Clip sizes are configured by the deployer wallet 0xda4bCe…3968 via calls with selector 0x249bc14b, one per asset. The splitter's implementation (0x1c65eA…1748) is unverified, so the sizing rule cannot be read; the effect of the calls can.

The gap: 6 September, tick by tick

This is the whole memo in one picture. Each bar is one poke(), hover or tap a bar for the transaction. The price line sits underneath on the same clock rather than on a second axis, so the eye compares timing, not height.

PONS burned per tick

6 Sep 10:00 to 7 Sep 04:31 UTC · 72 transactions

PONS burned per tick

PONS-PERP hourly close, USD

116:59 clip halved

220:52 to 20:54, 24 configuration calls from the deployer

320:59 clip raised fivefold

Show the 72 ticks as a table

Ticks in PONS burned (timestamps estimated from block height, accurate to about a minute). Hover a row to see its window on the chart:

Admin configuration calls: 24 transactions from 0xda4bCee7… between 20:52:20 and 20:54:04 UTC (the first of the batch), then one more (selector 0x75134ede) at 21:02:21. The first large tick was 20:59. The 16:59 halving is inferred from tick sizes; the corresponding admin calls were not retrieved (see method).

Founder post: @MEADGod, 00:10 UTC 7 Sep, "for those wondering." with the dashboard screenshot ($3.19M in the splitter, $480k in escrow), then "*twapping 15m fyi". That is three hours after the fivefold increase.

Day by day

From the splitter only; a second burn source, clones of the verified SinjohFeeRouter, is negligible and excluded.

What that implies

• Burn per day is a policy output. It can be turned down in a sell-off and up after one. The 6 Sep halving coincided with the heaviest selling on Hyperliquid.
• "Backlog" is real but finite. $3.19M in the splitter is about two days at the 7 Sep clip (about $1.8M a day), and then the burn depends on fresh fees again.
• The multiple should be computed on burn, not on platform fees. On 6 Sep the burn was $1.10M against press figures of $5.95M "fees". Market cap at 0.763 with a 699.5M float is about $534M, so 1.3× annualised burn.
• Anyone can call poke(). If the keeper is late, the schedule can still be run.

What would make this wrong

• The implementation is unverified. If the clip sizes are a function of balance or revenue rather than a manual setting, the 20:52 calls could be a coincident maintenance batch. The fivefold jump five minutes later makes that unlikely, but it is not proven.
• Timestamps are estimates. Tick times for 4 to 6 Sep are estimated from block height (about 0.1009 s per block). The 7 Sep rows after 04:31 are exact.
• The 16:59 halving has no admin-call evidence yet. Blockscout's transaction paging returned HTTP 500 past page one and the window was not recovered from the RPC.

---

Method and sources

Burns are Transfer events on the PONS token with to = 0x…dEaD, read with eth_getLogs and grouped by transaction. WETH spent is the Swap events on the PONS/WETH pool with the splitter as recipient and positive amount0. Tick cadence and callers come from eth_getTransactionByHash on each burn transaction. Admin calls are Blockscout's transaction list for the splitter, filtered to incoming, page one. Contract types are Blockscout's smart-contract endpoint: the splitter is an ERC1967 proxy; EIP-1167 clones of the verified SinjohFeeRouter are the second, tiny burn source. The RPC needs a User-Agent header and caps at 10,000 logs per call.