Released, then paced
Two rules in the token contract decide how these tokens reach the market: a vesting schedule, then a permanent pace.
- 180-day cliff
- 720-day release
- 1% a day
- 10% per 30 days
- Permanent
- Allocation
- 1,600,000,000 ZPZ
- Released per day
- about 2,222,222 ZPZ
Per-day figures worked from section 7: allocation divided by 720 days.
Pace · Every 30-day window
Once released, the wallet is protected: at most 1% a day and 10% per 30 days of what has been released, whichever is stricter. No expiry.
Section 6.1Pace Every 30-day window
ZPZ's Treasury and Development allocations reach the market in two stages, and both are written into the token contract. First they are released on a vesting schedule: nothing for 180 days, then an even release over 720 days. Then whatever has been released is paced: a protected wallet can move at most 1% a day and 10% per 30 days of it, with no expiry.
ZPZ is launching, so this is the design the whitepaper sets out, and every rule below links to the line it comes from in section 7 and section 6.
Two stages at a glance
| Stage | The rule | The numbers | Source |
|---|---|---|---|
| Wait | No tokens are accessible | 180 days | Section 7 |
| Release | Tokens vest continuously, at an even rate | 720 days | Section 7 |
| Protect | The receiving wallet becomes a protected wallet on its first release | From the first release | Section 7 |
| Pace | Outgoing transfers are capped by the stricter of two limits on what has been released | 1% a day, 10% per 30 days, no expiry | Section 6.1 |
The allocations themselves come from section 5: Treasury is 16% of the 10 billion cap, or 1,600,000,000 ZPZ, for operations and the DAO. Future Development is 20%, or 2,000,000,000 ZPZ, for upgrades, integrations and audits. Section 7 says both follow identical policies.
Stage one: released
The schedule has two parts. A 6-month cliff comes first, and the whitepaper is direct about it: no tokens are accessible for the first 180 days. After the cliff, a 24-month linear release begins, and tokens vest continuously over 720 days. From the first day of the schedule to the last is 900 days.
Linear means even. Divide each allocation by 720 days and the daily rate is fixed for the whole release:
- Treasury: 1,600,000,000 ZPZ over 720 days, about 2,222,222 ZPZ a day.
- Development: 2,000,000,000 ZPZ over 720 days, about 2,777,778 ZPZ a day.
- Together: 3,600,000,000 ZPZ over 720 days, exactly 5,000,000 ZPZ a day.
Daily figures worked from section 7: the allocation divided by 720 days.
No day releases more than any other, so there is no single date when a large block arrives at once. And the part that has not vested yet stays where it is:
Unvested tokens are reserved on-chain and excluded from every owner recovery and emergency function. The contract mathematically cannot release them early, to anyone.
Section 11 repeats the point in its list of funds the owner cannot recover: staked principal, reserved bonuses, unbonding balances, scheduled releases and unvested allocations.
Stage two: paced
A released token is not free to leave all at once. Section 7 says vesting beneficiaries are designated protected on their first release, and protected wallets follow the permanent caps in section 6.
The base is what was released, not the balance
The contract keeps a running total for each protected wallet, called the freed amount. Every qualifying vesting release adds to it. Tokens the wallet picks up in the market do not. The caps are a share of that total:
- 1% per day of the freed amount.
- 10% per 30-day window of the freed amount.
- The stricter limit applies, and the caps are permanent, with no expiry.
The two limits work together. At 1% a day, the 10% window is full after 10 days. From day 11 to day 30 nothing more can leave, and then a new window opens. In practice, a protected wallet can move at most 10% of what has been released to it in any 30 days.
Example figures If 100,000,000 ZPZ has been released to a protected wallet, it can send at most 1,000,000 ZPZ in a day and 10,000,000 ZPZ in a 30-day window.
Sending tokens does not shrink the base
An outgoing transfer uses up that day's and that window's allowance, but it never reduces the freed amount. The base only grows as more is released, so the pace is set by the release schedule, not by how much the wallet happens to hold that day.
The 30-day pace calendar
- Daily limit
- 1,000,000 ZPZ
- 30-day window limit
- 10,000,000 ZPZ
- Tokens move
- Nothing moves
- A limit binds or credit arrives
Day 10: window full.
Moved in this window: 10,000,000 ZPZ of 100,000,000 released (10%)
Paced
Steady 1% a day
The 10% window fills on day 10. Nothing more can leave until the window ends.
Read section 6.1“the permanent protected-wallet limits are 1% per day and 10% per 30-day window of the wallet's tracked cumulative freed amount [...], not of its total token balance. The stricter limit applies.”
Rules from whitepaper section 6.1. ZPZ is launching; this is the design the whitepaper sets out. Read section 6.1
The rules that close the shortcuts
A cap is only as strong as its edges. Section 6.1 covers each obvious way around it:
- Pacing happens at the sender. Every permitted outgoing transfer from a protected wallet is paced, including DEX sales and wallet-to-wallet transfers.
- Protection does not pass along, and neither does credit. Recipients do not inherit protected status or freed credit, so moving tokens to a fresh wallet does not reset anything. The tokens already counted against the sender's limit to get there.
- No looping. Restaking released tokens uses up the matching freed amount, so the same tokens cannot be released and restaked again and again to grow the base.
- No side door. Direct transfers from a protected wallet to the staking controller or other system custody contracts are blocked. Sending to a system address is not a way around the pace.
- Ceilings are set when a window opens. New credit or a rate change cannot enlarge an active ceiling. Credit received mid-window counts from the next window, at most 30 days later.
One movement is exempt by design: pulls by the staking controller into staking, for deposits and reward funding. Those keep tokens inside the system rather than sending them to the market.
Who else is paced
Treasury and Development are not the only wallets with limits. Section 6 lays out three layers:
| Who | Limit | Based on | How long |
|---|---|---|---|
| Protected wallets: Treasury, Development and full 3-year maturity-release recipients | 1% a day and 10% per 30 days, whichever binds first | The freed amount | Permanent, no expiry |
| All non-whitelisted holders | 1% a day on all external outflows; staking deposits are exempt | Current holdings | First 60 days after DEX launch |
| Anti-bot layer, all non-whitelisted | 50,000,000 ZPZ per transaction, 500,000,000 ZPZ per wallet, a 30-second sender cooldown and 3 sender transactions per 5 minutes | Each transaction | While anti-bot protection is enabled |
The 3-year stakers share the same cap for the same reason. At maturity, section 4.4 releases 15% of principal and bonus at withdrawal and the rest in 13 equal monthly tranches, and each release that adds credit is paced like a vesting release. Whether tokens come from vesting or from a matured stake, they reach the market on a schedule and then at a pace.
Kept apart on purpose
- Separate wallets. Liquidity and operations wallets must be distinct from every vesting beneficiary and must never receive vesting releases or freed-credit grants. Liquidity is seeded from its own allocation (section 7).
- No votes while unstaked. Only staked tokens vote. Unstaked balances, including any tokens in Treasury or Development wallets, carry zero voting power (section 10.1).
- Spending goes through tiers. Treasury spends up to $25k are decided by the council within a $100k monthly cap. Spends from $25k to $250k go to a DAO vote, and spends above $250k need a higher quorum and a timelock (section 10.2).
What the whitepaper states plainly
- Pacing limits outflows, nothing more. The caps limit how fast a protected wallet can send tokens. They say nothing about what the market will do.
- Wallet setup is a checked step. The whitepaper says the separation between vesting beneficiaries and liquidity or operations wallets must be checked before any schedule is created.
- Administration depends on configuration. Production administration is intended to use a multisig and a timelock, and these protections depend on the actual ownership and role configuration. The project will publish the multisig, signer threshold, timelock and roles before production use (section 11).
- You can check it yourself. The token, staking, DAO and buyback contract addresses are to be published and source-verified on Polygonscan before DEX launch, so every parameter here can be verified on-chain.
Released on a schedule no one can hurry, then paced by a cap that never expires. That is how the whitepaper says Treasury and Development ZPZ reaches the market.
FAQ
When can ZPZ Treasury and Development tokens first move?
Not during the first 180 days of their vesting schedule. Section 7 of the whitepaper sets a 6-month cliff in which no tokens are accessible, followed by a 720-day linear release. The whitepaper does not publish a start date, and launch targets are on the roadmap.
What is the freed amount?
The running total of qualifying ZPZ released to a protected wallet by a vesting release or the staking contract. The protected-wallet limits are a percentage of this total, not of the wallet's balance, and tokens bought in the market do not add to it.
How fast can a protected wallet move its released ZPZ?
At most 1% of its freed amount per day and 10% per 30-day window, and the stricter limit applies. At 1% a day the 10% window is full after 10 days, so nothing more leaves until the window ends.
Does the pace limit ever expire?
No. Section 6 lists the protected-wallet caps as permanent, with no expiry. The 60-day launch cap for ordinary holders is the one that ends.
Can the vesting schedule be sped up?
Section 7 says unvested tokens are reserved on-chain, excluded from every owner recovery and emergency function, and that the contract cannot release them early, to anyone.
Do Treasury and Development tokens vote in the DAO?
Not while unstaked. Section 10.1 says only staked tokens vote, and unstaked balances, including any tokens in Treasury or Development wallets, carry zero voting power.
Start here
Read section 7 of the whitepaper for the vesting schedule and section 6 for every cap. Then see the full supply picture in ZPZ Coin Tokenomics, try to break the burn floor in Many Token Burns Don't Shrink Supply, and follow a treasury spend through the DAO in The Life of a ZPZ Proposal. For news as it lands, follow @ZPZcoin on X.
ZPZ is a utility token, not an equity stake, a debt instrument or a security. 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.