BURNHOUSE Robinhood Chain · 4663 Factory not deployed Solidity 0.8.28 No owner · No withdraw · No upgrade read live from the contracts
The boiler room of an old incinerator: a cast-iron furnace door standing open with fire inside, pipes overhead, a walkway across the front
Burnhouse
0.000ETH BURNED

Nothing has burned yet. This counter moves the first time a project points its Pons creator fees at a burner.

Creator fees go in. The project’s own token stops existing.

Pons already has a buyback switch, but the tokens it buys go into a vesting vault and the protocol keeps 30% on release — that is a lock, and a lock can be undone. A Burnhouse burner sends every unit it buys to 0x…dEaD and is physically unable to do anything else: no owner, no withdraw, no upgrade path. Anyone may call execute(), including you, including nobody.

Point your fees here What it cannot do

Every figure on this page is an eth_call made while the page was being built. There is no database and no cache: if the node is down you get an error, never a stale number.

Every burner

No burner deployed yet. Once a project points its Pons creator fees at a Burnhouse address, its burns appear here automatically — this page reads the contracts, not a database.

How a project connects four calls, none of which require our permission

  1. Reserve the address

    predict() — The factory deploys with CREATE2, so a burner’s address is known before it exists. Call predict() with your token and take the address it returns.

  2. Point the fees at it

    Pons creator fee recipient — Set that address as the launch’s creator-fee recipient. Fees accrue in the Pons escrow from the very first trade, so this works before the burner is deployed. A launch already trading can hand over with transferCreatorFeeRecipient().

  3. Deploy the burner

    deploy() — Anyone may call it, and the contract that appears is the one predict() promised. There is no constructor argument that could point it somewhere else.

  4. Anyone runs a cycle

    execute() — The burner pulls the fees it is owed, buys the token at the venue Pons says is live, and sends every unit it receives to 0x…dEaD. No keeper is privileged; if nobody calls it, the fees simply keep accruing.

What a burner is unable to do the part that makes the rest of the page worth reading

Where the risk actually sits. The burner is ownerless, but it buys at whatever venue Pons reports as live, and it trusts Pons for that answer. If the launchpad reports a venue wrongly, the buy happens in the wrong place. That dependency cannot be removed by this contract, so it is written here rather than left out.

Graduation is handled

Each cycle reads the launch phase from Pons and routes the buy to the bonding curve or to the Uniswap v4 pool accordingly. The price anchor resets when the venue changes — carrying a curve price into a pool would make every subsequent fill look like a sandwich and freeze the buyback permanently. That failure was found in testing, not in production.

Nobody is the keeper

There is no bot with special rights. execute() is open, rate-limited only by a cooldown that is fixed at construction, and pays the caller nothing. Fees that nobody collects stay in the Pons escrow and are still there for the next person who calls.