The ZPZ whitepaper, in plain English.
Twenty-five terms from the ZPZ whitepaper, each with the number to remember and the section it comes from. Pick a tile to read it.
- 25 terms
- 6 families
- Every one from the whitepaper
Basics · Term 1 of 25
Utility token
- To remember
- Access
- Whitepaper section
- 12
ZPZ is designed to power access, participation and governance inside the EZPZ Trading ecosystem. It is not an investment vehicle, and holding it is not an equity stake or a debt instrument.
ZPZ is a utility token designed exclusively to power access, participation, and governance within the EZPZ Trading ecosystem. … ZPZ is not an investment vehicle, and nothing in this document or any associated communication should be construed as financial, investment, or legal advice. … Purchasing or holding ZPZ does not represent an equity stake, debt instrument, or any form of financial security.
Basics · Term 2 of 25
ERC-20
- To remember
- 18 decimals
- Whitepaper section
- 5
ZPZ is an ERC-20 token on Polygon and uses 18 decimals.
Token: ZPZ (ERC-20, Polygon), 18 decimals.
Basics · Term 3 of 25
Polygon
- To remember
- POL
- Whitepaper section
- 1
ZPZ is built on Polygon (POL), where it is designed to provide token-gated access, DAO participation and adoption incentives.
Built on Polygon (POL), ZPZ provides token-gated access, DAO participation, and adoption incentives.
Basics · Term 4 of 25
Upgradeable contract
- To remember
- Public process
- Whitepaper section
- 3.2.1
The burn floor has no ordinary setting that lowers it. Changing it would need a contract upgrade and a published whitepaper amendment.
The contract exposes no ordinary administrative setter that can lower this floor; changing it would require a contract upgrade and a published whitepaper amendment.
Basics · Term 5 of 25
Token-gated access
- To remember
- Set in ZPZ
- Whitepaper section
- 3.1
Each access tier is set as a fixed number of ZPZ, not a dollar amount. Holding that number opens the tier, and the DAO may adjust the thresholds.
Access tiers are defined in fixed ZPZ amounts, not fixed dollar values. … Holding a specific number of ZPZ tokens unlocks each tier. … Tier thresholds may be adjusted through DAO governance if market conditions make access impractical for new users.
Supply · Term 6 of 25
Max supply
- To remember
- 10B
- Whitepaper section
- 5
No more than 10,000,000,000 ZPZ can ever be minted in total. The count of tokens ever minted only goes up.
Maximum cumulative supply: 10,000,000,000 ZPZ. … This counter only ever increases.
Supply · Term 7 of 25
Live supply
- To remember
- Burns lower it
- Whitepaper section
- 5.1
Live supply is what burns reduce. A burn lowers it but never gives back minting room, and once supply reaches 5B the protocol cannot burn below 5B.
Burning reduces live supply but never restores minting capacity. … The protocol can therefore reduce supply from the 10B maximum toward 5B, but once supply reaches 5B it cannot burn below 5B.
Supply · Term 8 of 25
Progressive issuance
- To remember
- 1B first
- Whitepaper section
- 5.1
ZPZ started with 1,000,000,000 minted. The rest is minted on-chain in phases as each distribution phase activates, always within the 10B cap.
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.
Supply · Term 9 of 25
Burn
- To remember
- Permanent
- Whitepaper section
- 3.2
A burn destroys ZPZ for good, and burned tokens can't be minted again. Authorized platform contracts may burn ZPZ a user approves when it is spent on ecosystem services.
Burned tokens are permanently destroyed and cannot be re-minted because the cumulative mint counter never decreases. … 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.
Supply · Term 10 of 25
Burn floor
- To remember
- 5B
- Whitepaper section
- 5.2
Once live supply reaches 5,000,000,000 ZPZ, no protocol-controlled burn can take it lower. A burn that would cross the floor is refused in full, with no partial burn.
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. … can never be reduced below 5,000,000,000 ZPZ once it has reached that level.
Launch · Term 11 of 25
Launch window
- To remember
- 60 days
- Whitepaper section
- 6
For the first 60 days after DEX launch, a non-whitelisted wallet can move out at most 1% of its holdings per day, by DEX sale or peer-to-peer transfer. Deposits into staking are exempt.
All holders (non-whitelisted) … 1% of holdings per day on all external outflows (DEX sales and peer-to-peer transfers); staking deposits into controller and system contracts are 100% exempt … First 60 days after DEX launch
Launch · Term 12 of 25
Anti-bot limits
- To remember
- 50M / 500M
- Whitepaper section
- 6
For non-whitelisted wallets, while anti-bot protection is enabled, a single transaction can move at most 50,000,000 ZPZ and each wallet can hold at most 500,000,000 ZPZ. It is a defense against bots, snipers and manipulation.
Anti-bot layer (all non-whitelisted) … Max 50,000,000 ZPZ per transaction; 500,000,000 ZPZ max wallet; … While anti-bot protection is enabled … Bot, sniper, and manipulation defense
Launch · Term 13 of 25
Sender cooldown
- To remember
- 30 s
- Whitepaper section
- 6
For non-whitelisted senders, while anti-bot protection is enabled, a sender waits 30 seconds between transactions and can send at most 3 per 5 minutes. It applies to regular wallets and contract senders alike, with named exemptions.
Anti-bot layer (all non-whitelisted) … 30-second sender cooldown; 3 sender transactions per 5 minutes (EOAs and contract senders alike; registered pairs and explicit owner, whitelist, controller and system exemptions apply) … While anti-bot protection is enabled
Release · Term 14 of 25
Vesting
- To remember
- Coded
- Whitepaper section
- 7
The Treasury (1.6B ZPZ) and Development (2B ZPZ) allocations are released on coded vesting schedules in the token contract. Both follow the same policy.
The Treasury (1.6B) and Development (2B) allocations are subject to coded vesting schedules in the token contract. … Both follow identical policies:
Release · Term 15 of 25
Cliff
- To remember
- 180 days
- Whitepaper section
- 7
For the first 180 days (a 6-month cliff), none of the Treasury and Development vesting tokens are accessible.
6-month cliff: No tokens are accessible for the first 180 days.
Release · Term 16 of 25
Linear release
- To remember
- 720 days
- Whitepaper section
- 7
After the cliff, tokens vest continuously over 720 days (24 months). Unvested tokens can't be released early, to anyone.
24-month linear release: After the cliff, tokens vest continuously over 720 days. … The contract mathematically cannot release them early, to anyone.
Governance · Term 17 of 25
DAO
- To remember
- Staked votes
- Whitepaper section
- 10.1
In the ZPZ DAO, only staked tokens vote, proposers can't vote on their own proposals, each proposer can make at most 10 proposals per rolling year, every vote runs at least 3 days, and a proposal passes with more than 50% of votes cast plus a minimum number of votes in favor.
Only staked tokens vote. … Proposers cannot vote on their own proposals; this is enforced in the contract. … 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.
Governance · Term 18 of 25
Quadratic voting
- To remember
- √ stake
- Whitepaper section
- 10.1
Voting credits are the square root of your staked ZPZ, so 100x the stake gives only 10x the votes.
Voting credits equal the square root of a participant's staked ZPZ. … A holder with 100x the stake receives only 10x the votes.
Governance · Term 19 of 25
Snapshot
- To remember
- 1 hour
- Whitepaper section
- 10.1
Voting power is fixed at a snapshot one hour before the proposal is created. Tokens bought or staked after that snapshot add no votes on that proposal.
Voting power is fixed at a snapshot point set one hour before the proposal is created … Tokens acquired or staked after that snapshot carry no power for the proposal, eliminating vote-buying during active proposals.
Governance · Term 20 of 25
Sybil trade-off
- To remember
- Stated plainly
- Whitepaper section
- 10.3
In theory, splitting a large stake across many wallets can dilute quadratic voting, and the contract can't reliably link wallets to a common controller. The whitepaper states this limit directly.
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 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.
Trust · Term 21 of 25
Funds isolation
- To remember
- Excluded
- Whitepaper section
- 11
Staked tokens, reserved bonuses, tokens waiting to unbond, scheduled releases and unvested allocations are all outside the owner's recovery functions.
Staked principal, reserved bonuses, unbonding balances, scheduled releases, and unvested allocations are all excluded from owner recovery functions at the contract level.
Trust · Term 22 of 25
Two-step handover
- To remember
- Two steps
- Whitepaper section
- 11
Ownership of the contracts changes hands in two steps, a safeguard against accidental or hostile ownership moves.
Two-step ownership transfers … prevent accidental or hostile ownership moves.
Trust · Term 23 of 25
Emergency pause
- To remember
- 7 days
- Whitepaper section
- 10.2
The emergency pause is set at 7 days, with a report in 24 hours.
Emergency pause (7 days, report in 24h)
Trust · Term 24 of 25
Multisig and timelock
- To remember
- Intended
- Whitepaper section
- 11
Production administration is intended to use a multisig and a timelock. The project will publish and verify the multisig address, signer threshold, timelock address, delay and authorized roles before production use.
Production administration is intended to use a multisig and timelock. … The project will publish and verify the multisig address, signer threshold, timelock address, delay and authorized roles before production use.
Trust · Term 25 of 25
Designated KYC wallet
- To remember
- Designated
- Whitepaper section
- 10.3
Only the designated official project and compliance wallet is KYC-verified. KYC is not needed to vote, and published project wallets can be tracked by anyone on-chain.
Only the designated official project/compliance wallet is KYC-verified. … KYC is not a precondition for governance voting. … disclosed so every participant can independently observe and track them on-chain
The ZPZ whitepaper is precise, and precise can read like a contract. This glossary takes 25 key terms and says each one in plain English, with the number to remember and the exact section it comes from. Every definition restates the whitepaper and links to it, so you can always check the source.
How to read a tile
Each term sits on a tile, like an element in a periodic table:
- Number and symbol: the tile's place in the table, from 1 to 25, and a short symbol such as Fl for burn floor.
- Family: one of six groups: Basics, Supply, Launch, Release, Governance and Trust.
- The number to remember: the one figure or phrase that sums the term up, such as 5B for the burn floor.
- Section: where the whitepaper states it, linked, so the source is one tap away.
Our words, then plain English
Here are five sentences exactly as the whitepaper writes them. Flip each one to read what it means.
Five whitepaper sentences, decoded
- Exact whitepaper wording
If the request would , the transaction reverts and no portion of that burn is executed.
Burn floor
5B
Once live supply reaches 5,000,000,000 ZPZ, no protocol-controlled burn can take it lower. A burn that would cross the floor is refused in full, with no partial burn.
See it in the glossary - Exact whitepaper wording
reduces but never restores .
Burn
Permanent
A burn destroys ZPZ for good, and burned tokens can't be minted again. Authorized platform contracts may burn ZPZ a user approves when it is spent on ecosystem services.
See it in the glossaryLive supply
Burns lower it
Live supply is what burns reduce. A burn lowers it but never gives back minting room, and once supply reaches 5B the protocol cannot burn below 5B.
See it in the glossaryMax supply
10B
No more than 10,000,000,000 ZPZ can ever be minted in total. The count of tokens ever minted only goes up.
See it in the glossary - Exact whitepaper wording
The universal 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.
Launch window
60 days
For the first 60 days after DEX launch, a non-whitelisted wallet can move out at most 1% of its holdings per day, by DEX sale or peer-to-peer transfer. Deposits into staking are exempt.
See it in the glossary - Exact whitepaper wording
are reserved on-chain and excluded from every and emergency function.
Linear release
720 days
After the cliff, tokens vest continuously over 720 days (24 months). Unvested tokens can't be released early, to anyone.
See it in the glossaryFunds isolation
Excluded
Staked tokens, reserved bonuses, tokens waiting to unbond, scheduled releases and unvested allocations are all outside the owner's recovery functions.
See it in the glossary - Exact whitepaper wording
Tokens acquired or staked after that carry no power for the proposal, eliminating vote-buying during active proposals.
Snapshot
1 hour
Voting power is fixed at a snapshot one hour before the proposal is created. Tokens bought or staked after that snapshot add no votes on that proposal.
See it in the glossary
All 25 terms
Search for a word, or jump to a family. Each card shows the plain meaning first and the whitepaper's own words underneath.
All 25 terms in one place
Showing 25 of 25 terms
Basics5 terms
- Utility token
Access
ZPZ is designed to power access, participation and governance inside the EZPZ Trading ecosystem. It is not an investment vehicle, and holding it is not an equity stake or a debt instrument.
Read section 12 of the whitepaper, on Utility tokenFrom the whitepaper
ZPZ is a utility token designed exclusively to power access, participation, and governance within the EZPZ Trading ecosystem. … ZPZ is not an investment vehicle, and nothing in this document or any associated communication should be construed as financial, investment, or legal advice. … Purchasing or holding ZPZ does not represent an equity stake, debt instrument, or any form of financial security.
- ERC-20
18 decimals
ZPZ is an ERC-20 token on Polygon and uses 18 decimals.
Read section 5 of the whitepaper, on ERC-20From the whitepaper
Token: ZPZ (ERC-20, Polygon), 18 decimals.
- Polygon
POL
ZPZ is built on Polygon (POL), where it is designed to provide token-gated access, DAO participation and adoption incentives.
Read section 1 of the whitepaper, on PolygonFrom the whitepaper
Built on Polygon (POL), ZPZ provides token-gated access, DAO participation, and adoption incentives.
- Upgradeable contract
Public process
The burn floor has no ordinary setting that lowers it. Changing it would need a contract upgrade and a published whitepaper amendment.
Read section 3.2.1 of the whitepaper, on Upgradeable contractFrom the whitepaper
The contract exposes no ordinary administrative setter that can lower this floor; changing it would require a contract upgrade and a published whitepaper amendment.
- Token-gated access
Set in ZPZ
Each access tier is set as a fixed number of ZPZ, not a dollar amount. Holding that number opens the tier, and the DAO may adjust the thresholds.
Read section 3.1 of the whitepaper, on Token-gated accessFrom the whitepaper
Access tiers are defined in fixed ZPZ amounts, not fixed dollar values. … Holding a specific number of ZPZ tokens unlocks each tier. … Tier thresholds may be adjusted through DAO governance if market conditions make access impractical for new users.
Supply5 terms
- Max supply
10B
No more than 10,000,000,000 ZPZ can ever be minted in total. The count of tokens ever minted only goes up.
Read section 5 of the whitepaper, on Max supplyFrom the whitepaper
Maximum cumulative supply: 10,000,000,000 ZPZ. … This counter only ever increases.
- Live supply
Burns lower it
Live supply is what burns reduce. A burn lowers it but never gives back minting room, and once supply reaches 5B the protocol cannot burn below 5B.
Read section 5.1 of the whitepaper, on Live supplyFrom the whitepaper
Burning reduces live supply but never restores minting capacity. … The protocol can therefore reduce supply from the 10B maximum toward 5B, but once supply reaches 5B it cannot burn below 5B.
- Progressive issuance
1B first
ZPZ started with 1,000,000,000 minted. The rest is minted on-chain in phases as each distribution phase activates, always within the 10B cap.
Read section 5.1 of the whitepaper, on Progressive issuanceFrom the whitepaper
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.
- Burn
Permanent
A burn destroys ZPZ for good, and burned tokens can't be minted again. Authorized platform contracts may burn ZPZ a user approves when it is spent on ecosystem services.
Read section 3.2 of the whitepaper, on BurnFrom the whitepaper
Burned tokens are permanently destroyed and cannot be re-minted because the cumulative mint counter never decreases. … 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.
- Burn floor
5B
Once live supply reaches 5,000,000,000 ZPZ, no protocol-controlled burn can take it lower. A burn that would cross the floor is refused in full, with no partial burn.
Read section 5.2 of the whitepaper, on Burn floorFrom the whitepaper
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. … can never be reduced below 5,000,000,000 ZPZ once it has reached that level.
Launch3 terms
- Launch window
60 days
For the first 60 days after DEX launch, a non-whitelisted wallet can move out at most 1% of its holdings per day, by DEX sale or peer-to-peer transfer. Deposits into staking are exempt.
Read section 6 of the whitepaper, on Launch windowFrom the whitepaper
All holders (non-whitelisted) … 1% of holdings per day on all external outflows (DEX sales and peer-to-peer transfers); staking deposits into controller and system contracts are 100% exempt … First 60 days after DEX launch
- Anti-bot limits
50M / 500M
For non-whitelisted wallets, while anti-bot protection is enabled, a single transaction can move at most 50,000,000 ZPZ and each wallet can hold at most 500,000,000 ZPZ. It is a defense against bots, snipers and manipulation.
Read section 6 of the whitepaper, on Anti-bot limitsFrom the whitepaper
Anti-bot layer (all non-whitelisted) … Max 50,000,000 ZPZ per transaction; 500,000,000 ZPZ max wallet; … While anti-bot protection is enabled … Bot, sniper, and manipulation defense
- Sender cooldown
30 s
For non-whitelisted senders, while anti-bot protection is enabled, a sender waits 30 seconds between transactions and can send at most 3 per 5 minutes. It applies to regular wallets and contract senders alike, with named exemptions.
Read section 6 of the whitepaper, on Sender cooldownFrom the whitepaper
Anti-bot layer (all non-whitelisted) … 30-second sender cooldown; 3 sender transactions per 5 minutes (EOAs and contract senders alike; registered pairs and explicit owner, whitelist, controller and system exemptions apply) … While anti-bot protection is enabled
Release3 terms
- Vesting
Coded
The Treasury (1.6B ZPZ) and Development (2B ZPZ) allocations are released on coded vesting schedules in the token contract. Both follow the same policy.
Read section 7 of the whitepaper, on VestingFrom the whitepaper
The Treasury (1.6B) and Development (2B) allocations are subject to coded vesting schedules in the token contract. … Both follow identical policies:
- Cliff
180 days
For the first 180 days (a 6-month cliff), none of the Treasury and Development vesting tokens are accessible.
Read section 7 of the whitepaper, on CliffFrom the whitepaper
6-month cliff: No tokens are accessible for the first 180 days.
- Linear release
720 days
After the cliff, tokens vest continuously over 720 days (24 months). Unvested tokens can't be released early, to anyone.
Read section 7 of the whitepaper, on Linear releaseFrom the whitepaper
24-month linear release: After the cliff, tokens vest continuously over 720 days. … The contract mathematically cannot release them early, to anyone.
Governance4 terms
- DAO
Staked votes
In the ZPZ DAO, only staked tokens vote, proposers can't vote on their own proposals, each proposer can make at most 10 proposals per rolling year, every vote runs at least 3 days, and a proposal passes with more than 50% of votes cast plus a minimum number of votes in favor.
Read section 10.1 of the whitepaper, on DAOFrom the whitepaper
Only staked tokens vote. … Proposers cannot vote on their own proposals; this is enforced in the contract. … 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.
- Quadratic voting
√ stake
Voting credits are the square root of your staked ZPZ, so 100x the stake gives only 10x the votes.
Read section 10.1 of the whitepaper, on Quadratic votingFrom the whitepaper
Voting credits equal the square root of a participant's staked ZPZ. … A holder with 100x the stake receives only 10x the votes.
- Snapshot
1 hour
Voting power is fixed at a snapshot one hour before the proposal is created. Tokens bought or staked after that snapshot add no votes on that proposal.
Read section 10.1 of the whitepaper, on SnapshotFrom the whitepaper
Voting power is fixed at a snapshot point set one hour before the proposal is created … Tokens acquired or staked after that snapshot carry no power for the proposal, eliminating vote-buying during active proposals.
- Sybil trade-off
Stated plainly
In theory, splitting a large stake across many wallets can dilute quadratic voting, and the contract can't reliably link wallets to a common controller. The whitepaper states this limit directly.
Read section 10.3 of the whitepaper, on Sybil trade-offFrom the whitepaper
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 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.
Trust5 terms
- Funds isolation
Excluded
Staked tokens, reserved bonuses, tokens waiting to unbond, scheduled releases and unvested allocations are all outside the owner's recovery functions.
Read section 11 of the whitepaper, on Funds isolationFrom the whitepaper
Staked principal, reserved bonuses, unbonding balances, scheduled releases, and unvested allocations are all excluded from owner recovery functions at the contract level.
- Two-step handover
Two steps
Ownership of the contracts changes hands in two steps, a safeguard against accidental or hostile ownership moves.
Read section 11 of the whitepaper, on Two-step handoverFrom the whitepaper
Two-step ownership transfers … prevent accidental or hostile ownership moves.
- Emergency pause
7 days
The emergency pause is set at 7 days, with a report in 24 hours.
Read section 10.2 of the whitepaper, on Emergency pauseFrom the whitepaper
Emergency pause (7 days, report in 24h)
- Multisig and timelock
Intended
Production administration is intended to use a multisig and a timelock. The project will publish and verify the multisig address, signer threshold, timelock address, delay and authorized roles before production use.
Read section 11 of the whitepaper, on Multisig and timelockFrom the whitepaper
Production administration is intended to use a multisig and timelock. … The project will publish and verify the multisig address, signer threshold, timelock address, delay and authorized roles before production use.
- Designated KYC wallet
Designated
Only the designated official project and compliance wallet is KYC-verified. KYC is not needed to vote, and published project wallets can be tracked by anyone on-chain.
Read section 10.3 of the whitepaper, on Designated KYC walletFrom the whitepaper
Only the designated official project/compliance wallet is KYC-verified. … KYC is not a precondition for governance voting. … disclosed so every participant can independently observe and track them on-chain
Five numbers worth remembering
| Number | What it is | Section |
|---|---|---|
| 10B | The most ZPZ that can ever be minted, counted across every token ever created | 5.1 |
| 5B | The burn floor: once live supply reaches 5,000,000,000 ZPZ, no protocol-controlled burn can take it lower | 5.2 |
| 60 days at 1% | For the first 60 days after DEX launch, a non-whitelisted wallet can move out at most 1% of its holdings per day | 6 |
| 180 + 720 days | Treasury and Development vesting: a 180 day cliff, then continuous vesting over 720 days | 7 |
| 1 hour | Voting power is fixed at a snapshot one hour before a proposal is created | 10.1 |
What this glossary covers
It covers the rules readers ask about most. Staking, the presale and fee routing each have their own section of the whitepaper, and they read most clearly there in full: section 4 on staking, section 8 on the presale and section 3.2 on burns and fees.
A few limits the whitepaper states plainly, and so do we:
- The 5B level is a burn floor, not a price guarantee.
- The anti-bot limits apply while anti-bot protection is enabled.
- The contract cannot reliably link separate wallets to a common controller, so in theory quadratic voting can be diluted by splitting a large stake across many wallets.
FAQ
What is the ZPZ burn floor?
It is a 5,000,000,000 ZPZ floor on live supply, which applies once supply reaches that level. From then on, a protocol-controlled burn that would take supply below it is refused in full, and no partial burn happens. The whitepaper calls it a burn floor, not a price guarantee.
What is the difference between max supply and live supply?
Max supply is the 10,000,000,000 ZPZ cap on every token ever minted, and that count only goes up. Live supply is what burns reduce. Burning lowers live supply but never restores minting capacity.
What does quadratic voting mean for ZPZ?
Voting credits equal the square root of your staked ZPZ. A holder with 100x the stake receives only 10x the votes, and only staked tokens vote.
What is a vesting cliff?
For the Treasury and Development allocations, it is the first 180 days, when no tokens are accessible. After the cliff, tokens vest continuously over 720 days.
Do I need KYC to vote?
No. The whitepaper says KYC is not a precondition for governance voting. Only the designated official project and compliance wallet is KYC-verified.
Is ZPZ an investment?
No. The whitepaper describes ZPZ as a utility token designed to power access, participation and governance within the EZPZ Trading ecosystem, and says it is not an investment vehicle.
Start here
Read the full ZPZ whitepaper, then go deeper on two of these terms: try to break the floor in Many Token Burns Don't Shrink Supply and weigh a whale against the crowd in Inside ZPZ Governance. For the full supply picture, read ZPZ Coin Tokenomics, and for launch timing see the roadmap.
ZPZ is structured and intended to function as a utility token. It is not offered, sold, or intended to be classified as a security, investment contract, or financial instrument under applicable law. Nothing in this document constitutes financial, investment, or legal advice.
Cryptocurrency investments are highly speculative and volatile. You could lose the entire amount you contribute. There is no guarantee of future profits or returns. Regulatory changes may affect the token's utility. Smart contracts carry risk, including undiscovered bugs. Nothing here is investment advice. Do your own research.