The intended Base deployment

The initial token is intended to be an ERC-20 on Base. It is an ecosystem distribution stage, separate from the proposed native Layer 1.

PolicyPlanned policy
Maximum supply21,000,000 ZOIY, fixed.
Additional mintingNo additional mint function.
Reserved allocationsNo reserved team or private-investor allocation.
DistributionFair public distribution with a target of 100% circulating supply at launch.

These commitments must be checked against the deployed contract, holder distribution and liquidity mechanics. Creating the full supply under one controller does not by itself put all units into circulation.

Fixed supply also constrains the native chain

A future native network is intended to have a fixed monetary supply with no continuing coin issuance. Under that policy, validators cannot be promised indefinite rewards from newly minted coins.

The proposed long-run security budget must come from fees or other explicitly authorized revenue. Whether that supports sufficient decentralization is open. Delegation, slashing, stake concentration and fee policy need separate analysis.

Migration cannot create a second spendable supply

The candidate model places the fixed native supply in a locked genesis reserve. Native units would be released only after validating finalized, one-time source-chain migration claims.

Proposed accounting constraint, not an implemented bridge. Source-chain security remains part of the migration boundary.
Proposed accounting constraint, not an implemented bridge. Source-chain security remains part of the migration boundary.
U_Base(t) + U_Native(t) ≤ 21,000,000

Only simultaneously spendable economic units belong in this sum. A release requires finalized source evidence, an unused claim identifier and sufficient locked reserve. The claim marker and reserve accounting update atomically.

The native reserve would be an initial genesis allocation, not permission for unrestricted later issuance.

The bridge design is not settled

Migration must prove that source units were irreversibly locked or burned, verify that proof on the destination and establish the recipient's new ownership.

Approach discussedQuestions it introduces
Snapshot-based airdropCutoff height, omitted holders, replay and prevention of duplicate economic spending.
Live burn-and-redeemSource proof verification, reorganizations, ongoing custody and replay risk.
Locked native genesis reserveFinalized claim verification, unused markers, reserve conservation and exceptional recovery behavior.

Migration testing must cover pauses, competing claims, partial burns, lost keys and bridge compromise. A trustless Base verification mechanism has not been completed.