D4L - Platform Rules & Mechanics

This document states the platform's rules exactly as they are implemented today, for verification. It is organized by subsystem - smart-contract rules, backend rules, and the real-time/gamified layer - with the real numbers, in plain English, no code.

Three conventions used throughout:

Where the live testnet is currently running a different value from the intended production rule, both are shown, marked Live testnet:.
Passages revised in the 2026-07-16 update - the optional KYC "verified" badge and its own-the-data model, gas moving from platform-sponsored to user-paid in USDC, sign-in with an external wallet, the shift of the holder-gate Sybil defense onto the anti-snipe fee plus a minimum-balance-to-count rule, the manipulation-hardening of the battle price oracle, a testnet development build of prediction markets, and holding-based governance (earning governance by holding real tokens) - are highlighted in blue where they appear. Each highlighted block is stamped with the date it was added (you will see an "Added 2026-07-16" tag on it), so you can skim straight to anything dated later than the last time you reviewed instead of re-reading blue you have already seen. (The 2026-07-14 changes below have already been reviewed and are no longer highlighted.)
The ENTIRE immutability question - current state, what can change, what cannot, how, the regulatory verdicts with sources - lives in exactly ONE section: "Immutability & evolution" - deliberately placed FIRST, before the mechanics, because it governs what can be done with everything that follows (full analysis in D4L_REGULATORY_MUTABILITY_ANALYSIS.md). Where a specific rule elsewhere is changeable, that rule's own text says so in a sentence and points there - no second treatment anywhere. Open decisions are marked OPEN DECISION #N; the final section keeps the live-status snapshot, a one-line index of the open decisions, and cross-cutting items.

Everything below was verified against the current contracts, backend, and the live Base Sepolia deployment (Charter v2, d4l-base-sepolia-charter-v2; its user-facing trading surface is byte-identical to the earlier d4l-base-sepolia-v4 suite, now with the bounded parameter registry underneath).

What changed in the 2026-07-16 update - so nobody has to re-read the whole document

