The Life of a ZPZ Proposal: Six Gates to a Decision

A ZPZ proposal is designed to pass six gates before anything changes: who may propose, a snapshot of voting power, a voting window of at least three days, a count that needs more than half the votes cast, a route that depends on what is being decided, and a public record. Each gate is a rule in section 10 of the whitepaper, and this post walks one proposal through all six.

ZPZ is launching, so governance is not open yet. Everything below is the design the whitepaper sets out, and every rule links to the line it comes from. For the math behind the votes themselves, read 100x the Stake, Only 10x the Votes.

Meet the proposal

Access to EZPZ tools is designed in fixed ZPZ amounts, not dollars. The whitepaper also plans for the day that stops working: section 3.1 says a tier threshold can be adjusted by a DAO vote if market conditions make access impractical for new users.

Tier thresholds may be adjusted through DAO governance if market conditions make access impractical for new users.

So here is our example. A holder thinks an access tier has become too steep for newcomers and wants it lowered. That is a decision the whitepaper puts in holders' hands, which makes it a fair test of every gate.

Six gates, in order

Here is the whole path at a glance. The rings around the coin at the top of this post are the same six gates; pick one to read its rule.

Gate I. The proposer

Not every wallet can file a proposal. Creating one requires a minimum staked amount, and voting requires a minimum too. Both minimums are configurable and published on-chain; the whitepaper does not set the numbers yet.

There is also a ceiling. Each proposer may create at most 10 proposals per rolling year, so no one can bury the ballot under a pile of motions. Beyond that, the door is open: there is no allowlist, no registry and no identity check to take part (section 10.3).

Gate II. The snapshot

Before a single vote is cast, the count of who can vote is already fixed. Voting power is taken from a snapshot one hour before the proposal is created, and tokens bought or staked after that point carry no power on this proposal.

Voting power is fixed at a snapshot point set one hour before the proposal is created.

Two details make the snapshot hard to bend. Only staked ZPZ counts, so unstaked balances carry zero votes, including any tokens in the treasury or development wallets. And the contracts keep checkpointed balances, which the whitepaper describes as tamper-proof snapshot voting (section 11).

Gate III. The voting window

Every proposal stays open for at least three days. That gives holders time to notice it, read it and respond, and it rules out a vote that opens and closes while everyone is asleep.

During the window, each staker's votes equal the square root of their staked ZPZ, so a holder with 100 times the stake gets 10 times the votes. One person is missing from the ballot: the proposer. They cannot vote on their own proposal, and the whitepaper says the contract enforces it.

Gate IV. The count

When the window closes, the proposal needs two things. More than 50% of the votes cast must be in favour, and the votes in favour must reach a minimum number. Exactly half is not enough, and neither is a narrow win among a handful of wallets.

Passing requires more than 50% support of votes cast and a minimum number of votes in favour.

Gate V. The route

Passed proposals do not all travel the same road. Our tier proposal is a DAO decision because section 3.1 says so. Spending from the treasury is routed by size under the treasury policy in section 10.2, and the treasury itself is held in a multisig. The treasury desk below walks through those tiers.

Gate VI. The record

The last gate is daylight. The core EZPZ group and UOI wallet addresses designated for publication are disclosed, so anyone can follow their balances, staking activity and voting behavior on-chain. Treasury activity is covered by quarterly reports, and the DAO contract address is designed to be published and source-verified on Polygonscan before DEX launch (section 11).

That is the whole path. Now try to cheat it.

Try to game the vote

DAO takeover stories often follow a few familiar plays: buy in during a vote, rush a decision through, or pass it while almost nobody is watching. The panel below lists seven. Open each one to see the gate designed to stop it, and the one trick the whitepaper says it cannot block.

After a vote passes: the treasury desk

The treasury holds 16% of the 10 billion ZPZ supply, 1,600,000,000 ZPZ marked for operations and the DAO, under coded vesting (section 5). Spending from it is split into three tiers by size:

Small, routine spends move without a vote, inside a monthly cap. Larger ones come to holders. The largest need a higher quorum and a timelock, a waiting period before the decision takes effect, so everyone can see it coming. The whitepaper does not set the quorum or the length of the timelock yet.

