Ten Thousand Tokens

§ 01The too-many-tokens problem

The orthodox view treats each token launch as an isolated event: a project decides to issue, the market decides to price, and the success or failure of any single token is uncorrelated with the launches that precede or follow it. This view is empirically wrong.

Tokens compete for a finite resource: attention-weighted capital. The number of participants willing to discover a new token, underwrite its viability, and commit liquidity at any given moment is bounded, and that bound is shared across every token simultaneously in the market. When the number of tokens grows faster than the pool of attention-weighted capital, each marginal token receives less of each — fewer discoverers, thinner underwriting, shallower depth.

The observable consequences are three:

• Median lifetime collapse. A token launched in 2026 has a median active-trading lifespan an order of magnitude shorter than one launched in 2023.
• Holder dispersion. Per-token Gini coefficients worsen not because of whale concentration but because fewer people are paying attention to any single asset.
• Coordination failure on conviction. A participant with high-confidence in a single token cannot signal that confidence without first sorting through orders of magnitude more noise than would have been required a year prior.

No individual launcher can refrain unilaterally without losing the option value of their own launch. This is a textbook tragedy of the commons, and it cannot be resolved by social pressure or governance: the equilibrium is supplied directly by the protocols that lower issuance friction. Lowering friction further only accelerates the dilution.

The mechanism described in the remainder of this paper does not attempt to discourage launches by exhortation. It restructures the incentive landscape so that a fraction of any swap fees collected on launched tokens is routed to holders who have not yet burned, and the launchers themselves are subject — by hardcoded canonical parameters — to the same fee curve and supply geometry as every other launch in the system. Whether the mechanism produces meaningful flow to holders is contingent on the volume that the launched tokens attract, which is in turn contingent on the quality of the tokens themselves. The protocol does not screen launchers, does not vet tokens, and does not subsidize liquidity.

§ 02System architecture

Seven contracts compose the protocol. Three are central — the NFT factory, the per-NFT ERC20 (TTT), and the Uniswap V4 hook — and four are supporting: the fee splitter, the on-chain renderer, the global distributor allowlist, and a shared interfaces module.

The control flow is unidirectional: the NFT factory deploys TTTs at mint time and triggers their pool launches at burn time. The hook is shared across all 10,000 pools and is the only path by which ETH enters the fee economy. ETH flows are returned from the hook to (a) the FeeSplitter (for distribution to the deployer, TokenWorks, the PunkStrategy buyback wallet, and active NFT holders) and (b) the TTT contract itself (as the buyback reservoir).

§ 03Precedent: TokenStrategy's launch tax and buyback

Two of the protocol's mechanics are inherited directly from TokenStrategy, which pioneered and validated both at scale: the decaying buy-side launch tax described in §7, and the closed-loop buyback described in §8. TokenStrategy demonstrated that a steep, block-based decay curve can compress price discovery into a transparent, time-bounded window without requiring oracles, anti-bot heuristics, or social enforcement; and that the excess revenue collected by that curve, recycled in-ecosystem as a buyback, produces a sustained deflationary force on the launched token. Both mechanisms have track records that long predate this paper, and their adoption here is not an experiment but a confirmation.

TokenStrategy's contribution to the present design is therefore the launch geometry on the swap side: the 99→1% buy decay over 98 blocks, the flat 1% sell, the conversion of excess decay fees back to ETH inside the hook, and the routing of that ETH into the token's own buyback reservoir for permissionless execution. These are direct adoptions — the parameter values, the structural choices, and the closed-loop construction. We did not invent them; TokenStrategy did, and demonstrated that they work in practice.

What is not inherited from TokenStrategy, and what we believe is original to this protocol, is the routing of a fraction of those swap fees to the holders of NFTs that have not yet burned. The fee-routing primitive described in §9 — the 30% holder share, the MasterChef-style cumulative accrual, the pull-claim semantics, and the burn-time settlement — is the net-new contribution of Ten Thousand Tokens. The combination of TokenStrategy's launch geometry with a fixed-cap NFT coupon and a holder-pool routing layer is, as far as we know, novel; the components individually are not.

