ZPZ Coin Whitepaper

3.1Token-Gated Access Design

Access tiers are defined in fixed ZPZ amounts, not fixed dollar values. Holding a specific number of ZPZ tokens unlocks each tier. As ecosystem adoption grows, this design creates structural demand for the token: new participants must acquire and hold ZPZ to access premium features. Tier thresholds may be adjusted through DAO governance if market conditions make access impractical for new users.

3.2Platform Burn Mechanism

The token contract includes a dedicated platform-burn facility (burnForPlatform). Authorized platform contracts may burn user-approved ZPZ when it is spent on ecosystem services, subject to the same protocol burn floor applied to the automated buyback program. Before any protocol-controlled burn, the contract checks the live totalSupply against the 5,000,000,000 ZPZ floor. A burn request that would reduce totalSupply below the floor is rejected and the transaction reverts; the token contract does not partially execute the burn down to the floor. Burned tokens are permanently destroyed and cannot be re-minted because the cumulative mint counter never decreases.

Contract-enforced 70% / 20% / 10% ecosystem transaction-fee routing: Eligible ecosystem transaction fees actually received and retained by the platform are split by the contract as each payment is received: 70% to the disclosed treasury wallet, 20% to the disclosed development wallet, and 10% to the dedicated, verified on-chain buyback contract. The treasury and development destinations support ecosystem operations, reserves, engineering, integrations, audits, security, and platform maintenance. The 10% buyback share purchases ZPZ through an approved Polygon DEX router and burns the permitted ZPZ in the same coded execution flow. The contract, rather than a discretionary execution wallet, enforces the permitted router, slippage safeguards, event logging, and the 5,000,000,000 ZPZ burn floor.

The number of ZPZ tokens purchased and burned varies according to the 10% buyback share of eligible ecosystem transaction fees, prevailing market price, approved execution safeguards, and remaining burn capacity above the 5,000,000,000 ZPZ floor. While live totalSupply is at the floor, buyback-and-burn execution is halted but the 10% fee share continues to accrue. Halted reserves may be recovered only to the disclosed treasury through the owner-authorized recovery path; active reserves remain protected while supply exceeds the floor. Quarterly reporting discloses the eligible transaction-fee basis, the full 70% treasury / 20% development / 10% buyback routing, recipient addresses and transfer transactions, buyback-contract funding, purchase transactions, burn transactions, post-burn totalSupply, and any returned unspent amount. This usage-linked supply-management mechanism does not guarantee any token price or participant return.

4.1APY Accrual & Claiming

• Fixed calendar APY bands: APY rates are anchored to immutable calendar dates: Year 1 (17%) from the fixed program start (October 12, 2026 00:00:00 UTC), independent of deployment date, until October 12, 2027; Year 2 (9%) from October 12, 2027 to October 12, 2028; Year 3 (4%) from October 12, 2028 to October 12, 2029. No APY accrues globally after October 12, 2029. Restaking in Year 2 earns 9% and cannot reset the rate to Year 1.
• Regular stakes (Track 1): APY accrues continuously and may be claimed at any time.
• Whitelisted stakes (Track 2): APY accrues continuously on a second-by-second basis and may be claimed at any time. Exiting early prior to maturity settles 100% of accrued pro-rata APY earned up to the exact second of exit, with zero APY forfeiture. Funded APY is paid; any shortfall remains claimable after replenishment.
• Claiming APY never affects staked principal and never affects double-reward eligibility.
• Annual compounding yield & pool capacity:Unclaimed completed-period rewards are added to the eligible reward base in subsequent years (eligibleAmount += unpaid[i]). Stakers who withdraw APY annually receive the simple 30.00% yield (17% + 9% + 4%). Stakers who leave rewards unclaimed earn compound interest across the fixed calendar years: 1.17 × 1.09 × 1.04 = 32.6312% cumulative yield (3,263,120 ZPZ on a 10M stake). If the reward pool is temporarily underfunded at a claim or exit, unpaid APY remains recorded on-chain as an accrued liability and stays claimable once replenished, without blocking principal movements.

Worked example: 10,000,000 ZPZ whitelisted stake

4.2The Double-Reward (Participation Bonus)

Whitelisted stakes that remain in the program for the full 3-year lock receive a participation bonus equal to 100% of the remaining principal, so the position doubles. The bonus is a loyalty incentive for long-term ecosystem participation, not an investment return.

