How $FLUKE actually works.

All fees in WETH. The hook never touches $FLUKE.

The fee is taken by the pool itself, not by a separate contract you have to trust. It comes off the WETH side of every swap — out of the WETH you pay on a buy, out of the WETH you receive on a sell. The contract never holds $FLUKE and has no code that sells it, so nothing here can dump on you.

Under the hood: a Uniswap v4 hook using the custom-accounting path (BeforeSwapDelta). The money being swapped and the money taken as fees are separate by construction, not by policy.

That's 90% of every fee going back into the coin — pots and burn. The remaining 10% of sell fees is the treasury, and it deserves its own explanation:

The timelock tunes odds. It never touches money.

Everything the contract owes — the pots, the treasury, money waiting to burn, prizes not yet paid — is tracked in one ledger of obligations. The test suite proves that nothing the owner can reach is able to move any of it. Not some of it. Any of it.

• No rescue function. No pot sweep. No skim. There is no code path by which the deployer, the keeper, or the timelock extracts pot money.
• Payouts only via wins. Pot solvency is an invariant: money leaves a pot through a settled, beacon-verified win and nothing else.
• Your money is not our money. The fee system can never touch the funds you are swapping, and pot, treasury and liquidity balances are kept strictly apart. (Mixing those two up produced both high-severity findings in a comparable project's audit — it is why the separation is an invariant here, not a convention.)
• What the 48-hour timelock can change: pot split, cadences, floors, caps, κ, the nomination window, the multiplier schedule, the prize whitelists, the stock rail switch. Every change is public for 48 hours before it takes effect — and none of these are balances.
• What nothing can change: the fee routing to an owner's benefit, the burn vault, the signature check in settlement, the liability ledger.

Pots size themselves to real volume.

Each pot has a live target — the number on the board. A pot is in play when its balance reaches its target; prize = the target (or the balance, if a same-round earlier win left it short). Targets follow fee inflow:

EWMA_daily_inflow is a weighted average of the last week or so of daily fee inflow (recent days count more; a day from a week ago counts half). Today's trading never lifts today's target — so a burst of coordinated buying can't inflate a pot and then win it in the same hour.

*The stock switch sits behind the 48 h timelock, so the deploy is sequenced: it is queued at deploy and matured before the pool opens — the rail is on from the first swap. A stock leg that cannot fill delivers WETH instead.

†The meme switch sits behind the same 48 h timelock and is sequenced the same way: queued at deploy, matured before the pool opens (each venue re-verified first), so the meme rail is on from the first buy. Same fallback rule — a leg that cannot fill pays WETH; nothing is ever withheld.

*And be clear about what a tokenized stock IS: a third-party token that tracks a share price, not a brokerage share — no voting rights, no dividends. Its issuer keeps admin powers this protocol cannot override: pause, wallet blocklist, contract upgrade, and burning tokens already in a winner's wallet. The issuer also restricts who may hold them, including US and Canadian residents. A TENDIES win is custody of that token, with that token's rules. Terms & eligibility has the full statement.

• Below the floor, the prize stays at the floor and the pot simply pays less often. It never pays a smaller amount than the floor.
• Between floor and cap, the prize grows with volume at its cadence.
• At the cap, the pot pays more often instead of bigger. A cap never stalls a pot.
• Overflow: a pot holding more than 48× its target routes further inflow to FEAST — when the small pots overflow, the surplus goes to the holders. FEAST's own overflow goes to burn.

Dollar targets on a WETH pot read off a keeper-published rate: at most one update per hour, at most ±25% per update, inside an immutable floor and ceiling.

Same odds per dollar, for everyone — up to the caps.

In words: your win probability is your buy size, times a fixed constant (κ), times the pot's share of fees, divided by the pot's current prize. Bigger buy → better odds, until the caps in the formula bite. Bigger prize → longer odds — which also means a fat pot doesn't pay better odds; it pays a bigger prize at the same odds per dollar. There is no clever moment to buy; the dashboard just shows when the prize is worth watching. The rules:

• Eligible buy: $5 minimum, at most one fetch per wallet per hour. A $5 fetch at the launch BONE target is about 1 in 1,825 — small, and shown exactly before you buy.
• The caps mean the fetch is deliberately the small buyer's game. 25% odds cap per pot, and a buy counts at most 3% of the pool's depth: at a $100 BONE target every buy above ~$2,300 caps out, and past the depth cap a bigger buy adds no odds at all. A very large buy gets a fraction of the small buyer's odds per dollar — on purpose (it's also what makes buy-bot farming pointless). The excess fees a big buy pays flow to the holders' pot — and that is where size wins: the feast draw is weighted by bag × time, so the large holder's edge is the weekly draw, not the fetch. Both caps are shown in the exact odds quoted before every buy.
• Odds are pinned at commit against the round's frozen context (targets, rate, config) — fixed before the randomness that decides them exists. The commit and resolve events carry the exact probability used, so anyone can recheck it.
• No streak bonuses, no luck multipliers, no gates. Earlier designs had them. When we replayed those designs against real chain trading data, a 20-wallet bot farm earned 3.3× its fees by farming the bonuses — so they were removed. In the final design, splitting money across many wallets earns exactly nothing.