The qualitative observation from TokenStrategy — that block-decaying buy taxes and in-ecosystem buyback recycling produce healthier launches than the alternatives — is the empirical basis on which §§ 7–8 of this paper rest. Whether the addition of the holder-pool layer in §9 produces a corresponding qualitative improvement at the NFT-holder layer is an empirical question that this paper cannot answer in advance.

§ 04The collection

Each of the 10,000 NFTs is identified by its tokenId and rendered entirely on-chain. The image is composed of four layers, each deterministic in keccak256(abi.encode(tokenId)):

• A black field, carrying the entire composition.
• Three concentric orbital rings at fixed radii (220, 320, 440 in a 1000-unit viewBox), rendered in dim gray.
• One to four moons per ring, with seed-derived count, angular position, and size. Moons are placed by arc-bucketing: each orbit's angle space is divided into count equal arcs, and each moon sits within its own arc with bounded jitter, so adjacent moons on the same orbit never overlap.
• A 5×5 vertically-symmetric pixel glyph at the center, rendered in one of four pattern modes and a seed-derived RGB color.

The center glyph is drawn directly from the visual lineage established by Jack Butcher through Visualize Value and the Avvatars generative algorithm, which originated the 5×5 symmetric-grid form. The four pattern modes shown above — grid, rings, blocks, diagonal — are direct ports of that vocabulary, preserved here without modification. The orbital additions are this protocol's extension: a single, deterministic glyph at the center, with seed-derived satellites in steady motion around it. The composition is intended to convey the protocol's central metaphor — the patient core, the active periphery.

The renderer is implemented in approximately 250 lines of Solidity and consumes ~260,000 gas per tokenURI call. There is no IPFS, no Arweave, no off-chain dependency: every pixel of every NFT is generated, on demand, from on-chain state. A 65-entry sine lookup table (130 bytes, scaled by 10,000) supplies the trigonometry; quadrant symmetry covers the full circle.

§ 05The mint

The mint window opens with startMint() (owner-gated, one-shot, requiring prior configuration of the renderer, hook, and Merkle root) and runs for 7 days. Three minting paths are active concurrently:

NFTs are soulbound until totalMinted == MAX_SUPPLY. Until that condition holds, every transfer and approval reverts. This is the protocol's coordination forcing function: the only way any NFT can ever be transferred is for all of them to be minted. There is no partial unlock, no time-based release. A holder sitting on an NFT through an unsold window has no exit liquidity except through a refund — burning the NFT in exchange for 0.01Ξ — and the secondary market does not yet exist.

If the mint window closes unsold, paid mints may burnAndRefund(tokenId) to recover the full mint price. Claimed mints are flagged nonRefundable at mint time and cannot be refunded; this asymmetry prevents free-claim holders from draining the protocol treasury after the fact. If the mint window closes at full supply, transfers and approvals unlock permanently, the owner withdraws the treasury (less a per-NFT reserve of 2 wei), and the launch phase begins.

§ 06The launch

burnAndLaunch(tokenId) is the central action of the protocol. It is permissionless, reentrancy-guarded, and gated on full sellout. Its execution sequence:

1. feeSplitter.onBurn(tokenId, msg.sender) — pays the burner their accrued share of the holder fee pool, clears their rewardDebt, and decrements the active-shares denominator. The burner is settled atomically with the denominator change.
2. _burn(tokenId) — the NFT is destroyed.
3. ttt.setMetadata(name, symbol, imageURI) — the burner's chosen branding is committed permanently to the token.
4. ttt.setLauncher(msg.sender) — a one-shot assignment. The launcher is the burner, and the address is credited with 50% of any swap fee collected on this token for the lifetime of the pool. The launcher's realized cash flow is bounded by the volume on the pool and may be zero.
5. A transient flag loadingLiquidity is set, the Uniswap V4 pool is initialized at a hardcoded sqrtPriceX96 corresponding to 10 ETH ≡ 1B TTT, the canonical liquidity position is minted (1 wei of ETH + the full 1,000,000,000 TTT supply, locked irrevocably to a burn address), and the flag is cleared.

Two properties deserve emphasis.