• Funding is secured at stake time: The moment a whitelisted stake is created, the full bonus amount is reserved from the staking reward pool. If the pool is short, the contract automatically draws the deficit from the designated reward treasury in the same transaction. A whitelisted stake cannot be created unless its future bonus is fully reserved.
• Because the bonus is pre-reserved, it cannot be diluted, reduced pro-rata, or displaced by later stakers.
• The bonus applies to principal remaining at maturity. Early-withdrawn portions forfeit only their own bonus. Pool-funded amounts return to the reward pool; treasury-funded amounts become independently recoverable refund liabilities owed to their original funding treasury.

4.3Early Exit (Before 3-Year Maturity)

Whitelisted participants can exit before maturity. Full and partial early exits are supported directly by the contract:

• The amount unstaked is returned immediately, less a 1% fee, with no unbonding delay.
• The withdrawn portion forfeits its double-reward bonus. Pool-funded bonus returns to the reward pool; treasury-funded bonus is recorded as a separate refund liability to the original funding treasury.
• Zero APY forfeiture: all accrued pro-rata APY earned up to the exact second of exit is settled without forfeiture. Funded APY is paid immediately; any shortfall remains an on-chain claimable liability after replenishment and does not block principal withdrawal.
• Partial exits leave the remaining principal fully staked, still accruing APY, and still eligible for its double reward at maturity.
• No market-protection penalty: Early exit does not designate a wallet protected. For a wallet already protected, withdrawing principal restores freed credit only up to the credit consumed at deposit; locked principal creates no new credit. Its outgoing transfers remain subject to Section 6. Accrued APY is settled without forfeiture; any unfunded amount remains claimable after replenishment.

4.4Maturity Release Schedule

After full 3-year maturity, when the holder withdraws, the remaining principal plus its equal double-reward bonus enter a fixed release schedule, hard-coded in the staking contract:

• 15% of the total matured amount (principal + bonus) is released at withdrawal.
• The remaining 85% releases in 13 equal monthly tranches from that date (one tranche every 30 days).
• The schedule is fixed in the contract and cannot be changed by DAO vote. This guarantees that every participant, and every future market buyer, knows exactly how matured supply enters circulation.
• Maturity-release recipients are designated protected when qualifying credit is released. Their permitted nonzero ordinary outgoing transfers are subject to Section 6 pacing. Controller pulls into staking are exempt; direct protected transfers into the controller or other system custody contracts are blocked.

Worked example: 10,000,000 ZPZ staked to full maturity

4.5Reward Pool & Treasury Backstop

• The staking reward pool funds APY payments and double-reward bonuses. It is funded from the Staking Rewards allocation and can be topped up at any time.
• Double-reward bonuses are reserved in full at stake time, with an automatic treasury draw covering any pool shortfall in the same transaction. This is the strongest possible funding guarantee.
• APY is paid from the pool at claim time; if temporarily short, unpaid APY remains accrued and claimable after replenishment, and never blocks principal withdrawals.
• Reserved bonuses, staked principal, pending unbonding balances, and scheduled releases are all excluded from any owner recovery function. They cannot be withdrawn by anyone except their rightful owners.

4.6Per-Address Double-Reward Cap

The whitelisted double-reward program is capped at 50,000,000 ZPZ of eligible principal per address, enforced cumulatively in the staking contract. This is a total-per-address cap, not a per-stake cap:

• The contract tracks each address's cumulative whitelisted principal. A new whitelisted stake is rejected if it would push the address's running total above 50,000,000 ZPZ, so an address cannot bypass the cap by creating multiple smaller stakes.
• The running total decreases when a whitelisted position is exited early or matures, freeing capacity for that address within the cap. New whitelisted stakes remain subject to the fixed December 28, 2026 deadline.
• Coins held by an address above the 50,000,000 cap are not eligible for the double reward. They may instead be staked in the regular APY track (Track 1), earning 17%/9%/4% APY with no lock and a 14-day unbonding exit. Alternatively, they may be held subject to the standard market-protection sell caps in Section 6. The excess does not receive the doubling bonus under any path.
• Per-address enforcement and cross-address limitation: the smart contract enforces the 50,000,000 ZPZ limit cumulatively for each approved Track 2 address. Track 2 addresses are manually approved, but universal KYC is not required for the whitelisted cohort and approval does not represent verification of the wallet owner' identity. Only the designated official project/compliance wallet is KYC-verified. Because the contract cannot determine whether separate wallets are controlled by the same person, the 50,000,000 ZPZ limit is an on-chain per-address cap and is not represented as a verified per-person cap. No comprehensive public list or confidential identity registry of all Track 2 participants is established or promised under Section 10.3. Hard-coded pre-launch staking cutoff deadline: Whitelisted staking is restricted to the pre-launch phase. The contract enforces WHITELIST_STAKING_DEADLINE = 1798416000 (December 28, 2026 00:00:00 UTC, independent of the eventual DEX launch date). After this timestamp, stakeWhitelisted() permanently reverts with StakingWhitelistedStakingWindowClosed(). All Track 2 participation must be established prior to public DEX trading.

5.1Minting Policy & Supply Integrity

• Hard cap: The contract enforces MAX_SUPPLY = 10,000,000,000 ZPZ against cumulative tokens ever minted (totalMinted). This counter only ever increases.
• Burn permanence and floor: Burning reduces live supply but never restores minting capacity. Every protocol-controlled burn path, including burnForPlatform and the automated buyback contract, is protected by the 5,000,000,000 ZPZ floor. A requested burn that would reduce live totalSupply below 5,000,000,000 ZPZ is rejected and reverts rather than being partially filled. The automated buyback burns only within the remaining capacity above the floor. The protocol can therefore reduce supply from the 10B maximum toward 5B, but once supply reaches 5B it cannot burn below 5B.
• Progressive on-chain issuance: 1,000,000,000 ZPZ was minted at contract initialization. Remaining allocations are minted on-chain in phases (presale, liquidity seeding, staking pool funding, and vesting creation) as each distribution phase activates, always within the 10B cap. Existing member balances recorded during the pre-chain phase are honored through this on-chain issuance.
• Minting is restricted to the contract owner; upgrades are restricted to the upgrade controller. Section 11 describes the administration arrangement. The 5B floor has no ordinary setter; any implementation change must follow the public, audited upgrade process.

5.2Supply After Burn and the 5B Floor

For each protocol-controlled burn, the full requested burn must fit within the remaining burn capacity above 5,000,000,000 ZPZ. If the request would cross the floor, the transaction reverts and no portion of that burn is executed. For automated buybacks, the buyback contract burns only within the remaining capacity above the floor. After any successful burn, post-burn totalSupply equals current totalSupply minus the full requested burn amount and can never be reduced below 5,000,000,000 ZPZ once it has reached that level.

• Example: normal execution. If current totalSupply is 8,000,000,000 ZPZ and the contract purchases 250,000,000 ZPZ, the full 250,000,000 ZPZ may be burned and post-burn totalSupply becomes 7,750,000,000 ZPZ.
• Example: floor-crossing request. If current totalSupply is 5,200,000,000 ZPZ and a 300,000,000 ZPZ burn is requested directly, the transaction reverts because the requested burn would reduce totalSupply below the 5,000,000,000 ZPZ floor. No partial 200,000,000 ZPZ burn occurs. An automated buyback avoids this condition by sizing its purchase to no more than the available 200,000,000 ZPZ burn capacity before the burn is attempted.
• Progressive-issuance clarification: The 5B figure is a burn floor, not a guarantee that 5B tokens are always minted or circulating. Because issuance begins with 1,000,000,000 ZPZ and progresses in phases, live totalSupply may be below 5B before later allocations are minted. The floor applies only once live totalSupply reaches 5B.

6.1Freed-Amount Mechanics for Protected Wallets

