Tangentx

The coin is an ERC-20 launched onto a Pons V2 bonding curve on Robinhood Chain. Pons V2 is an ETH-denominated curve: full supply mints to the curve, and on sellout the launch graduates automatically into a permanently locked full-range Uniswap v4 position managed by a singleton hook. The launch configuration is committed before the first trade and cannot be edited afterwards.

Total supply is minted once, in the constructor, and there is no mint function anywhere in the bytecode: 1.000B exist and 1.000B will ever exist. 800.0M are sold along the curve to whoever arrives; 200.0M are held back for migration. There is no vesting schedule, because there is no one to vest to.

When the curve raises its migration threshold of 0.85 ETH it graduates to a Uniswap v4 pool, and the migrated position is permanently locked by Pons' singleton hook rather than burned — enforced by a contract that is not ours, not by our promise not to touch it.2 That is where the depth in §8 begins, rather than at zero, and it is why the first term of L is already beyond anyone's reach, including ours.

Two Pons behaviours are inherited and worth stating. A snipe tax starts at 99% of a buy and decays to zero across five seconds, applying only to buys; the first settle cannot run inside that window. And because the Pons hook binds permanently to one factory, a new version of the launchpad ships as an entirely new address set rather than an in-place upgrade, so the pool this coin graduates into is the pool it lives in for good.

The token carries exactly one capability beyond the ERC-20 standard: burn(uint256), which destroys the caller's own balance and nothing else. It exists because OpenZeppelin's _transfer reverts on the zero address, so there is no other way to destroy supply. There is no owner, no Ownable, no proxy, no initialize, no pause, no blacklist, no fee-on-transfer, and no _beforeTokenTransfer override. This is deliberate and it is checkable by reading one verified source file. Nothing about holding the coin is programmable by us. All behaviour lives beside the token, in a contract that can move its own balances and nothing else.

What is left to design, then, is not the distribution. It is what happens to the revenue.

The whole system is one state struct, three balances it controls, and five functions. Its interface is small enough to print.

The interesting part of an interface is what is missing from it. There is no setParams, so T₀ and the halving cannot be edited after deployment. There is no withdrawLiquidity, so the blue third is one-way by construction rather than by promise. There is no pause, no migrate, no proxy, and no admin. A rule you can amend is a preference; a rule with no amending function is a constraint, and only the second one is worth writing a paper about.

Because settle is permissionless and reverts below target, the schedule needs no operator and grants none any discretion. If we vanish, a bot cranks it. If the bot vanishes, a holder cranks it. If nobody cranks it, the subsidy waits and the state simply does not advance — the failure mode is a pause, and §8 shows a pause costs nothing.

settle takes no arguments. There is nothing to pass: the block index lives in storage, the target is a shift of it, and every other address is immutable and set at construction. A function that accepts no parameters cannot be called with the wrong ones.

It proceeds in eight steps, all inside one transaction, guarded by a reentrancy lock. Any failure reverts the whole block rather than leaving it half-settled.

1. Preflight. Compute ΔTₙ = T0_WEI << min(n, N) and require the fee balance to hold at least that. Below target the call reverts with SubsidyBelowTarget and costs the caller only gas.
2. Sweep. Collect the accrued hook fee into the contract. Fees are taken in WETH, so what arrives is the quote asset and no leg needs a swap before it can be spent. The balance is zeroed in the same transaction that reads it, which is what makes settle idempotent within a block: a second call in the same block finds nothing and reverts at step 1.
3. Keeper. Pay msg.sender min(2% of swept, gasUsed × basefee × 1.2), taken from the yield leg and from nowhere else. On Solana a crank is free. On the EVM it is not, and a schedule that depends on charity is a schedule that stops. Paying the keeper out of yellow leaves red and blue untouched, so the invariant in §6 is unaffected.
4. Split. The remainder is divided in uint256 wei, never floats: the burn leg is swept / (3 << min(n, N)), the yield leg is swept / 3, and liquidity takes the remainder, so the wei of integer-division dust lands in the pool rather than being stranded. The three legs sum to the sweep by construction, and the contract asserts it.
5. Two buys. The red and blue legs each execute a separate swap against the pool — the curve before migration, the v4 pool after it, selected on the live migration state rather than on a stored guess — with minOut derived from a TWAP rather than from spot reserves. Separate calls, so a thin pool that can absorb one leg but not both fails the block cleanly instead of settling a lopsided one. TWAP rather than spot because a permissionless buy of known size at a known trigger in a public mempool is otherwise a standing invitation; a manipulated pre-state fails the block instead of settling into it.
6. Burn. The red purchase is destroyed with burn(balance) — the whole balance, not a computed figure. state.supply is then reloaded from token.totalSupply() after the call rather than decremented locally, so the contract's idea of supply is the chain's idea of supply and cannot drift from it.
7. Deposit. The blue purchase is paired with its WETH and added to a full-range v4 position in the same pool, opened and held by LiquidityLock, which has no withdraw function and no timer to wait out. This is a separate position from the one Pons locks at graduation, because the graduation position is managed by Pons' singleton hook and is not ours to add to. Both are permanently locked; only the second one compounds. Its only outward path is collectPoolFees(), which sends fees to one hardcoded address. This is the assumption Proposition 3 rests on, enforced by bytecode with no opcode for the alternative.
8. Advance. The yield leg moves to the stake pool and the reward index advances by yield × 1e18 / staked in fixed point, so a claim is O(1) per holder regardless of how many blocks they sat through. Then n += 1, settledAt = block.timestamp, and a BlockSettled event is emitted carrying every figure above.