Hardcoded canonical parameters. Every launched token starts at the same initial price, with the same liquidity profile, on the same fee tier, behind the same hook. The launcher exercises no discretion over starting valuation. This eliminates an entire class of launch-time games — founder dump, asymmetric liquidity, fee tier manipulation — and makes the launches structurally comparable to one another.

One-time launch window. The loadingLiquidity flag is the only window in which the hook permits pool initialization or seed-liquidity addition. After it closes, the pool is permanent. There is no re-initialization path, no governance escape hatch, no parameter mutation.

§ 07The decaying launch tax

The Uniswap V4 hook (TTTHook) governs every swap on every launched token. Its central feature is the buy-side launch tax curve. Buys at the first block after launch pay a 99% fee. The fee decays by 100 basis points (1%) per block, reaching the resting fee of 1% at block 98 and remaining there indefinitely. The decay is purely block-based: no oracle, no TWAP, no volume integration. A bot attempting to acquire tokens at deployedAt + 0 pays 99%; one waiting until deployedAt + 49 pays 50%; one waiting until deployedAt + 98 pays 1%. The curve is identical for every participant, on every token, in every launch.

The only variable a participant can manipulate is which block they enter on, and that variable is observable to all. This produces a fair-launch property that does not require external coordination, anti-bot heuristics, or social enforcement: the launch tax monotonically rewards waiting, and waiting is the same for everyone.

Sells are taxed at a flat 1% at all times. There is no decay schedule on the sell side, and no launch-window dynamic. The asymmetry is intentional — the buy-side curve exists to compress price discovery into a transparent, time-bounded window; the sell-side rate exists to fund the protocol indefinitely.

§ 08The buyback loop

On every buy, the hook collects the buy-side fee in TTT, internally swaps that fee back to ETH (using its own transient-allowance bumping to satisfy the TTT transfer guard, of which it is not a distributor), and routes the resulting ETH in two streams:

• The 1% resting-fee equivalent, in ETH, is forwarded to FeeSplitter.depositETH(token) and distributed per §9.
• Everything above the 1% resting fee — the entirety of the decay surplus — is transferred to the TTT contract itself.

The ETH accumulated at the TTT contract is the buyback reservoir. The reservoir is permissionless: any caller may invoke TTT.buyback() to draw up to 1 ETH per block from the reservoir, collect a 0.5% bounty for triggering the call, and use the remainder to purchase TTT on the open pool. The purchased TTT is held on the contract permanently. It is never distributed, never staked, never released. It is structurally inert.

The economic effect is closed-loop. ETH that entered the system as a buy-side fee never leaves the ecosystem of the token it was a fee on. It is converted to ETH at the moment of collection (insulating its value from TTT volatility while in transit), then redeployed to purchase the very token it was a fee on, and the purchased token is permanently removed from circulation. The decay window funds the token's own deflation, directly and continuously.

This is the answer to a class of objections frequently raised against high-launch-tax mechanisms: that the tax extracts value from buyers without returning anything to the token, and that early buyers subsidize late buyers without compensation. Here, every basis point above the 1% resting fee is returned to the token's own economy as a permanent supply contraction. The early buyers who pay 99% are not subsidizing the launcher or the platform — they are subsidizing the token itself, against the buyback reservoir of which every subsequent holder benefits.

The buybacks are unbounded in duration. As long as there is any swap activity on the token, ETH flows into the reservoir; as long as there is ETH in the reservoir, buybacks proceed. The supply of TTT in circulation is monotonically decreasing in cumulative swap volume.

§ 09Fee routing to un-burned holders

The FeeSplitter is the protocol's routing layer. Every depositETH call into it carries 1% of the swap on a launched token (the resting fee in ETH from §8), and that ETH is split four ways on every deposit:

The 80% of every deposit going to the deployer, TokenWorks, and PunkStrategy is paid out immediately and synchronously, in plain ETH transfers, on every call. The 30% holder share is the protocol's distinctive piece, and it does not pay out on every deposit — it accrues, and is claimed.

How the 30% holder share is accrued