Worked example at launch-scale volume ($100k/day): a $100 buy is about 1 in 91 on BONE and 1 in 964 on TENDIES — roughly one buy in 83 is a fluke. The board shows the live figures for your exact buy before you swap.

Ticket = bag × time. Nothing else counts.

• bag₁₄ is the coins you've held for at least 14 days — your smallest balance in the window, read from the token's own checkpoints.
• M steps with your wallet's hold clock: 1× at day 14, 2× at day 30, 3.5× at day 60, 5× at day 90 and after.
• Any balance decrease resets the clock to zero — a sell, a transfer out, any amount. A top-up keeps your clock, but the new coins need their own 14 days before they join the bag.
• While the pot is at target, anyone can arm the weekly draw (the keeper does). When the beacon round lands, every eligible wallet has a score — keccak(randomness, drawId, wallet) weighted by its ticket — and the best score wins. The math (an "exponential race") makes the chance of holding the best score exactly your ticket's share of all tickets.
• For 48 hours, anyone can nominate the winner — the keeper does it as a matter of course, and if it ever nominated the wrong wallet, one transaction from anyone (the real winner most of all) corrects it: the contract only ever accepts a better score. Then the draw settles and one holder is paid the full prize in WETH. No sign-up step, no owner-controlled winner list, no draw that splits the feast.

Why sybil games don't work

Split your bag across 10 wallets and you hold 10 tickets, each with a tenth of the odds — the same overall chance, minus the gas you paid to split. Buying big the day before a draw earns nothing for 14 days. Running bots changes nothing: a bot's bag is just a bag. The wallet that has held the most, longest, holds the biggest ticket — that is the design working as intended.

The winning number doesn't exist when you enter.

Randomness comes from drand quicknet — a public randomness service run by a group of independent organizations (universities, infrastructure companies), publishing a cryptographically signed random value every 3 seconds. No single member can predict or steer the output. The flow:

• Your entry commits to beacon round head + 2 — a round whose value has not been produced yet, by anyone, anywhere.
• When the round lands, the contract verifies drand's signature itself, on-chain (BLS verification via the chain's built-in precompiles). A bad or forged signature cannot settle anything. There is no trusted oracle in the path — the relay service only delivers drand's bytes to the chain; it cannot invent or alter them.
• If the relay lags or dies: while it lags, new entries simply target a round slightly further in the future (a timelocked safety margin), so the lag can't be exploited. If it's fully down for 30+ minutes, new entries pause — but anything already pending can always settle or be cancelled. Nobody's entry is ever stuck.

Sellers shrink the supply.

• 25% of every sell fee accrues as WETH in the BurnVault — an immutable contract with no owner, no setters, no upgrade path.
• Once ≥ 0.01 ETH has accrued, anyone can call burn(): the vault buys $FLUKE on the canonical pool — at most 1% of the pool's WETH-side depth per call, stopping at ~1% price impact — and burns what it bought. Unspent WETH waits for the next call.
• The vault's buy is exempt at the hook: no fee recycling, no entry, no effect on pot averages. It holds $FLUKE for the length of one transaction and has no code path to sell.
• Each FEAST draw pins its tickets at arming — and tickets have no supply term at all — so a burn can never change a draw that's already in flight — burns raise every holder's odds from the next draw.
• Sandwiching the burn buy caps out at the ~1% impact bound and costs the attacker the hook's own 1% + 3% fees to try.

