[0]: An On-Chain Commons Experiment Against Time

BNB Smart Chain · PancakeSwap V2 · The rules are the contract

This document describes the mechanism and its parameters. The deployed, source-verified contract code is the final authority.
Nothing here is investment advice, and no return is promised. By taking part you accept that this is an experiment, not a financial product.

Prologue

Crypto is tired of stories that never end. So we are running a public experiment that starts from zero and leaves its fate entirely to math: 0 team allocation, 0 insider reserve, 0 referral kickbacks, and every 20 USDT locked into a black-hole pool.

Every Agent ID gets exactly one way in. The whole game revolves around a 10-minute countdown. When the market is hot, the curve climbs through 1,000 tiers toward a 10,000x ceiling. When the market hesitates, every 10 minutes of silence makes the contract burn 486,111 tokens of unminted supply, without mercy.

Every second a bystander hesitates permanently destroys supply on behalf of those who showed up. It ends when all 500,000 shares are minted, or when the unminted supply burns down and the curve freezes, after which every contract permission is renounced. We want to see how far a crowd of real, mutually unknown Agents can carry a spark born from zero once the rules are locked in stone.

Contents

1. At a Glance
2. Three Zeros
3. The Ticket: One Agent ID, One Mint
4. The 10-Minute Countdown
5. The Curve: 1,000 Tiers, a 10,000x Ceiling
6. Where the 20 USDT Goes: the Black-Hole Pool
7. Vesting: Earlier Means Slower
8. One Pool Only: Trading Rules
9. Endgame: Sell-Out or Freeze
10. What We Want to Observe
11. How the Rules Are Locked: Contracts, Permissions and Audits
12. How to Take Part
13. FAQ

Appendices:

• A: Parameter Reference
• B: Formulas
• C: Glossary
• D: Tier Table

1. At a Glance

Three things are written into the contract: The money goes into the pool. Supply burns. The curve can stop.

2. Three Zeros

0 team allocation. The contract has no team share and no position that unlocks for the team. The deployer mints share #1 from a plain wallet to seed the pool, paying the same 20 USDT, receiving the same amount, vesting on the same schedule, and, like everyone else, minting only once.

0 insider reserve. No private sale, no seed round, no market-maker allocation. Every token comes from exactly one of two sources: participants minting along the curve, or the pool-seeding reserve used to build the pool.

0 referral kickbacks. No referral rebates and no bonus mints for bringing people in. One ticket is one share; inviting others never turns it into two.

Two exceptions, stated plainly:

3. The Ticket: One Agent ID, One Mint

3.1 Why Agent ID

A Binance Agent ID is a soulbound NFT issued by SPACE ID on BSC mainnet (registry contract 0x60B9262456dE011F7d15a54CdD8c48bAaa8B022F). Every Binance user can claim one .ai name for free in the app. It cannot be transferred, and its holder is that user's Binance Agentic Wallet.

Behind each Agent ID sits the platform's real-person identity verification, so mass-producing accounts is limited by cost and compliance. For the first time this gives "one per person" real meaning on-chain: the people who enter are real Agents who do not know each other, not a farm of studio accounts. This premise relies on Binance's identity system; it is not something the contract itself can prove.

3.2 Rules

• Each Agent ID can mint successfully once
• Each wallet address can mint successfully once
• Verification happens entirely on-chain: the contract reads the holder straight from the registry. There is no backend signature and no trusted private key
• The only exception is share #1: the deployer mints it from a plain wallet to seed the pool, without checking or consuming any Agent ID. From share #2 on, everyone must hold an Agent ID

3.3 Two Ways In

The authorization is MintAuthorization(minter, wallet, agentId, deadline). It is bound to this minter and to the authorized wallet, and is valid for at most 7 days. It can only be used once, because the Agent ID itself can only be used once.

4. The 10-Minute Countdown

This is the heart of the experiment. The contract tracks a single moment: the time of the last successful mint. From that moment, two clocks start at once.

4.1 The Fire: Idle Burn

For every full 10 minutes without a successful mint, the contract burns from the supply that has not been minted yet:

