ZGBA-1R Technical Paper

01Scope and contract identity

This paper is intended for developers and technical reviewers familiar with Solidity and ERC-20 behavior. It specifies the identity of ZGBA1R, a single contract deployed on Ethereum mainnet, its state transitions for total supply, balances and allowances, and its dependencies on external systems. Operating plans and allocations by purpose are addressed in the whitepaper.

• Deployed contract · source · ABI ↗
• Deployment transaction ↗
• ERC-20 standard ↗

02State and invariants

Let A be the set of addresses, B(a) the balance of address a, L(o,s) the allowance owner o grants to spender s, and S the total supply. Amounts are uint256 integers in base units, with a range of 0 to 2²⁵⁶−1. One ZGBA equals 10¹⁸ base units. The constructor assigns the amounts below to distinct valid recipients d and r.

S = 1,000,000 × 10¹⁸ = 10²⁴
B(d) = 2 × 10²³; B(r) = 8 × 10²³
Σ B(a) = S; 0 ≤ B(a) ≤ S
∀ n ≥ 0: S(n) = S(0)

Σ denotes the sum of balances across all addresses, and n counts state transitions after deployment. Supply changes occur only in the two constructor _mint calls. Runtime functions expose no mint, burn or upgrade path.

A successful transfer deducts an amount from the sender and credits the same amount to the recipient. A self-transfer leaves the balance unchanged. Approvals do not move balances, and failed calls revert their state changes. The initial total supply is therefore preserved through each transition.

• Deployed contract · source · ABI ↗
• OpenZeppelin · ERC20 source v5.6.1 ↗

03Transfers, approvals and atomic failure

The parameters from, to and v denote the sender address, recipient address and amount in base units, respectively. transfer(to,v) transfers v from the caller’s balance; transferFrom(from,to,v) transfers v within the allowance granted to the caller by from. Both functions require a valid recipient and sufficient balance.

approve(spender,v) sets the caller’s allowance for spender to v; it does not add to the previous allowance. An allowance of uint256 maximum is treated as unlimited and is not decremented by delegated transfers. Other allowances decrease by the amount of a successful delegated transfer.

transfer: B(a)′ = B(a) − v·1[a = from] + v·1[a = to]
approve: L(owner, spender)′ = v
transferFrom: L′ = L − v  (L ≠ 2²⁵⁶ − 1)
revert: state′ = state

In these formulas, ′ denotes the resulting state, and 1[condition] equals 1 when the condition is true and 0 otherwise. A revert rolls back the failed call’s state changes, leaving no partially applied balances, allowances or logs. A failed transaction included in a block may still consume gas and the sending account’s transaction sequence number, or nonce.

The zero address and the token contract itself are rejected as transfer recipients. Other recipient contracts are not checked for the ability to release tokens. Zero-value transfers between valid addresses and self-transfers are permitted and emit a Transfer event. A delegated self-transfer still reduces a finite allowance.

approve rejects the zero address as spender and emits an Approval event on success. A delegated transfer that reduces a finite allowance does not emit a separate Approval event. The current allowance must therefore be queried through allowance(o,s).

Approvals do not expire automatically. An approved spender may use the existing allowance before a change is processed. The recommended procedure is therefore to first set it to zero and confirm the revocation. This is a client recommendation, not a precondition enforced by approve. Revocation cannot cancel a transfer already executed. EIP-2612 permit, which supports approval submission based on a signature, is not implemented.

• ERC-20 standard ↗
• OpenZeppelin · ERC20 source v5.6.1 ↗

04Clients and transaction confirmation

For a displayed amount q and an amount v in base units, v = q × 10¹⁸. The value v must be a nonnegative uint256 integer, and a transfer must not exceed the sender’s balance. The client converts decimal input to base-unit integers and rejects values requiring more than 18 fractional decimal places, exponent notation, negative values and malformed input. The recipient, amount and network shown in the wallet must be verified before signing.

Transaction preparation, wallet signing, submission, block inclusion and finality are distinct states. A transaction hash identifies the transaction but does not establish success.

The receipt’s status and blockHash, the actual transaction’s chain, sender, target, amount and nonce, and its Transfer or Approval logs are compared with the details reviewed before signing. Delegated allowances are queried again at a finalized block. The supplied client treats missing responses, timeouts and transaction or log mismatches as unverified.

Finality is assessed by checking that the finalized block reported by the RPC is at or above the transaction’s inclusion block and that each block hash matches the canonical-chain query at that height. If the RPC does not support finalized-block queries, the client reports inclusion without treating it as finality.

Signing takes place in an external wallet; the client does not request private keys or recovery phrases. RPC endpoints provide node access for chain queries and transaction submission. Comparisons between independent providers use responses for the same block.

• Ethereum · gas and fees ↗
• Ethereum · consensus ↗

05Auction allocation and external-contract accounting

The address r corresponds to the constructor argument distribution. The auction creation transaction moved 800,000 existing ZGBA from r to the auction and liquidity provision contracts. The formulas below use displayed ZGBA amounts from the transaction’s Transfer logs; they are not current balances or circulating supply.

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.

• Uniswap · ZGBA auction ↗
• Auction creation · transfers and events ↗

Qdeveloper_initial = 200,000 ZGBA
Qauction_deposit = 601,503.759398496240601504 ZGBA
Qliquidity_allocation = 198,496.240601503759398496 ZGBA
Qauction_deposit + Qliquidity_allocation = 800,000 ZGBA
Qdeveloper_initial + Qauction_deposit + Qliquidity_allocation = 1,000,000 ZGBA

The schedule parameters start, end and claim identify the opening, closing and first claim blocks, respectively, and must satisfy start < end ≤ claim. Each step’s mps expresses a per-block fraction of the full auction amount in units of 1/10,000,000. For example, mps=100,000 over 100 blocks covers the full auction amount. The sum of mps × block count must equal 10,000,000, and the block counts must sum to end − start.

This schedule allocates existing auction tokens; it represents neither new issuance nor vesting of the developer holdings. Payment assets, refunds, unsold tokens and rounding remainders are settled separately under the auction rules.

The auction is in progress. The liquidity provision contract is 0x2EEF0e2a9a652d755AccAD95a24541A98B5CA000. That transfer does not establish a pool deposit, LP position creation or a completed lock. Creation-time allocations, current holdings and settled or claimed amounts are distinct.

• Uniswap · CCA source v2.1.0 ↗

06Code behavior and on-chain state verification

Code behavior tests and deployed-state queries are separate procedures. The contract is identified by chain ID and address together, rather than by name or symbol alone.

Behavior test conditions and results

The contract was instantiated with test accounts in an EthereumJS 10.1.3 Prague EVM without connecting to a public network. Its runtime bytecode hash matches the hash specified in this paper. Recompiling the verification input also reproduced the build artifacts’ ABI, creation bytecode and runtime bytecode.

No disagreement with the expected state transitions was found within the scenarios exercised below. RPC checks used simulated responses to test client behavior; they did not measure the availability of actual providers.

Deployed-state query procedure

Perform the following queries through a node with chain access at the same finalized block. Record each result with the chain, contract, block number, block hash and query time.

• Deployed contract · source · ABI ↗
• Deployment transaction ↗