Everything already reviewed still stands; these are the ONLY changes, and each is also highlighted in blue where it appears.
A new optional KYC "verified" badge (Section 8): identity verification (a government ID plus a face/liveness match) earns a display-only "verified" mark that gates nothing; D4L owns the resulting data outright on the exchange (Coinbase/Kraken) model, keeps the identity record and purges the biometric fast, protects the per-check verification bill from junk-submission abuse (with an approved-only-billing fallback vendor held in reserve), and the whole data-holding posture is added to the counsel list.
Gas is moving from platform-sponsored to user-paid in USDC (Section 7): users still never need ETH, but they now pay their own network fee in USDC through a self-configured paymaster, with no platform subsidy (built and config-gated; the live app still sponsors until it is deployed, switched on, and tested).
Sign-in with an external wallet (Section 7): a user can log in with their own wallet, which becomes a credential over an auto-provisioned smart account that does the trading; those users trade on the same path and count as holders, but leaderboards and governance stay account-tier-only.
Sybil resistance for the 50-holder gate changed (Section 5): external wallets buy the curve freely and count as holders; the defense now leans on the anti-snipe launch fee plus a minimum-balance-to-count rule, not a registered-platform-wallet-only buy gate. The separate launch-signing gate is unchanged (OPEN DECISION #10).
The battle price oracle is now hardened against manipulation (Sections 3 and 4): the price a battle scores on is a trailing time-average with a per-block cap on how far any single block can move it, so faking a battle result - or a de-graduation re-list price - now means sustaining a false price across many blocks at real, escalating cost. The per-block cap was sized by an out-of-band cost simulation, and the de-graduation re-list price also gained a lower floor.
A testnet build of prediction markets now exists (Section 6): the parimutuel forecasting mechanic - stake the in-game currency on a battle outcome, winners split the pool - is built and in internal testnet testing; rolling it into the live app is planned.

What changed in the 2026-07-14 update - so nobody has to re-read the whole document

Everything already reviewed still stands; these are the ONLY changes, and each is also highlighted in blue where it appears.
The graduated exchange is moving to Uniswap v4 with D4L's own pool hook (built + in testing; deploys with the next contract release - the live venue is still Curve): this lets us set our own custom pool values, and it turns the exchange, the battle price source, and the scoring rule into settings we can re-tune later without a factory reset (see "Immutability & evolution"; Sections 3 and 4; "Where the money goes").
Governance is now earned, not bought: the per-realm "Proof of Culture" model replaces the old buy-a-badge-to-vote (Section 6).
Built (staged) a bot-filtered "shadow price": a display price that strips out bot and wash trading, kept entirely separate from the price money settles on (Section 5).
4GRUDGE was redesigned: the winner is decided by dollar market-cap gain, the vote is earned and eligibility-gated, and the winner lands on the ladder at the closest-average-market-cap level (Section 9).
The token supply split is flagged as the one identity constant deliberately kept un-tunable (see "Immutability & evolution").

Immutability & evolution - the strategy for changing as much as we can, without redeploying, within regulatory bounds

This section covers the strategy for how much we can change in a token's lifecycle, WHEN in that lifecycle each thing can change, and how we do all of it while staying inside regulatory bounds. Its purpose is practical: for any change we might ever want to make, this section tells you its disruption level - a one-transaction registry update, a single-contract deploy, or a full factory reset - so it is clear in advance which changes are cheap and which would shake the whole platform. Everything here is written to be verified: the regulatory claims carry their sources, and the mechanisms are standard, well-established smart-contract patterns - the contracts can be constructed exactly as described.

Here is why this matters so much. This platform is a new idea - nobody has run a system of launch curves, graduations, and token battles before - so it is likely, maybe even early on, that numbers and rules will need to change once real data comes in. And we want to make those changes WITHOUT a full factory reset. Terminology, used consistently below - there are three sizes of change, and they must never be confused:

A factory reset: deploying a whole new ecosystem of core contracts (the launch factory, its paired vault, re-pointing the site). A whole new version of the platform: large changes, heavy re-testing, and real frontend complexity, because the site then has to keep working with the older versions alongside the new one. This is what we are trying to avoid.
A single-contract deploy: publishing ONE new contract (for example, one new ladder) and aiming a pointer at it. Small, cheap, nothing else redeploys.
A registry update: changing a number in the settings registry. One transaction. This is the goal state for every tunable value.

One distinction to understand before the table, because it explains why some rows need a deploy and others never do - values versus code:

Every smart contract has two parts. Its CODE is frozen forever the instant the contract is deployed - nothing and nobody can ever edit it; that is the immutability of smart contracts. Its STORAGE holds values the code is built to read and write, and storage is meant to change - that is what it is for.

The settings registry is a contract whose code does exactly one thing: hold named values, and let the authorized key update them - only within the hard-coded ranges, only after the public waiting period. Every plain NUMBER (a fee, a gate, a floor) is a value in the registry's storage. Changing it is one transaction that overwrites the stored value; no new contract comes into existence anywhere.

A FORMULA is not a value - it is code, and on the blockchain, code exists only as a deployed contract. So a new curve formula must be deployed once as its own contract, and what the registry stores is that contract's ADDRESS - which is itself just a value, so making the new formula current is once again a one-transaction registry update.

Rule of thumb: if it can be written down as a number, changing it is only ever a registry update; if it computes something, the new version is deployed once as its own contract and the registry then records its address. So the goal is simple to state: keep as little hardcoded as possible, and make everything else changeable for the future - while never touching what anyone already bought.

The strategy: point to contracts instead of hardcoding. If a value is hardcoded into a contract, changing it means deploying a whole new contract. But if the contract POINTS to another contract for that value - or even for whole logic - then changing it means just updating what the pointer targets: one transaction, no redeploys. Concretely:

Every tunable NUMBER (fees, the graduation gates, the $54,321 floor, the curve calibration, the creation fee) lives in one central settings registry, and each new token copies those values into its own storage the moment it is created.
Even LOGIC can be pointed: the bonding-curve MATH can live in a pricing-engine contract each token pins at birth, and the LADDER RULES live in a rules contract tokens pin at graduation. The token's own pinned copy is what keeps this inside the regulatory lines: a change only ever shapes tokens that pin AFTER it, and physically cannot reach any token that already pinned - indirectly mutable for the future, absolutely immutable for everyone who already bought.

The limits: Nothing can ever change on a LIVE token mid-phase - a token trading on its curve keeps its curve terms; a token mid-battle keeps its battle terms. The workable gray area is changing things for a token AT ITS MILESTONES (graduation, re-graduation after a de-graduation), which becomes defensible when that behavior is part of every token's terms from day one and the possible values are limited to ranges declared in advance (the fixed limits, below). And depending on the architecture we pick for battle rules, we may even keep tokens on older rule sets able to compete against tokens on newer ones (the shared-arena option below) - that is one of the open decisions. (Full sourced analysis behind everything here: D4L_REGULATORY_MUTABILITY_ANALYSIS.md. Settled in the 2026-07-03/04 design review.)

Build status (2026-07-05). The registry-and-pointer architecture described in this section is now BUILT and deployed to the Base Sepolia testnet as the Charter v2 suite. Live on testnet: the bounded, timelocked settings registry (D4LParamsRegistry), the pricing-engine contract each token pins at birth (D4LCurveEngineV1), a read-only views contract (D4LTokenLens), and the one-shared-arena battle ladder (option B2 below). Genesis registry values reproduce today's economics exactly, so every mechanic in this document reads the same as it did before. What the testnet proves is the MECHANISM, not a settled policy: the partner decisions this section marks open - how wide the fixed limits may ever be, whether to keep the shared arena for mainnet, and the de-graduation-reset variant - are unchanged, and the pre-mainnet hardening still stands (transfer the registry admin key to a multisig, set the longer mainnet timelock, freeze the bounds).

The graduated exchange is moving to Uniswap v4 with D4L's own pool hook. On v4, instead of inheriting a fixed, off-the-shelf exchange's behaviour, we set our own custom values on the pool: its smoothed battle price, who may add or remove its liquidity (only the platform's vault), the between-battle price freeze, and the platform's share of every swap fee. We use v4 for two reasons. First, it lets us set those values ourselves rather than accepting an exchange's. Second, it keeps them changeable for the future the same way everything else here is: the exchange, the battle price source, and the scoring rule are each reached through a registry pointer, so any of them can be re-tuned or replaced with a single-contract deploy plus a registry update - never a full factory reset. It is also the seam the bot-filtered battle price rides on: because the price source is a pointer, a bot-filtered price source can be introduced the same cheap way later, with nothing already graduated affected (see the bot-filtered price in Section 5).

THE ANSWER - everything that can change: what the change is, why it is allowed, and when it takes effect.

Every item marked "registry update" is ONE transaction to change - never any deploy of anything. The items run in lifecycle order: creation, the curve, graduation, battles, de-graduation.

Creation fee ($4.44)

The change: registry update.
Why it is allowed: paid and consumed in the creation transaction itself - nobody holds anything that depends on it.
When it takes effect: whoever creates after the change pays the new fee; done.
Status: SAFE - the simplest tunable in the system.

Who may launch (the creation gate)

The change: a registry update to ROTATE the signing key, or a one-way registry update to OPEN launches to everyone permanently.
Why it is allowed: the gate decides who may CREATE a new token; it is read fresh at each creation and never copied into any token, so it is part of no one's economics and binds no holder - changing it cannot reach a token that already exists (the same reason the creation fee is safe).
When it takes effect: the next creation. Rotating swaps the authorized key; opening (retiring the signer) makes creation permissionless FOREVER and can never be re-gated.
Status: gated at launch; the open path exists so launches can be opened later as a deliberate, timelocked, one-way decision, never a factory reset (OPEN DECISION #10).

Other launch numbers (minimum trade sizes, the launch-approval time ceiling)

The change: registry update.
Why it is allowed: copied into each token at birth - a change cannot reach any existing token.
When it takes effect: only tokens born after the change.
Status: SAFE - green-lit.

Curve fees (1% buy, the 60% launch-window fee, 2%->1% sell, the whale-dump surcharge)

The change: registry update.
Why it is allowed: each token copies its fees at birth - a change physically cannot reach any existing token.
When it takes effect: only tokens born after the change; every existing token keeps its birth fees forever, through every phase including de-graduation.
Status: SAFE - green-lit.

Curve calibration (start FDV, reserves)

The change: registry update, with a calibration review first - the values are one calculation, not independent dials: a $60k floor works, ~$150k breaks pool seeding.
Why it is allowed: copied at birth - same as the fees.
When it takes effect: only tokens born after the change.
Status: SAFE - green-lit.

Token supply split (1B total / 800M curve / 200M pool reserve)

The change: NOT a registry update - it is a compile-time IDENTITY constant. Changing it for future tokens needs a factory reset (it is compiled into BOTH the token factory and the settings registry, which must change together); for every existing token it never changes.
Why it is locked: the split is threaded through the curve math (the virtual-reserve offset), the de-graduation re-seed, and the pool-seed fit - it is part of what a token IS, not a dial you can turn. It is already covered below by "an existing token's own terms" and "its supply."
When it takes effect: fixed at birth, forever; a different split binds only tokens created after a factory reset.
Status: IDENTITY CONSTANT - the one calibration value deliberately not registry-tunable.

The curve MATH itself

The change: single-contract deploy of the new pricing engine, then a registry update makes it current (the factory never redeploys).
Why it is allowed: the engine ADDRESS is pinned at birth exactly like a number - existing tokens keep their engine for life.
When it takes effect: only tokens born after the change; a token's engine follows it everywhere, including de-graduation re-seeds.
Status: SAFE doctrine, now partly built - the engine-pointer architecture and the first engine (D4LCurveEngineV1) are BUILT and live on testnet; a replacement or second engine is still a single-contract deploy to do only if a formula change is ever actually wanted.

Graduation gates ($54,321 market cap / 50 current holders / 7 minutes)

The change: registry update.
Why it is allowed: a token locks its gate values at birth, so a change cannot touch any token climbing toward them - buyers keep the goal they bought toward.
When it takes effect: at a token's birth. If the gates change while a token is still on its curve (it has not graduated yet), that token keeps its original gates. The only thing that can reset them for a token is a DE-GRADUATION - it entered the battle ladder, lost in the pit, and returned to its curve - and how that reset works is an OPEN CHOICE for the partners: either the token climbs back under the current gates outright, even if harder (one uniform rule for every arena entrant - legally the same milestone pattern as battle rules), or it climbs back under whichever set is easier, its original gates or the current ones (which makes it impossible for any holder to ever face a harder deal than they bought - the strongest posture, at the cost of a special case). Neither variant is regulatorily required over the other. (Worth knowing for the choice: easier gates also mean a smaller entry market cap, and a shallower pool is cheaper to move by percentage - an edge we can choose to grant early tokens, not a rule.)
Status: SAFE - green-lit for the birth-locking; the de-graduation-reset variant is the open choice above.

The exchange venue a token graduates into (the graduated pool, and the whole exchange behind it)

The change: registry update for the pool's tunable numbers - or, for a different venue entirely (a different exchange, or a new pool type), a single-contract deploy of the new venue adapter plus a registry update to make it current.
Why it is allowed: a token holds no pool until the moment it graduates - the pool is created right then, and from day one every token's terms say it is created on the platform's current venue. A change never touches any pool that already exists.
When it takes effect: this is one of the things that CAN change for a token that is already launched - while it sits on its bonding curve, the venue it will eventually graduate into can change, because the pool binds only at the moment of graduation, when it is created. If the token later de-graduates and climbs back, the new pool is created the same way, on whatever the current venue is then.
Status: DEFENSIBLE - the same milestone pattern as battle rules, and milder (the venue is infrastructure, not competition rules). This is the seam the move to Uniswap v4 rides on (see Current status): the graduated venue is reached through a registry pointer, so switching the exchange the platform graduates into is a single-contract deploy plus a registry update, never a factory reset. Installing this venue/price/scoring pointer architecture in the first place - the Curve-to-v4 move - is a heavier one-time cutover that ships with the next release; only after that install are further venue, price-source, or scoring changes the cheap single-contract-deploy-plus-registry-update kind, never a factory reset.

The battle price source (the contract that reports each token's smoothed battle price)

The change: single-contract deploy of a new price source, then a registry update to make it current - or a registry update alone for its tunable numbers.
Why it is allowed: a token pins its price source at graduation, exactly like its pricing engine - a change cannot reach any token already graduated under the old one.
When it takes effect: only tokens that graduate after the change; a graduated token keeps its price source for its whole ladder life, including a de-graduation re-listing.
Status: SAFE doctrine - the price the ladder reads is now behind a pointer, so the smoothing and the manipulation-resistance can be improved over time without a factory reset. This is also what lets a future bot-filtered battle price drop in as a single-contract deploy plus a registry update (see the bot-filtered shadow/display price in Section 5; that one is display-only - a bot-filtered settlement price would be the future drop-in described here).

The battle scoring rule (how a winner is decided from the two prices)

The change: single-contract deploy of a new scoring rule, then a registry update to make it current - or a registry update for any tunable it exposes.
Why it is allowed: a token pins its scoring rule at graduation, exactly like its price source - a change cannot reach any token already graduated under the old one, and a battle always finishes under the rule it started with.
When it takes effect: only tokens that graduate after the change; a live battle is never re-scored.
Status: SAFE doctrine - built as part of the v4 suite (see Current status). Today it is the plain "higher percentage gain wins" rule; keeping it behind a pointer means a future refinement (a tie-break tweak, or a different fairness measure, always inside the fixed limits) is a single-contract deploy, never a factory reset.

Battle rules (KO %, window length, promotion, and the waiting-too-long rescue rule)

The change: registry update - or a single-contract deploy of one new rules contract, depending on which of the options below is chosen.
Why it is allowed: from day one, every token's terms say its battle rules are whatever the platform's current rules are when it enters the ladder, and those rules can never go outside fixed limits set forever. (Re-graduation is not a special door - it is the same three graduation gates re-earned, with the holder count restarted at de-graduation; since those buyers necessarily buy after any rules change is public, the ordinary door also strengthens the legal position.)
When it takes effect: this too can change for a token that is already launched - a token on its curve holds no battle rules yet, so while it climbs, the rules it will eventually fight under can change; it takes the current rules the moment it first graduates. After that, it depends on the architecture chosen below: under the pinned options, it keeps those rules for its whole ladder life and only a de-graduation resets them; under the shared arena, each NEW battle pairs under the then-current rules, with levels carrying. Either way, one thing is absolute: a battle always finishes under the rules it started with.
The fixed limits: hard bounds written in forever - the shape of a token's life never changes, the knockout threshold can only ever sit within [X,Y], the battle window within [A,B], promotion and demotion move one level at a time, tie rules are published, and there are zero per-token powers. Future rules can only ever be variations inside these bounds. Their honest status: a CHOICE that strengthens the case, not a legal mandate - no rule requires them, but the regulatory research makes tight limits the condition that keeps the shared-arena option defensible (an unbounded "rules can become anything" lever is what draws the recharacterization argument). How wide each bound is IS the real mutability policy - deciding those numbers is the partner conversation.
Where the rules live (OPEN DECISION #7, partner meeting): three options. B1 - sealed generations: the rules live in the ladder contract itself; a change is a single-contract deploy of one new ladder that future graduates join; every token keeps its rules forever (lowest risk - the regulatory default; the cost is everything in the next field: split groups, stranded winners, the rescue mechanism). B2 - one shared arena: one ladder forever; every token simply plays its NEXT battle under the then-current rules - a battle always finishes under the rules it started with, mid-battle never changes, and levels carry (win at prestige 4 under the old rules, fight your prestige-5 battle under the new ones). A change is a registry update, rules evolve for all tokens equally like league seasons, and the entire next field disappears: no split groups, no stranded winners, no rescue rule needed. The cost: a token's competitive rules can change during its ladder life - defensible gray resting on four conditions (the token's economics never move; changes stay inside the fixed limits; equal for all tokens with zero per-token discretion, after the public delay; mid-battle is sacred), with counsel sign-off required (memo question 8). B1.5 - one contract, pinned buckets: each token copies its rules at graduation and matchmaking only pairs same-ruleset tokens; registry-update convenience, but B1's costs (the buckets still split and strand).
Build status (2026-07-05): option B2 is the architecture now BUILT and deployed on testnet - one shared BattleLadder, with each battle's rules snapshotted into it from the registry at pairing and frozen for that battle. This does not settle OPEN DECISION #7: keeping B2 for mainnet, and how wide the fixed limits may ever be, remain the partner and counsel conversation; what changed is that the mechanism they are deciding about is now real and testable.
What happens to tokens when the rules change (this whole field applies ONLY under the pinned options B1 / B1.5 - under B2 none of it exists): tokens on different rulesets cannot fight each other. Losers migrate forward on their own - a pit loss de-graduates the token, and its climb back joins the current rules - so old groups drain naturally. The gap to close before the first change: a token that keeps WINNING on an old ruleset runs out of opponents, and since a graduated token is frozen between battles, it ends up locked with nothing to fight. The rescue rule fixes it - anyone can trigger it: waited more than N days on an outdated ruleset, move to the current ruleset KEEPING its prestige level (resetting a winner to entry level would punish the wrong party), or step down to the curve; only N needs deciding. Server cost of a change: our servers watch every ruleset that still has live tokens; the website stays one website as long as every ruleset publishes the same data format.
Status: OUR OPERATING MODE - defensible gray, bounded.

Which curve a de-graduated token returns to

The change: factory reset (one-time, to redesign the token-to-factory bond).
Why it is allowed: not allowed - exit terms are sacred; the alternative is counsel-gated.
When it takes effect: the birth curve, forever.
Status: PARKED - OPEN DECISION #8.

Everything off-chain (matchmaking pace, prestige display, paid moves, store, UI)

The change: ordinary product work - no chain involved.
Why it is allowed: nothing binds on-chain.
When it takes effect: anytime, for everyone.
Status: NO CONSTRAINT - most data-driven tuning lives here.

Never changeable: an existing token's own terms; money destinations; holders' exits; the rules of a phase a token is currently in; per-token targeting

The change: no change exists.
Why: this untouchable core is the trust guarantee that buys everything above.
When: set at birth, forever.
Status: STONE.

WHEN in the lifecycle a change can bind - the three ways, with the legal backing for each. The regulatory line, in one sentence: what the law forbids is DISCRETION over terms people already bought - not evolution itself (the 2026 SEC/CFTC release fixes buyer reliance at time of sale; the pending CLARITY Act explicitly tolerates "pre-established, transparent rules applied consistently, not changed at one party's discretion"; full citations at the end of this section). So for anything we want to change, the only question is WHEN a token's copy of that rule binds: Way 1 - copy at birth (SAFE): a September token keeps $54,321 forever, a November token gets $60,000; a change never reaches anyone who already bought. This is how ALL launch economics work. Way 2 - adopt at a milestone (GRAY, and OUR OPERATING MODE for the arena): a token adopts the then-current battle rules at its milestones - at minimum on the climb back after a de-graduation, and under the shared-arena option at every new battle pairing. This is defensible for three reasons, and none of them require knowing changes in advance: first, from day one every token's terms say "re-entry adopts the then-current rules" - so a later change is part of the deal people bought, not a change to it; second, those rules can never become something wild - only a variation inside fixed limits everyone saw from the start (this is the strongest of the three); third, a de-graduated token cannot re-enter at all until 50 new buyers choose it under the rules as they stand. We will NOT pre-announce specific changes - the right values will be learned from live data, and this defense deliberately does not depend on foresight we cannot have. (A regulator could still argue we kept a lever - untested; counsel question 1 tests exactly this.) Way 3 - change rules under live tokens (NEVER): even fair-and-equal, it rewrites terms people already own; and targeting one specific token is the power that gets platforms sued. Also banned outright: upgradeable contracts ("proxies") - the technique that swaps the program underneath tokens that already exist.

The guardrails, ranked by what they actually remove. BOUNDS remove power - the big one: every registry value has hard min/max ranges baked in, published; a pointer into a tightly bounded family of rulesets is almost no power, while "we may change anything," even disclosed, is still unlimited control. GENERALITY removes targeting: changes apply to everyone equally; there is zero per-token discretion anywhere. TIME removes surprise - the smallest: every change goes through a public timelock (days) with on-chain events, and the key sits behind a multisig.

The de-graduation door - the one moment where things can refresh for an already-launched token (cross-cutting; in front of counsel). Several items above share one pattern: they can refresh when a token falls off the ladder and climbs back - its battle rules (under the pinned options B1/B1.5; under the shared arena B2 the rules refresh at every battle pairing instead, so this door matters less for them), its graduation gates (the open choice: current gates outright, or only ever the easier set), and the pool it graduates into (recreated with the current configuration). What never refreshes even here: the token's own economics - its curve, its fees, its supply, its holders' exits (and, as parked in the list above, the curve it returns to stays its birth curve). All the refreshing items lean on the same three defenses, none of which require knowing changes in advance: the refresh behavior is in every token's terms from day one; what it can refresh TO is bounded by fixed limits everyone saw from the start; and the climb back requires 50 fresh buyers who buy after any change is public - the ordinary graduation door doubling as consent. The leftover exposure, shared by all of them: the holder who bought under the old terms and HELD through the de-graduation - which is exactly what the fixed limits shrink. This pattern is the regulatory research's central gray item and is explicitly in the counsel memo (question 1 + addendum); the standing position is to keep the door - it is what moves tokens forward - and keep it bounded.

Why none of this ever fragments the game - private vs shared. Every term is either PRIVATE (a token's own business: curve math, calibration, fees, graduation bar) or SHARED (the arena two fighters step into: the battle ruleset). The reason private differences never matter in a battle: a graduated token is not on its curve at all - its curve is dormant, it trades on its own pool - and a battle reads ONLY each token's own pool price, judging the percentage change from each token's own starting point. The battle never looks at how either token launched. So, explicitly - two tokens can battle each other even if they have:

different bonding-curve calibrations (one launched at a $5,432 FDV, the other at some future $8,000 FDV) - can battle;
different curve fees or graduation gates (one graduated at $54,321 with 50 holders, the other at a future $60,000 with 75) - can battle;
entirely different curve MATH engines (old formula vs new formula) - can battle;
different creation fees paid, different re-entry bars, different anything-private - can battle;
wildly different prices or market caps (a $0.001 token vs a $10 token) - can battle; the percentage design makes them equals. The ONE thing two tokens must share to fight: the battle ruleset itself (same KO threshold, same window - the game they are both playing). That is the only compatibility requirement in the entire system, and it is why shared terms are the only place versions create separation. Three rules generate everything: (1) nothing a token is born with ever changes - and what it is born with is its own economics, the shape of its life, and the fixed limits on future battle rules, NOT the specific battle rules themselves; (2) private terms never affect who you can fight; (3) shared terms must match to fight, and that is the only place generations exist.

The sources. SEC/CFTC Joint Interpretive Release (Nos. 33-11412; 34-105020; 91 FR 13714, eff. Mar. 23, 2026): reliance fixed at time of sale ("post-sale representations or promises would not convert the prior sale into an offer or sale of an investment contract"); the danger is a "central party" with "operational, economic, or voting control" (fn. 54); "administrative and ministerial activities are not managerial efforts" (fn. 42). CLARITY Act (H.R. 3633; House-passed 294-134, Jul. 17, 2025; pending in the Senate): "pre-established, transparent rules applied consistently, not changed at one party's discretion." Ripple (S.D.N.Y. 2023): the transaction, not the token, is the unit of analysis.

For the partner conversation, the one-paragraph version: "Smart contracts being immutable does not mean the platform cannot evolve - current US authority forbids DISCRETION over terms people already bought, not evolution itself. Our design points every tunable value and rule at central contracts, and each token takes its own permanent copy at the right moment - at birth for its economics, at ladder entry for battle rules. Re-entry bars can only ever get easier for a token, never harder, and battle rules can never leave fixed limits everyone saw on day one. We can tune essentially everything for future tokens from live data, in one transaction, without redeploying - and nothing anyone bought ever moves against them."

1. Token creation & the bonding curve (the launch market)

Before a token "graduates," it trades only against a built-in pricing formula run by the platform - not on a real exchange. This is the launch phase, and it is where the anti-bot rules and the fair-launch guarantees live.

Who can launch. A token can only be created with a fresh, one-time authorization signed by the D4L platform - this is the gate on who is allowed to launch. Every launch actually involves two signatures, in a fixed order: first the platform signs the approval, then the user signs the transaction that carries that approval inside it. The order can't be flipped - the user's signature covers a package that already contains the platform's approval, so ours must exist first. That's the only reason the approval has a validity window at all: it has to stay valid while the user finishes their half (clicking through the wallet prompt, the transaction landing on-chain). The platform issues approvals valid for 30 minutes, and the contract enforces a hard 1-hour ceiling so a longer-lived one can't even be issued by mistake. An approval that never gets used simply dies on its own when the window closes. Each approval is single-use (every launch needs a fresh one) and is bound to the exact wallet that requested it, the token's name and symbol, the chain, and the contract - so a leaked or stolen approval is worthless to anyone else, and it can never be redeemed twice. To be clear on what it is NOT: the approval does not reserve or claim the token's name or symbol. Names and symbols are not unique on the platform - someone else can launch a token with the same name via their own approval. It is purely a launch permission, nothing more.

Who may launch can change - and can open completely. Who is allowed to launch is not fixed forever. The key the platform signs approvals with lives in the settings registry as a bounded, timelocked value, so it can change in two ways without ever redeploying the factory. It can be ROTATED: swapped for a new signing key (for example if a key is ever compromised) through the ordinary announce-then-wait-then-commit path, with no effect on any token that already exists. Or it can be OPENED PERMANENTLY: the signer is retired entirely, after which anyone may create a token with no platform approval at all, and the gate can never be re-imposed - opening is one-way, and once open it stays open forever. This is deliberate. It lets the platform move from gated launches to fully permissionless launches later as a single announced, timelocked decision rather than a whole new deployment. The platform launches GATED and stays gated until the surrounding pieces are ready: creator terms-of-service acceptance, a public feed that surfaces third-party launches, and moderation of what we display, plus counsel sign-off on a world where creators bind to no terms (OPEN DECISION #10). Either way, changing or opening the gate only ever affects who may create the NEXT token. It cannot reach, re-key, or alter anything about a token that already exists, because the gate is read fresh at each creation and is never copied into a token.

Creation fee. Creating a token costs a flat $4.44 USDC, paid to the platform treasury. It is the simplest tunable in the whole system: it is charged and consumed in the very transaction where the token is born, so there is no existing token to protect - a pure point-of-sale price, changeable within pre-committed bounds after a public delay, paid with eyes open by whoever creates next (see "Immutability & evolution"). It is separate from any first buy.

Pure fair launch (no premine). The creator receives zero tokens at creation. The entire supply is minted to the platform's curve; the creator is recorded only for attribution. There is no founder allocation and no special minting power - if the creator wants tokens, they buy on the same curve as everyone else. The creator may optionally make a first buy in the same transaction (becoming the first holder), and that buy pays the normal 1% fee, not the anti-snipe rate.

Supply. Every token has a fixed total supply of 1,000,000,000 (one billion), sealed at creation - there is no ongoing minting. 800 million (80%) is the inventory the curve sells during the launch phase. 200 million (20%) is held back to seed the token's own liquidity pool when it graduates.

How price moves. Price is set by a constant-product formula - the industry-standard market math (the same family Uniswap invented) but with D4L's own Arena Curve calibration; none of pump.fun's numbers appear anywhere in the system. The platform tracks a pair of virtual reserves whose product stays constant, and price is simply their ratio. Every buy removes tokens and adds money, so the next buyer pays more; every sell does the reverse. Nobody sets the price by hand and there is no outside price oracle - price is purely a function of how much has been bought and sold. Rounding is always tuned a hair in the curve's favor, so it can't be drained by rounding tricks.

The 5-4-3-2-1 calibration. Every token launches at a fully-diluted valuation of about $5,432.10 (a start price of roughly $0.0000054321 per token). The graduation floor is exactly 10x that at $54,321 - a clean tenfold move, and the source of the "5-4-3-2-1" name (the dollar figure $54,321 is the digits 5,4,3,2,1 in order). Reaching that floor happens after about 616 million of the 800 million curve tokens are sold - roughly 77% of the curve inventory (about 62% of the entire supply). Because every token launches with identical curve constants, this is a universal constant of the platform: the $54,321 floor always lands at exactly 615,962,502 tokens sold, with about $10,581 raised - the same point for every single token, deterministically. The 800 million is an allocation, not a sale target: the last ~184 million is deliberately never sold (the top of a constant-product curve is a near-vertical blow-off zone where tiny buys would move price violently).

Trading fees on the curve.

Buys: a flat 1% fee in normal conditions (see the anti-snipe launch fee in Section 5 for the opening seconds).
Sells: a base fee that starts at 2% at launch and slides down linearly to 1% by the time the token is ready to graduate, so early flippers pay more than long-term holders (plus an anti-dump surcharge on unusually large single sells - Section 5).
All fees go to the single platform treasury.

Trade guards.

Minimum trade sizes stop dust spam: a buy must spend at least $0.001 USDC, a sell must move at least 0.001 of the token.
A buy larger than the remaining curve inventory is partially filled, and the buyer is charged only for what they actually receive - never overcharged.
A sell can never pull out more money than the curve actually holds.
Any USDC sent directly to the contract (bypassing a real buy) never touches the curve: it moves no price, mints no tokens, credits no one, and cannot be pulled out by any trade. Updated 2026-07-03 (ships with the next factory deploy): instead of being permanently locked, that stray money is swept to the platform treasury by a function anyone can trigger, whose destination is fixed in the contract - a rule, not an admin power (it provably cannot touch a cent of the curve's real reserves; verified by tests). Refunding a genuine mistake is then a case-by-case support decision, made off-chain (policy lean: refund only when the sender was a D4L platform wallet - the sender of any transfer is public on-chain), backed by a Terms-of-Service line that money sent directly to contracts outside the app is non-refundable, so any refund is goodwill, not obligation. Regulatory verdict (2026-07-04): implementation validated (provably-cannot-touch-reserves + fixed destination are the key protective facts), with three requirements: publish OBJECTIVE goodwill-refund criteria (arbitrary case-by-case invites unfair-practices arguments); add the ToS line; and one counsel item - state unclaimed-property/escheatment law (CA SB 822/AB 1052, NY) is the real exposure, likely inapplicable to our no-account posture but must be confirmed (OPEN DECISION #6).

Pre-graduation transfers are blocked. A pre-graduation token can only move through the curve (buy/sell); ordinary wallet-to-wallet transfers are blocked. This is what keeps the live holder count exact and prevents off-curve games. Regulatory verdict (2026-07-04): KEEP - net helpful (supports the "no public securities market pre-graduation" story; with zero creator allocation it strengthens the defensible posture per Ripple's treatment of resale restrictions). Standing rule: always describe it as a PRODUCT MECHANIC, never in investment terms - it is also the feature private plaintiffs cite (the pending pump.fun class action). OPEN DECISION (#3, partner meeting): keep the block, or build the middle ground - allow sends, but only wallets that BOUGHT on the curve and still hold count toward graduation (received tokens never count), recipients limited to platform wallets. That kills the fake-distribution attack and blocks outside trading pools, but the token must then track two kinds of balance (bought vs received) - real contract complexity and audit surface - to enable a flow there is no user data on yet.

2. Graduation - the three gates

Graduation is the moment a token leaves the launch curve and gets its own real exchange pool. It is gated by three conditions that must all be true at the same instant:

Market cap at or above the $54,321 floor.
At least 50 wallets currently holding the token (a live count).
At least 7 minutes (420 seconds) since launch.

The dollar figure is a floor, not a cap. Hitting $54,321 does not stop or pause trading. Buying continues and the price keeps climbing past $54,321 while the slower gates (holders, age) catch up, so a token graduates at whatever market cap it happens to sit at when its last lagging gate clears - often well above the floor.

If the curve sells out before the gates clear. The only hard limit past the floor is the physical 800M inventory: a buy bigger than what remains is partially filled and charged only for what it actually receives. If the curve fully sells out while a gate is still unmet (the ceiling under the current calibration: about a $433,600 market cap, roughly $38,800 raised), buys simply pause; sells still work (they put inventory back on the curve), and the token graduates the moment its lagging gate clears - no token ever graduates without all three gates, period. One neat consequence of the live holder count: it updates during a buy and graduation is checked at the end of it, so the 50th distinct holder's own buy is the transaction that graduates the token. (OPEN DECISION #5, partner meeting: should a total sell-out force graduation even with gates unmet? For: inventory is done - arguably the market has spoken. Against: one whale could buy out the whole curve and instantly graduate a one-holder token - exactly what the 50-holder gate exists to prevent. Regulatory verdict: not a regulatory question at all - either behavior is rule-based and keyless; purely a product call.)

"Current holders," not "total buyers." The holder count is measured live, at the moment graduation is checked. A wallet is counted the instant a buy takes it from zero to a nonzero balance, and it drops out the instant it sells its whole balance back to zero. So a wallet that buys and then fully sells no longer counts. A wallet that sells only part of its position still counts (it still holds something). This is the strong reading of "50 holders": 50 wallets actually holding at graduation time, not 50 people who ever touched it.

7 minutes, everywhere. The minimum age is 7 minutes on both testnet and mainnet - there is no separate longer production value and no 12-hour variant anywhere in the code. (Any older reference to a "~12h production target" is stale and has been corrected.)

Automatic and permissionless. Graduation is re-checked at the end of every buy, and anyone can also "poke" a token to check it. (A "poke" is just a nudge: a public function call that makes the contract re-check its own conditions right then - the caller sends no money, has zero influence on the answer, and poking an unqualified token does nothing. It exists because contracts cannot wake up on their own - e.g. when the 7-minute clock finishes but nobody happens to buy, someone must send a transaction that makes the contract look. Our backend does this automatically within seconds; the point of "anyone can" is that the platform is a convenience, not a dependency.) So once the age gate has cleared, a token that already meets the money and holder gates graduates on the next buy or the next poke - no privileged party is needed, and it can graduate with no further buying.

Shown instantly (gamified), confirmed on-chain. The backend tracks the live holder count, market cap, and token age itself, so the app shows graduation progress ("X / 50 holders," time remaining) and the graduation moment instantly - it does not wait on the contract or a keeper. The moment all three gates are met, the app reflects graduation and fires the on-chain graduation in the background; the contract stays the source of truth that the backend reconciles to (the same "instant feel, chain confirms" model used for price - Section 7).

Locked at deploy - per token, with the registry path for the future. The two adjustable gate values (holder minimum = 50, age minimum = 7 min) are fixed permanently when the factory is deployed; there is no admin switch, and no gate can ever change for a token already on its curve (people are actively buying toward a known goal - that never moves). Under the green-lit parameter registry ("Immutability & evolution"), all three gate values become registry numbers each future token copies at birth - changeable for future launches in one bounded, delayed, public transaction, never for anyone already launched.

The rejected "health oracle" (OPEN DECISION #1 - resolved in principle). A partner spec once proposed a fourth gate: a platform-held key that must attest a token's holder-quality (wallet clustering, fake volume, concentration - checks that cannot be computed on-chain) before it may graduate. It was never built - there are zero references anywhere in the code - and the regulatory research CONFIRMED rejecting it: discretion over whether a market opens is the single most security-like power a platform can hold (the paradigm "managerial efforts" that makes the platform a regulated "central party"). Preferred replacement, still to decide with partners: strengthen the gates on-chain and trustlessly - require a minimum holding per wallet to count toward the 50 (kills dust-wallet padding, adds no key). If an oracle is ever reconsidered at all: block-only with an auto-pass timeout (may DELAY a suspicious graduation, never cause or permanently block one), and only after counsel review.

Reversible. Graduation can be undone: a graduated token that later loses at the very bottom of the battle ladder (the pit) is DE-GRADUATED - dropped back onto its bonding curve (Sections 3 and 4). (Two different words for two different falls: a DEMOTION is dropping one prestige level on the ladder; a DE-GRADUATION is losing in the pit and leaving the ladder entirely, back to the bonding curve.) A token can only be graduated once at a time; it can only re-graduate after first being de-graduated. If the gate values ever change, a token still on its curve keeps its original gates; what a DE-GRADUATED token climbs back under - the current gates, or only ever the easier set - is an open partner choice (see "Immutability & evolution").

3. Battles & the prestige ladder (after graduation)

Once graduated, a token enters a prestige ladder and fights other graduated tokens one-on-one.

The contest. A battle is a head-to-head between exactly two graduated tokens, decided purely by which token's price rose by a larger percentage during the battle window. Absolute price doesn't matter - a $0.001 token and a $10 token compete on equal footing, judged only on their own percentage change from their own starting price. And nothing about how the tokens LAUNCHED matters either: two tokens with different bonding curves, different fees, different graduation gates, even entirely different curve math can fight each other as equals, because a battle reads only each token's own pool price - the launch curve is dormant the moment a token graduates (the full compatibility list is in "Immutability & evolution," private vs shared).

The price used is smoothed, not spot - and here is the exact mechanism. Battles read each token's time-averaged pool price, not the instantaneous last-trade price. The smoothing is an exponential moving average (EMA): the venue continuously maintains a running average of its own price, every trade updates it, and recent prices count more while older prices fade away exponentially. Under the v4 design (see Current status) this EMA is maintained by the platform's own in-pool price source, inside the hook - built deliberately to behave the same way the earlier Curve pool's own built-in oracle did, so the number the ladder reads, and every rule that depends on it, is unchanged whichever venue is underneath. The fade speed is a parameter of that price source: about 14 and a half minutes of memory, so the oracle weights roughly the last quarter hour of trading toward the most recent minutes. The consequence: a single big trade or one-block spike barely moves the average - to win a battle you genuinely have to hold a higher price over time, not fake a momentary wick. Two safeguards enforce that: the ladder scores on a trailing time-average, never the latest tick; and a per-block cap limits how far any single block can move that price, so pushing it to a false level means sustaining the push across many blocks against real, escalating trading cost, not a one-shot wick. The size of that per-block cap is the manipulation-cost lever, sized from an out-of-band cost simulation (see Current status). This is deliberate manipulation resistance, and the same price source is used everywhere price matters after graduation: battle scoring, knockout and forfeit checks, and the price a de-graduated token re-lists at - one price source for everything.

The battle window. If neither early-ending condition fires, the battle runs its full window and the higher percentage gain at that moment wins.

Intended (production): 24 hours.
Live testnet: 30 minutes (shortened for faster iteration).

Early win - knockout (KO). A token wins immediately if its smoothed price is up by at least the KO threshold and holds at or above it continuously for 5 minutes (a 5-minute candle). If the price dips below the threshold during a check, the hold timer resets.

+100% gain, held 5 minutes - same on testnet and mainnet (corrected from an earlier looser test value; with unlimited test USDC there's no reason to lower it).

Early loss - forfeit. The mirror image: a token automatically loses on the spot if its smoothed price falls by at least the forfeit threshold and holds that low continuously for 5 minutes, handing its opponent an instant win.

-50% loss, held 5 minutes - same on testnet and mainnet (corrected from an earlier looser test value).

(If we ever want to change these thresholds or the window length: never for a battle already running - beyond that, how a change reaches tokens depends on the open architecture decision, and any change stays inside the fixed limits. Full mechanics: "Immutability & evolution.")

Ties go to the waiter. Each ladder level has one waiting slot; the token already waiting is the "home" side. If the two tokens end exactly even, or both cross their winning condition in the same check, the tie breaks in favor of the waiter.

Climb and fall.

Win → up one prestige level (and the winner re-enters the higher level's queue, so it can chain straight into its next fight).
Lose → down one level (a demotion).
New graduates enter at level 1.

The pit (level 0, last chance). Losing your level-1 battle drops you to level 0, the pit - the last-chance tier, because there is nowhere lower to fall. Winning in the pit sends you back up to level 1. Losing in the pit knocks the token off the ladder entirely: it is de-graduated and returned to its bonding curve (Section 4).

Prestige is a cushion. Because you only fall one level per loss, a token at level N needs N+1 consecutive losses to be knocked all the way out (fall to the pit, then lose in the pit). Only a level-1 token is "two losses and out."

Between battles, price is frozen. A graduated token is only tradeable while it is inside a live battle; between battles it is locked. This guarantees each new battle starts exactly at the price the previous one ended, so the ladder is a continuous, gap-free contest and off-hours price moves can't create an unfair head start.

Walkover - when a pool cannot answer (OPEN DECISION #9 - the current behavior is a baseline, NOT the accepted design; this must be decided before mainnet). To pair or settle a battle, the ladder calls the token's pool and asks its price - and like any contract call, that can fail instead of answering.

How it can fail, and who is at fault in each case:

A defect in our graduation seeding that produced a malformed pool - OUR fault.
A bug or black-swan state in the venue's own pool code - the exchange's fault (audited, battle-tested code running billions elsewhere; extraordinarily unlikely - true of both the live Curve pool and the Uniswap v4 pool it is moving to).
A pathological pool state reached through extreme trading or liquidity moves - nobody's fault in particular; a market accident.
Deliberate sabotage to dodge a loss - largely theoretical here (standard tokens offer no callback path, and pool locks do not persist between transactions), but the design must still never reward the attempt. In every realistic case the token's HOLDERS are blameless - which is why "you instantly lose" cannot just stand as the final answer.

What is non-negotiable in ANY version: the opponent is never held hostage; settlement always terminates; stalling is never worth attempting; and no human ever decides an outcome (an operations override would be an admin power over battles - excluded outright).

The options:

Instant walkover loss (the baseline in place): maximal liveness, zero complexity - and the loss does route the token back toward the working market (repeated losses end in de-graduation, restoring tradability). Harsh on blameless holders.
At PAIRING - skip and requeue: no battle exists yet, so the readable opponent simply pairs with the next waiter while the unreadable token retries each tick; only sustained unreadability past a DEADLINE becomes a loss. Nobody is harmed by the retrying.
At SETTLEMENT - bounded grace: retry for a short fixed window before the walkover fires, protecting holders from a transient glitch; the opponent waits at most the grace.
Void and re-battle - REJECTED at settlement (if the readable side was winning, voiding robs an earned win); at pairing it is the same thing as skip-and-requeue.

The likely landing: options 2 + 3 layered on the baseline - generous first, terminal always. The numbers to decide with the partners: the pairing deadline and the settlement grace.

A battle always runs under the rules it started with. Mid-battle, the rules never change - window length, KO/forfeit thresholds, and hold times are locked for that battle the moment it pairs. What a token's NEXT battle runs under is the open architecture decision (OPEN DECISION #7, "Immutability & evolution"): under the pinned options, a token keeps the rules it graduated into for its whole ladder life; under the shared arena, each new battle pairs under the platform's then-current rules, with levels carrying.

Rehome (a safety valve for stranded tokens). If operators deploy a newer byte-for-byte identical ladder, a token left waiting with no opponent on the old one can be moved ("rehomed") to the current one by anyone - keeping its exact prestige level and rules. Guards: the destination must be identical, the token must be genuinely idle (never mid-battle), and it must have waited a minimum delay (live testnet: 1 hour; fork/default: 24 hours).

Who runs the battles - and why the game still feels instant. Checking for KO/forfeit and settling a finished battle are both open to anyone to call. Two speeds work together. The site reacts in REAL TIME: our servers stream every trade, so the moment a token crosses a threshold the page shows it, the hold-candle counts down live - and that same crossing immediately triggers the on-chain checkpoint, within seconds of the trade. A background heartbeat (roughly every 30 seconds) re-checks everything as a FALLBACK, so nothing ever depends on the real-time path being healthy. (The blockchain itself is discrete - a contract only looks when someone sends it a transaction - which is why the design is instant-trigger plus heartbeat; "continuous" does not exist on any chain.) Worst case if every real-time trigger fails: an early-ending lands up to one heartbeat late - never a corrupted result, because the fixed battle window is a guaranteed fallback. Two clarifications on cost and truth: READING the chain is free (no gas - only WRITES cost anything, and those fire when something actually happens), so the backend does not ration its checking - it continuously reconciles its mirror against on-chain state, and the chain is not a fallback source of truth, it is the ONLY truth (any mismatch rolls the display back - Section 7). And the deepest fallback is the contract itself: every check and settlement is permissionless, so even with our servers gone, anyone can poke the battles along - and with no pokes at all, outcomes still resolve at the fixed window. Launch posture: run the reconciliation sweep tight (every few seconds - it is reads) with an alert on any mismatch, and relax the cadence only as the system earns trust with real data.

4. Graduated liquidity & the no-rug guarantees (the vault)

When a token graduates, a real exchange pool is created and seeded, and an owner-less vault holds the liquidity. This is what makes graduation both reversible and impossible to rug.

The pool is seeded at the graduation price - no gap, no instant dump. The launch contract hands over the accumulated USDC plus the reserved meme tokens in the exact ratio of the graduation price, and the pool opens at that price. So there is no phantom jump or crash the moment a token graduates. (About 195M of the 200M reserved tokens actually pair into the pool at the current calibration; the ~5M remainder stays as locked curve inventory, recycled if the token is later de-graduated.) The full supply picture at a floor graduation: roughly 616M (61.6%) in buyers' hands, ~195M (19.5%) plus all the raised USDC in the pool, and ~189M (18.9%) in total (the never-sold curve tail plus that ~5M) locked in the launch contract as the de-graduation re-seed reserve - supply no key can ever touch. For comparison, pump.fun sends a similar share to its pool (~20.6% vs our ~19.5%) but has ~79% circulating at migration versus our ~62%; the difference is the locked reserve, which is the price of D4L's reversible graduation - no other launchpad has one.

Liquidity is held, not burned - on purpose. Most launchpads burn the pool's ownership receipt to lock liquidity forever. D4L deliberately keeps it in the vault, because holding it is the only way to cleanly reclaim the assets and re-seed the curve if the token is de-graduated. Keeping it is not a rug risk here, because no human can ever make the vault release it (below).

No owner, no withdrawal, no rug. The vault has no owner, no admin, and no withdraw / rescue / sweep function. Liquidity has exactly two possible destinations, ever: into a token's own exchange pool when it graduates, or back into that same token's own bonding curve when it is de-graduated. It can never go to the platform, to the team, or to any person - even the one key the team holds cannot move a single unit of anyone's funds.

Anyone can graduate a token; only the token's own ladder can de-graduate it. Graduation is permissionless (the vault verifies the three gates are genuinely met and fails otherwise). De-graduation (the reversal) can only be triggered by the token's own ladder, and only as the automatic result of losing in the pit - not by any team button. No key can ever target a specific token - re-rule it, de-graduate it, or touch its funds; how rule changes reach tokens in general is the open architecture decision ("Immutability & evolution").

The reserve can never run dry - even a total sell-out keeps a cushion. The 200M pool reserve is a separate bucket from the 800M the curve sells: launch-phase buyers can only ever buy from the 800M side, so the 200M is always fully intact on graduation day - which is its whole job (it is the stock the DEX pool is seeded from). And the higher a token graduates, the FEWER tokens its pool needs (pairing the raised USDC at a higher price takes fewer tokens): a floor graduation pairs ~195M of the 200M into the pool, while a full-sell-out graduation (the $433k ceiling) pairs only ~89.5M - leaving ~110.5M of unused pool reserve locked as the de-graduation cushion. The algebra closes cleanly: across every possible graduation point, the locked fall-back stock is never less than ~110M tokens (~11% of supply), worst case being exactly the total-sell-out token. No token can de-graduate into an empty pantry.

At de-graduation, the pool's contents come back immediately - nothing waits for re-graduation. The vault withdraws its entire share of the pool - both the meme and the USDC - and hands all of it straight to the bonding curve in the same flow; that recovered content is the primary re-seed material, and the locked reserve is the top-up. A later re-graduation gets a brand-new pool, seeded fresh. (What about the old pool afterwards? Nobody has to lock it - the token itself is the lock: every pool trade requires moving the token, and a de-graduated token is transfer-locked back to curve-only, so the old pool becomes physically untradeable the instant de-graduation happens, automatically, with no cleanup step that could be forgotten. Pools are public, so an outsider could have added their own liquidity during a battle window; the platform never touches other people's share - it stays theirs, with the meme side frozen in the dead pool until the token is next transferable (a live battle after a re-graduation). Token amounts stuck in a dead pool are just an inert holder and do not affect the re-opened curve's math, which only ever pays out against money it actually holds. Outside liquidity-providing into battle-token pools is at-your-own-risk, and user-facing docs should say so plainly.)

Why the locked reserve exists - pools give back less meme the higher the price went. A pool holds two sides in balance, so if a token mooned during its ladder run, buyers pulled meme out and pushed USDC in - and when that pool is dissolved at de-graduation, what comes back can be mostly USDC with very few meme tokens. A re-opened curve with no inventory would be a broken market (nothing to buy). So at de-graduation the recovered pool tokens are combined with the reserve the contract kept, and the combined stock is re-split the same 80/20 way as launch: most becomes the curve's sellable inventory, a fifth is set aside to seed the next pool if the token re-graduates. The reserve is what guarantees every de-graduated token comes back as a real, tradeable market with a next chapter possible.

De-graduation is a relegation, not a reset. A de-graduated token does NOT restart at the $5,432 launch state. It re-opens at its own carried-over price (below), its holders keep what they hold, its sell-side is backed by exactly the real USDC recovered from its pool (sells can never exceed that real backing), and its pricing FORMULA is unchanged - the same birth math it launched with, never remade; what gets recalculated are only the STARTING VALUES the formula runs on (its internal reserves), so the same machine re-opens at the carried-over price with the actual current float - behaving exactly like a fresh curve would at that same price and distribution. Different history, same physics; only re-graduation must be re-earned from scratch (fresh 50 holders, fresh clock).

A de-graduated token always returns to its BIRTH curve, at its birth fees. Exit terms are sacred - its holders always sell on the exact fee terms they bought under. (Whether a future redesign should let a de-graduated token adopt the then-current curve engine instead is OPEN DECISION #8, parked - see "Immutability & evolution.")

De-graduation re-lists at the fair (averaged) price, not spot. When a token is de-graduated, the vault dissolves its pool, recovers the assets, and re-opens the bonding curve at the token's time-averaged price captured before the pool is touched - never the instantaneous spot price. This closes an attack where someone crashes the pool in the same transaction as the de-graduation and then buys the freshly re-opened curve cheap. If the averaged price can't be read (broken pool), it safely falls back to the recovered asset ratio, so a broken pool can never permanently freeze a de-graduation. The re-list price is additionally floored at a fraction of the token's birth price, so even a driven-down reading cannot crater the re-opened curve.

The rare above-the-line de-graduation (and why it is not value teleportation). A token can lose in the pit while still priced ABOVE the $54,321 graduation line (it lost on relative performance - battles judge percentage gains, not absolute price). In that rare case the curve re-opens quoted just under the line, and it is important to be precise about what that does and does not do. What is conserved: every recovered dollar and every holder's every token - nothing is skimmed. And the total money all holders can collectively extract from the re-opened curve is exactly the recovered pot regardless of the opening quote (a curve can only pay out dollars it physically holds; market cap was never a pot of money, on any platform). What the quote changes is only the head start: a high re-opening quote lets the fastest dumpers drain more of the same pot per token, leaving less for everyone behind them; the clamped quote de-escalates that race, and because the full pot backs a lower quote, the re-opened curve is actually over-backed - sellers are safest here. The clamp is an opening quote, not a ceiling: the floor never blocks buying, so if the higher valuation was real, buyers hit the discount immediately, the price runs straight back up while the 50 fresh holders accumulate, and the token re-graduates at whatever the market truly bids. If nobody bids it back up, the higher number was hollow, and the clamp simply said so. Why it cannot re-open above the line at all: the bonding curve is the training market, calibrated for the road from launch to graduation - a curve born already above the line would sit with the money gate pre-passed and could loop (de-graduate, instantly re-qualify, battle, de-graduate); clamping under the line is what makes re-graduation meaningful. UX note for the site: in this rare case a holder's displayed value does drop at re-listing - the page should say so plainly ("re-listed at the graduation line - full backing preserved, all tokens intact").

It can't get stuck or be jammed. If the pool-dissolution step can't run in the same transaction as a pit loss, the battle still settles and the de-graduation is finished later by a safe public retry - the battle outcome is final immediately, and the liquidity move follows reliably. Because pools are public and anyone can add liquidity to one, the vault only ever reclaims its own proportional share (with a 1% tolerance), so a stranger donating a fraction of a token can't lock a token out of de-graduation.

The team's only two powers. The deployer key holds exactly two powers: (1) steer the GENERAL rules going forward - what future events run under (future graduations, and under the shared-arena option, future battle pairings) - always within the disclosed framework and its fixed limits, and (2) soft-pause new graduations by pointing at a non-working target (which corrupts nothing and touches no existing token). That is the entire extent of team power - no fund movement, no reaching a specific token, no altering a battle already running. To be precise about what "re-ruling" means, because the architectures differ: under the pinned options, an existing ladder token never experiences a rule change at all; under the shared arena, a live token's NEXT battle picks up the then-current rules - but that is the system applying the mechanism written into every token's terms from day one, not the key singling anyone out. Under every architecture, the key itself can only ever move the general, bounded, delayed dial - never one token, never one battle. Any rules change is public on-chain, with an event, before it governs anything. Regulatory verdict (2026-07-04): this key does NOT raise the platform's risk tier (forward-only = governance/ministerial under the 2026 release), with one action item: narrow the "pause new graduations" half to emergency-only, timelocked, publicly logged, and ideally sunsetting - in the final pre-mainnet factory reset (the same one that installs the registry).

Audit trail. Every pool the vault ever deploys for a token is recorded, so a token's full graduate → de-graduate → re-graduate history is traceable on-chain.

5. Anti-cheat, anti-bot & integrity

The platform defends launches mostly with fees baked into the contract that nobody can turn off, plus a few backend controls. The framing, stated in the code itself: you can't cheaply prove someone is a real unique person, so the strategy is to make bot swarms expensive and visible, not impossible.

The anti-snipe launch fee (the primary defense). For the first few blocks after a token launches, every buy pays a punishing flat 60% fee, which then drops to the normal 1% and stays there.

The window is measured in blocks, not seconds - the first 5 blocks (roughly 10 seconds on Base's ~2-second blocks) - specifically because the most common bot attack is buying in the exact same block the token launches, where no time has elapsed and a time-based window couldn't tell the bot apart from the launch.
The window is sized to close right about when a real human could first realistically land a buy through the app.
It is the primary defense because it can't be dodged: every wallet pays it on every in-window buy regardless of history, so spinning up fresh wallets doesn't help.
The creator's own initial buy at launch is exempt and pays only 1% (they're not a sniper).

The anti-snipe fee doubles as bot detection. Because every buy is recorded on-chain with the fee it paid, and snipe-window buys pay the distinctive 60% rate, the platform (and anyone reading the chain) can see exactly which wallets snipe-bought and what they paid. So the same mechanic that taxes bots also flags them.

Anti-dump on sells. On top of the decaying 2%→1% base sell fee, a single unusually large sell pays an extra surcharge, while ordinary sells pay nothing extra. The surcharge only triggers when one sell is bigger than 1% of the tokens sold so far, then scales up with how oversized it is, capped at +15%. (The exact steepness is flagged in-code as a tuning knob to calibrate before mainnet.)

Fair-launch / no-admin guarantees (recap). Zero creator premine, no admin, no mint authority, no owner, no pause, immutable fees and treasury - all covered in Section 1, and all part of the integrity story.

📅 Added 2026-07-16 Buying the curve is open - and Sybil resistance does not depend on gating it. Anyone can buy on the curve: a platform account's smart wallet and a user's own external wallet buy on exactly the same terms, and both count toward the live holder count. The platform does NOT restrict curve buying to registered platform wallets - an earlier design proposed a registered-wallets-only buy gate as the Sybil defense, and that approach has been dropped, because gating buys turns real external-wallet holders away and still cannot prove one person is not many. Instead, two contract-level mechanisms carry Sybil resistance for the 50-holder graduation gate, and neither adds a key or a gate on who may trade:

the anti-snipe launch fee above, which makes a swarm of buys genuinely expensive - every in-window buy pays the 60% rate no matter whose wallet it is;
a minimum balance to count - a wallet has to hold more than a dust threshold to be counted toward the 50 - which removes the cheap "many wallets each holding a speck" padding attack (the same minimum-holding rule proposed as the on-chain health-oracle replacement in Section 2).

Backed by the per-IP account-creation cap below, this makes "50 holders" a meaningful liveness signal - not a proof of 50 distinct humans, which nothing on-chain can be, but a bar an attacker has to pay real money and hold real balances to clear. The separate gate on who may LAUNCH a token (the platform's creation signature) is a different mechanism entirely and is unchanged - see "Who may launch" in Section 1 and OPEN DECISION #10.

Buy-ban moderation. A one-time appointed manager can block specific wallets from buying (never from selling - a flagged wallet can always exit its position). Regulatory verdict (2026-07-04): the block-buys-never-sells asymmetry is materially safer than the reverse (a power that could trap a holder would look like custodial control); requirement: publish OBJECTIVE ban criteria - arbitrary application invites unfair-practices arguments.

Backend account limits (also the wallet cap). The backend caps how many accounts a single internet address can create - default 5 per IP per 24 hours (tunable) - to stop someone spinning up unlimited funded accounts. Because one account gets exactly one default wallet, this per-IP account cap is the per-IP wallet cap for platform accounts, which limits how cheaply one actor can farm platform accounts toward the holder count (external wallets buy freely and are held in check instead by the anti-snipe fee and the minimum-balance-to-count rule above). It's sized so a shared household (several people behind one home IP) can each make an account, while a single actor can't spin up a swarm from one IP. It fails closed: if the rate-limit store is down, it blocks creation rather than allowing unlimited. The IP it uses is the unforgeable one from Cloudflare's connecting-IP header, so a caller can't spoof it to get a fresh quota, dodge a ban, or frame someone in the logs.

Off-chain "soft-sniper" detector (built, not enforcing). A backend detector watches for wallets that repeatedly buy right after the fee window drops and then dump fast, across many launches. It only flags on a strong repeated conjunction (an early post-fee buy and a fast large dump, on enough of a wallet's recent tokens); a holder or a slow seller never trips it. When it flags, enforcement is a buy-ban only (selling always stays open). Today it is off by default, and dry-run (log-only) even when on - the intended rollout is to observe first, review the flagged set, retune, then enforce.

The residual risk. None of this proves personhood. A determined, well-funded attacker using anti-detect browsers, residential proxies, and rented identities (about $1 to tens of dollars per identity) can still defeat device/IP checks, and collusion among genuinely-real people is unsolved everywhere. Until the minimum-balance-to-count rule is enforced, the 50-holder graduation gate can in principle be padded by one actor with many throwaway wallets each holding dust - so today it is a coarse "is this token alive" check, not proof of 50 distinct people; the anti-snipe fee and that minimum-balance rule are what raise the cost of padding it. Mandatory phone/captcha/third-party personhood gates were researched and deliberately rejected (worthless or too much real-user friction). (The optional KYC "verified" badge in Section 8 is a different thing entirely - it is display-only and gates nothing, so it adds a legitimacy signal without becoming a mandatory personhood wall.) An optional small refundable stake to launch a token (to price swarms linearly) is proposed but not built.

The two-price design - a bot-filtered "shadow price." The deepest anti-bot idea in the system is to stop trusting a single number for two very different jobs. A token has one price that both the SITE displays and the CONTRACT settles on; the design splits them:

a settlement price that stays hardened and on-chain - the smoothed moving average the battle rules already read, the number money actually moves on, deliberately hard to move and impossible to fake;
a display price computed off-chain that filters OUT the trading the bot-detection flags as inauthentic - a per-wallet "shadow curve" that shows the market as it would look without the wash trading, so the site reflects genuine demand instead of manufactured volume.

The two never touch: the shadow/display price is presentation only and can never reach settlement, so it carries no custody or market-integrity risk. The detection behind it - exactly which trading gets filtered out - is meant to be refined against real data, which is why it lives behind the swappable price-source pointer rather than being hardwired: because the battle price sits behind that pointer ("Immutability & evolution"), the bot-filtered price source can be sharpened over time with a single-contract deploy plus a one-transaction registry update - no factory reset, and nothing already graduated affected. It is the same swappable bot-detection module the governance section describes the community eventually helping to improve.

6. In-game currency, prediction markets & governance (the off-chain economy)

D4L has a second economy that lives only in the backend database, never on-chain.

Off-chain and strictly non-convertible. Players buy an in-game currency with USDC, then spend it inside the platform. That currency can never be converted back into USDC, crypto, or cash - it is a one-way, closed loop (like Robux or V-Bucks). This non-convertibility is the deliberate regulatory firewall: a closed-loop game currency is treated as a game item, not a regulated financial instrument. There is no cash-out anywhere in the system, by design. (The current display name "Degen Points" / "DP" is a placeholder.) Regulatory verdict (2026-07-04): low-risk ONLY while this wall is absolute - under FinCEN's 2013 guidance a strictly closed-loop currency is not money transmission and not a gambling "thing of value"; but ANY redeemability, transferability-for-value, or use of the currency to place wagers converts both analyses and requires immediate counsel review. The wall is load-bearing: it lives in code AND Terms of Service.

The one-way on-ramp. Players buy currency by sending USDC to the platform treasury (paying the small network fee in USDC, never needing ETH), and coins are credited only after the payment is proven on-chain - the transaction must have succeeded, moved the exact expected amount, and gone to the treasury. Each on-chain payment can be credited exactly once (tracked by its unique transaction fingerprint, so retries or chain replays never double-credit), and only to the account that actually paid. Improvement to adopt (2026-07-04): credit instantly, confirm on-chain - the same model everything else uses. Waiting for on-chain proof before crediting is stricter than it needs to be: the backend submits the payment itself (it has already checked the balance, simulated the transfer, and sent it), so coins can be credited the moment the payment is validated and sent - instant, gamified - with the on-chain proof remaining the source of truth: the credit finalizes on confirmation, and in the rare failure the ledger reverses (the coins, and anything bought with them, all-or-nothing), exactly like a reverted trade (Section 7). The closed loop is what makes this safe: because the currency can never be cashed out, the worst case of a failed payment after an instant credit is clawing back game items - never a leak of real money.

Packages (placeholder values - no real thought has gone into these numbers yet). Base rate is 100 coins per $1, with bigger bonuses on bigger packages: $5 → 500 coins (+0%), $10 → 1,100 (+10%), $25 → 3,000 (+20%), $50 → 6,500 (+30%), $100 → 14,000 (+40%). To be clear about their status: these are placeholders that were never seriously designed - the rate, the tiers, and the bonus curve all still need to be actually figured out (pricing psychology, what a coin should be worth against store items, and how the bonuses ramp). Changing them is a config edit that doesn't change how the flow works. Currency can also be earned in-platform (event rewards, a daily bonus, prediction winnings, admin grants), not only bought.

The store.

Currency is spent on four item types: badges, fighter skins, fighting moves, and emotes. Skins and fighting moves are cosmetic/gameplay flair (e.g. a special KO animation); badges and emotes are profile items. (Governance weight is no longer a store item - it is earned, not bought; see Governance below. Badges now display earned standing rather than carrying purchased votes.)

A purchase is all-or-nothing (coins deducted and item granted together, or fully rolled back), and you can't buy the same item twice.

Governance. The first place governance shows up is the 4GRUDGE community vote (nominating which community token faces a well-known "OG" token in a grudge battle). The original design computed a voter's weight as a base vote of 1 plus the weight of every governance badge they had bought - which meant voting power could be bought outright. That changed: a voter now has to qualify first (they must actually hold money on the platform and use it - the same eligibility that makes the bot-filter meaningful), and their weight is a base vote of 1 plus their earned grudge-realm reputation, never anything purchased. Weight is always computed server-side from what the player has actually earned, never trusted from the browser, and a wallet the bot-detection flags does not qualify at all. This is the narrow, live-facing edge of the wider earned model described below.

A wider governance model - "Proof of Culture." The badge weight above was a narrow starting point: it decided only 4GRUDGE nominations, and it was bought outright. It has grown into a proper earned-reputation system - "Proof of Culture" - now designed and built as a staged, off-chain backend engine (see "Current status"). The design is below.

The split is about who is best placed to make each decision. For the platform experience - what users want, what makes the game better, what content gets made - the people who use it most are the best judges, the same way the players who play a game most know best what would improve it. So we give them real weight on those decisions. It makes the platform better and gives users real influence over it. D4L keeps the decisions it has to own as a business, and those do not go to a vote. This is what would make D4L an actually decentralized platform, not just a Web3 app running on a blockchain.

What the community could govern:

The war chest - where a set-aside portion of fees goes across the platform (development, rewards, bug bounties, features), within an allocation D4L sets, and never paid to voters directly. This presumes the war-chest subsystem of OPEN DECISION #2 exists, and it governs only what that fund spends on - never the on-chain fee destinations, which stay keyless.
Creative content - which animations, fighter moves, skins, and cosmetics get made.
The bot detection - the filtering would be a swappable module, so the community could submit improved versions. A submission is scored against a benchmark of known bot and real behavior, the way AI models are ranked, and only one that measurably does better becomes a candidate. It is tested by others, the score is publicly reproducible, and it clears the safety process and a vote before use.
Grudge matchmaking - which outside token to grudge against (the 4GRUDGE vote above, widened).
Direction and tuning - bounded settings such as how strict the bot-filtering is.

What stays with D4L: the core economics and revenue, the safety of outcomes and the real price, and the business and legal direction.

How governance is earned - Proof of Culture. Weight is not one pool - it is split into separate realms, each earned its own way, because being good at one thing should not silently buy you a say over another:

a usage/content realm earned directly by genuinely using the platform and spending on it - the more you really use it, the more say you get over content and product direction, with the gains tapering so no single big spender dominates;
heavier realms - the war chest, and safety/bot-detection - that you cannot earn just by being active: they take a successful contribution, one that measurably turned out well (a grudge pick that then did real volume, a bot-detection improvement that measurably works), and only then does your ordinary activity amplify it. No success, no weight in that realm, no matter how busy you are.
a grudge realm earned by being genuinely good at picking grudge matches, scored the way a forecaster's track record is scored - you gain for calling them right, not merely for voting.

Each realm hands out tiered badges automatically as your underlying weight in it crosses set thresholds, so a badge becomes proof of what you earned, never something you buy - the underlying number is continuous, and the badges are simply its visible tiers. Two things keep it honest: reputation decays over time, so weight reflects who is contributing now rather than who was early once; and closely-correlated accounts are discounted together, so you cannot split yourself into a crowd. And the whole thing is bot-filtered and tied to your D4L account (external wallets take part by linking to an account): a wallet the bot-detection flags earns zero governance weight, which is what stops anyone from farming a say simply by manufacturing activity - the same bot-filtering the shadow price (Section 5) feeds. Because a flagged wallet earns zero weight, this leans on the same bot-detection as the shadow price (Section 5): as that detection sharpens, so does the integrity of every vote. (Both the correlation-discount and the flag-zeroing are built as seams wired to the shared bot-flag store, but stay inert until governance is activated and the store is populated - see "Current status".)

How it would stay safe. Every governed lever is bounded: each setting can only move within limits fixed in the contracts, every change is announced with a public delay before it takes effect, and no change alters a battle already underway. Nothing governed can reach the core economics, an outcome, the real price, or D4L's revenue.

Why it can roll out in stages. The earned-reputation engine is built and staged now, but governance does not have to be fully live at launch - it is off-chain, so widening or correcting it is ordinary product work, not a contract change. The plan is to switch it on in stages: begin with the narrow 4GRUDGE vote, then widen the realms as the math is calibrated against real data and the bot-filter is wired in (see "Current status"). Where a future lever ever touches the contracts - for example war-chest spending - it is designed to widen by a registry update or a single-contract deploy, never a factory reset.

📅 Added 2026-07-16 Holding - rewarding the people who hold, to lengthen a token's life. The realms above are earned by using the platform and by proven contributions. There is one more way to earn governance, and it exists to fight the single worst habit of meme coins: the instant pump-and-dump. We reward people who buy and hold real tokens - the bigger the position and the longer they hold, the more governance they earn - because rewarding holding is exactly what lengthens a token's life, which is the whole point of the platform. Like everything else here it is non-redeemable reputation, never money, and it follows the same iron rule as the rest of the model: holding only ever amplifies governance you already earned another way - it can never create governance out of nothing, and it can never unlock a realm you have not legitimately earned into. A pure bag-holder who never contributed still has zero say in the earned realms; holding just makes what you did earn count for more. The four things it measures. Your one holding score is built from four ingredients multiplied together, so all four have to be real for it to count:

Is the token real? Only a graduated token with real liquidity counts (graduation being the same 50-distinct-buyer, $54,321 bar from Section 2). A coin still on the bonding curve, a dead micro-cap, or - crucially - a coin you minted yourself and never truly graduated all count as zero and are ignored entirely. This is what stops "mint my own coin and hold it forever to farm governance."
How much is really at risk? The current dollar value of what you still hold, counted with strong diminishing returns so whales never dominate.
How long have you held? Rising fast over the first weeks, then flattening - holding longer pays more, but "hold forever" is capped, not infinite.
Are you still holding right now? The score tracks your current position, so selling part cuts the ongoing reward in proportion while you keep whatever you already banked.

The exact math, in plain terms.

Amount. Turn the dollars you still hold into "amount points" as amount = square root of (dollars at risk / 100). The square root is the anti-whale rule: $100 gives 1 point, $5,000 gives about 7, and $500,000 gives about 71 - so 100x the money is only about 10x the reward, never 100x.
Duration. A multiplier that starts at 1 for a fresh hold and climbs toward a ceiling: duration = 1 + 2 x (1 - e^(-days held / 30)), frozen once you pass 180 days. That is about 1.4x at a week, 2.3x at a month, 2.7x at two months, and its 3x ceiling by three months - and it never climbs past the 180-day cap, so nobody is paid just for sitting on an ancient bag. Anything held under 3 days is cut toward zero, which kills flash holds.
Rate and banking. Each day a position earns is-it-real (0 or 1) x amount x duration in conviction points, and that running total also fades on a 35-day half-life. Because you keep adding while you hold, a steady position climbs to a stable, finite level and never runs to infinity; when you sell part you stop adding on the part you sold but keep what you banked, and it simply fades from there over the next couple of months.
Across tokens. If you hold several real tokens they are combined with diminishing returns - the biggest counts fully, the next counts half, the next a third - so spreading the same money across many coins saturates instead of stacking.
The boost. Your one holding score then lifts the governance you already earned, capped: up to +50% on the use-the-platform realm, and up to +100% (war chest / safety) or +50% (grudge) on the earned realms - but only on top of standing you already earned there. If you earned nothing in a realm the boost there is zero, and if your holding score is zero nothing changes for anyone.

Backing a winner. Holding a token through a battle win earns its holders a real, earned grudge-governance credit - because backing a winner and holding it is proven judgment, the same kind of achievement as nominating or creating a winning token. Holding the winning 4GRUDGE champion through its grudge pays the most; then, if you keep holding it as it climbs the prestige ladder, each ladder win it earns while you hold stacks another, smaller credit. Sell it or let it start losing and the credits stop (you keep what you banked); and because the credit is scaled by conviction you have actually built up, someone who buys the instant before a win earns essentially nothing. How every farm attempt fails. A $2 bag or a self-minted coin scores zero on the "is it real" gate or the amount, so forever times zero is still zero. A whale with 100x the money gets only about 10x the raw score and, after the caps, under 2x the actual effect. Wash-trading in a loop holds nothing over time and pays fees, so it earns nothing. Splitting one bag across a hundred wallets is defeated upstream - governance only counts for real accounts, and the correlation-discount collapses a coordinated cluster back to about one honest holder. Flashing a big balance for a single moment earns almost nothing, because the reward is built from held time, not a snapshot. The numbers to set (these are decisions, not code). The values above are starting points chosen from research into real meme-coin lifespans; they are meant to be reviewed and set as a product decision, and most are safe to publish while a few (marked private) should stay internal so they cannot be gamed:

How much more the longest holds earn (currently a 3x ceiling) and where the curve is steepest (around 30 days) - the shape of the loyalty reward.
The hold-forever cap (currently 180 days) - past which age earns no extra, so dormancy is not farmable.
The minimum hold (currently 3 days) - below which a hold is cut toward zero.
How slowly earned holding-governance fades after you sell (currently a 35-day half-life) - long enough to honor real loyalty, short enough that someone who dumped months ago does not keep voting; research says keep this under about two months.
The two boost caps (currently +50% on the use-the-platform realm, up to +100% / +50% on the earned realms).
The size of the "backed a winner" bonuses - the 4GRUDGE one is deliberately larger than the ladder one.
(Private, set from live data:) the benchmark holding score at which the boost maxes out, the exact "is it real" quality thresholds, and the amount scale.

What stays true no matter the numbers: holding only ever amplifies earned governance and can never open a gate; whales stay sublinear; and dust, self-mints, wash loops, wallet-splits, and flash balances all round to zero. Status: designed and built as a staged, off-chain engine and running in shadow (it computes each account's holding score but binds no live vote yet); the starting numbers above are to be set from research and then calibrated against real data before it is switched on, exactly like the rest of the Proof-of-Culture model.

Prediction markets.

📅 Added 2026-07-16 Players forecast battle outcomes by staking the in-game currency, and winners are paid in the in-game currency. Because the stakes and payouts are all the non-redeemable game currency - never USDC or real money - it is a game mechanic, not regulated betting. The mechanism is a classic parimutuel (a shared-pool bet, like a racetrack tote): everyone who backs a side stakes into that side's pool, and when the result is known the winning side splits the whole market's money in proportion to how much each winner put in. There is no fixed price and no counterparty - your odds are just your share of the pool, and they drift in real time as other people bet. The house seeds it, and takes a burned rake. Every market opens with the house seeding each outcome equally with 1,000 coins, so a two-token battle market opens at exactly 50/50 and neither side is ever empty. That seed is house liquidity, not a payout claim - it is never paid back out. The house then takes a 5% rake, and the rake is burned: removed from circulation, credited to no one. The live odds. Write each outcome's pool as M_i (its 1,000-coin seed plus every stake placed on it) and the whole market as T (the sum of all the outcome pools). Then for outcome i:

Implied probability (what the market "thinks" the chance is): p_i = M_i / T.
Decimal odds (what one staked coin returns if that side wins): odds_i = 0.95 x T / M_i, where the 0.95 is the post-rake multiplier k = 1 - 5%.

The less money sits on a side, the higher that side pays - the parimutuel's defining feature: backing the underdog is worth more. The payout. At settle the winning outcome w is frozen with its pool M_w and the market total T, and every winning stake is paid payout = floor( 0.95 x stake x T / M_w ). Flooring is always down, so the winners' payouts summed together can never exceed k x T - the house can never pay out more than the market took in after rake. The losing side's stakes, the winning seed's own share, the 5% rake, and the fractional flooring dust are all burned. (The arithmetic runs on exact integers, so even a very large stake is never off by a single coin in either direction.) Worked example. A market for Token A vs Token B opens seeded 1,000 / 1,000, so T = 2,000 and both sides read 50%. Players then stake 4,000 on A and 1,000 on B:

The pools become M_A = 5,000, M_B = 2,000, so T = 7,000.
The board now reads A about 71.4% (5,000 / 7,000) and B about 28.6%.
Decimal odds are A = 0.95 x 7,000 / 5,000 = about 1.33x and B = 0.95 x 7,000 / 2,000 = about 3.33x - B is the underdog, so it pays far more per coin.
Token A wins. Someone who staked 1,000 on A is paid floor(0.95 x 1,000 x 7,000 / 5,000) = floor(1,330) = 1,330 coins, a 33% gain. Everyone on B loses their stake (burned). Had B won instead, that same 1,000-coin stake on B would have returned about 3,325 coins.

Lifecycle. A market opens the moment its battle is paired (at 50/50) and takes live bets; it locks - no further bets - when the battle crosses its KO/forfeit line or reaches its end time; and it settles on the confirmed on-chain winner, inheriting the same finality/reorg guard the battle keeper uses, so a payout is never made on a result that could still reorg away. A battle that never really happens (a walkover with no bets) voids, and a void refunds every stake in full. Both settle and void are exactly-once and atomic - the entire market pays out (or refunds) inside a single database transaction, so no one is ever double-paid or half-paid. Economy note (the one thing to tune). The 5% burned rake is the structural sink and the 1,000-coin seed is a structural subsidy: whether any one market nets a small mint or a small burn depends on how lopsided the betting was, but across many markets the rake is what stops minted winnings from inflating the currency. This is the piece to tune before a wide rollout - the seed size, the rake, and an optional per-market stake cap (off by default) are all configuration, photocopied into each market the moment it opens, so a later change never alters a market that is already live. Status: implemented as a testnet build for internal testing (open, bet, live odds, settle-on-real-winner, void-and-refund); the live-app rollout and the economy tuning above are the remaining work.

Ledger integrity. Every balance is derived from an append-only ledger where each credit and spend is its own permanent line; the fast-to-read wallet balance is kept in sync with it in the same step, so the two can never drift.

7. Accounts, gas in USDC & the real-time/gamified layer

Chain and money. The platform runs on Base (a fast, low-fee chain; mainnet chain 8453), with Base Sepolia (chain 84532) as the testnet. All trading and pricing is in USDC (a US-dollar stablecoin, 6 decimal places); on testnet a free stand-in (MockUSDC) lets testers be given practice funds. Network gas is ultimately paid to the chain in ETH under the hood, but users never hold ETH: they pay their own gas in USDC through a paymaster, so there is nothing to acquire or manage besides USDC (below). Moving from testnet to mainnet is a single configuration switch.

No seed phrases. Users log in with email, Google, Twitter, or Apple (or their own external wallet - see "Sign in with your own wallet" below). Behind the scenes the platform provisions each user a modern smart wallet (a smart account) that holds their USDC and executes their trades; the user never sees, stores, or is responsible for a private key or seed phrase. Note for later sections: the login creates an underlying "owner" key and a separate smart account, and it's the smart account that is the on-chain identity - it's what holds USDC, what pays its own gas in USDC, and what any on-chain ban would have to target.

📅 Added 2026-07-16 Sign in with your own wallet. A user who already has their own external wallet can sign in with it instead of a social login. In that case the external wallet is used only as a login credential - a way to prove who they are - and the platform still automatically provisions them an embedded smart account behind it, exactly like every other user, with no separate account-creation step: that smart account is created for them on first sign-in. The embedded smart account is what actually trades, holds USDC, and pays its own gas, so external-wallet users trade on the same path as everyone else and count as holders just the same. The one difference is deliberate: signing in with an external wallet does not by itself grant the full account tier, so those users are excluded from leaderboards and governance, which stay account-tier-gated (an external wallet can still take part in governance by linking to a full account - see Section 6). One account, one wallet. Each social login creates exactly one account with one default smart wallet, and account creation is capped per IP by the backend, so one account = one default wallet and the per-IP account cap is also the per-IP wallet cap. Buying on the curve is not gated on being a registered platform wallet: platform smart wallets and users' own external wallets buy on the same open terms and both count as holders (Section 5). The backend still records each account's default wallet for its holder-count mirror and moderation, but that record is bookkeeping, not a gate on who may trade. 📅 Added 2026-07-16 Users pay their own gas - in USDC, never ETH. Every action - create, buy, sell, and buying in-game currency - is submitted from the user's smart wallet through a paymaster that lets the network fee be paid in USDC, so the platform does not subsidize gas and the user never has to hold or spend ETH. The paymaster is self-configured by the platform (it accepts USDC and settles the ETH gas underneath), so a user only ever needs USDC - a little on top of the actual trade amount to cover the small network fee - and never a separate gas token. Paymaster access is guarded server-side. The browser never talks to the paymaster service directly (that would leak its secret key and let anyone abuse the gas relay). Instead it goes through a backend proxy that keeps the key server-side and enforces: only allowed request types, only genuine D4L smart accounts, only approved contracts (the current factory and USDC), plus a flood limit (about 240 paymaster calls per minute per user/IP; a normal trade is ~2 calls).

The backend signs one thing: token creation. For a create, the backend issues a short-lived authorization (30-minute validity) bound to that user's smart wallet, the token name/symbol, the chain, and the specific factory; it refuses if its chain config or signer doesn't match the live network. It never signs buys or sells - those go straight from the user's smart wallet through the paymaster path. Otherwise the backend only reads chain state and records what happened.

Testnet faucet (testnet only). On testnet, accounts are auto-topped-up with free practice USDC (1,000,000 per top-up, 5-minute cooldown) and re-minted if a balance drifts to zero after a test-chain reset. This is disabled on mainnet by a default-deny rule.

The "instant feel" - optimistic projection. The site feels immediate because when a user buys or sells, the backend first simulates the trade against current chain state. If it would fail, the user is told at once and nothing is sent to the chain. If it passes, the predicted new price and market cap are broadcast live to everyone watching that token, and the user sees the result immediately, while the real transaction is submitted in the background.

The mirror covers the holder count too - so graduation is instant. The backend tracks the live holder count (up when a wallet first buys, down when it fully sells) alongside market cap and token age, mirroring the contract's exact rules. That's what lets the app show "X / 50 holders" and flip a token to graduated the instant all three gates are met, instead of waiting on the contract or a keeper. The chain confirms right after and stays the source of truth: the graduated flag and the pool deployment are reconciled from on-chain, and a rare mismatch rolls back just like a reverted trade.

The blockchain is the source of truth. After showing the prediction, the backend submits the real transaction and waits. On success it confirms and syncs real balances; on failure it rolls the display back and broadcasts a "trade reverted" signal. Critically, whether a token has graduated is never faked from a predicted number - it is only ever taken from the actual on-chain flag, because the extra graduation gates may not be met.

No accidental double-spend. The moment a user starts a trade, a per-user lock is held through the whole background submission, so a double-click or impatient retry is rejected ("trade already in progress") rather than firing a second real transaction that would spend USDC twice.

Live updates. The site keeps an authenticated real-time connection: market/price changes go to a shared room so all viewers of a token update together, while a user's private balance changes are pushed only to that individual (updating the header/trade panel within ~100 ms). There are per-IP connection and handshake limits to prevent abuse.

Two run modes, never mixed. The platform runs in a real mode (wired to the live chain, actual on-chain trading) or a showcase mode (a mock market simulation for demos, no contracts) - the configuration refuses contradictory combinations, and there is a kill-switch to temporarily freeze on-chain trading for maintenance while the rest of the site stays up. (The showcase deployment runs on separate infrastructure with mock market data; the real deployment runs against Base Sepolia.)

8. Identity verification & the KYC badge (optional, display-only)

📅 Added 2026-07-16 D4L lets any user optionally prove they are a real, unique human by verifying a government ID, and wear a "verified" badge for it. The badge is display-only and gates nothing - not trading, not token creation, not graduation, not battles. Nobody is ever required to verify, verifying unlocks no mechanical advantage, and skipping it takes nothing away; it is a cosmetic mark that a real, checked person stands behind the account. Why it exists. D4L is a player-versus-player battleground, so the most valuable thing to know about a token is whether the wallets behind it are real people or a bot swarm. A token whose holders are mostly verified humans is visibly a real PVP token - real players, not bots or sybil wallets - which is the whole point of the format. So each token can carry a "percent of holders verified" signal, letting a buyer judge legitimacy at a glance, the same way the anti-snipe fee and the live holder count already let the market read a launch. For the platform, the verified-identity data is itself a genuine, valuable asset - the same reason the major exchanges own theirs. We own the data - the exchange model. The check is run the way Coinbase and Kraken run theirs. A specialist verification vendor does the machine-learning work - is the ID document authentic, does the selfie match the ID, is a live person really present - and then retains nothing. Every artifact (the ID images, the identity fields read off the document, and the selfie / liveness capture) is pulled into D4L's own encrypted storage, and the vendor deletes its copy. D4L is the sole system-of-record: we hold the data, and no third party keeps a copy. Two clocks - keep the identity record, purge the face fast. The two kinds of data are treated very differently on purpose, because they carry very different risk and very different value:

the identity record - the ID images, the name, date of birth and ID number, and the pass-or-fail result - is kept as the platform's asset, written once and held on a roughly five-year clock;
the biometric - the selfie and the face match - is purged fast and is built to be crypto-shreddable, so destroying one key erases it for good.

The reasoning is blunt: the biometric carries the most legal risk and the least asset value, so it is held for as little time as possible. The result is that D4L owns a real identity database without hoarding a library of faceprints. Consent first, always. Explicit written consent is captured and enforced before anything is collected - the verification cannot even start without it. What it costs - and why the real cost is not the technology. Standing the feature up is cheap. The moving parts are about $1 per verification, near-zero storage (on the order of a tenth of a cent per user per year), plus the engineering, which is built. The larger costs are not launch costs at all - they are the enterprise-grade custodian overhead a platform grows into as it scales, the cost of being trusted to hold identity data rather than the cost of collecting it:

a SOC 2 audit (about $25k-$80k);
penetration testing (about $10k-$30k);
cyber / breach insurance, which runs higher for a crypto platform holding biometric data (about $15k-$50k a year and up - and the policy has to be checked to confirm biometric data is not excluded);
and a privacy function, anywhere from a fractional privacy officer (about $30k-$80k) up to a full data-protection officer.

The important shape of this: that overhead is roughly flat whether the platform has ten thousand users or a hundred thousand, so per user it only shrinks as we grow. Stated plainly: owning the data is cheap; being a trusted custodian of it is the real, scale-independent expense. Protecting the verification bill - and the fallback if it is ever abused. Because each real verification costs about a dollar, someone hostile - a rival, for instance - could try to run the bill up by firing off junk verification attempts. Two things stop that. First, before any attempt ever reaches the verification vendor, the platform rate-limits it, so the same person or network cannot keep spawning fresh checks - and pure garbage such as a blurry photo or an abandoned attempt is never billed at all, because only a genuine, completed check costs anything. Second, the launch vendor (Persona, run the exchange way described above) bills for every completed check, so if a flood of junk ever did get past the rate-limit there is a ready fallback: a second vendor (iDenfy) offers a mode that bills only for approved verifications - where a rejected or abandoned attempt costs nothing - for a small premium, roughly fifty cents more per approved check on top of a low monthly minimum. The plan is deliberate: launch on Persona, watch the real decline-and-abuse rate, and move to approved-only billing only if the data shows we need it - insurance we buy the moment it pays for itself, not before. The legal picture - collecting IDs needs no license, but holding them creates real duties. No license is required to collect this data. Money-transmitter / MSB status turns on controlling other people's funds, not on collecting identity documents, and D4L is non-custodial - so verification does not pull the platform into a licensing regime. The obligations here are privacy-and-security obligations, not licensing ones:

written consent BEFORE any biometric capture - this is the Illinois BIPA requirement and the single most important defense, because BIPA carries $1,000-$5,000 per person and is a class-action magnet; it is exactly why the biometric is purged fast and held as briefly as possible;
a public retention-and-deletion policy;
real security - encryption is both the control itself and, under most breach-notification laws, a safe harbor if data is ever exposed;
honoring deletion requests;
and a privacy policy.

Because the badge is optional and gates nothing, and the data is never sold (selling biometric data is itself banned), the exposure is bounded. Where it sits with counsel (an open item, not settled here). Holding biometric and ID data still makes D4L a data custodian with real duties, and it softens the platform's otherwise clean "purely non-custodial, not a regulated intermediary" posture. Neither of those is treated as resolved in this document. Both the decision to hold biometric / identity data at all, and the way it softens the non-custodial posture, are flagged for the crypto-securities and privacy counsel review alongside the other open regulatory items (see "Cross-cutting regulatory items"), not decided here.

9. Grudge matches / 4GRUDGE

A grudge match is a community token squaring off against a well-known "OG" token, where the community nominates the challenger through the earned, eligibility-gated governance vote described in Section 6. Anyone can create a token specifically FOR a grudge battle - and it still launches and graduates through the ordinary gates like any other token; the grudge event does not bypass graduation. The grudge only decides where a graduated token enters the prestige ladder.

How a grudge is decided (the rebuilt design). The two sides are compared on the one thing that is fair across tokens of very different sizes: the dollar increase in market cap each achieves over the grudge window (a fixed window, currently set to 24 hours). The larger dollar gain wins. This replaces the earlier broken approach of comparing the two sides on mismatched scales, where one side effectively always won. There is no prestige at stake inside the grudge itself.

What the winner gets - a ladder placement, not a shortcut. Winning a grudge does not hand out a prestige level for free. The winning token is placed onto the prestige ladder at the level whose tokens' average real market cap is closest to the winner's own market cap after the battle - so it enters among genuine peers, neither handed a top rung nor buried at the bottom.

How the placement is done. The placement level is computed off-chain from the live ladder's market caps (the average real market cap at each prestige level, nearest to the winner's post-battle market cap) and then written on-chain through a one-time, single-purpose call that only sets where an already-graduated winner sits - it never touches graduation itself. The early-knockout number for the grudge window is still a placeholder to settle.

Where the money goes (fees & treasury)

Every fee - the $4.44 creation fee, the 1% (or 60% launch) buy fee, and the 2%→1% (plus anti-dump) sell fee - routes to a single, immutable treasury address fixed at deploy. There is no fee-split and no separate "war chest" - one treasury, no admin able to redirect it. (OPEN DECISION #2, partner meeting: the Arena Curve spec's 55% platform / 45% per-token "war chest" split is not built - it needs the war-chest subsystem to exist - and is a pending product decision. Fee DESTINATIONS are the sacred, keyless part of the posture; fee RATES are registry numbers under Section 1's green-lit plan.)

Two structural facts about where fees can and can't come from:

Pre-graduation, fee capture is total, by construction. The token is non-transferable except through the platform's curve, so the bonding curve is the only market that can exist for it - and the fee is baked into the contract itself. Every buy and sell pays the treasury regardless of what interface produced the trade (our site, a bot, a raw script). Nobody can trade around the fee, because there is nowhere else to trade.
Post-graduation, the platform captures a share of every swap fee. A graduated token's pool charges a swap fee on every trade, and a share of that fee flows to the D4L treasury - in-protocol, from every interface (our site, a bot, a raw script), unavoidable because the pool is the only venue the token has. On the live Curve venue the pool charges 0.26%-0.45% of volume (sliding with pool balance) and splits it 50/50 by a hardcoded pool constant: half compounds into the pool's own liquidity - which the vault holds, so it deepens the token's market and returns to its curve on a de-graduation - and the other half is the platform's, claimed to the treasury (D4L runs its own copy of the pool factory with the fee receiver set to the treasury, so the outside DAO earns nothing from our pools; the admin share accrues in the pool and is swept by a keeper). Under the move to Uniswap v4 (see Current status) the same capture is done by the platform's own pool hook, which skims the platform's share of each swap straight to the treasury - the same outcome, and that share is a value we set on our own hook - re-tunable by deploying a new hook and repointing the venue at it, a single-contract deploy plus a registry update, never a factory reset. So platform revenue = creation fees + bonding-curve trading fees + the platform's share of graduated swap fees + the in-game currency on-ramp. This directly aligns the business with the battles: the longer a token lives and the harder it trades, the more it pays the platform.

Sources of revenue - the complete list. Everything above and throughout the doc, combined in one place:

Creation fees - a flat $4.44 USDC per token launched, paid to the treasury at creation.
Bonding-curve trading fees - 1% on buys (60% during the launch anti-snipe window), 2% sliding to 1% on sells, plus the whale-dump surcharge (up to +15%) on oversized single sells. Capture is total before graduation: the curve is the only market that can exist for the token, so every trade pays, from any interface.
Graduated swap fees - the platform's share of every swap fee on every graduated token's pool, in-protocol and unavoidable, captured to the treasury (on the live Curve venue that share is 50%, split by the pool and swept by a keeper; under Uniswap v4 the pool hook skims the platform's share directly, and that share is a value we set on our own hook - re-tunable by deploying a new hook and repointing the venue at it, a single-contract deploy plus a registry update, never a factory reset).
In-game currency sales - the one-way USDC-to-coins on-ramp. Note the economics: the store, paid fighter moves, and (if ever built) prediction-market stakes are all coin SINKS, not separate revenue lines - the revenue is realized when coins are bought, and everything spendable exists to drive that demand.
Treasury skim - stray USDC sent directly at the contracts sweeps to the treasury. Incidental recovery, not a business line. The alignment across all of them: the platform earns from activity and longevity - launches, trading on both venues, and an engaging enough game that people buy coins - never from holding users' funds, which it structurally cannot do. (Verified on the live Curve venue: the pool's admin-fee split is 50% in the pool's source, and our live Base Sepolia factory 0xc1914b3...'s fee receiver reads as the treasury on-chain, so the outside DAO earns nothing from our pools. Under Uniswap v4 the same capture is enforced by the platform's own pool hook - see Current status.)

Current status & pre-mainnet checklist

Everything above describes the intended design. Here is what is actually live today and what still needs to happen before mainnet - this is the part most worth a careful read, since it's where "intended" and "shipped" differ.

Live now (Base Sepolia testnet, deployment d4l-base-sepolia-charter-v2):

The Charter v2 parameter-registry architecture is deployed: the bounded, timelocked settings registry (D4LParamsRegistry), the birth-pinned pricing engine (D4LCurveEngineV1), the read-only views lens (D4LTokenLens), and the one-shared-arena battle ladder (option B2) are all live. Genesis registry values reproduce today's economics exactly, so the gates, fees, and calibration below read unchanged; what is new is that those values are now registry-tunable for FUTURE tokens only (forward-only, bounded, timelocked), never for anyone already launched.
Graduation gates are the real rule: 50 current holders / 7 minutes / $54,321.
The battle KO/forfeit thresholds are being corrected to the real +100% / -50% (an earlier deploy carried a looser +30% / -20% test value); the battle window stays short on testnet (30 min) only so the timer path is testable without a 24h wait.
Being built now - the holder-gate Sybil posture: the earlier plan to wire a registered-platform-wallet-only buy gate has been dropped - external wallets buy the curve freely and count as holders. Sybil resistance for the 50-holder gate now leans on the anti-snipe launch fee (already live) plus a minimum-balance-to-count rule (to be enforced), backed by the per-IP account-creation cap (5/IP/24h) and the backend holder-count mirror that drives instant graduation progress.
Buy-ban moderation is still off (optional, wireable one-shot).
The soft-sniper detector is off / log-only.
Prediction markets now have a testnet build (a parimutuel on battle outcomes, staked in the in-game currency); rolling it into the live app is planned.
The in-game store catalog and all coin-package / badge numbers are placeholder values pending final tuning and a catalog seed.
Mainnet contract addresses are still empty - mainnet is not yet wired.
The live graduated trading venue is still Curve. The Uniswap v4 venue suite (D4L's own pool hook, the v4 adapter, the scoring module, the re-routed vault + ladder) and the on-chain 4GRUDGE ladder-placement path are built and in testing but not deployed; they land as one atomic cutover with the next contract release. Until then, graduated tokens trade on the live Curve pools.
The Proof-of-Culture governance engine is built but staged (off-chain, not yet active): the per-realm earned-reputation math, decay, tiers, and the 4GRUDGE outcome-credit hooks exist in the backend, but the module is not wired into the live app, the bot-filter that zeroes flagged accounts is not yet reading the flag store, and the governance math corrections are not yet applied. Governance is not live.
The bot-filtered shadow/display price, the shared bot-flag store, and the net-flow/wash detector are built but staged - display-only, not wired into the live app, and they never touch settlement.

📅 Added 2026-07-16

Gas is still platform-sponsored in the live app. The move to user-paid gas in USDC is built but config-gated: the USDC paymaster and the client path exist, but the live app currently runs the sponsored (platform-pays) path. Switching it on is a deploy-the-paymaster, flip-the-config, and test step (see "Before mainnet").
External-wallet sign-in shares the same trading path as social-login accounts (an auto-provisioned smart account does the trading, and those users count as holders); leaderboards and governance remain account-tier-gated.

Before mainnet (hardening + decisions):

Set the battle ladder to the intended production numbers (24h / +100% / -50%), or confirm new ones.
Finalize the Sybil-resistance posture for the holder gate now that the registered-wallet buy gate is dropped: enforce a minimum holding per wallet to count, tune the anti-snipe launch fee, and/or raise the 50 figure.
Calibrate the anti-dump surcharge steepness (currently a provisional value).
Re-populate the paymaster provider's dashboard contract allowlist (deliberately left empty during testing) as an independent second safety layer.
Roll prediction markets into the live app (a testnet build of the parimutuel exists). Seed the store catalog, and finalize the currency's real name/branding.
Settle the 4GRUDGE subsystem's placeholder numbers (the grudge early-knockout figure) - Section 9.
Harden handling of rare chain reorganizations after an optimistic update.
Design the stranded-winner exit before the first battle-rules change (only needed under the pinned options - see "Immutability & evolution"): winners left on an outdated ruleset need a rule-based, level-preserving way into the current one.
Wire trade-triggered instant checkpoints in the keeper: real-time KO/forfeit detection straight from the trade stream (checkpoint within seconds of the crossing trade), with the heartbeat as fallback - the gamified layer must never wait for a polling tick.
From the regulatory research (2026-07-04): the parameter registry (decision #4) is now BUILT and deployed on testnet (Charter v2) - before mainnet transfer its admin key to a multisig, set the mainnet timelock, and confirm the bounds; narrow the deployer key's "pause new graduations" power (emergency-only, timelocked, logged, ideally sunsetting); publish objective buy-ban criteria; publish objective goodwill-refund criteria for the skim; add the ToS non-refundability line; decide EU geofencing before any EU exposure; and put the eight counsel questions (in D4L_REGULATORY_MUTABILITY_ANALYSIS.md) in front of a crypto-securities lawyer before mainnet.
Deploy the Uniswap v4 venue suite as one atomic cutover: publish the hook, the v4 venue adapter, the scoring module, and the re-routed vault + ladder; do the three one-shot wirings (trust the adapter as the sole LP; set the vault on the adapter; set the grudge manager on the ladder); cut the addresses + ABIs over together; set the hook's swap-fee legs to Curve parity; its per-block manipulation-cost bound (maxTickMove) has now been sized from the out-of-band simulation and the price source hardened to a real trailing-window average that battle scoring and the de-graduation re-list both read, with a re-list lower floor - no longer a placeholder; confirm the dust-trade floors now read from the registry.
Apply the two authored database migrations before their features go live: the governance-tables migration and the wallet-flag (bot-flag) table.
Activate Proof-of-Culture governance: wire the staged engine into the live app; point the governance bot-filter at the shared bot-flag store (today it flags no one); apply the governance math corrections (make CONTENT weight require genuine usage, normalize the signal units, recalibrate the gated amplifier, and add the missing per-day inflow cap, net-of-wash spend netting, correlation-discount, and contribution-review / conflict-of-interest layers) before any realm is load-bearing; seed the genesis reviewer set for the gated realms; and validate the 4GRUDGE implied-probability source before GRUDGE weight decides anything.
Roll out the bot-detection / shadow price + net-flow/wash detector (display-only first, never touching settlement), then move enforcement from log-only through observe → review → enforce (buy-ban only; selling always stays open).

📅 Added 2026-07-16

Deploy the user-pays-gas USDC paymaster and flip the gas config from platform-sponsored to user-paid, then test the full path end to end (create, buy, sell, buy-currency) before launch - until this lands, the live app keeps sponsoring gas.

Open decisions index (each is discussed IN FULL in its own section - this is just the list for the partner meeting):

Health oracle - rejected, replacement (min-holding rule) to decide → Section 2.
55/45 fee split / war chest → "Where the money goes."
Pre-graduation transfers: keep the block vs the middle ground → Section 1.
Parameter registry - GREEN-LIT and BUILT; the Charter v2 registry (bounds + timelock + engine pointer) is deployed on testnet, and the three v4 pointer domains (venue / price source / scoring) are built but deploy with the v4 cutover. Remaining pre-mainnet work: transfer the admin key to a multisig, set the mainnet timelock/bounds, and land the v4 pointer domains → "Immutability & evolution."
Sell-out force-graduation (product call only) → Section 2.
Skim refund policy + ToS line + escheatment counsel item → Section 1.
Where battle rules live (B1 / B1.5 / B2) + how wide the fixed limits on battle rules may ever be - B2 is the option now BUILT + deployed on testnet, but keeping it for mainnet and the limit widths stay open → "Immutability & evolution."
Which curve a de-graduated token returns to (parked) → "Immutability & evolution."
Walkover forgiveness for unreadable pools (skip-and-requeue at pairing; bounded grace at settlement; the deadline numbers) → Section 3.
Launch access - stay gated, or open creation to everyone (and when). The signing gate is a rotatable, one-way-openable registry value (built); mainnet launches GATED. Opening is a deliberate later decision, gated on creator terms-of-service acceptance, a public creation feed for third-party launches, moderation of what the platform displays, and counsel sign-off on a creators-bind-to-no-terms world → Section 1 + "Immutability & evolution." Plus, not numbered: choosing the de-graduation-reset variant for the graduation gates (current gates outright vs easier-only) and setting the stranded-winner sunset days (both in "Immutability & evolution"), and the deployer-key pause-power narrowing (Section 4).

Cross-cutting regulatory items (no single section owns these):

The full sourced analysis behind every verdict above lives in D4L_REGULATORY_MUTABILITY_ANALYSIS.md, including the EIGHT exact questions for the crypto-securities lawyer - put them in front of counsel before mainnet.
EU: MiCA makes the platform's "DeFi exemption" from CASP licensing genuinely doubtful (the immutable treasury, programmatic pool deployment, and in-protocol fee capture all cut against it) - geofencing EU users pre-authorization is the conservative path; EU counsel separately.
Legislation watch: if the CLARITY Act passes as drafted, re-run the whole analysis (statutory ≥20%-control "mature blockchain system" test + a CFTC digital-commodity broker/dealer regime, where the 50% swap-fee capture becomes the key registration question).
Identity data (the KYC badge, Section 8): collecting IDs needs no license (D4L is non-custodial - money-transmitter/MSB status turns on controlling funds, not collecting documents), but HOLDING biometric and ID data makes D4L a data custodian with real privacy-and-security duties (BIPA-compliant written consent before any biometric capture; a public retention/deletion policy; encryption; honoring deletions; no sale of biometric data) and softens the platform's "purely non-custodial, not a regulated intermediary" posture. Both the decision to hold this data at all and that softening go to the crypto-securities and privacy counsel review - not resolved here.

Known stale numbers to fix (not design questions - just wrong text):

The in-app support AI currently tells users the creation fee is "5 USDC." The real, enforced fee is $4.44. This should be corrected so the support assistant stops quoting the wrong number.

Immutability & evolution - the strategy for changing as much as we can, without redeploying, within regulatory bounds​

1. Token creation & the bonding curve (the launch market)​

2. Graduation - the three gates​

3. Battles & the prestige ladder (after graduation)​

4. Graduated liquidity & the no-rug guarantees (the vault)​

5. Anti-cheat, anti-bot & integrity​

6. In-game currency, prediction markets & governance (the off-chain economy)​

7. Accounts, gas in USDC & the real-time/gamified layer​

8. Identity verification & the KYC badge (optional, display-only)​

9. Grudge matches / 4GRUDGE​

Where the money goes (fees & treasury)​

Current status & pre-mainnet checklist​