The Bedrock · Dead Claims Stay Dead

What can go wrong

Written to be useful to someone looking for a reason not to buy. If any of it is wrong or out of date, that is a bug and worth telling us about.

Start here

This game is zero-sum, and most buyers lose

The median buyer recovers less than their fee

The stream pays out exactly what the 2% fee takes in, minus the creator’s 15% of the fee. Nothing here creates value: every ETH a winner collects was paid in by another trader. In a replay of the mechanism against a real trading day (The Ladder’s tape, 2,632 swaps, 504.68 ETH), approximately 34% of day-one buyers earned back more than their fee; approximately 22% did over the full tape. The median buyer recovered less than what they paid. After the fee and the rake this is negative-sum across all participants: most people should expect to lose money.

The winners are concentrated by design. In the same simulation, the top tenth of claims — the entries the market never revisited — took approximately 84% of the entire stream. That concentration is decided by survival, not chance: there is no randomness anywhere in the contracts, and it is verifiable from the ClaimPlanted / BandDied events. But it means the realistic outcome for a typical entry is a small, steady loss, and the good outcomes belong to a minority.

What the design claims for itself is only the incidence: losers are breached entries — people who bought local tops — and winners are entries the market never closed below. Whether that transfer is one you want to be on either side of is your call to make before you buy, not after.

What the creator takes

15% of every fee — 0.30% of traded volume — taken when the creator collects their own accrual, never from principal, entry, exit or supply. It is a published immutable constant, it can be renounced to zero one-way, and it can never be raised. The creator holds no tokens: no allocation, no premine, no reserve. But the rake is not the whole creator take — the creator also permanently holds the immortal genesis band, an uncapped second stream detailed in The creator holds the genesis band below. Together the two takes come to about 22.5% of all fees, and that share rises as buyers lose.

The creator’s second take

The creator holds the genesis band

An uncapped insider claim, on top of the 15% rake

Beyond the 15% rake, the creator permanently holds band 0 — the immortal genesis band. The pool launches at genesis tick 184400 and the price can never trade below it, so band 0 can never be breached and never dies. It earns from the same 85% fee stream as every buyer’s claim, at a frozen weight of CREATOR_BAND0_WEIGHT = 1e18 — forever. Every buyer plants only in bands 1 and above, all of which are breachable. No buyer can ever hold an immortal seat.

Replayed against the real trading day — The Ladder’s tape, 2,632 swaps, 504.68 ETH — in sim/creator_band0.py, the two takes together (the 15% rake plus the band-0 stream) come to:

HorizonCreator’s total takeWhy
Full tape~22.5% of all fees the immortal band earns steadily alongside a churning field of buyer claims
Day one~54% of all fees few buyer claims exist yet, so the immortal band takes a large share of a thin stream
In decline→ 100% of the residual as buyers’ bands are breached and die, the one seat that cannot die absorbs the survivors’ stream

This take is uncapped, and it grows precisely when buyers do worst. The 15% rake can be renounced to zero one-way; the genesis band cannot — it is immutable like the rest of the contract. As claims die in a falling market, the band-0 share climbs toward the whole of what is left, because the stream simply divides among fewer survivors and band 0 is the permanent survivor. It is not paid from principal, supply or anyone’s tokens — it is a claim weight in the hook, earning its pro-rata cut of the fee stream like any other claim, that happens never to be able to die.

Why this is on the page and not buried

An immortal insider seat that pays the creator more as ordinary buyers are wiped out is exactly the insider-favouring shape this project’s own FWA detection work exists to flag. It is a deliberate design choice by the author, published here in full — the numbers, the mechanism and the constant name — rather than hidden in the bytecode for someone else to discover. A version of this that was not disclosed would be the FWA pattern; a disclosed one is an accountable choice you can price before you buy. Judge it with the numbers in hand, not after.

The code

This has not been audited by a third party

No third-party audit

An internal adversarial review is run before launch, in the same style as the two prior tokens in this family — fork tests against the live Uniswap contracts, working proof-of-concept attacks, regression tests for every fix. That is a thorough search. It is not a proof, and it is not an audit. The people who wrote the code also reviewed it, which is a known blind spot that no amount of rigour removes. The contracts are immutable: nothing found after launch can be fixed.

Things the review does not cover: formal verification, symbolic execution, a long-horizon fuzzing campaign, and any economic review with real capital at stake. The lineage helps — the fee-skim machinery is reused verbatim from The Sluice and the block-open death guard from The Ladder, both proven on mainnet — but the composition of proven parts is itself new code, and new code is where bugs live.

The ordinary ways

How you lose money

The price can fall

This is a token with a market price. It can go down, including to nearly nothing. You keep whatever tokens you bought, and they can be worth less than you paid. No mechanism here prevents that, and nothing about the design implies the price should rise.

A breached claim is a 2% loss with no consolation

When a block opens below your entry band’s floor, your claim dies — finally. A later recovery does not revive it; buying the band again starts a brand-new claim from zero. The fee you paid is gone into the stream, where it pays the survivors, including whoever’s selling breached you. There is no second chance, no refund and no lottery ticket. The design’s only answer to a breach is “buy lower” — which costs another fee.

Your entry is the price after your buy, not before

A large buy pushes the price up, and the claim it plants sits in the band the price lands in — the higher, more fragile entry your own buy caused. This is deliberate (it stops a whale from planting a deep claim with a shallow buy), but it means a big market buy at a local top is the single worst trade this system offers.

Selling burns your claim

A sell pays the same 2% fee and gives up a matching share of your live claim weight, pro-rata across your entries. You cannot realise your tokens’ price and keep the earning position. If you sell everything, your claims are gone even though the bands never died.

Earnings arrive at the pool’s pace, not yours

