D4L - Platform Rules & Mechanics
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.
📅 Added 2026-07-20 Four conventions are 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-20 update - the complete 4GRUDGE opponent-selection flow, overlapping discovery credit, logarithmic event vote influence, and the first-to-graduate challenger race - are highlighted in blue where they appear.
-
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.
- Instant graduation is live on the private test network (see "Current status"): a coin there is shown as graduated in the same update that shows the buy that graduated it.
- The 44-holder gate and the partial fill are not live on a network yet; they reach the private test network with its planned reset.
- The holder gate is 44 current holders, not 50 (Section 2): every rule in this document that said 50 now says 44.
- It is a registry update, so it applies to coins created after it takes effect, and every coin already launched keeps the 50 it was born with.
- The last buy is a partial fill (Section 2): when a coin already has its 44 holders and its 7 minutes, the buy that would carry it past $54,321 is filled only up to $54,321 - the buyer is charged only for the part that fills, the rest of their money is never taken, and the coin graduates at $54,321.
- Until now that buy filled whole and carried the coin past the line it was graduating on: a coin with 340 holders graduated at $54,461 because its last $25.59 buy filled in full, where about $5.45 of it was enough.
- A coin still graduates above $54,321 in one case only: its holders or its 7 minutes were still short when the buy that took it past $54,321 arrived, so trading carried on above the mark and it graduated at whatever its market cap was when that last gate was met.
- Graduation is instant (Sections 2 and 7): a coin graduates in the same transaction as the buy that meets its last gate, and every screen shows it as graduated at that moment, at the same speed a trade shows.
- Opening the pool and taking the ladder seat follow one block later, and nothing on screen waits for them.
- Until now the app said "all gates met - graduating" with a loader for about six seconds, because it waited for that second step before saying the coin had graduated.
- Status: the instant graduation is live on the private test network since 3 October 2026; the 44-holder gate and the partial fill are not live on a network yet (see "Current status").
- The partial fill is launch-contract code, so it reaches a network only with a factory reset, and coins already launched keep filling their last buy whole.
- Users have paid their own gas in USDC in the live testnet app since 5 August 2026 (see "Current status"). This document still said the app sponsored gas and that user-paid gas was built but switched off. The live app sends every user action from the user's smart account and pays its network fee in USDC through D4L's own USDC paymaster; D4L's guarantor fronts the fee and the account repays it within the same action, and Pimlico's hosted service submits the action to the chain.
- The private test network runs the same path for every account it simulates. Simulated and test accounts are funded with USDC only and pay gas in USDC through the same paymaster design. Only the paymaster's network-fee deposit and the platform's own infrastructure accounts hold ETH.
- Unchanged: the decided mainnet path is Pimlico's managed USDC paymaster with real USDC, where D4L holds no ETH at all. It has not been exercised end to end yet (see "Before mainnet").
- No market caps what one account stakes (Section 6). One account could hold at most 2.5x the per-outcome seed (2,500 coins) in one market, which refused an ordinary forecast from anyone who had already backed a side once or twice. A forecast is now bounded only by the player's own coin balance.
- A player can back both sides of the same market (Section 6), as on other prediction markets. Each side is its own position, and another stake on a side adds to it. Backing both sides can never lock in a profit: the winning side is paid from the final pools after the 5% rake, and no split of stakes between the two sides returns more than it cost under both results.
- The forecast rank scores each position and adds them up (Section 10), one result per player per market, so backing both sides at the same odds scores about zero rather than counting twice.
- Status: live on the private test network since 30 September 2026. Forecast markets are an off-chain game mechanic, so neither change touched a contract.
- A re-graduation opens its pool at the graduation price too (Section 4). A de-graduated coin's curve holds its whole recovered pot, which is usually more money than its smaller pool reserve can pair at the graduation price. The pool now takes exactly what pairs at that price, and the rest stays locked in the launch contract as that coin's own backing, going back to its curve if it is de-graduated again. Pairing all of it had opened a re-graduated pool at about 10 times the curve's last price, a jump anyone could take by buying the curve and selling into the new pool.
- The 7-minute clock counts from the re-listing after a de-graduation (Section 2), and the platform pokes a de-graduated coin within seconds of that clock clearing, the same as a fresh launch.
- Status: the poke is live on both test networks since 30 September 2026. The pool fix is built and tested; it reaches a network only with a factory reset (mainnet launches with it), and coins already launched keep the pairing their contract was born with. See "Current status."
- New: the No Contender - the top of the ladder never waits frozen (Section 3). "No Contender" is a placeholder name. Until now a coin that won its way to a level nobody else had reached sat frozen in the queue until another coin climbed up to fight it, which could take days or never happen. Now the coin alone at the highest level keeps its place in the queue but trades freely, and it is challenged in exactly two ways: a coin reaches its level, or a coin waiting below it climbs to its market cap.
- Every coin still moves one level per result, from its own level. A market-cap challenge is the one battle between two different levels: a level-2 challenger that wins climbs to level 3, and the No Contender it beat drops one level from wherever it stood.
- One trade-off is written down rather than left implicit: a No Contender's next battle starts from wherever its free trading took the price, so its holders can see a challenger coming. Moving the smoothed price down and back up costs real money on both legs; whether that is expensive enough is a pre-mainnet review item.
- Status: live on the test network since 17 September 2026. Going live was a single-contract deploy of a new battle ladder, and coins already pinned to the previous ladder keep today's rule.
- Every coin is now a tokenized fighter (Section 1). A coin still has everything any meme coin has - a name, a ticker and a logo, where every wallet and screener already looks - but at creation it also permanently records the fighter it is: its body, its skin, the logo coin that forms its head, the fight moves it owns and the license that governs it. The token keeps a fingerprint of that record that can never be changed, so buying the coin is buying a share of that exact fighter, and nobody, D4L included, can swap it later.
- The fighter's look travels; the fight stays on D4L. Other sites may show a D4L fighter wherever they show the coin, and that reach is intended. The move animations, the choreography that turns buys into punches, the arena and the battle engine are D4L's game and are not part of the token. The line is held by copyright, trademark and the fighter license rather than by hiding files, because anything a browser draws can be copied.
- The launch approval now also covers the logo and the fighter (Section 1), so a launch can no longer carry a different logo than the one the platform approved.
- Store skins and moves belong to the player, not the token (Section 6). They change how a player's buys look in the arena and never alter the fighter a coin was born as.
- Pre-mainnet list: complete the app cutover and live browser checks for the deployed fighter factory reset, send the license draft to counsel, pin fighter records to permanent public storage, and file copyright registrations for the hand-built fighter body, moves and arena, plus the trademarks.
- New: "The player rank" (Section 10). Tokens have had a rank since the prestige ladder was written; this is the rank of the PERSON. It answers one question - who is playing the game best, which means winning the most battles with the most contribution - and contribution is the percentage of a token you held while it fought, never the dollars, so $600 in a fresh $60,000 graduate counts for as much as $6,000 in a token ten times bigger.
- One rule runs the whole thing. Every action scores once when it settles, and every score fades on a 60-day half-life, so a rank is always a statement about the recent past: it settles at about 87 days of your average daily score, a high rank costs far more to hold than a low one, and half of it is gone after two months idle.
- The seven ways a rank moves are written out with their formulas and worked numbers: backing a winner by holding through a battle it wins, selling into a loss (the only penalty, at 2.5x), holding a real token, creating a coin that wins, winning the corner-plate duels, forecasting at the odds you took, and riding a token from its bonding curve to graduation. Holding through a LOSS costs exactly nothing, and it makes the next win pay up to four times more - that is the rule the whole model is built around.
- It is standing, not money and not a vote. It pays no currency, decides no battle and never touches a price or a balance, and it is a separate ledger from the earned governance of Section 6 - backing a winner can earn both, and neither one buys the other. The numbers in it are dials; the ones that are real decisions are set out as cards, with the still-open ones at the end of the section.
- Sudden death now covers 4GRUDGE as well (Section 9). The rule is identical to the ladder's; only the unit differs. A ladder battle compares percentage gain, because it is two D4L coins under one price regime. A grudge compares market-cap gain, because it is a D4L coin against an outsider of completely different size - and that is already the yardstick a grudge uses to pick its winner and to write its knockout line. One caveat that is specific to a grudge: the opponent's market cap is only known when the reporting committee agrees a figure, so the lead only advances on a fresh agreed figure, never on a bare poke from a passer-by. Otherwise anyone could pump the D4L side and take the lead against a number nobody had re-checked.
- Sudden death: when both coins are past the same line, the contest becomes head-to-head (Section 3). Until now a knockout asked a question about ONE coin - "did it hold +100% for five minutes?" - and whoever's five minutes finished FIRST won on the spot. That is decided by who crossed the line earliest, which has nothing to do with who is winning the fight: a coin up 500% could lose to one up 101% simply because the other one got there first. From now on, while BOTH coins are past the knockout line neither can win by the absolute rule - the battle goes to sudden death, and the winner is whichever coin is AHEAD on percentage gain and stays ahead for the same five minutes. The forfeit line works the same way in the mirror: when both coins have collapsed past it, the one that holds the lead survives and the other loses. A coin cannot escape by dipping back under the line, because the moment it does, the opponent's original knockout - which has been counting the whole time, only suspended - lands immediately. Dead-even means nobody is holding above the other, so nothing ends early and the battle runs its window.
- The knockout and forfeit holds stay at 5 minutes (Section 3). They were raised to 15 earlier the same day and are being taken back to 5: a short hold ends fights fast and keeps them watchable, and that is worth more than the precision a longer one buys. The trade is written down in Section 3 rather than left implicit - a five-minute hold is shorter than the ten-minute average it is judged against, so a knockout can land on momentum rather than at a settled price. Both sides move together on purpose: shortening one without the other would make losing easier to trigger than winning. Rules are stamped into a battle when it is paired, so battles already running keep the holds they started with, and the settings registry's 48-hour public waiting period applies - live testnet runs 15 minutes until 23 August 2026.
- A grudge is judged on the OPPONENT's price regime, not ours (Section 9). An ordinary battle is symmetric - both tokens on our venue, smoothed the same way. A grudge is not: the outside opponent trades on its own venue with its own depth and its own averaging. Scoring it through our smoothing would rate a market we do not run by a rule it never played under. The challenger reverts to D4L's regime the moment it takes its place on the ladder, so nothing about the one-off follows it into ordinary competition.
- The grudge's 24-hour window is the grudge's own, not the ladder's (Section 9). The two are the same length today and read like one setting, but they are separate settings on separate contracts - changing one leaves the other exactly as it was.
- Correction: the grudge's early-knockout number was called "a placeholder" (Section 9). It is not. It is open on purpose, and the reason is now written down: a grudge pits a D4L token against an outsider of different age, depth, and cost-to-move, so the knockout line that ends an even ladder battle honestly is not automatically the line that ends a David-versus-Goliath grudge honestly. The ladder's own +100% / -50% is the starting point, not the answer.
- New: "The arena animation - fight moves and who lands the hit" (Section 3). The battle page shows one strike per side per short slice of time (a single block, chosen to fit the ~1.2-second strike animation). In each slice the biggest buy on each side lands the hit and shows its message - owning nothing is fine, that buyer throws the standard jab-cross with their name on it. The two side-winners are then compared, and only the LARGER of the two may throw a bought fight move, and only if one was selected; if it had none, nobody throws one that slice and the smaller side does not inherit it. Buys are never queued or refused to protect the animation.
- The knockout finisher is armed, not selected. It is on from the moment it is bought, because nobody can aim the buy that ends a fight. It fires for whoever sends a token over the knockout line and HOLDS it there, passing to the next later buyer who owns one if that buyer does not. A run at the line that falls back before the hold completes wins nothing and resets.
- Recorded as planned, not built: crowd combinations. When several paid buys land in the same slice, the intended evolution is a multi-hit combination crediting each of them in size order, plus a ticker for everyone beyond that - so a crowded moment looks crowded instead of putting people in a queue.
- The test network now runs the real production battle rules (Section 3). The document said the live testnet used a shortened 30-minute battle window and that the KO/forfeit thresholds were still "being corrected". Both are done: the live suite runs the full 24-hour window, +100% / -50%, 5-minute holds (raised to 15 minutes on 2026-08-21 and taken back to 5 the same day - see that update's card), and a 24-hour rehome wait. The permissive testnet graduation gates are also gone - the live gate is the real 50 holders / 7 minutes / $54,321, with the intended 48-hour public waiting period on settings changes. (The holder gate became 44 on 2026-10-02 - see that update's card.)
- The graduated-venue swap fee is now stated for the venue we actually run ("Where the money goes"). The document described the retired Curve pool's 0.26%-0.45% sliding fee swept by a keeper. The live Uniswap v4 venue charges a flat 0.30%, split exactly 50/50 by our own pool hook, with the platform's 0.15% skimmed straight to the treasury on the swap itself.
- The team holds three powers, not two (Section 4). A third existed and was not listed: a one-time, unchangeable wiring of the 4GRUDGE coordinator. It moves no funds and names no token, but "exactly two" was wrong and is corrected rather than quietly widened.
- The de-graduation withdrawal has no tolerance band (Section 4). The "1% tolerance" described the retired Curve pool's proportional withdraw. On Uniswap v4 the vault holds a discrete position of its own, so the reclaim is exact - a stricter guarantee than the one stated.
- The prediction-market stake cap is ON by default, not off (Section 6). One account can hold at most 2.5x the per-outcome seed in one market. (Removed on 2026-09-30 - see that update's card.)
- The bot-filtered display price is further along than stated (Sections 5 and 9's status). It is wired and running on the backend; what is missing is a page that shows it and a populated bot-flag store.
- Correction, and it matters (Section 4 - de-graduation): the de-graduation re-list floor tied to a fraction of the token's birth price is not absolute, and the earlier wording that said a driven-down reading "cannot crater the re-opened curve" was too strong. The re-list price is now capped LAST at what the recovered pot could actually pay out to the whole remaining float, so a token whose pool came back nearly empty re-opens BELOW that floor. The reason is holder exits: a curve quoted above its own backing lets the first sellers drain the pot and leaves everyone behind them unable to sell at all. Everything the floor was written for - a price reading pushed down while the money survived - still works exactly as described.
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).
Intended rules that are not yet live are identified as such in the current-status section.
- Status only, no rule changes: the Uniswap v4 venue suite and the 4GRUDGE coordinator deployed to the test network on 2026-07-21, so the "Current status" section no longer says the live venue is still Curve. Newly graduated tokens on the test network trade on the Uniswap v4 pools.
- 4GRUDGE now starts by selecting the outside opponent: each qualified account gets one immutable Pump.fun-token suggestion whose confirmation automatically supports that option, plus one separate vote that can move but cannot support the account's own suggested option.
- Discovery itself now earns GRUDGE reputation: every final support activation that occurs after a suggestion credits every earlier suggester of that canonical option, including suggestions that lose, while suggesters of the winning option receive an exact additional 50% of their own downstream support.
- Reputation matters without becoming permanent control: each event freezes a logarithmically damped vote influence before participation begins, and any correlation discount multiplies the whole vote, including its base unit.
- The challenger is chosen by an open creation race after the opponent vote: users launch event-linked D4L tokens through the ordinary bonding curve, the first one to satisfy every normal graduation gate becomes the challenger, and the 4GRUDGE result then determines its ordinary ladder destination.
- 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 holder gate became 44 on 2026-10-02 - see that update's card.)
- 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.
- 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 a D4L 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.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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 change: for a token that already exists, no change exists - the token carries a fingerprint of its fighter record that nothing can rewrite. For FUTURE tokens, what goes into a new record (a new body, new skins, a reviewed license version) is ordinary product work, because the platform writes each record before it approves that launch; changing HOW a token stores the fingerprint would need a factory reset.
- Why it is locked: the fighter is part of what the token IS - buyers buy that fighter - and a record that could be swapped afterwards would make "you own this fighter" false.
- When it takes effect: fixed at birth, forever; a new body, skin or license version binds only tokens launched after it is published.
- Status: STONE for every existing token; a new record version for future launches is off-chain product work.
- 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.
- The change: registry update - the 2026-10-02 move of the holder gate from 50 to 44 is exactly this kind of change.
- 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 change: NOT a registry update - how a buy fills is launch-contract code, not a number, so changing it for future tokens needs a factory reset; for every existing token it never changes.
- Why it is locked: the launch contract's code is frozen the moment it is deployed, and every token it creates trades through it for life.
- When it takes effect: only tokens created after a factory reset; a token already launched keeps the fill rule of the launch contract it was born on, through every phase including a de-graduation.
- What stays a number: the $54,321 the fill stops at is still the registry value in the card above, copied at birth - only the rule that the last buy stops there is code.
- Status: STONE for every existing token.
- 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 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 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.
- 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 (under the No Contender rule, Section 3, the coin alone at the top at least keeps trading instead of freezing - but it still has nobody 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.
- 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.
- 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.
- 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 44 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 44 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 44 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 refuses any approval whose life exceeds a ceiling, so a longer-lived one can't even be issued by mistake. That ceiling is currently 1 hour. It is a settings-registry number (see "Immutability & evolution" - "Other launch numbers"), not a value welded into the contract, so it can be retuned for future launches within a compiled maximum of 4 hours that nothing can ever exceed. 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, its logo, the fighter it is born as, 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.
📅 Added 2026-09-12 Every coin is a fighter. Every token launched on D4L is born as a fighter, and that fighter is part of the token itself, not a picture the website chooses to draw beside it. A coin keeps everything any other meme coin has - a name, a ticker and a logo, in the standard places every wallet and screener already reads - so anywhere that only understands logos still shows the logo. On top of that, at the moment of creation the token permanently records the fighter it is: the fighter's body, its skin, the coin carrying the logo that forms its head, the set of fight moves it owns, and the license that says who may do what with it. The platform writes that record once, before it approves the launch, and publishes it where anyone can read it. The token keeps a fingerprint of the record: a cryptographic hash, a short code that comes out completely different if even one character of the record changes. Anyone can fetch the record and check it against the fingerprint the token carries, so nobody - D4L included - can later swap in a different fighter for a token that already exists. The fingerprint is set at creation and can never be changed, exactly like the token's name and its supply. Buying the token is buying a share of that fighter. What travels with the token, and what stays D4L's. The fighter's identity - how it looks and which moves it owns - is public, so wallets, screeners and other sites may show the fighter wherever they show the coin, and that reach is intended. The fight itself is not part of the token: the move animations, the choreography that turns buys into punches, the arena, and the battle engine are D4L's game content and run on D4L. A battle is an event in D4L's own contracts, priced by D4L's pools and settled by D4L's ladder, so another site can display a fighter but cannot stage its fights. That exclusivity rests on copyright, trademark and the fighter license, not on hiding the files: anything a browser draws can be copied, so the rules say which copying is allowed rather than pretending copying is impossible. The fighter license. The license every token records grants four things in plain terms. Anyone may display the fighter to identify, list, market or hold the token, for free and forever. Holders may use their coin's fighter for personal and community purposes, up to a commercial limit counsel will set. Nobody may use D4L's fighter body, skins or moves to make other fighters, tokens or games, or stage the fighter in combat outside D4L, without a separate license. The license travels with the token and outlives Degen4Life. The creator keeps the rights in their own logo and grants the display rights those four terms need. The license is a first draft that counsel has not yet reviewed. Every token records exactly which version it was born under, so a reviewed version is published as a new version and never rewrites what an earlier token recorded. Fighter skins and fight moves bought in the store (Section 6) belong to the player's account and change how that player's buys look in the arena; they never change the fighter a token was born as.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.
- The buy that takes a token to its $54,321 graduation is partially filled the same way once the market cap is the token's last open gate: it fills only up to $54,321, and the buyer is charged only for that part (Section 2).
- 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 44 wallets currently holding the token (a live count).
- At least 7 minutes (420 seconds) since launch - or, for a de-graduated coin, since it went back to its curve.
If the curve sells out before the gates clear. While a token is still waiting on its holders or its age, 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 44th 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 44-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 "44 holders": 44 wallets actually holding at graduation time, not 44 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, for a fresh launch and a de-graduated coin alike; 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.
📅 Added 2026-10-02 Graduation is instant. A token graduates inside the transaction that meets its last gate: the buy that completes the gates, or the poke when the 7-minute clock was the last gate to clear. Every screen shows it as graduated at that moment, at the same speed a trade shows (Section 7). Opening the pool and taking the ladder seat are a second transaction that follows one block later, and nothing on screen waits for it. In between, the token cannot be traded: its curve has closed and its pool is not open yet. Until that moment, the app shows live graduation progress ("X / 44 holders," time remaining) from the platform's own mirror of the holder count, market cap and token age. The contract stays the source of truth: if the chain drops the graduating transaction, the screen goes back with it, exactly as a reverted trade does.Locked at birth - per token. All three gate values live in the settings registry, and each token copies them into its own storage the moment it is created ("Immutability & evolution"). No gate can ever change for a token already on its curve - people are actively buying toward a known goal, and that never moves. Changing them for FUTURE launches is one bounded, delayed, public transaction; there is no admin switch that reaches any token that already exists, and no per-token function anywhere. This is built and live: the registry, the bounds, and the public waiting period are all deployed, so this is how the gates work today rather than a planned path.
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 44 (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: also 24 hours. The test network ran a shortened 30-minute window earlier; the suite live today runs the full production value.
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. 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. In a market-cap challenge the No Contender is the home side. If the two tokens end exactly even, the tie breaks in favor of the waiter. Both coins crossing the SAME line no longer resolves as a tie at all - that is sudden death, decided by who holds the lead (above). The waiter's advantage applies to a genuine dead heat, and to the one case where the two coins meet OPPOSITE endings in the same check - one knocking out while the other forfeits.
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.
- Each coin moves from its own level. That only matters in a market-cap challenge of the No Contender (below) - the one battle between two different levels.
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."
📅 Added 2026-09-16 The top of the ladder never waits frozen - the No Contender. "No Contender" is a placeholder name; the rule is what matters. Every level has one waiting slot, and an ordinary waiter sits frozen until a coin arrives at its level. That works everywhere except at the very top. A coin that wins its way to a level nobody else has reached - or the very first coin to graduate - can only be reached by another coin climbing all the way up, which could take days or never happen, and a frozen wait that long would stop the leader's growth for nothing. So the coin sitting alone at the highest level any coin holds is the No Contender, and it is not frozen. It keeps its place in the queue at its level, but it trades freely - price discovery - for as long as nobody challenges it. It is challenged in exactly two ways:- By level. Any coin that reaches the No Contender's level fights it, through the ordinary waiting slot, exactly as it would fight any other waiter.
- By market cap. Any coin waiting at a lower level whose market cap climbs to the No Contender's market cap fights it. Market cap here means the same smoothed price every battle scores on, times the coin's supply, so a one-block wick can neither force a challenge nor dodge one. A coin in the middle of its own battle finishes that battle first, and is compared once it is back in the queue.
Between battles, price is frozen. A graduated token is only tradeable while it is inside a live battle; between battles it is locked. The one exception is the No Contender (above), which trades while it waits because nobody can arrive to fight it. 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 (24 hours - the same value on the live test network as the intended production one; an earlier test suite ran 1 hour).
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.
📅 Added 2026-08-19The arena animation - fight moves and who lands the hit​
The battle page is not a chart with a picture next to it: two fighters stand in a ring and throw punches, and every punch is a real buy that someone made. This is the rule that decides whose buy becomes which punch. The beat. The arena works in short fixed slices of time, one for each strike it can show. A slice is a single block on the chain, a bit under two seconds, which is chosen to fit the strike animation rather than the other way round - every strike runs about 1.2 seconds, so one slice holds a whole punch with a moment to settle before the next begins. Buys do not queue behind each other and are never turned away to protect the animation. A trade is a trade; what a slice decides is only who is shown. Who lands the hit. In each slice, the biggest buy on each side wins that side. That buyer's name, their buy size, and their message are shown over their fighter, and their fighter throws a punch. Winning a side does NOT require owning anything: a buyer with no fight move simply throws the standard jab-cross, with their name and their message on it exactly the same. The reward is for the buy. Who throws a fight move. The two side-winners are then compared against each other, and only the larger of the two may throw a bought fight move - and only if they had one selected. The other side throws the standard jab-cross with its message. If the larger of the two has no fight move selected, nobody throws one in that slice; the smaller side does not inherit it. This is deliberate, and it is what makes the arena read like the fight it is drawing: the side putting the bigger money in lands the bigger blow, the side putting in less still gets to talk, and a run of slices won by one side looks like the beating that the price is actually describing. Selecting a move happens at buy time, not in a settings screen. A move is chosen for one specific buy, from the buy panel, at the moment of buying - one move per buy - together with the message that will ride on it. A move can carry its own minimum buy size, set when the move is created; a buy under that minimum still competes for its side and still shows its message, it just throws the standard jab instead. The knockout finisher is different, and it is armed rather than selected. Nobody can aim the buy that ends a battle, so the finisher cannot be attached to a chosen buy: it is simply on, from the moment it is bought, and it fires on the buy that ends the fight. The buy that pushes a token over the knockout line and HOLDS it there wins the knockout, and the finisher plays for that buyer. If that buyer does not own a finisher, it passes to the next buyer after them who does. A run at the line that falls back before the hold completes wins nothing and resets: someone has to send it over again, and the credit belongs to whoever sends it over the time it sticks. A sudden-death win is still a knockout and still plays a finisher - the winner is past the knockout line by definition, since that is what put the battle into sudden death. What the winning buy had to do is simply harder: it had to take the LEAD and hold it, not just clear the line. A forfeit-duel win plays no finisher, for the same reason an ordinary forfeit does not: nobody knocked anybody out. Planned, not yet built - crowd combinations. The rule above shows one strike per side per slice, which is the right behavior at ordinary volume and stays honest at any volume, because losing a slice costs a buyer the animation and never the trade. The intended evolution is for a crowded slice to look crowded rather than quiet: the fighter throwing a multi-hit combination when several paid buys land together, each impact crediting a different buyer in size order, with everyone beyond that named in a fast credit ticker and a counter for the rest. Congestion should make the fight bigger, not put people in a queue.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.
📅 Added 2026-09-29 A re-graduation opens at its graduation price too - and the extra backing stays with the coin. A de-graduated coin's curve carries its whole recovered pot, while its re-listing price is held under the graduation line (below), so it usually holds more money than a fresh curve at the same price would have raised. Its pool reserve is also smaller than a first launch's: the fifth set aside when it was de-graduated, not the full 200M. So at re-graduation that reserve cannot pair all of the money at the graduation price. The pool takes the whole reserve and exactly as much USDC as pairs with it at the graduation price, and opens at that price. The rest stays locked in the launch contract as that coin's own backing: no key can move it, it is never swept to the treasury, and if the coin is de-graduated again it goes back to its curve together with the pool's contents. Pairing all of the money with the smaller reserve would instead open the pool far above the curve's last price, and whoever bought the curve just before and sold into the new pool would walk off with the recovered money that backs every other holder.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 plus any its last graduation kept back (above) (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 44 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 prices off the fair (averaged) price, not spot - and never above what the recovered pot can pay. When a token is de-graduated, the vault dissolves its pool, recovers the assets, and re-opens the bonding curve from 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. That averaged price is a candidate, not the final answer. Three bounds are applied to it, in this order: it is held under the graduation line (above), floored at a fraction of the token's birth price so a merely driven-down reading cannot crater the re-opened curve, and finally capped at the highest price the recovered pot could actually pay out to the entire remaining float. The last one wins ties, and that ordering is the whole point.
The birth-price floor is not absolute, on purpose. Where the pool's money survived and only the price reading was pushed down - the manipulation case the floor exists for - the floor sets the re-list and the attacker buys nothing cheap. Where the money itself is gone, because the pool was genuinely drained to almost nothing, the pot-cap wins and the curve re-opens below that floor. That is a deliberate trade, not an oversight. A curve holding almost nothing while quoting a high price is not protected, it is insolvent: the first sellers take the little that is there and every holder behind them finds their sell simply fails. The platform always chooses "everyone can still sell, at a low price" over "nobody can sell, at a high one". What stops the cheap re-opening from being a free supply grab is that the price tracks the pot: whoever crashed the pool had to destroy that money to get there, the re-opened float is only ever as cheap as the money that came back with it, and the anti-snipe launch fee re-applies to the re-opened curve for its first blocks. One rounding limit worth stating plainly, because it only becomes reachable after a crash this deep: the platform's money has six decimals, so a position whose entire sale would come to less than $0.000001 cannot be sold - the smallest unit of the currency, not a failure of the curve. Any materially sized position always sells.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 44 fresh holders accumulate, and the token re-graduates under the same rule as any launch (Section 2): at $54,321 if its holders and its 7 minutes are already there, or wherever the market has carried it if it passed $54,321 while still waiting for them. 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 position, so a stranger adding liquidity or donating a fraction of a token can't lock a token out of de-graduation. On the Uniswap v4 venue the vault's holding is a discrete position of its own rather than a share of a common pot, so the withdrawal amount is exact and there is no tolerance band at all (the earlier wording described the retired Curve pool's proportional-withdraw call, which needed a 1% slippage tolerance).
The team's only powers. The deployer key holds exactly three 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, (2) wire the 4GRUDGE coordinator, ONCE and only once, to a contract the vault cross-checks against the rest of the suite before accepting (after that the setting can never be changed again, and it names no token), and (3) 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 44-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 44 - 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).
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 44-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 44 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. Store skins and moves belong to the player's account: they change how that player's buys look in the arena and never change the fighter a token was born as (Section 1). (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.
📅 Added 2026-07-20 The first place governance shows up is the 4GRUDGE community vote that selects which well-known outside "OG" token the community wants to fight. 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 participant 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 influence comes only from earned grudge-realm reputation, never anything purchased. Each event converts that decayed reputation through a logarithmic curve, freezes the resulting influence before the account participates, and uses the same frozen influence for that account's immutable suggestion support and separate vote. The logarithmic curve keeps higher-reputation players meaningfully stronger while making each additional reputation point worth less than the previous one, so experience cannot become permanent control. Weight is always computed server-side from what the player has actually earned, never trusted from the browser, and a bot-flagged account does not qualify at all. Closely correlated accounts are discounted as a group, and that discount multiplies the whole vote, including its base unit, so a crowd of fresh coordinated accounts cannot escape the protection merely because they have not earned reputation yet. 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 (such as 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 in two distinct ways: by discovering an outside-token option before later community support arrives, whether or not that option ultimately wins selection, and by later proving judgment through actual 4GRUDGE and ladder outcomes. Selection-round discovery is recorded in full as raw credit, while its future voting influence is logarithmically damped.
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. For 4GRUDGE that correlation discount covers both earned influence and the base vote, and each event freezes the result before the account's first action so nothing earned during the event can amplify that same event. 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 44-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.
-
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 durationin 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.
- 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.
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 asM_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 multiplierk = 1 - 5%.
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, soT = 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,330coins, 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.
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 / 44 holders" and flip a token to graduated the instant all three gates are met, in the same moment the buy that met the last gate shows, instead of waiting for the pool to open or for a keeper (Section 2). 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 - a predicted price crossing $54,321 is not a graduation, because the extra graduation gates may not be met, so a token is shown as graduated only once all three gates are met, and that is then confirmed from the chain's own record of the graduation.
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.
- 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.
- 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.
9. Grudge matches / 4GRUDGE​
📅 Added 2026-07-20 A 4GRUDGE event is a community-created D4L token fighting a well-known outside "OG" token, with the community first selecting the outside opponent and then racing to create its challenger. Suggesting and using the separate vote happen concurrently during one community-selection window, in either order. 1. Suggest the outside opponent. A qualified account can make exactly one suggestion for the event by submitting and confirming a real Pump.fun token address. The suggestion is permanent for that event and cannot be withdrawn, replaced, or edited after confirmation because other people may act on it. The confirmed chain-and-address identity is the canonical option: if another account suggests the same token, the system attaches that account as another suggester of the same option instead of creating a duplicate row. Every confirmed suggestion automatically places one support activation on its canonical option using that account's event-snapshotted influence. 2. Cast the separate vote. Every qualified account also gets one separate vote in addition to the support carried by its suggestion. That vote cannot target the option the account suggested, but it can target any other option and can move whenever the voter changes their mind while the shared selection window remains open. Moving the vote atomically removes its old target's count and weight and adds them to the new target. Only the vote's final target counts when selection closes; earlier targets count for neither selection nor discovery credit. The winning outside token is the option with the greatest final weighted support from suggestion supports plus current separate votes. 3. Freeze influence before participation. The server takes each account's decayed GRUDGE reputation, converts it through a logarithmic curve, applies the account's correlation discount to the entire result including the base vote, and freezes that influence for the event before the account's first action. The frozen value cannot change during that event, so support or reputation earned in the current event never feeds back into the same selection. The curve's calibration values come from completed-event and shadow-mode data and are fixed for the entire event. 4. Credit discovery in full. Every immutable suggestion and every final separate vote receives a server-assigned monotonic activation sequence. For each suggester, the system counts every final qualified support activation for that same canonical option whose activation sequence is later than the suggestion's sequence. The same later support is credited in full to every earlier suggester who independently got there before it; this overlap is intentional and is never divided by the number of co-suggesters. A suggestion's own automatic support helps its option win but does not reward itself, while a later co-suggester's automatic support does count for every earlier suggester. Discovery credit uses one raw unit per qualified final support activation, not the supporter's governance weight, so old influence cannot recursively manufacture new influence. Suggesters of losing options keep all of their downstream discovery credit because identifying an option that attracted real later support still demonstrated useful judgment. 5. Add the extra governance when a suggestion wins. When an option wins the community selection, each of its suggesters receives extra governance on top of ordinary downstream discovery credit. The exact rule is: bonus = 50% of the winning option's final raw support, multiplied by the suggester's downstream-support fraction raised to the power of 1 (b = 0.5, gamma = 1).
At those fixed values the bonus equals half of that suggester's own downstream support, so an early suggester of the winner earns 1.5 times their downstream support while an equally supported losing suggestion earns its downstream support once.
A late bandwagon suggestion receives only the support that actually arrived after it and the corresponding smaller amount of extra governance for winning.
Raw overlapping discovery remains fully recorded and open-ended; decay plus the logarithmic influence curve, rather than an arbitrary per-event reward cap, keeps future decisions contestable.
6. Race to create the D4L challenger.
After the outside-token vote resolves, the selected OG remains fixed and the event opens a challenger-creation race.
Users create D4L tokens after the race opens and explicitly link them to that event while they are still on the ordinary bonding curve.
Every candidate follows the normal launch, trading, holder, age, market-cap, and graduation rules with no shortcut or special graduation path.
The first event-linked token whose ordinary graduation transaction satisfies every gate wins according to canonical chain ordering and becomes the 4GRUDGE challenger.
That already-graduated challenger is reserved outside ordinary ladder matchmaking while its grudge is assembled and played.
It adopts whichever compatible ladder code is current at that exact graduation, rather than whichever ladder happened to be current when the outside-opponent vote opened.
Every later candidate remains an ordinary D4L token and follows the normal post-graduation ladder path when it graduates.
7. Play the market-cap-gain battle.
The two sides are compared by the dollar increase in market cap each achieves over a fixed window, currently 24 hours.
That 24 hours is the GRUDGE's own window, not the ladder's, even though the two happen to be the same length today.
They are separate settings on separate contracts: changing the ladder's battle window would not move the grudge's, and vice versa.
Worth stating because "24 hours" appearing in both places reads like one setting governing both, and acting on that assumption would change one contest while leaving the other exactly as it was.
The side with the larger dollar gain wins, so a tiny coin cannot win merely by posting a spectacular percentage gain on a very small starting value.
There is no prestige at stake inside the grudge itself.
📅 Added 2026-08-21
The grudge is judged on the OPPONENT's price regime, not on ours.
An ordinary battle is two D4L tokens on D4L's own venue, so both sides are smoothed the same way and the contest is symmetric by construction.
A grudge is not: the outside opponent trades on its own venue, with its own liquidity depth and its own averaging behaviour.
Reading that token through D4L's smoothing would be scoring a market we do not run by a rule it never played under - it would make the same dollar move look larger or smaller purely according to whose venue it happened on.
So for the duration of a grudge, the challenger is judged under the opponent venue's price regime, and reverts to D4L's the moment it takes its place on the ladder.
The reversion is the important half: a grudge is a one-off against an outsider, and nothing about that one-off should follow the token into the ordinary ladder, where every other competitor is playing under D4L's rules.
The grudge's own early-knockout number is still open, and deliberately so.
It is not an oversight and it is not a number nobody has thought about - it is open because a grudge is not a fair fight in the way a ladder battle is.
The two sides differ in age, in liquidity depth, and in how much money it takes to move each of them, so the knockout line that makes an even D4L-versus-D4L battle end honestly is not automatically the line that makes a David-versus-Goliath grudge end honestly.
The ladder's own +100% / -50% is the starting point, not the answer, and settling it needs the asymmetry priced rather than assumed.
📅 Added 2026-08-30
Sudden death applies to a grudge too - in market-cap gain, which is the grudge's own unit.
The rule is the ladder's, word for word (Section 3): while BOTH sides are past the knockout line, neither can win by the absolute rule, and the winner is whichever side is AHEAD and holds that lead for the same five minutes.
The only difference is what "ahead" is measured in.
A ladder battle is two D4L coins under one price regime, so it compares percentage gain.
A grudge is a D4L coin against an outsider of completely different size, so it compares market-cap gain - the same yardstick the grudge already uses to pick its winner at the end of the window, and the same one its knockout threshold is written in.
Nothing new was invented for this: the grudge had one unit already, and sudden death uses it.
Everything else carries over unchanged.
Suspended is not cancelled, so a side that drops back inside the line hands its opponent the knockout it had already earned.
The lead is strict, so an exact tie ends nothing early and the window decides.
One thing sudden death cannot do in a grudge is move faster than the committee.
The D4L side's market cap is read live from its own venue, but the opponent's is only known when the reporting committee agrees on a figure.
So the lead only advances when a fresh agreed figure lands - never on a bare poke from a passer-by.
Without that, anyone could pump the D4L side and take the lead against an opponent's number that nobody had re-checked, and the opponent would never get to answer.
The same principle already governs the grudge's ordinary knockout.
📅 Added 2026-07-20
8. Route the graduated challenger after settlement.
If the D4L challenger wins, it enters the prestige ladder at the level whose tokens' average real market cap is closest to the challenger's own post-battle market cap.
If the OG wins, the still-graduated D4L challenger enters ordinary matchmaking at the normal entry level instead.
The routing call only chooses the already-graduated challenger's ladder destination; it can never graduate, de-graduate, change the token's economics, or alter the finished 4GRUDGE result.
The keeper role is owner-rotatable, and the same public recovery delay used for stranded-ladder recovery also protects the reserved challenger: after that delay, anyone may release an unstarted challenger or route an otherwise-unrouted D4L winner to ordinary entry level.
Selection-round discovery credit is not revoked by the battle result, while the separate post-battle creator, nominator, and holder achievement credits described in Section 6 settle from the confirmed outcome.
📅 Added 2026-09-11
10. The player rank​
Tokens have had a rank since the prestige ladder was written: a token climbs a level when it wins a battle and drops one when it loses. This section is the rank of the PERSON. It is a separate ladder with its own rules, and it sits beside the token's rather than on top of it. What it ranks, and why. D4L is community wars, and every buy is a punch. The platform only works if tokens live past graduation, and a token lives past graduation when more people are buying it than selling it. So the player rank answers exactly one question: who is playing the game best, which means winning the most battles with the most contribution. Contribution is not how many dollars you put in. It is how much of the token's win you were: the percentage of the token you held or bought while it fought. The same $600 is a full contribution in a fresh $60,000 graduate and a third of one in a token ten times bigger, and that is the point - it is the share you moved, not the money. The rules it enforces, in order:- Holding a token through a battle it WINS earns rank, scaled by the share of the token you held and by how decisive the win was.
- Battles held through keep building: hold through three lost battles and the eventual win pays far more than the same win after one lost battle. It counts battles, not days.
- Holding a token through a battle it LOSES costs nothing, because the holder did the right thing.
- Selling a token during a battle it then LOSES costs rank, scaled by the share sold, because that is the mirror image of contributing to a win.
- Buying into a battle counts like holding, for the part of the battle the buy was actually in for.
- Creating a coin that wins earns its creator rank on every win and again at graduation.
- Winning the corner-plate contest earns rank, and knocking a higher rank off the stage pays more.
- Forecasting earns rank at the odds taken, so calling a 20% underdog pays far more than riding a 99% favorite.
- Riding a token from its bonding curve to graduation earns rank in proportion to how long it was held on the curve.
rating(now) = sum over every scored event of score x 0.5 ^ (days since the event / 60)
That is the whole engine, and the rest of this section is only how each kind of event is scored.
A rating never goes below zero.
Three things follow from the one rule, and they are why it was chosen over a chess-style rating:
- A rating settles at about 87 days of your average daily score, so doing more, bigger and better raises the ceiling, and there is no cap to grind into.
- Higher ranks cost more to hold, automatically: a rating of 5,000 loses about 58 points a day to the fade while a rating of 300 loses about 3. The top of the ladder has to be re-earned every day; the middle is held with a win every few days.
- Stop playing and you slide: half a rating is gone after two months idle, three quarters after four.
- Bronze, 0 to 249: divisions at 0 / 60 / 140. New accounts, dust, flippers, dumpers, snipers, and creators who dump their own coin.
- Silver, 250 to 999: divisions at 250 / 450 / 700. A $300 player after two weeks, profit-takers, and players who bail on losing battles.
- Gold, 1,000 to 2,499: divisions at 1,000 / 1,500 / 2,000. A $100 player after four months, a $300 player after two.
- Platinum, 2,500 to 4,999: divisions at 2,500 / 3,300 / 4,100. A $300 player after five months, a $1,500 player after two.
- Diamond, 5,000 to 7,999: divisions at 5,000 / 6,000 / 7,000. A $1,500 player after four months, a whale after two.
- Red, 8,000 and up: divisions at 8,000 / 9,000 / 10,000 and up. Whales and the biggest contributors.
- Degen, the summit: the top 250 players who are already Red, held as a live leaderboard position.
- The rule that protects the summit: you must be Red to be Degen, so a thin early leaderboard can never hand the top of the game to a Silver.
score = K x weight x performance.
- K is the size of that kind of event, and there is one K per kind (they are listed as dials at the end of this section).
-
weight is how much of the TOKEN you were:
weight = square root of (your share of the token's market cap / 1%), capped at 1, with positions under $10 ignored entirely. So 0.01% of a token is 0.1, 0.25% is 0.5, and 1% or more is a full 1. In a fresh $60,000 graduate $600 is full weight and $60 is 0.32; in a $600,000 token that same $600 is 0.32. - performance is how well it went, and it is where the battle counter, the decisiveness of the win, whose community you beat and the odds you took all live.
- In from the start to the end: the whole position counts.
- Bought at 95% of the way through: about 5% of the buy counts.
- Sold half at the midpoint: half is still there at the settle, so half counts.
- Sold everything before the settle: nothing is there at the settle, so nothing counts, even though the token won.
tenure = 0.5 + 0.25 x (battles held through that were won) + 1.0 x (battles held through that were lost), plus 0.5 if the position also rode the bonding curve, capped at 4.
A position counts as held through a battle if at least half of it is still there at the settle, and a fresh position counts half until it has been through one.
So a fresh position is 0.5x, one win makes it 0.75x, one held loss makes it 1.5x, three held losses make it 3.5x, and four reach the 4x cap.
Two players who bought the same amount at the same time, one of whom held through three lost battles and the other through one, collect 3.5x and 1.5x on the very same next win.
Holding through a loss is worth four times holding through a win, which is the whole point: the loss is where holding actually costs something.
Performance is the outcome, how decisive it was, and what your bag did.
Decisiveness m is 1 for a knockout and otherwise min(1, |your gain - their gain| / 50%).
Your bag is pnl, the token's own percentage gain across the battle, capped between -50% and +100% and read as a fraction.
Then performance = 0.5 + 0.3 x m + 0.2 x pnl, which runs from 0.5 for a scrape to 1.0 for a knockout with the bag doubled.
Against what rank - the community factor.
Each side of a battle has a community rank: the weight-averaged rating of the accounts holding it when the fight starts, shown on the battle page before it begins.
Beating a stronger community is worth more: factor = 1.5 - E, where E is the Elo expectation against their community rank at 10x odds per 800 RR.
Three tiers above you pays 1.43x, a level fight pays 1.0x, and three tiers below pays 0.57x.
It is deliberately gentle: it can never double a score and it can never zero one.
A daily cap.
Backing credits are capped at 150 RR per account per day.
That is what stops spreading dust across a hundred tokens from beating five real positions, since the square root rewards splitting otherwise, and it keeps an eight-position whale from running away from the field.
Worked numbers - $500 in a $60,000 token, an average win, level communities.
- A fresh position scores about +24 RR.
- The same position after one held win scores about +36.
- After one held loss it scores about +71.
- After three held losses it scores about +166.
- A knockout with the bag doubled pays about 1.5x each of those.
- The same $500 bought at 95% of the way through the battle scores about +1, because only about 5% of it counts.
-2.5 x 80 x square root(share sold / 1%) x loss magnitude
where loss magnitude = 0.3 + 0.2 x m - 0.1 x pnl, running from 0.3 for a narrow loss to about 0.55 for a forfeit with the bag halved.
There is no community factor on a penalty: it is about what you did, not about who the opponent was.
Selling during a battle the token then WINS is not penalized at all - you simply collect nothing on the part you sold.
Holding through a loss scores exactly zero.
- Selling $500 of a $60,000 token into a narrow loss costs about 58 RR.
- The same sale into a forfeit costs about 100 RR.
- For that same player an ordinary win pays 24 fresh and 166 after three held losses, so one sale costs between one and two ordinary wins, and never a tier.
6 x weight x ramp x tenure: the ramp climbs from zero to full over the first three days, so a one-day-old position earns a third of its tick, and tenure then climbs from 1.0 to 2.0 over thirty days, capped at 12 RR a day per account.
"Real" is the same token-quality gate the holding governance of Section 6 already uses: graduated, with real liquidity, and not taken down.
The weight is your current share, so a bag that doubled through wins earns on the doubled amount, and the three-day ramp keeps a one-night bag to about a third of a day's tick.
On its own, holding settles a $1,000 tenured bag near 1,040 RR: holding alone can reach Gold and nothing above it, and battles are what move a player past that.
4. Creating a coin that wins (K = 40).
A token's creator scores 40 x performance x community factor on every battle it wins, another 40 RR when it graduates, and -20 RR if it is de-graduated.
That last one is the pit loss of Section 4, not a demotion: a creator whose coin merely drops a prestige level pays nothing.
A creator who also holds their own coin scores as a holder on top of that, and a creator who dumps their bag into a loss is penalized exactly like anyone else.
The dump is the normal case rather than the exception - the research behind the model found that 95% of pump.fun creators are out of their own coin's top fifty holders by the time it graduates - and simulated creators who dump finish at 19 RR.
5. Duels - the corner-plate contest (K = 12 a duel).
Section 3 already judges every beat of a live battle: the biggest buy on each side wins its corner plate, and the bigger of the two takes the stage.
Each beat where BOTH sides had a buy is a duel between the two corner winners, scored like a chess game on their current ratings:
gain = 12 x weight x 2 x (1 - E), where weight = square root(the SMALLER of the two buys / $500) capped at 1, with a $10 minimum on the smaller buy.
The loser loses exactly what the winner gains, so duels move rank between players and never create it.
A player rated 600 whose $200 buy beats a player rated 1,300 whose buy was $150 takes +11.6 RR, and the reverse pays +1.6.
The gap can only do so much: a Silver beating a Diamond on the same buys takes about 13 RR, because the factor tops out at 2.
Guards: plus or minus 60 RR per battle, the n-th duel between the same two players in one battle counts 1/n, and duels between accounts in the same correlation cluster score nothing.
6. Forecasts - calling the outcome at the odds you took (K = 30).
A settled forecast on the prediction markets of Section 6 scores 30 x weight x 2 x (result - p), where the result is 1 for a win and 0 for a loss.
p is the implied probability at the price you were filled at, which the parimutuel gives as 0.95 x stake / your payout-if-win, and weight = square root(stake / 1,000 DP) capped at 1.
Stakes are Degen Points, the in-game currency, so forecasting costs no money and pays no money.
📅 Added 2026-09-30
A player who backed both sides of one market has each position scored on its own, and the two are added into the one result that market gives them.
A market scores each player once, never once per side, so equal stakes on both sides placed at the same odds score about zero.
📅 Added 2026-09-11
- 1,000 DP on a 22% underdog scores +47 RR if it wins and -13 if it loses.
- The same stake on a 90% favorite scores +6 if it wins and -54 if it loses.
- Forecast credits are capped at plus or minus 40 RR a day, and a forecaster who is guessing nets zero over time.
40 x curve-tenure x weight, where curve-tenure is the share of the token's life on the bonding curve that you held it for.
$300 held from day one of a three-day launch in a $60,000 graduate scores about +28 RR, and the same $300 bought ten minutes before graduation scores about nothing.
The balance, and how it was found.
The brief was: not so hard that one sale craters you, not so easy that selling and not fighting ranks you up.
The model was balanced on a simulated population calibrated to real pump.fun data and run for 180 days, with six model players who have fixed money, buy into live battles and each play one fixed strategy.
- Whale, $10,000 across 8 tokens, holds through everything: 9,611 RR, Red. Day 8 / 13 / 27.
- Committed, $1,500 across 5, holds through everything: 5,987 RR, Diamond. Day 10 / 21 / 63.
- Regular, $300 across 3, holds through everything: 2,874 RR, Platinum. Day 16 / 67 / 148.
- Casual, $100 across 2, holds through everything: 1,569 RR, Gold. Day 58 / 117 / never.
- Drawdown-cutter, $300, holds its wins but sells whenever the bag is down: 2,364 RR, Gold. Day 39 / 80 / 180.
- Bails on losses, $300, sells whenever the token is behind: 624 RR, Silver. Day 38 / 160 / never.
- Profit-taker, $300, sells whenever the bag is up: 539 RR, Silver. Day 54 / never / never.
- 2x: a $500 sale costs 47 RR into a narrow loss and 80 into a forfeit; the player who bails on every losing battle still finishes at 1,050 (Gold), the profit-taker at 914, the drawdown-cutter at 2,593.
- 2.5x, the chosen value: the same sale costs 58 RR and 100; the bailer finishes at 624 (Silver), the profit-taker at 539 (Silver), the drawdown-cutter at 2,364.
- 3x: the same sale costs 70 RR and 120; the bailer finishes at 254 (Bronze), the profit-taker at 338 (Silver), the drawdown-cutter at 2,212.
- Why the middle: at 2x a player who sells out of every losing battle still reaches Gold, which is too easy; at 3x one dump into a forfeit costs five fresh wins, which is too hard. At 2.5x a sale costs one to two ordinary wins, the bailer and the profit-taker both sit in Silver, and a disciplined drawdown-cutter reaches about 80% of a pure holder.
- One rating per D4L account, on the same identity rule as governance, with every linked wallet's activity aggregating to it.
- Full-account tier only: sign-in-with-external-wallet accounts trade and count as holders, but they stay off the boards, exactly as they do for leaderboards and governance today.
- A bot-flagged account earns nothing and is invisible on the boards, and a duel against one does not count for the other side either.
- Accounts inside the same correlation cluster cannot duel each other for score.
- A new account starts at 0 RR and is shown as unplaced until its first scored event.
- Buy the winner in the last minute: about 5% of the buy counts, and the exit is a sale that lands in a lost battle about half the time. Simulated: 2 RR after 650 snipes.
- Sell before the settle in a winning battle: nothing is held at the settle, so nothing is collected.
- Dump a losing bag: scored on the share sold, at 2.5x, with no community discount to soften it.
- Spread dust across a hundred tokens: the 150 RR daily cap, and positions under $10 do not count at all.
- Be a whale: the square-root share weight is capped at 1% of a token, so a whale climbs by backing more battles on more days, not by writing a bigger cheque.
- Farm duels with alt accounts: same-cluster duels are void, the smaller buy sets the weight, each repeat pair counts 1/n, the per-battle cap is 60 RR, and the whole thing is zero-sum anyway.
- Mint a coin and dump it: the creator credit on a win is 40 RR, while dumping the dev bag into the first lost battle costs more than that. Simulated creators who dump: 19 RR. A self-minted coin that never truly graduated fails the token-quality gate and scores zero from the start.
- Sit on a rank: it halves every 60 days.
- Back both sides of a forecast: each position is scored against the odds it took and the market adds them into one result, so equal stakes on both sides at the same odds score about zero, and the 5% rake means the pair always costs coins.
- Fade half-life: 60 days. It sets both the ceiling (about 87 days of daily score) and how fast an idle rank slides.
- Sell-into-loss multiplier: 2.5x. THE balance dial, swept above.
- Held-loss tenure: +1.0 per held loss, against +0.25 per win, 0.5 fresh and a cap of 4. At +0.5 the pure holder falls behind the drawdown-cutter.
- What a held loss itself costs: 0. Set it above zero and every tier compresses, which the simulation showed and which the rule rejects on purpose.
- Daily backing cap: 150 RR. Lower and the top of the board is decided by consistency, higher and it is decided by size.
- Community-factor scale: 800 RR per 10x, kept gentle at 0.57x to 1.43x.
- Full-weight share: 1% of market cap, with a $10 minimum position. The share of a token at which one battle carries full weight. Private, so it cannot be played against.
- Backing K, and 4GRUDGE K: 80 and 160. How much one battle moves you.
- Holding K, its daily cap and its ramp: 6 a day, 12 a day, 3 days. How much pure holding is worth.
- Creator K and the de-graduation penalty: 40 on each win and at graduation, -20 at a de-graduation.
- Duel K, per-battle cap and minimum buy: 12, 60 RR, $10. How much the corner-plate contest matters.
- Forecast K and its daily cap: 30 and 40 RR. How much forecasting matters against backing a token.
- Graduation K: 40. The reward for riding the curve.
- Tier bands and the summit: 250 / 1,000 / 2,500 / 5,000 / 8,000, with the top 250 Red players as Degen. A display choice, confirmed from shadow data.
- The sell multiplier: 2.5x is what the sweep chose, 2x is gentler and 3x is harsher.
- Whether a creator's coin being de-graduated should cost them at all: -20 RR in the design, and it can be zero.
- The daily backing cap of 150 RR: lower decides the top by consistency, higher decides it by size.
- How much the corner-plate duel should weigh in the mix: at K = 12 with a 60 RR cap it decides divisions, not tiers.
- Whether forecasting counts toward this rank at all, or lives on a board of its own.
- The half-life: 60 days makes the rank a measure of current form, 90 would be gentler on anyone taking a break.
- The tier names, including whether the sixth tier stays "Red", and whether Bronze keeps three divisions.
- When to flip from shadow to live: the engine fills its ledger for a few weeks, the bands are confirmed from that distribution, and only then does the app show real ranks.
- Where these sit: every one of them is an off-chain number, changed by editing a setting and replaying the ledger from the events, so none of them is one of the numbered on-chain open decisions.
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.
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 Uniswap v4 venue the pool charges a flat 0.30% and the platform's own hook skims half of it - 0.15% of volume - directly to the treasury on the swap; 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 Uniswap v4 venue, read from the test network on 2026-08-03: the platform's pool hook carries a 0.15% liquidity leg and a 0.15% treasury leg - a 0.30% total split exactly 50/50 - and its treasury address reads as the platform treasury on-chain, so the capture is enforced by our own hook with no outside party in the path. The earlier verification quoted here was of the retired Curve pool factory and no longer describes the live venue.)
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 live on the test network are the rule as it stood before 2026-10-02: 50 current holders / 7 minutes / $54,321 - the intended holder gate is now 44, which is not live yet (see the 2026-10-02 graduation items below).
- The battle rules on the test network (read back from the live settings registry on 2026-08-03, again on 2026-08-21, and again on 2026-08-29): KO +100%, forfeit -50%, both held 5 minutes - all three at their intended production values. The earlier looser +30% / -20% test thresholds are gone. Two settings on the test suite are deliberately NOT the production ones, so a full battle can be watched end to end in one sitting: the battle window runs 15 minutes rather than the intended 24 hours, and the settings registry's public waiting period is 1 hour rather than the intended 48. Both are pre-mainnet items. The rehome waiting period is the full 24 hours.
- The graduation gates on the test network are the real launch gate: 50 current holders / 7 minutes / $54,321. The 50 is the holder gate as it stood before 2026-10-02; the intended 44 is not live yet (see the 2026-10-02 graduation items below). The earlier permissive testnet genesis (1 holder / no age gate) is retired; a permissive genesis is now refused outright on any live network and only works on a throwaway local chain. The settings registry's public waiting period on the test suite is 1 hour, not the intended 48 - a deliberate testnet concession so a rules change can be exercised in a session, and a pre-mainnet item. It is fixed at deployment (the registry has no setter for it), so moving it to 48 hours is part of the mainnet deploy, not a later transaction.
- The minimum balance a wallet must hold to count toward the holder gate is still set to zero on the live test suite, so any nonzero balance counts. Turning it on is one of the pre-mainnet items below.
- 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 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.
- The factory reset for tokenized fighters is deployed on the test network. The new factory can permanently record each coin's fighter fingerprint at birth. The live app cutover is awaiting browser verification, so live app launches still use the earlier factory and record no fighter.
- The No Contender (Section 3) is LIVE on the test network, since 17 September 2026. It lives in the battle ladder's code, so it went live as a single-contract deploy of a new ladder plus the vault's pointer to it - nothing else in the suite moved, no account or coin address changed, and nothing was wiped. Coins pinned to the previous ladder keep today's rule - including the five coins that were already waiting frozen, each alone at its own level - because a coin is only ever moved between identical ladders; they would get the new rule only through a factory reset. The platform drives both ladders at once, which is the point: this was also the first live test of upgrading one core contract while the site keeps running. The first coin to graduate afterwards was crowned, traded freely while it waited, was fought by the next graduate, won, and was crowned again one level higher.
- Re-graduation pool seeding (Section 4) is fixed in the contract code but not yet deployed. The fix is in the launch contract, so it reaches a network only with a factory reset, and coins already launched keep the pairing their contract was born with, because a coin's contract never changes after launch. Until then a re-graduating coin on the test networks opens its pool above its curve's last price: 10.4 times and 48.6 times for two coins on the private test network on 29-30 September 2026.
- The poke for a de-graduated coin whose 7-minute clock is its last gate (Section 2) is live on both test networks since 30 September 2026. Before it, such a coin waited for the next buy to graduate even with every gate met; the first one poked had waited two hours and graduated six seconds after the fix went live.
- The instant graduation display (Sections 2 and 7) is live on the private test network since 3 October 2026; the live testnet app does not have it yet.
- On its first graduation there, the coin's page showed it as graduated 22 milliseconds after the graduating buy reached the page, in the same update that showed the buy, and no "graduating" line appeared at any point.
- The 44-holder gate and the partial fill at $54,321 (Section 2) are built and tested in the contracts and rehearsed end to end on a local copy of the private test network, and neither is live on a network yet.
- In that rehearsal, a $50 buy into a coin $20.01 short of $54,321 was charged $20.01 and graduated the coin at $54,321.00, with the 44-holder gate in force.
- They reach the private test network with its planned reset onto the new launch contracts.
- Both test networks still run the 50-holder gate, and on both the buy that graduates a coin still fills whole and can carry it past $54,321.
- The 44-holder gate is a registry update: it binds coins created after it takes effect, and every coin already launched keeps the 50 it was born with.
- The partial fill is launch-contract code, so it reaches a network only with a factory reset, and coins already launched keep filling their last buy whole because a coin's contract never changes after launch.
- The instant display is a change to the app and its backend and touches no contract.
- The partial fill is tested to land a coin within $0.00002 of $54,321 and to charge the buyer exactly the amount it is quoted beforehand.
-
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 graduated trading venue on the test network is now Uniswap v4. 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 arena, challenger-race reservation, operator-recovery path, and post-battle ladder-routing path were deployed to the test network on 2026-07-21 as one atomic cutover, and the app's backend and frontend now point at the new suite. Newly graduated tokens trade on the Uniswap v4 pools; the retired Curve pools remain on-chain but are no longer the target.
- The rebuilt 4GRUDGE opponent-selection backend and frontend are implemented and the on-chain coordinator is deployed to the test network (2026-07-21). They include immutable suggestion support, one movable separate vote, final-state counting, the overlapping discovery ledger, event-frozen influence, logarithmic conversion, whole-vote correlation discounting, authoritative Pump provenance checks, and the forecast-card interface. The backend cutover work, bot-filtered calibration, and headed-browser release verification still have to complete before this flow is live. Governance is not live.
-
The bot-filtered shadow/display price, the shared bot-flag store, and the net-flow/wash detector are built and they never touch settlement. Correction to an earlier "not wired" status: on the backend the shadow price IS live - it is mounted in the running service, every recorded on-chain trade advances the token's shadow curve, and the resulting price is cached, broadcast, and served on read-only endpoints. What is NOT built is the last mile: no page in the app displays it yet, and the flag store that decides whose trades get filtered out is still empty because the detectors run in log-only mode. So it is a working, wired, display-only feed that currently has nothing filtered out of it and nowhere to show.
- Users pay their own gas in USDC in the live testnet app (since 5 August 2026). Every action's network fee is paid in USDC through D4L's own USDC paymaster, D4L's guarantor fronts it until the account repays it within the same action, and Pimlico's hosted service submits the action. The platform no longer sponsors gas. The private test network uses the same path for every simulated and test account.
- 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):
- Confirm the battle-ladder numbers for mainnet. The intended production set is 24h / +100% / -50% with 5-minute holds. The holds were raised to 15 minutes and taken back to 5 on 2026-08-21, which is worth knowing when confirming: the short hold is a deliberate choice for pace over precision, not a value nobody has revisited.
- 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 holder figure (44 by design since 2026-10-02).
- 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 grudge's own early-knockout number - Section 9. Open on purpose: a grudge pits a D4L token against an outsider with different age, depth, and cost-to-move, so the ladder's symmetric knockout line is the starting point rather than the answer.
- Launch mainnet on a launch contract that carries the re-graduation seeding fix (Section 4), and prove it on a test network first with one full cycle: graduate, lose in the pit, climb back, and check that the new pool opens at the curve's last price.
- Launch mainnet on a launch contract that carries the graduation partial fill and on a settings registry that carries the 44-holder gate (Section 2), and prove both on a test network first: a coin with its holders and its age already met takes a buy larger than the distance to $54,321, graduates at $54,321, and the buyer is charged only for the part that filled.
- Settle the No Contender (Section 3): its final name, and whether its one trade-off - a sell-off just before a challenger pairs lowers the price the battle is measured from - needs a guard, sized against the cost of moving the smoothed price down and back.
-
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, and a re-list cap applied after that floor so the re-opened curve is never quoted above what the recovered pot can pay the float; 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: apply and deploy the authored 4GRUDGE migration and interface; point the governance bot-filter at the shared bot-flag store; calibrate every influence and turnout value against bot-filtered shadow data and adversarial account-count scenarios; keep earned GRUDGE weight non-binding until the capture thresholds pass; seed the genesis reviewer set for the gated realms; and validate the separate post-battle 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).
- Complete the app cutover and live browser checks for the deployed tokenized fighter factory reset (Section 1). Put the fighter license draft in front of counsel, pin every fighter record to permanent decentralized public storage with a pinning-service account, and file copyright registrations for the hand-built fighter body, fight moves and arena, plus the trademarks.
- Land the player rank (Section 10): run the engine in shadow so it fills its ledger without showing anyone a rank, confirm the tier bands from that distribution, settle the dials that are still open (the sell multiplier, the daily backing cap, whether forecasting counts toward the same rank), and only then switch it on in the app.
- The user-pays-gas USDC paymaster is deployed and switched on in the live testnet app (5 August 2026). Before launch: make an end-to-end check of the full path on the real testnet against the live services (create, buy, sell, buy-currency) a standing release gate, and exercise the decided mainnet path, Pimlico's managed USDC paymaster with real USDC, end to end.
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." 11. The No Contender - its final name, and whether its pre-challenge sell-off trade-off needs a guard → Section 3. 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.