Pick a kind of proposal below, or set a spend amount, and see where it goes.

What no vote can reach

A DAO vote carries real weight, but the whitepaper puts some rules outside its reach on purpose. These are the ones designed to stay put whatever a vote decides:

• The 10 billion cap. The cap counts every token ever minted, and that count only goes up. Burning never makes room to mint more (section 5.1).
• The 5 billion burn floor. No ordinary setting can lower it. Changing it would take a contract upgrade and a published whitepaper amendment (section 3.2.1).
• The release schedule in section 4. It is fixed in the contract, and the whitepaper says it cannot be changed by DAO vote (section 4.4).
• Unvested treasury and development tokens. They are reserved on-chain and cannot be released early, to anyone (section 7).

One more setting sits outside the vote, for a different reason. The 70/20/10 split of eligible ecosystem fees is an owner setting, not a DAO decision. The owner can change it as long as it totals 100%, and every change is recorded on-chain (section 3.2.1). We would rather you read that here than find it later.

Safety rails around the process

• Emergency pause. 7 days, with a report within 24 hours (section 10.2).
• Guardian powers with an end date. They sunset after 12 months, or sooner if a DAO vote ends them.
• Signer rotation. The treasury policy includes a signer rotation policy for the multisig.
• Audits, bug bounties and quarterly reports. All three are listed as standing safeguards in the treasury policy.
• Two-step ownership transfers. Ownership of the contracts moves in two steps, which the whitepaper says prevents accidental or hostile ownership moves (section 11).

Honest limits

• Some numbers are not set yet. The minimum stake to propose, the minimum stake to vote, the minimum votes in favour, the higher quorum for Tier 3 and the length of the timelock are not fixed in the whitepaper. The voting minimums are configurable and published on-chain.
• Small spends skip the vote. Tier 1 spends up to $25k are decided by the council, inside a $100k monthly cap.
• Wallet splitting. One person could split a large stake across many wallets to collect more votes. The contract cannot reliably link those wallets, and the available check is watching published project wallets on-chain (section 10.3).
• Administration depends on setup. Production administration is intended to use a multisig and a timelock, and the whitepaper says these protections depend on the actual ownership and role configuration (section 11).
• The fee split is an owner setting. As covered above, the owner changes it, not a vote.

Six gates make a ZPZ proposal slow to rush and hard to buy during a live vote, and the whitepaper names the places where it is not airtight.

FAQ

How long does a ZPZ governance vote last?

At least three days. Every proposal has a minimum 3-day voting window under section 10.1 of the whitepaper.

When is ZPZ voting power counted?

At a snapshot set one hour before the proposal is created. ZPZ bought or staked after the snapshot carries no votes on that proposal.

Who can create a ZPZ proposal?

A staker who holds at least the minimum staked amount. The minimum is configurable and published on-chain, and the whitepaper does not set the number yet. No allowlist or identity check applies.

How many proposals can one proposer create?

At most 10 per rolling year.

What does a ZPZ proposal need to pass?

More than 50% of the votes cast, plus a minimum number of votes in favour. Exactly half does not pass.

Can a DAO vote lower the 5B burn floor?

No. There is no ordinary setting that lowers the floor. Changing it would require a contract upgrade and a published whitepaper amendment, under section 3.2.1.

Who approves small treasury spends?

Spends up to $25k are decided by the council, capped at $100k a month. Spends from $25k to $250k go to a DAO vote, and spends above $250k need a higher quorum and a timelock.

Do I need KYC to vote?

No. KYC is not a precondition for governance voting, and any staker can vote. Other KYC rules may still apply where law, presale rules, an exchange or a payment provider require them.

When can I vote?

ZPZ is launching, and governance is not open yet. The launch targets are on the roadmap, and targets can move.

Start here

Read section 10 of the whitepaper for every governance rule. Then see the vote math in 100x the Stake, Only 10x the Votes, look up any term in The ZPZ Glossary, and try to break the burn floor in Many Token Burns Don't Shrink Supply. For news as it lands, follow @ZPZcoin on X.