The holder share is distributed pro rata across the NFTs that have not yet burned, using a MasterChef-style cumulative accumulator. Each deposit increments a single global accETHPerShare by holderShare × SCALE / activeShares(), where activeShares() = MAX_SUPPLY − burnCount. Each NFT carries a rewardDebt[tokenId] snapshot of the accumulator at its last sync. Pending fees for any token id at any time are (accETHPerShare − rewardDebt[id]) / SCALE. Three properties make this scale:

• O(1) per-NFT claim. A holder claiming fees on N NFTs pays gas proportional to N storage writes — independent of total launches, total deposits, or total holders.
• Inheritance on transfer. rewardDebt is keyed by token id and is not synced on NFT transfer. The new owner inherits the seller's debt snapshot and automatically claims everything accrued since the previous sync. Hot-path NFT transfers do not touch the splitter at all.
• Burn-time settlement. The splitter's onBurn callback pays out the burner's accrued share before burnCount increments. The denominator change is atomic with the payout. There is no race condition over which side of the burn an accrual lands on.

The dynamic divisor: ETH / 10,000 → ETH / (remaining)

The numerator of the holder share is fixed at 30% of every deposit. The denominator is not. Initially, when the collection has just sold out and no NFTs have been burned, the 30% pool is divided among all 10,000 NFTs — so each NFT's claim on a given deposit is precisely 30% × ETH ÷ 10,000, or 0.003% of the deposit. The instant the first NFT is burned, the denominator drops to 9,999, and every subsequent deposit is divided among the survivors — not the original 10,000. The redistribution is automatic, immediate, and applies to all future deposits, not retroactively to past ones.

The mechanism is therefore monotonically concentrating. Every burn permanently shrinks the divisor on every future deposit, and the per-NFT slice of every future deposit permanently grows. There is no path by which a burned NFT can re-enter the active set; the population of un-burned NFTs is a strictly decreasing function of time.

The visualization above renders five snapshots of the same 30% pool, divided different ways. At burnCount = 0, an individual NFT's slice is a sliver — visually almost imperceptible against the full pool — because the 30% is being shared with 9,999 other claimants. At burnCount = 9,000, the slice is ten times larger; at burnCount = 9,990, a thousand times larger. At burnCount = 9,999, the single remaining un-burned NFT collects the entire 30% holder share of every subsequent deposit on every launched token in the system. The slice has grown from 0.003% to 30%, a factor of 10,000.

What the table is and is not. The figures above describe the proportional claim that each un-burned NFT has on every deposit into the FeeSplitter. They do not describe a yield, a return, or any guaranteed cash flow. A 30% claim on zero deposits is zero. The realized ETH that any holder receives is bounded above by the swap volume on launched tokens and bounded below by zero. If no swaps occur — if launched tokens do not attract volume, if launchers' tokens have no product-market fit, if the launch tax is never paid because no one trades — then no fees route to the splitter, and the share dynamics above describe a share of nothing. The protocol does not manufacture volume; it can only route fees that volume produces.

Each burn does two things simultaneously: it adds one new token to the launched set — a token that may produce swap fees if it attracts volume, and may produce none if it does not — and it shrinks the divisor on the holder pool. A holder who refrains while others launch is positioned at the intersection of both effects, but the effects only convert to cash flow to the extent that the new launches are themselves traded. Whether the mechanism works, in the sense of producing meaningful flow to un-burned holders, is an empirical question with no a-priori answer. It depends entirely on the quality and volume of the tokens that launch.

§ 10The argument for "too many tokens"

The protocol's resolution of the too-many-tokens problem rests on two structural choices, applied jointly:

The cap is hard. No 10,001st NFT can ever be minted; no 10,001st token can ever be launched through this primitive. Supply is bounded by an immutable constant. The protocol does not require governance, social pressure, or external regulation to maintain the bound — it is enforced by the code itself, with no admin function capable of overriding it.

The externality on non-launchers is non-negative. When a participant launches, the un-burned holders gain a proportional claim on a share of that token's future fees. The claim can produce nothing — if the launched token never trades — but it cannot produce a negative cash flow. This is a weaker statement than "every launch enriches the un-burned holders," and it is the correct one: an un-burned holder is never harmed by another participant's decision to launch, but neither is the holder guaranteed any positive flow from it. Whether the externality realizes as cash depends on whether the launches are themselves successful.

