01Overview
The supply of most tokens on Ethereum mainnet can change through community decisions or changes to contract logic. Such supply changes, combined with deteriorating market conditions, may increase the quantity of tokens in circulation and compound downward pressure on prices. To address this issue, this paper presents ZGBA-1R, an experimental token with no administrator, a fixed total supply and immutable transfer rules. ZGBA-1R (Zero Growth By Architecture - One Rule; symbol: ZGBA) is an ERC-20 token deployed on Ethereum mainnet that supports only holding, transfers and spending approvals.
This whitepaper describes the token’s design, supply, allocation plans, usage procedures and operating conditions. Deployment and issuance records are presented separately from future plans. Formulas and state transitions are specified in the technical paper.
| Item | Details |
|---|---|
| Network | Ethereum Mainnet · chain ID 1 |
| Contract address | 0x6Eb545C0dF5132c1E3ea543bf66902e657273059 |
| Total supply | 1,000,000 ZGBA · fully issued at deployment |
| Deployment status | Mainnet deployment and Etherscan source verification complete |
Issuance records can be checked in the deployment transaction, and the contract rules in the publicly available source code and ERC-20 standard.
02Design and verification
ZGBA-1R uses OpenZeppelin’s ERC20 implementation. It was deployed as a single contract without a proxy, so its code cannot be modified or replaced after deployment.
The contract has a fixed supply and no administrator powers. The issuer cannot mint additional tokens or adjust supply in response to changes in demand caused by external factors.
| Item | Details |
|---|---|
| Supply | No additional minting or burning functions |
| Administrator powers | No address freezing, balance seizure or transfer pause |
| Recipients | Transfers to the all-zero address or the token contract itself are rejected |
- Deployed contract · source · ABI ↗
- ERC-20 standard ↗
- OpenZeppelin · ERC20 source v5.6.1 ↗
- Ethereum · contract immutability and upgrade mechanisms ↗
Verification results and limitations
Bytecode matching the runtime code hash specified in the technical paper was tested in an isolated EVM. Under the test conditions, total supply and aggregate balances were conserved, and finite and unlimited allowances were processed as designed. Failed calls reverted the token state to its pre-call state. These results are limited to the inputs used in the test environment. They do not establish network performance under real conditions, compatibility with all wallets and external contracts, or operational results involving real assets.
Etherscan’s Exact Match label indicates that the published source matches the deployed code. The technical paper covers compiler settings, function behavior, test conditions and on-chain comparison procedures.
Transaction processing performance
| Item | Scope |
|---|---|
| Throughput and time to finality | Depend on Ethereum’s block processing and consensus. No separate network or throughput scaling mechanism |
| Comparative performance | No speed improvement or cost reduction percentages are calculated, as no comparative measurements under equivalent conditions are provided |
03Supply and allocation
Total supply is the full amount recorded by the token contract’s totalSupply(). One ZGBA is divided into 10¹⁸ base units and can be displayed to 18 decimal places. Balances at inaccessible addresses remain part of total supply.
Circulating supply is the quantity of tokens in market circulation under a defined methodology. It has not yet been calculated here, as existing holdings entering the market can change circulating supply even when total supply is fixed.
| Initial recipient | Amount issued · share of total supply |
|---|---|
| Developer | 200,000 ZGBA · 20% |
| Auction and liquidity | 800,000 ZGBA · 80% |
Lock-up and vesting
The token contract has no time-based transfer lock or vesting. Auction claims and locks on external LP positions are governed by their respective contracts.
Allocation at auction creation
The auction creation transaction on 2026-10-31 moved 800,000 ZGBA from the existing supply: 601,503.759398496240601504 ZGBA to the auction contract and 198,496.240601503759398496 ZGBA to the liquidity provision contract. These executed amounts differ from the original plan of 600,000 auction tokens and 200,000 liquidity reserve tokens. No new tokens were issued.
The total supply was issued in full at deployment. All amounts below move within this supply, without further issuance.
Public auction
The Uniswap Continuous Clearing Auction (CCA) is in progress. CCA allocates existing tokens over a defined period and sets clearing prices from bid demand. Each participant’s allocation depends on their maximum bid price, budget and the auction terms.
| Item | Observed value |
|---|---|
| Status | In progress |
| Auction contract · Ethereum | 0xe1c98ff2dcfbb1a70ae64ab6fe01ff868682eeec |
| Payment asset | USDC |
| Clearing price | 0.10 USDC / ZGBA |
| Bid volume | 0 USDC |
| Supply sold | 0% |
| Tokens deposited into the auction | 601,503.759398496240601504 ZGBA |
| Start date · estimated end | 2026-10-31 · 2026-11-07 |
| Start · end · claim blocks | 26,309,169 · 26,359,718 · 26,359,718 |
| Displayed LP commitment · lock expiry | 20.0% · 2027-05-09 |
Price, bid volume, supply sold and LP terms are the Uniswap interface values at the observation time. Auction closing and claims are block-based; calendar dates are estimates. The LP commitment percentage is distinct from the allocation of ZGBA as a share of total supply. A displayed lock expiry does not establish that a pool has been created, funded or its position locked.
Liquidity provision
Liquidity provision (LP) involves depositing already issued ZGBA and a paired asset into a trading pool to enable exchanges between the two assets. The holder of a pool share or position has the right to withdraw the assets and fees attributable to that share or position. Holding ZGBA alone does not confer these rights.
04Usage procedures
ERC-20 defines a common interface for balance queries, transfers and spending approvals. Balances and allowances are recorded in a smart contract on Ethereum. Users review and sign transactions in a wallet. RPC provides an interface to a node for querying chain state and submitting signed transactions. Token transfers do not pass through a separate transaction approval server operated by the project.
Tokens move through a direct transfer by the holder or a transfer by an approved spender. Private keys and recovery phrases are managed in the wallet.
Transfers
The token is identified by both Ethereum mainnet and its contract address. If an ERC-20-compatible wallet does not display it, the address can be added as a custom token. A name or symbol alone cannot identify the token.
To transfer tokens directly, the holder enters the recipient address and amount, then reviews and signs the transaction in a wallet. Gas fees for transfers, approvals and revocations are paid in ETH and cannot be paid in ZGBA. The project charges no additional token transfer fee.
A transaction hash alone does not establish successful execution or finality. The execution result, recipient, amount and finality can be checked in a wallet or block explorer.
Spending approvals
A spending approval allows another address to transfer tokens on the holder’s behalf. The holder needs no separate approval to transfer tokens directly. Approval alone does not move tokens. The approved address can transfer tokens within the allowance without another signature from the holder.
Approvals do not expire automatically. To change an existing allowance, the recommended procedure is to set it to zero, confirm the revocation and then set the new allowance. The token code does not enforce this sequence. Revocation cannot cancel transfers already executed, so the spender address and required amount must be checked before approval.
05Operating authority and funding
Holders may dispose of their token holdings even though the contract has no administrator powers.
| Area | Authority | Available actions |
|---|---|---|
| Token holdings | Address signing authorities and approved spenders | Direct transfers and disposal, or delegated transfers within the allowance. The same rules apply to developer, auction and liquidity holdings |
| Website, documents and browser tools | Maintainers | Revise documents, fix tool defects, improve tool security and compatibility, and update verification materials |
Scope of maintenance
If a defect is found in the token, the developer may publish its impact and supporting evidence and advise users to discontinue use. A new contract would constitute a separate token at a different address, so existing balances would not be transferred automatically.
Operating funds
An operating budget and recurring revenue model have not been established. Auction proceeds are a one-time source of funds. Displayed bid volume is not treated as settled or received operating funds.
06Implementation plan
The auction has started. Closing and the first claim block are set to 26,359,718. The Uniswap interface estimates closing on 2026-11-07; timing may change with block production.
After closing, settlement, claims, refunds, unsold tokens, liquidity execution transactions and positions will be checked and published. Displayed LP terms and completed deposits or locks are reported separately.
| Stage | Tasks | Conditions |
|---|---|---|
| Auction creation and funding · observed | Auction created and 800,000 ZGBA allocated at block 26,309,167 | Creation transaction and Transfer, AuctionCreated and TokensReceived events checked |
| Public auction · in progress | Track USDC bids, clearing price and supply sold | Dated observation and the Uniswap source |
| Closing and claims · scheduled | End and first claim block: 26,359,718 | Verify settlement, claims, refunds and unsold tokens through execution transactions |
| Liquidity provision · execution unconfirmed | Displayed LP commitment: 20.0%; lock expiry: 2027-05-09 | Verify pool, deposits, positions, recipients, withdrawal authority and lock execution |