b = supply cap / 4320 ≈ 486,111 tokens

4,320 ten-minute periods is 30 days. If nobody ever showed up, the entire supply would burn away in about 30 days.

• What burns is supply that has not been minted yet, not anyone's holdings
• Anyone can call settleIdleBurn() to settle it; the website has a button for this
• A successful mint resets the countdown
• The countdown only starts after share #1 is minted; there is no idle burn before it
• The cumulative amount burned can be read directly from the contract's quotaBurned() and is shown live on the website. This supply was never minted, so it never appears in the black-hole balance; the sell tax and the reserve left over at the end are the tokens actually sent to 0x…dEaD

Every second a bystander hesitates permanently destroys supply on behalf of those who showed up.

4.2 The Temptation: Dutch Drift

The price is always 20 USDT, but while nobody enters, the amount each share receives slowly grows: every idle minute multiplies it by 1/0.999 (about +0.1%).

Q_dutch = Q_base / 0.999^m, where m is the number of whole minutes since the last successful mint.

This temptation has a ceiling (see 5.2) and is easy to break: as soon as someone else mints first, the clock resets and the next share goes back to the curve price.

On one side the fire is burning; on the other, the price is tempting you. The longer you wait, the more you get. But the longer you wait, the more burns, and someone can beat you to it at any moment.

4.3 Pausing Freezes the Clocks

In a serious incident the admin can pause minting. While paused, both the idle burn and the Dutch clock are frozen; after resuming they continue from where they stopped, so a pause never burns more or pays out more. A pause has no time limit. It is one of the powers the admin keeps until permissions are renounced (see 11.3), and the minter's permissions cannot be renounced while it is paused.

5. The Curve: 1,000 Tiers, a 10,000x Ceiling

5.1 Tier Base

The 500,000 shares are split into 1,000 tiers of 500 shares each. The base amount per share in tier k:

Q_base(k) = 37000 × 10000^(−(k−1)/999)

Tier 1 gives 37,000 tokens per share; tier 1,000 gives 3.7. For the same 20 USDT, the unit price rises from about 0.00054 U to about 5.4 U, a 10,000x difference from first to last. Each tier step reduces the amount per share by about 0.92%, so the curve rises smoothly with no big jumps.

The full tier table is in Appendix D. It is an issuance schedule, not a price promise; the real pool price is set by the market.

5.2 The Ceiling on Dutch Drift

circulating = total supply − black-hole balance
Q_cap = circulating / 5000
actual Q = min( Q_dutch, max(Q_base, Q_cap) )

In other words, waiting can earn a share more tokens, but at most "a 20 U share valued at a 100,000 USDT circulating market cap", and never less than the tier's base amount. Q_cap looks only at circulating supply and never reads the order book, so nobody can switch it on or off by pumping or dumping the price.

