FOMO4D: A Perpetual Countdown Auction with
Deflationary Token Coupling on Uniswap v4

Mechanism design, settlement accounting, and distributional analysis

FOMO4D Working Group · Revision 1.0 · August 2026
www.fomo4d.app · @fomo4d_RH

1 Introduction

FOMO4D descends from the 2018 experiment Fomo3D, which demonstrated that a countdown auction with continuous dividend distribution can sustain adversarial participation at scale for months.¹ The present design retains the original's economic skeleton — a rising key curve, a resettable countdown, team-parameterized revenue splits, and a terminal pot — and departs from it in three respects. First, the game is coupled at the protocol layer to a tradable asset, $4D, through a mandatory burn leg: every purchase spends 20% of its value buying and destroying $4D. Second, the game is single-round and terminal: there is no seed for a successor round, and settlement distributes the entire pot. Third, the game holds no upgrade path and no pause switch, and the liquidity backing $4D cannot be removed by any party.

One privilege does exist and is stated here rather than buried: an owner address can call emergencyWithdrawAll and move the contract's entire BNB balance out. It exists so that funds can be pulled ahead of an attacker mid-exploit. It cannot be constrained in code to that purpose — a contract cannot tell an attack from avarice — so it is a trust assumption, not a safety mechanism. Two things make it checkable rather than merely promised: every call emits EmergencyWithdrawn with the amount and destination, and the function touches nothing else — the clock, the flag, every key balance and vault survive untouched, so the funds can be sent back and the round resumes as if nothing happened. The privilege can be renounced permanently by calling transferOwner(address(0)).