The combination produces an equilibrium in which:

• A holder with high conviction about their token launches. They are credited with 50% of any swap fees collected on that token for the lifetime of the pool; if the token attracts volume, that credit becomes a meaningful flow.
• A holder without high conviction does not launch. Their proportional share of the holder pool grows as others burn, but the cash value of that share is contingent on volume from the launches of others.

Burning as costly signaling

To burn an NFT is to voluntarily forfeit a proportional, growing claim on every future deposit into the FeeSplitter. That forfeiture is the direct cost of launching, and it is paid by the launcher to the remaining un-burned holders at the instant of the burn. A rational launcher will burn only if they expect their token's 50% launcher share — integrated over the token's traded lifetime — to exceed the present value of what they give up. What they give up is itself a function of the system's accumulated activity: the larger the holder pool's existing flow, the more the burner sacrifices.

The signal is self-calibrating. Early in the platform's life, before any holder pool has accumulated, the forfeit cost is low, and the bar for burning is correspondingly low. As the platform proves out — as launched tokens attract volume and the un-burned pool fills — the forfeit cost rises, and the implicit bar that a prospective launcher must clear rises with it. A launcher considering whether to burn at a high holder-pool valuation must believe more strongly in their token than a launcher considering the same decision at a low valuation, because the opportunity cost they are accepting is correspondingly greater.

This is the mechanism by which the protocol is intended to convert platform success into launch quality. It does not require gatekeepers, vetoes, governance votes, or curation committees. It requires only that participants behave rationally about their own forfeiture — a weaker assumption than the standard ones made about market participants. A launcher who burns at a high holder-pool valuation is making a public, costly, and irrevocable statement that their token's expected fee output exceeds the forfeit. The act of burning therefore carries informational content that scales with the platform's accumulated value. Low-conviction launchers, by construction, find the cost of that statement unbearable as the platform matures — and they are filtered out by their own arithmetic, not by the protocol's rules.

The filter is endogenous and tightens with success: the better the existing launches perform, the higher the bar for the next one. Whether the filter actually produces higher-quality launches in practice is, like every other empirical claim in this paper, dependent on participant behavior the protocol does not control. The mechanism establishes the incentive; participants must do the rest.

§ 11Conclusion

The token economy will, on its present trajectory, produce more tokens in the next two years than have been issued in the prior history of the industry. The question is not whether this growth can be slowed — it cannot, and probably should not — but whether protocols can be designed in which growth is structurally aligned with the holders of the protocol itself.

Ten Thousand Tokens is one such design. None of its individual components is novel: burns, MasterChef accrual, decaying launch taxes, hook-mediated fees, soulbound mints, and on-chain art are all established primitives, each with multiple production-grade precedents. What is novel is the configuration: a fixed-cap primitive in which a fraction of fees from launched tokens is routed to NFT holders who have not yet burned, where excess decay fees are recycled, in ETH, into each launched token's own buyback reservoir, and where the geometry of every launch is hardcoded and identical.

What the protocol does not do, and cannot do, is manufacture volume. The fee-routing mechanism is a passive aqueduct: it carries water only if water arrives. Whether the 10,000 NFTs ever produce meaningful flow to their un-burned holders is contingent on whether the tokens that launch through the primitive — chosen and configured by their individual burners — attract trading activity. The protocol does not screen launchers, does not vet tokens, and does not subsidize liquidity. If no launched token trades, no fee routes. The mechanism may not work, and "work" here is an empirical question with no a-priori answer.

The 10,000 NFTs are a single experiment, run once, in a sealed environment. There are no follow-on collections. There is no governance layer that can mint additional units. The NFTs are not securities, do not promise returns, and do not constitute investment contracts; they are collectibles with a routed-fee mechanism attached, and the mechanism may produce nothing. The collection is the protocol, and the protocol is finite. Within those four walls, the only question that remains — and it is the only question we are ever asked — is whether to burn.