Early on, circulating supply is small and Q_cap ≤ Q_base, so Dutch drift has no effect. Only around tier 10 (about share #4,700) does circulating supply open this door. Even then, by our estimates the total extra issuance from Dutch drift is in the low millions of tokens (about 0.06% of the cap). It is a source of tension, not a major source of supply.

If the remaining supply is less than Q for the final share, that share receives whatever remains.

5.3 Self-Protection

Transactions generated by the website and by /api/mint-tx carry three protective parameters:

6. Where the 20 USDT Goes: the Black-Hole Pool

Every 20 USDT goes into the official 0/USDT pool, and all LP created by issuance is sent to the black-hole address 0x…dEaD, where nobody, including the deployer, can withdraw it. Liquidity that others add on their own belongs to them and is not covered by this.

6.1 Phase One: Reserve Pairing

For roughly the first 100 shares, the full 20 USDT of each share goes into the pool, and the tokens needed are taken from the 3.7 million pool-seeding reserve at the current pool price:

need = 20 × tokens in pool / USDT in pool

Share #1 is minted by the deployer from a plain wallet and seeds the pool at the tier-1 price (20 U + 37,000 tokens). If someone donates USDT to the pair before the pool is seeded to distort the opening price, the contract pairs against all the USDT in the pool proportionally, so the donation is neutralized.

This phase builds the pool to about 2,000 USDT of depth, so that it is not so shallow at launch that one or two trades can blow through the price.

6.2 Phase Two: Half Buy, Half Pair

Once the reserve can no longer pair the next share, each 20 USDT is split in half:

1. 10 U buys tokens at market in the official pool
2. 10 U is added to the pool together with the tokens just bought; any bought tokens beyond what pairing needs are burned
3. Whatever remains of the pool-seeding reserve is sent to the black hole when this phase begins

So every share does two things: it pushes the pool price up and makes the pool deeper.

6.3 Same-Block Anti-Sandwich

The first time the pair is touched in each block, the token contract records the pool price at the start of the block. If at mint time the current pool price has been pushed up or down by more than 5% from this reference, the whole transaction reverts. Pumping the price earlier in the same block and then sandwiching your mint does not work.

After each mint adds its liquidity, the reference price is updated to the post-mint pool price. That way several mints in the same block don't get in each other's way (the price impact of a mint itself is not counted as deviation), and only third-party pumps or dumps between two mints are blocked.

7. Vesting: Earlier Means Slower

Minted tokens enter linear vesting with no cliff, releasing second by second from the moment of minting. The vesting duration for share n:

T(n) = 168 − (n−1) × 165 / 499999 hours

Share #1 vests over 7 days; share #500,000 over 3 hours.

transferable = Q × min(1, elapsed / T(n))

• Vesting only limits transfers out; transfers in are unrestricted
• Earlier shares get more tokens and release more slowly, stretching sell pressure over a week
• Later shares get very few tokens and release quickly

8. One Pool Only: Trading Rules

Tax applies only to the official pair:

• Wallet-to-wallet transfers are not taxed
• Tax rates can only go down, never up; once permissions are renounced they are fixed forever
• Transfers into recognizable unofficial pools (such as another V2 or V3 pool) are blocked, to prevent tax evasion through outside pools and shadow liquidity. The Uniswap V4 PoolManager and the PancakeSwap Infinity Vault hold the funds of every V4/Infinity pool and cannot be detected automatically, so they are written into the contract at deployment and blocked by default
• When trading on PancakeSwap, use the fee-on-transfer functions (...SupportingFeeOnTransferTokens). The PancakeSwap website and major wallets handle this automatically; a plain addLiquidity will lose USDT

Why V2: constant-product is simple to implement, has a small audit surface and behaves predictably. The cost is limited aggregator compatibility, which we accept in exchange for one clear, single pool.

8.1 Shallow-Pool Slippage Reference (buys, including pool fee and buy tax)

9. Endgame: Sell-Out or Freeze

The experiment has only two possible endings. Both are written into the rules, and the contract announces them by itself:

When the end arrives: minting closes forever; the remaining pool-seeding reserve goes to the black hole; the pool and the black-holed LP stay on-chain forever, and trading continues as normal.

9.1 Supply Ledger

The buffer of about 80.63 million tokens equals about 166 idle periods of burning. Once cumulative idling exceeds it, every 10-minute stall directly squeezes the supply available to later tiers. Where the curve finally freezes is decided by the collective pace of every participant.

10. What We Want to Observe

We set no standard of "success" for this experiment. Its outcome is itself the data we want to see:

• With rules that cannot change and nobody to bail anyone out, how far up the tiers real participants will push the curve
• Between the pressure of the countdown and the temptation of the Dutch drift, how people will choose
• How deep a pool can be built one 20 USDT share at a time
• Which tier the curve freezes at, and how the market prices it afterwards

11. How the Rules Are Locked: Contracts, Permissions and Audits

11.1 Contracts

All source code will be published and verified on BscScan.

11.2 Invariants

1. Total supply never exceeds 2.1 billion
2. All LP created by issuance is in the black hole and nobody can withdraw it
3. Each address and each Agent ID succeeds at most once
4. Vesting tokens can never be transferred out beyond the released portion
5. Nobody can mint outside the curve, change the cap, the tier formula or the vesting rules, raise the tax rates, or replace the minter

11.3 What the Admin Can Still Do Before Renouncing

To handle incidents in the early days, permissions are not renounced at the moment of deployment. Until they are, the admin can only:

The admin cannot: mint extra supply, change the cap or the curve, unlock anyone's position, withdraw LP, raise tax rates, replace the minter, or freeze arbitrary addresses.

Renouncing permissions: both the token contract and the minter will call renounceOwnership, in transactions anyone can check on-chain. This happens once the system is confirmed to run smoothly, and no later than the end of issuance. The contracts have built-in ordering guards so a mistake cannot lock the system up: the token contract can only renounce after the minter is set; the minter can only renounce after share #1 is minted and while it is not paused. After renouncing, every item in the table above is closed forever and the rules are locked for good. We recommend a Safe 2-of-3 for the project multisig.

11.4 Audits

The contracts went through a round of static analysis plus four independent AI audits: Slither, then Gemini, Grok, GPT and Claude each reviewed the code independently and wrote attack cases. No vulnerability was found that could directly steal funds or LP. Every issue raised was either fixed or, after evaluation, accepted as a design trade-off, and every fix comes with regression tests.

12. How to Take Part

1. Claim an Agent ID in the Binance app: Wallet → Agentic Wallet → Agent ID, and turn on Developer Mode
2. Hold at least 20 USDT and a little BNB for gas in the Agentic Wallet
3. Open the website, enter your Agent ID, and check the current tier, the expected amount, the vesting duration and the countdown
4. The website generates two commands, "approve USDT" and "mint", for your AI agent to run with baw contract-call; or let your agent read the site's /skill.md and do it on its own
5. Once minted, your tokens vest linearly, second by second
6. Sell in the official PancakeSwap pool; transfers into other pools are rejected

13. FAQ

How many tokens does the team get?
Zero.

Whose tokens does the countdown burn?
It burns supply that has not been minted yet, not anyone's holdings. For those already in, it means supply is permanently shrinking.

Can I mint more than one share?
No. Once per Agent ID, once per address, and no referral bonuses.

Why do early shares vest over 7 days and later ones over only 3 hours?
An early share receives tens of thousands of times more tokens than a late one, so vesting it longer spreads out the sell pressure. Later on, the unit price is already high and the amounts are tiny, so they unlock faster.

If I wait instead of minting, do I get more?
A little more, but there is a ceiling. Every 10 minutes 486,111 tokens of supply are burned, and someone can beat you to it and reset the clock at any moment. That is the game.

What happens after the freeze?
Minting closes forever, the pool and the black-holed LP remain on-chain forever, the token keeps trading, and the market sets the price.

Can the rules change after issuance ends?
No. The permissions on both contracts will be renounced, and after that nobody can change any parameter.

Closing

[0] promises no wealth, only rules.

The money goes into the pool, supply burns, and the curve can stop. Everything else (tiers, countdown, vesting, tax) exists only so this experiment can be verified on-chain and carries a real cost in time.

A crowd of real Agents who do not know each other, a 10-minute countdown, and a set of rules written in stone. Where the spark goes is up to everyone who shows up.

Appendix A: Parameter Reference

Appendix B: Formulas

Q_base(k)    = 37000 × 10000^(−(k−1)/999)                 k = 1…1000
m            = floor((t − time of last successful mint) / 60)
Q_dutch      = Q_base / 0.999^m
circulating  = total supply − black-hole balance
Q_cap        = circulating / 5000
Q            = min(Q_dutch, max(Q_base, Q_cap), remaining mintable supply)
T(n)         = 168 − (n−1) × 165 / 499999  hours           n = 1…500000
transferable = Q × min(1, elapsed / T(n))
idle burn    = 2,100,000,000 / 4320 ≈ 486,111 tokens every 10 minutes
phase-1 pair = 20 × tokens in pool / USDT in pool

Appendix C: Glossary

Appendix D: Tier Table (every 10th tier)

There are 1,000 tiers of 500 shares each. The table below lists every 10th tier; any tier can be computed with Q_base(k) = 37000 × 10000^(−(k−1)/999), and the current tier can be read from the contract's quote().

[0]: An On-Chain Commons Experiment Against Time