The whole supply is the liquidity. Forever.

$FLUKE trades on one canonical Uniswap v4 pool against WETH, with the hook attached. There is no liquidity program and no farming — liquidity is handled entirely by the contracts, three ways:

• The launch position is the supply. At launch, the entire token supply enters the pool as liquidity. No team allocation sits outside the pool; the only way anyone holds $FLUKE is by having bought it.
• There is no withdraw function. The launch position lives in a contract with no remove and no collect code. This is stronger than a third-party locker with an unlock date and an admin key: the code to pull the liquidity does not exist, so nobody can pull it. Including the team.
• The pool deepens as the coin grows. There is no LP fee — the pool charges zero, so a round trip is the 1% buy and the 3% sell and not a basis point more. Depth still grows on its own: the launch position starts as pure $FLUKE, so every net buy leaves its ETH behind inside it. Depth works out to the geometric mean of the launch valuation and the current one, which also loosens the 3% depth cap on odds (§04) as the coin grows.

Why a copycat pool can't drain it

The token's leak guard means $FLUKE leaves the canonical pool only through a real buy. Someone can create a fake second pool and sell into it, but nobody can buy $FLUKE out of the real pool through it, and wrapped or claimed balances can't be cashed out around the hook. Every real trade passes through the one pool where the hook runs.

What runs the machine, and what it costs.

Of the 3% sell fee, 10% is the treasury — about 0.14% of trading volume, and 7.3% of every fee the coin collects. There is no treasury cut on a buy at all: a buy’s whole 1% goes to the pots.

It cannot be raised. The 10% is a constant compiled into the contract, not a setting. The timelock can retune odds, cadences and payout lists; it cannot touch this. Changing it would take a new token.

A mechanism like this doesn’t run itself for free, and pretending otherwise is how projects quietly die. It pays for:

• People — community artists, Telegram admins, content creators. Paid, not “contributing”; volunteers leave.
• Tools — AI subscriptions, design software, the things this is built with.
• The machine — the keeper, RPC nodes, hosting, and the drand relay, which is the one cost we can price to the dollar: about $841 a year of gas (§07). It is the smallest line here, not the biggest.
• Ongoing review, which does not stop at launch.
• What comes next — there is more planned than this launch, and building it costs money.

It is uncapped: being a share of volume, it is large when the coin is busy and small when it is quiet. It is structurally separate from prize money — treasury accounting cannot reach pot balances, principal or escrow (§02). And it is on chain: the address, the balance and every movement are public.

The limit, plainly: we do not publish an itemised budget. You can watch what the treasury holds and what leaves it; you cannot see which artist was paid what. The number to hold us to is the one in the code rather than on trust — 10% of the sell fee, fixed.

What's modelled vs what's guaranteed.

Payout frequencies below come from replaying the mechanism over 108 days of real chain trade data, at several volume levels. They're what the math does to real order flow — they are not a promise of any payout, ever. What is guaranteed: the probability shown at your entry is the probability used at settlement.

At launch the pots start empty. Under this ladder the first BONE pays within the first hour of real volume, TENDIES on day 0–1, and FEAST draws begin on day 14 — the launch surge and the small pots' overflow accumulate in FEAST until then, so the first feast belongs to everyone who held from day one.

You don't have to trust this site.

Improbable is not the same as unaccountable. Every fluke settles against a drand round nobody could see when the buy was made, and anyone can recompute it afterwards. The odds are long; the outcome is not loose.

Every settled fetch emits its inputs: the buy, the pinned probability, the beacon round, the outcome. The verify page takes any receipt and, in your browser:

• recomputes the probability from the round's frozen context,
• fetches the drand round and checks its BLS signature against the beacon's public key,
• recomputes the outcome and compares it to what the contract paid.

If any of that ever disagrees with the chain, the page shows the mismatch. Contract addresses, the spec, and the full review history are linked below.