0200 Protocol · Base mainnet

XO2

Deployed 2026‑09‑03. Every figure on this page was read from the chain, and every one of them tells you how to read it yourself. Where we cannot prove something, the page says so instead of rounding it off.

Read this first

XO2 has no utility today.

It does no work in our product. It captures no fee, carries no governance right, entitles you to no revenue and is not required to call anything we run. base‑transaction‑decoder takes USDC and has never taken XO2.

Nothing on this page is an offer to sell, a solicitation, or a claim about future value. There is no public sale, no liquidity pool and no market. If that changes, this page changes with it and says when.

the contractread 2026-09-04 01:1xZ

address0xdE906C748E56fD6F648eb8564532673257Ac414bBase mainnet, chain 8453—

namename()0200 Protocol

symbolsymbol()XO2

decimalsdecimals()18

supplytotalSupply()Fixed. There is no mint function to raise it100,000,000

Seven contracts were deployed from one address in eleven transactions. Both halves are readable: each of the seven addresses below returns code from eth_getCode, and the deploying address moved from nonce 2 to nonce 13.

Two of the deployments failed, and that is the point.

The eleven transactions were not eleven successes. Nine succeeded and two reverted — and of the nine that were deploy calls, seven succeeded and two reverted. Those are two different sentences answering two different questions, and collapsing them into one number is how the count was first got wrong.

the two failuresread from receipts

nonce 8Duplicate distributor, sent after nonce 7 had already deployed it0x5b88e0d0…1f71 · reverted, no logs16,516,751 gas

nonce 10Duplicate token, sent after nonce 9 had already deployed it0xe6e193c8…8675 · reverted, no logs16,517,772 gas

A wallet popup vanished mid-signature and the transaction was re-sent. It happened twice. Both re-sends were deployments to an address that was already occupied, and because every contract here was deployed with CREATE2 — where the address is fixed by the salt rather than by the sender’s nonce — the duplicate reverted instead of deploying a second copy. With nonce-based CREATE each re-send would have landed at a fresh address and produced a real duplicate contract holding real supply.

Total cost of both mistakes: 33,034,523 gas, which is about $0.50 at the gas price our own decoder reports for the block that carried the token deployment. We are publishing the failures because they are the only evidence we have that the design choice was worth making, and evidence about ourselves is the kind nobody volunteers.

No wallet holds the supply.

All 100,000,000 sit in five release contracts. The address that deployed them holds none, the distributor that filled them holds none, and there is no owner who can move them.

five locks · one beneficiaryholding & per-30-day ceiling

founder/team0x78e0DA18…408Fceiling 417,000 per 30 days20,000,000

treasury0x9F0Ddc55…A818ceiling 630,000 per 30 days15,000,000

ecosystem0x98aa8D4F…B6CEceiling 520,000 per 30 days25,000,000

contributors0x6594662D…CeDaceiling 210,000 per 30 days5,000,000

undesignated0x3f4Fb350…9Cd1ceiling 729,000 per 30 days35,000,000

Holdings sum to 100,000,000 exactly. Each lock carries its own ceiling and they are never pooled — a lock cannot borrow another's allowance. Every lock enforces a 30-day delay before a release completes.

Five schedules, one destination

All five locks release to the same address. They differ in when, not in who.

Founder/Team, Treasury, Ecosystem, Contributors and Undesignated are five names for five schedules, not five recipients. Read beneficiary() on each of the five addresses above: it returns one distinct value, 0xf4211E309d80a074dAc37C616d1Aa7899ed29807. That is also the address that deployed the contracts.

Two facts about the rate, and neither is computable from the other.

two separate measurementsdo not divide one by the other

ceilingMost that can become movable in any rolling 30-day windowThe five per-lock ceilings summed, while every lock still holds a balance2.506%

exhaustionEarliest point at which every lock could be emptyGoverned by the slowest bucket, Ecosystem, at 48.08 windows~3.95 yr

These are two measurements, not one number expressed twice. Dividing supply by the ceiling gives 3.28 years, which is eight months short, because the locks drain independently against their own holdings rather than from a shared pool — two of them empty at 23.81 windows, after which the maximum rate falls to 1.666% per window. That division is how this figure was got wrong twice before it was got right.

No annualised rate is published. The 30-day window is the mechanism; a year is a convenience, and converting to one produced two of the four errors made arriving at these two numbers.

Nobody can mint, pause, upgrade or seize it.

We checked by calling the privileged functions rather than by reading our own source. Each of these reverts on the deployed token, because the function does not exist:

absent on 0xdE906C74…414bevery call reverts

owner()            getOwner()          admin()
pendingOwner()     transferOwnership() renounceOwnership()
mint()             burn()              burnFrom()
pause()            unpause()           blacklist()
upgradeTo()        implementation()    setName()

Where we are verified, and where we are not.

On Basescan: the token, the distributor and one of the five locks are exact-match verified. The other four locks are byte-for-byte identical to that verified lock apart from their release ceiling, which appears three times in each lock's runtime bytecode as a PUSH32 constant and agrees with ceiling() called on that lock.

On Sourcify: not verified. Sourcify is a separate registry and we have not submitted to it. Our own decoder therefore flags our own distributor with unverified_contract — and that flag is correct. We would rather tell you than have you find it.

If it ever reads “all contracts verified” on this page, that is erosion and it is wrong.

Check all of it yourself.

Nothing here needs our cooperation. These are actions, not coordinates — byte offsets go stale, calls do not.

reproductionany Base RPC

# the five ceilings, read from the locks themselves
ceiling()      on each of the five lock addresses
beneficiary()  on each — one distinct value, or our claim is wrong
balanceOf()    on the token, for each lock — sums to totalSupply()

# the four locks Basescan marks "similar match"
eth_getCode    on each, diffed against the verified lock:
               identical apart from the ceiling constant

# nothing is held by a person
balanceOf()    for 0xf4211E30…9807 and 0x3129b6…1783 — both zero

There was an earlier token, and it is not this one.

A different wallet, 0x3129b6…1783, deployed a token called $0200 on 2026‑09‑01 at 17:21 UTC. It was retired 31 hours later: the pool was withdrawn and the entire supply sent to an address it cannot leave. That wallet holds none of it, and holds no XO2 either.

Both tokens are permanently on Base and both are visible from those addresses. XO2 was not deployed by that wallet — it was deployed by 0xf4211E30…9807, the same address that receives every release above.

One thing here you cannot check and are taking from us: both wallets are ours. No chain query establishes that — we are telling you, in our own voice, because a page arguing that you should check everything cannot quietly mix in something you can't.