Your claim’s income is a pro-rata share of actual trading fees. If trading dries up, live claims earn almost nothing, however good the entry. On a small position, the gas to collect can be a meaningful share of what you earned.

The attack everyone asks about

Can a whale dump to kill your claim? Priced: it loses money

The obvious attack — the assassin whale — sells hard to open a block below rival bands, killing their claims and concentrating the stream on its own deeper entries. We simulated it across whale depths, rival depths, dump sizes and future-volume mixes. It was unprofitable everywhere; the best case for the attacker was a loss of 0.225 ETH. Three costs stack against it — the 2% fee on the dump, the forfeiture of the whale’s own live weight, and the mark-down of its own bag — but the decisive one is structural: the future fee flow it wants to capture arrives as new buys that plant new claims, diluting exactly the share it tried to grow. Buying more weight is strictly cheaper than assassinating, so the attack is dominated.

The residual case, documented

A future made almost entirely of sells would stream fees to the whale without diluting it. But an all-sell future is a falling price, which breaches the whale’s own claims; the simulation stayed unprofitable even at futures that were 80% sells. This residual is an argument from simulation, not a proof, and a sufficiently strange market could sit in a corner the simulation did not. Mainnet is the real test, and one of the pre-registered predictions is precisely that no such attack profits — scored on-chain, not tuned.

An honest corollary: none of this protects your individual claim. The guard makes killing claims unprofitable, not impossible. A whale willing to lose money — or simply a real crash — will still breach your band, and your claim will still be dead. Deaths are the mechanism working, not the mechanism failing.

The related flash attacks fail structurally: death requires the next block to open below the floor, so an atomic flash-loan crash that repays in the same transaction kills nothing, and a flash-loan buy must sell in the same transaction to repay — forfeiting the weight it just planted and paying the fee both ways.

Who owns the claim

Smart wallets, bundlers and Telegram bots may take your claim

The claim goes to the transaction’s signer

Claims are attributed to tx.origin — the externally-owned account that signed the transaction. If your buy reaches the pool inside an ERC-4337 smart-account bundle, through an account-abstraction relayer, or via a Telegram trading bot, the signer is the bundler or the bot’s relayer, and the claim is planted for them, not for you. You still get your tokens; you do not get the earning position, and there is no way to reassign it afterwards.

This is not hypothetical. Measured on The Ladder’s real trading tape, 866 actual traders sat behind 465 distinct signers, and approximately 49% of hypothetical claim credit would have gone to bundlers and bot relayers rather than to the people whose money it was. An optional self-designation override for smart wallets (a hookData field naming the beneficiary) is the planned mitigation; the default remains the signer. Until you have verified how your wallet routes swaps, buy from an ordinary EOA wallet through an ordinary router.

What is behind the price

The marked value is mostly not backed by anything

The pool launches with the full fixed supply and zero ETH — the starting fully-diluted value is about 9.82 ETH. The only ETH behind the token at any later price is what buyers have paid in on the way up, so the market cap you can compute from the price is not money that exists. This is the same arithmetic published for The Ladder, where the backing ratio settles near 11% and does not improve as the price climbs.

Selling walks the price back down

There is no separate bid. Every sale pushes the price down through the liquidity it came up, so what an exit realises depends entirely on how early it is: the first sellers out get most of the marked price, the last get a few percent of it. This follows from a one-sided pool and applies to any token launched this way. The price you see is not the price you can all leave at — and here, every step of that walk down is also killing claims as it goes.

Known issues

Things we know about and did not fix

If every buyer band dies, the residual flows to the creator’s band 0

The creator’s band 0 is immortal — it can never be breached and never dies — so totalLiveWeight is never zero and the escrow branch is unreachable. When every buyer band dies — everything from band 1 up breached — the residual fee stream does not escrow, and it does not pass to a future buyer; it flows to the creator’s band 0, the one seat that cannot die. This is the immortal seat detailed under The creator holds the genesis band: as buyers’ claims are wiped out, band 0’s share climbs toward 100% of what is left.

A very fast crash sweeps deaths over several blocks, and a doomed claim can over-collect a little

Death processing is capped at 8 bands per block, with carry-over, so gas cannot run away in a crash. A move through more than 8 bands in one block settles its remaining deaths over the following blocks. No claim escapes — the deaths land a block or two late — but during those blocks a doomed claim is still counted as live, and if its holder calls collect() in that gap they are paid up to the current rate rather than frozen at the moment of death. This is dilution, not insolvency: the doomed weight is still in the denominator when the fee is shared, so what it collects comes out of the survivors' rate, never out of anyone's principal — an adversarial solvency test (test/SolvencyDrip.t.sol) proves the contract balance always covers every claim. The most a single doomed claim was measured taking from survivors this way is about 0.026 ETH in a deep multi-block cascade; it is bounded by the 8-band sweep cap and is small next to typical claim sizes.

The front end trusts whatever node it reads from

The numbers on the app are computed from data supplied by an RPC endpoint, which is a different trust domain from the wallet that signs. A hostile or compromised node can make things look better than they are. The app simulates every transaction before sending and refuses to send to an address with no code, but a client-side check cannot fully solve this. Use your own node if you have one.

Outside our control

Things that can change without us

Contract addresses

The token is named THEBEDROCK.FUN on chain, ticker BDRK. It is not deployed yet — this page goes live with the pool. When it deploys, the verified addresses will be listed here and in deploy.json, and each contract will name this site in its WEBSITE() function. The contracts will be immutable: no owner, no admin, no upgrade path, no pause.

Token — THEBEDROCK.FUN (BDRK)
0x0000000000000000000000000000000000000000 (placeholder)
Hook — BedrockHook (claims, bands, stream, collect)
0x0000000000000000000000000000000000000000 (placeholder)