• Protected-wallet basis: the permanent protected-wallet limits are 1% per day and 10% per 30-day window of the wallet's tracked cumulative freed amount (the contract's freedAmount ledger), not of its total token balance. The stricter limit applies.
• What counts as freed: Qualifying ZPZ released to a protected wallet by the staking contract or a vesting release is added to the freedAmount ledger. This includes release paths that invoke the contract's freed-amount accounting, rather than ordinary tokens acquired independently in the market.
• Outgoing transfers do not reduce the base: an outgoing transfer consumes daily and 30-day allowances without reducing freedAmount. Each ceiling is fixed when its window opens. New credit or a rate change cannot enlarge an active ceiling. Credit received mid-window enters the basis when that window expires, at most 30 days later.
• Restaking consumes freed amount: When qualifying released tokens are restaked, the corresponding freedAmount is consumed under the contract's anti-ratchet rule. A participant cannot repeatedly release and restake the same tokens to increase the sell-cap basis.
• Transfers do not propagate protection: recipients do not inherit protected status or freed credit. Every permitted nonzero outgoing transfer from a protected sender is paced at source, including wallet-to-wallet transfers and DEX sales. Controller pulls into staking for deposits and reward funding are exempt. Direct protected transfers to the controller or other system custody contracts are blocked; sending directly to a system address does not provide a pacing bypass.
• Clarified launch-window outflow scope and staking exemption: The universal first-60-day launch cap of 1% of current holdings per day applies to all external token outflows (both AMM sales and wallet-to-wallet transfers) from non-whitelisted holders, preventing bypass via multi-wallet distribution. Crucially, token transfers depositing into the staking controller (marketProtectionController) and authorized system contracts are explicitly exempt from this daily limit from day one, ensuring users can stake their desired token balance freely upon launch.

10.1On-Chain Voting Mechanics

• Quadratic voting: Voting credits equal the square root of a participant's staked ZPZ. A holder with 100x the stake receives only 10x the votes. This structurally limits whale domination and gives coordinated smaller holders real collective power.
• Snapshot-based: Voting power is fixed at a snapshot point set one hour before the proposal is created, consistent with the MIN_VOTING_DELAY protection. Tokens acquired or staked after that snapshot carry no power for the proposal, eliminating vote-buying during active proposals.
• Only staked tokens vote. Unstaked balances, including any tokens in Treasury or Development wallets, carry zero voting power.
• Proposers cannot vote on their own proposals; this is enforced in the contract.
• Proposal creation requires a minimum staked threshold; voting requires a minimum staked threshold; both are configurable by governance administration and published on-chain.
• Each proposer may create at most 10 proposals per rolling year; every proposal has a minimum 3-day voting window.
• Passing requires more than 50% support of votes cast and a minimum number of votes in favour.

10.2Treasury Operations Policy

• Treasury: Planned 4/7 multisig. Today the treasury is a single-key wallet; the multisig address and signer threshold will be published when it is live. Planned tiers: T1 ≤ $25k (council, $100k/mo cap); T2 $25k–$250k (DAO vote); T3 > $250k (higher quorum & timelock).
• Safeguards: Emergency pause (7 days, report in 24h); audits & bug bounties; quarterly reports; signer rotation policy.
• Decentralization: Guardian powers sunset after 12 months or earlier by DAO vote.

10.3Open Voting, Published Project Wallets & Identity Scope

ZPZ governance is open by design: every staker can vote. There is no allowlist, registry gate, or identity requirement to participate in governance. Voting power flows from staked tokens under the quadratic mechanics in Section 10.1. Transparency around designated project wallets is achieved through publication, not gating:

• Published project wallet addresses: The core EZPZ group and UOI wallet addresses designated for publication are disclosed so every participant can independently observe and track them on-chain, including their balances, staking activity, and voting behavior. Publication is a transparency measure and is independent of whether a wallet owner is KYC-verified.
• Designated KYC scope: KYC is not required for ordinary token holding, governance voting, or every wallet admitted to the whitelisted Track 2 double-reward program. Only the designated official project/compliance wallet is KYC-verified. Separately, the project team is KYC-verified: CertiK granted a Gold team KYC badge on October 27, 2026 (see section 11). Track 2 addresses remain subject to manual eligibility approval, but that approval does not constitute identity verification and does not establish a one-wallet-per-person rule. Other participants or transactions may still be subject to KYC/AML where required by applicable law, presale rules, an exchange, a payment provider, or transaction-risk controls. KYC is not a precondition for governance voting.
• Sybil trade-off, stated plainly: Quadratic voting can theoretically be diluted by splitting a large position across many wallets, and open voting means the contract does not prevent this on the community side. The available mitigation is limited observability: activity from published project wallets can be monitored on-chain, but the contract cannot reliably link undisclosed wallets to a common controller without identity controls. We state this limitation directly rather than presenting quadratic voting or wallet publication as airtight.