The whole path costs roughly 450k gas, which is why this runs on Robinhood Chain rather than on mainnet, where the cost of settling would distort the schedule it is meant to execute. The Settler is the only caller for every external call, no function accepts an authority argument, and there is no proxy — so the bytecode that settles block 0 is the bytecode that settles block N. Verify it against this document; where the two disagree, the code is what you own.

The revenue the contract spends is the trading fee. Pons V2 pays creators in ETH by default through Uniswap v4 hooks rather than accumulating fees in the launched token, with conversion handled at the hook. The Settler is named as the creator at launch, so the creator leg accrues to it directly and no leg needs a swap before it can be spent. The creator address is the entire integration surface; there is no custom hook to write and none to trust. This matters: a fee-on-transfer coin is blocked by aggregators, breaks routing, and would contradict the inertness claimed in §2. All fees are charged at the pool, none at the token.

The configuration sets a flat 200 bps pool fee with a 50% creator share, so 100 basis points of volume reaches the fee beneficiary.1 It is paid by buyer and seller alike, it does not decay with market capitalisation, and it does not stop at migration — the graduated pool keeps paying the same leg to the same address.

We call that balance the pending subsidy and we treat trade volume as the hashrate producing it. If V is quote volume,

A block therefore needs 30 ETH of volume to close at genesis, not the 100 ETH the same target would demand at thirty basis points. The fee is the dial that sets how hard the coin is to mine, and it was set once, before launch, in a configuration no one can edit.

There is a second, smaller source. The locked position earns trading fees like any other position, and collectPoolFees() routes them into the same balance. On Solana that yield is dead. Here the blue third compounds: every block makes the next block's subsidy slightly easier to reach.

And that is the entire monetary base. No emission, no inflation, no treasury sale. Coin is never created after genesis; it is only ever bought back with money the market itself paid in.

When a block settles, the balance is divided in three.

burn

Coin is bought from the pool and destroyed. Supply falls and the figure in storage falls with it.

liquidity

Coin is bought and paired into a position the LiquidityLock holds. Depth rises and stays risen.

yield

Paid in WETH to holders who stake, pro rata. The reason to hold rather than to have held.

Write bₙ, lₙ, y for the three shares of block n. Yellow is fixed at a third forever, red halves at every block, and blue is whatever is left:

Every basis point the burn gives up is received by the pool. Nothing is reclaimed by an operator, nothing is redirected, and the shares sum to one at every block. The coin converts itself from a deflationary asset into a deeply liquid one on a schedule fixed before the first trade.

A block does not close on a clock. It closes when the work has been done — when the fee balance has reached its target — and targets double:

Block 0 asks for 0.30 ETH of fees, about 30 ETH of volume. Block 10 asks for 307 ETH on its own. Difficulty rises exactly as fast as the burn share falls, and that is the whole construction: put difficulty on one axis and burn share on the other and the schedule traces xy = k. The name is not decoration.

The clamp. Both the target and the split freeze at block N. Uncapped, the schedule strangles itself: by block 20 a single block would demand a million times T₀, no block would ever close again, and every fee accrued thereafter would sit unspendable forever while stakers earned nothing. Freezing both factors preserves the invariant exactly — the cancellation below does not care what n is once both sides stop moving — so the mechanism runs indefinitely at its terminal difficulty instead of expiring.

The burn is therefore denominated in money, not in coin. Every block places the same 0.10 ETH bid and takes off the market whatever that buys — a great many coins early, very few later. An unbounded series of identical bids against a supply that is shrinking and a price that is not.

Let Sₙ be supply and Lₙ the cumulative locked capital after block n, and let Pₙ be the price the burn executes at. The state advances as

Where this proof is weak, stated plainly. The step Pₙ ≥ Lₙ/S₀ is an assumption, not a result. Deep liquidity bounds how far a given sale moves price; it does not put a hard floor under price. If price does not rise with depth, the destroyed series is not geometric and the positive limit is not guaranteed. Past the clamp the series degrades from geometric to roughly harmonic, which diverges over unbounded blocks. Neither of these matters on any realistic timescale — numerically, pricing each burn at the 4× premium over depth the model assumes, destruction has all but finished by block eight and settles at 9.9% of genesis supply, a terminal float of 901.1M — but a proof that leans on an assumption should say which one.

Define depth as locked WETH committed per surviving token:

What this is and what it is not. Lₙ is capital committed, not the pool's current WETH balance — sells draw quote out of a constant-product pool, and Fₙ does not track that. So Fₙ is a depth ratio, not a redemption floor. Nothing here is claimable; there is no path by which a holder converts a token into the WETH behind it. What monotonic depth buys you is that each unit sold moves price less than the last one did, forever, and that this property has no downward step available to it — not in a drawdown, not in a panic, not if volume stops for a year. Idleness is the worst case, and the worst case is a pause, not a reversal. There is no state of the world in which the contract gives back depth it has already committed, because there is no function anywhere in it that removes liquidity.

That is a weaker claim than a floor. It is also a true one, and it is the one the code actually enforces.