Throughout, monetary quantities are denominated in BNB. The system deploys two contracts: Fomo4DGameV2 (all game logic) and TokenBuyer (the burn leg's execution path). Three more are external and not ours to control: $4D is issued by the BSC liquidity venue, which also creates its bonding curve and, on graduation, its Uniswap v4 pool. Fomo4DPlayerBook — the referral identity layer — is reused from the first round, so names registered then still resolve.

Delegating the token to the BSC liquidity venue is a deliberate reduction. The first round minted its own ERC-20, ran its own v4 hook for fee capture and liquidity locking, and carried a Zap periphery so holders could pay the burn leg in kind. That put an AMM integration, a fee pipeline and a second purchase entrypoint inside the game contract, and each of those needed its own answer to "who is the real buyer". The second round asks that question once and answers it msg.sender. The contract went from 16,370 bytes to 7,956.

2 The Key Auction

2.1 Price curve

Keys are priced along the affine curve inherited verbatim from the original contract:

with a = 74,999,921,875,000 wei (≈ 7.5×10⁻⁵ BNB) and b = 156,250,000 wei (≈ 1.56×10⁻¹⁰ BNB), where k is the number of whole keys already sold. Integrating (1), cumulative spend C and outstanding keys K satisfy the closed forms

so the marginal price is monotone non-decreasing in inflow: no later entrant ever pays less than an earlier one. Because the original constants were calibrated for a round two orders of magnitude larger, the curve has a long flat region: prices remain within a factor of two of a until C ≈ a²∕2b = 18 BNB. Early participation is therefore approximately egalitarian by construction, which suppresses the profitability of launch sniping on the key side (§9.2).

2.2 Properties of a key

Capital committed to keys is recovered only through dividends and terminal settlement; the curve price of a key is not a redemption value. The liquid side of the system is $4D (§3).

2.3 Payment decomposition

Every purchase of value v decomposes at execution time as follows: 20% of v is spent in the same transaction market-buying $4D, which is then burned; the remaining 80% (the BNB leg) splits into a 10% referral commission (paid only to a registered referrer, otherwise redirected to the pot, §6), a 2% team allocation, and an 88% residual divided between the dividend and pot accounts according to the buyer's team selection:

Team choice affects only this split, never the number of keys received. In the 2018 round, between 83% and 91% of capital selected the maximum-dividend team; the presence of four options is best understood as expressive rather than strategic.¹

The interface presents this decomposition as an 80/20 rule: each key is paid for with 80% BNB and 20% $4D. There is one way to pay it — all BNB, through buyKey — and the contract acquires and burns the $4D leg itself. A player never has to hold $4D to play.

The burn leg is dispatched through TokenBuyer, and its failure is contained there: the call is made low-level and any failure returns the BNB to a queue for the next attempt rather than reverting the purchase. The reasoning is that buying $4D touches state the game does not control — the BSC liquidity venue's curve, its graduation, its pool — and a player's purchase should not be hostage to it. The queue also batches: below 0.001 BNB no purchase is dispatched, since a single burn costs roughly 400k gas and burning dust individually is not worth it. What the contract guarantees is not that every buy burns, but that every wei of the burn leg is either burned or still queued.

2.4 Early-inflow cap

Until cumulative inflow reaches 50 BNB, each address may spend at most 2 BNB on keys. The excess of an over-limit purchase is not refunded but credited to the buyer's withdrawable vault, so the transaction never reverts. The cap widens the early holder set during the flat region of the curve — the window in which position, not price, is the scarce resource.

3 The $4D Token

3.1 Issuance

$4D is issued through the BSC liquidity venue, a launch platform on the same chain, rather than minted by this project. The entire supply S = 10⁹ is created at launch and deposited into a bonding curve; trading opens on that curve immediately. Once cumulative real inflow reaches the graduation threshold (4.2 BNB), the curve closes and its reserves seed a Uniswap v4 pool whose liquidity is locked permanently. The token is a standard ERC20Burnable, which is what lets the burn leg destroy supply rather than merely park it at a dead address.

Graduation proceeds in three phases — NotGraduated → Swept → PoolCreated — and the curve marks itself graduated at the second, before the pool exists. That interval is a real state, not a theoretical one, and it is where a naive integration breaks: the curve refuses trades and the pool cannot yet be traded against. TokenBuyer detects it and completes the graduation itself; the call that does so is permissionless and retryable, so the first buyer to arrive during the window simply pushes it through on the way past.

Delegating issuance costs the project the ability to set the curve's shape, the supply, or the graduation threshold — all are fixed by the platform's configuration. It buys, in exchange, a liquidity lock the project cannot revoke even if it wanted to, a trading venue that exists independently of this game, and one less contract to get wrong.

3.2 The burn leg

The 20% burn executes at prevailing market prices with no oracle, no TWAP, and no fixed token schedule. The buyer's bill is fixed in BNB by the key curve; price movement can perturb only the number of tokens burned — a quantity with no private beneficiary, which is what removes the flash-loan attack surface.

Where the purchase lands depends on where the token is in its life. Before graduation TokenBuyer buys on the BSC liquidity venue's bonding curve; after it, through the graduated v4 pool. The choice is read fresh on every call rather than cached, because graduation can be triggered by the very purchase being made. Whichever path runs, the tokens are acquired and then destroyed with burn(): totalSupply falls, which is a stronger claim than transferring to a dead address and one the first round's own token could not make.

Burns are batched — the queue must reach 0.001 BNB before a purchase is dispatched — and a permissionless pokeBurnQueue() drains it otherwise. Anything that goes wrong downstream delays the burn without touching the purchase.

3.3 Utility summary

• Second leg of every key. 20% of all game inflow is forced, price-insensitive buy pressure on $4D, immediately destroyed — supply is strictly non-increasing.
• Deflationary by construction. Every key ever bought destroys supply, and the contract publishes the running total, so the claim is checkable rather than asserted.
• Exposure without playing. $4D is the instrument for participants who want price exposure to the game's activity without entering the auction. Its liquidity is locked by the BSC liquidity venue and cannot be withdrawn by this project.

3.4 Trading fees

Trading fees on $4D are charged by the BSC liquidity venue, not by this project, and they do not pass through the game contract at all. the BSC liquidity venue takes a base fee on the curve and, after graduation, through its own hook; the creator's share of that — plus the optional creator tax fixed at launch — is paid directly to the wallet registered at issuance. Nothing reaches the pot on its own.

It can still get there by hand. donateToPot takes BNB and adds it to the pot, where it is distributed by the terminal split like any other pot balance; the team uses it to return trading-fee revenue at its own discretion. The interface offers no button for it — a donation is an operational act, not a move in the game — but the function is permissionless rather than team-only on purpose: the pot only ever takes money in, so letting anyone contribute costs nothing, while restricting it would turn "did the team actually send the fees back" into a matter of trust. As written it is a matter of record — PotDonated carries the amount and the sender.

This is a departure from the first round, which ran its own hook, bucketed swap fees 80/20 into pot and team, and swept the pot's share in at settlement. That arrangement gave the pot a second income stream, but it also meant the number a reader saw on the game contract was not the whole one — the page had to add the unswept balance back to explain itself. Here the pot is what the contract says it is, the fee income is visibly the team's, and any of it that returns does so as a transaction anyone can point at.

Remark (no fee-to-dividend leg). An earlier revision of the first round routed 40% of trading fees into the dividend mask. Audit demonstrated the mechanism is unsalvageable in principle: masks pay "holders at the instant of accrual," so any actor who can influence the pull timing — by nesting the purchase inside their own pool unlock, or by buying dust while K = 0 — captures the accumulated stream (measured instances: 14.0 BNB in one transaction; a 0.0001 BNB purchase returning 7.6 BNB). The lesson generalizes past the specific bug: any income stream a mask can be made to pay out on demand is a lever, and the safest place for fee revenue is outside the game's accounting entirely — which is where it now sits.

4 The Countdown and the Liveness Condition

The clock initializes at T_init = 3 h. Each whole key purchased adds T_inc = 30 s, capped at T_max = 6 h beyond the present. The purchaser of the most recent whole key holds the flag. The game ends only when the clock reaches zero — that is, when no participant anywhere buys a single whole key for a full T_max window. Sustained life requires

which is 0.22 BNB/day at genesis and grows only as √C (≈ 1.6 BNB/day after 1000 BNB of inflow). The heartbeat is deliberately cheap: a perpetual game means perpetual dividends and perpetual burn pressure, and the pot is positioned as an eventual jackpot rather than a scheduled event.

5 Dividend Accounting

Dividends derive from a single pipeline: the gen leg of subsequent purchases. Accounting is the original's global-mask scheme, O(1) per operation:

where M is the global mask, d a dividend event, and (k_i, m_i) player i's key count and personal mask. Rounding dust accrues to the pot. All balances — dividends, referral commissions, winner's prize, and purchase credits — are held in pull-model vaults released only by the owner's withdraw(). There is deliberately no reinvest(): compounding is withdraw followed by buyKey, keeping mask settlement and key minting on disjoint code paths.

6 The Referral Identity Layer

A 10% commission on the BNB leg of every purchase is payable to the purchaser's bound referrer. Binding and eligibility are separated in time. A referrer address binds at purchase (and persists until overwritten), but the commission pays out only if the referrer holds a registered name in Fomo4DPlayerBook at the moment of each payment; otherwise that 10% joins the pot. Registration costs 0.01 BNB — paid in full to the immutable team address — and names (lowercase a–z0–9_, 1–32 characters) are unique, permanent, and limited to one per address. Late registration retroactively activates existing bindings from that point forward.

The fee is a filter, not a wall: a registrant recoups it after referring 0.125 BNB of volume, and self-referral through a second wallet is not preventable — for a sophisticated participant the referral program is, in effect, an 8% rebate (§9.3). The layer's actual functions are spam reduction, a human-readable link namespace (?ref=alice), and team revenue.

7 Termination and Settlement

When the clock lapses, any address may call finalize(); the winner's own withdraw() performs an inline finalization first, so settlement depends on no third party. The sequence is fixed: (i) route any residual burn queue to the team vault — routing it to the pot would let the terminal buyer manufacture failed burns as a self-rebate; (ii) distribute:

There is no next-round seed. If the game terminates with zero keys ever sold (a token market that never produced a player), the pot routes to an immutable post-game receiver. After termination, purchases revert, the pool persists indefinitely, subsequent trading fees accrue to the team address, and vault claims never expire — the cost, and the proof, of having no administrative sweep function.

8 The Economic Flywheel

The mechanisms of §§2–7 are not independent features; they compose into a closed loop of three mutually reinforcing flywheels, each of which generates the demand that powers the next (Figure 1). This closure is the design's central claim: no single component needs external subsidy, because every component's output is another component's input.

8.1 Flywheel Ⅰ — the token market funds the pot

Every $4D swap, in either direction, pays a 2% BNB-side fee of which 80% accrues to the pot (§3.4). The jackpot therefore grows continuously and autonomously: speculation, market making, and ordinary trading on $4D all convert into prize capital, whether or not a single key is sold that day. The pot is not funded by emissions or by a treasury — it is funded by the token's own economic activity.

8.2 Flywheel Ⅱ — the auction is a perpetual buyback-and-burn engine

Twenty percent of every key purchase market-buys $4D at prevailing prices and destroys it (§3.2). Auction demand is thus mechanically transmuted into price-insensitive token demand plus strict supply contraction. Rising auction activity pushes the token up its curve; supply only ever shrinks. The flywheel's earliest turns are funded by organic volume alone — there is no launch-window subsidy standing in for it.

8.3 Flywheel Ⅲ — key yield closes the loop

A key is a productive asset from the moment of purchase: it earns a pro-rata share of the gen leg of every subsequent purchase (§5), a claim on 50% of the pot at termination, and — for the final buyer — the 48% jackpot itself. The growing pot from Flywheel Ⅰ raises the value of both terminal claims, drawing new key demand; that demand extends the clock, deepens the dividend stream for incumbents, and spins Flywheel Ⅱ. The loop closes: fees fill the pot, the pot sells keys, keys burn the token, and the token's market generates the fees.

The heartbeat condition (Eq. 4) quantifies the loop's persistence: a day's clock costs 2880 keys, under 2 BNB of inflow even at a thousandfold scale — while the same day's trading fees, dividends, and burn all compound regardless. The system is engineered so that its resting state is running.

9 Robustness under Adversarial Play

A mechanism that redistributes value will be probed by sophisticated actors. FOMO4D's approach is to price adversarial behavior so that its proceeds flow back into the loop of §8, rather than to promise prevention. Four dynamics are analyzed and absorbed by design.

9.1 The terminal race

The flag in the final seconds is worth up to 48% of the pot against the marginal cost of one key, so the closing blocks resolve as a speed competition among automated participants. The deployment chain's first-come-first-served ordering without a public mempool makes this a clean latency race — no bribery auction, no reordering games — and every competing bid in that race is itself a key purchase: it extends the clock, pays dividends to all holders, and burns $4D. The endgame contest, whoever wins it, is revenue for the system.

9.2 Launch accumulation

Early accumulation of $4D is rational and expected. The design meets it economically: the per-address cap of 2 BNB, in force until 50 BNB of cumulative inflow, raises the marginal cost of launch-window concentration without pretending to prevent it. Independently, the flat region of the key curve (§2.1) keeps early auction entry approximately egalitarian. Accumulation pays a toll that funds the game; it is a revenue source, not a threat.

9.3 Self-referral

A participant operating two addresses can direct their own 10% referral leg to themselves after a one-time 0.01 BNB registration. The identity layer is therefore priced as a filter and a namespace, not a wall: it deters casual misuse, gives every serious participant a shareable handle (?ref=alice), and converts registration into protocol revenue. Where self-referral occurs, the rebate simply functions as a volume discount for committed players — capital that is, by construction, already inside the loop.

9.4 Early-inflow capping

The 2 BNB per-address cap (§2.4) raises the marginal cost of concentration during the flat region of the curve — each additional tranche requires a fresh address and its own gas — which widens the early holder set that Flywheel Ⅲ pays dividends to. The cap self-retires once inflow reaches 50 BNB and the curve itself begins pricing position.

10 Parameters

11 Verifiability

Every claim in this document reduces to a contract read: curve constants and splits are public constants; pot, inflow, key totals and the cumulative burn are public state; the liquidity lock is the BSC liquidity venue's, not ours, and readable on its factory. Governance is one function wide — emergencyWithdrawAll, described in §1 — and owner() says who holds it, or reads as the zero address once it has been renounced. The interface reads all of this directly from the chain, including the $4D price, which comes from the BSC liquidity venue's curve rather than a local model, so what it displays is the contract's own state rather than a projection of it.