Token Mechanics: POWER & ZERO

Power token (PowerToken.sol)

With great power comes great responsibility.

The primary token for operational governance, featuring strong incentives for active participation.

• Standard & Properties: ERC-20 compatible. Implements IEpochBasedInflationaryVoteToken which includes:
  • Epoch-based snapshots for historical balances/votes.
  • ERC-5805 for voting and delegation (delegate, getPastVotes).
  • ERC-3009 for transfer authorization (transferWithAuthorization).
  • 0 decimals.
• Voting Usage: The voting token for StandardGovernor (simple majority) and EmergencyGovernor (threshold-based). Vote weight is determined by the balance snapshot taken at the end of the epoch before the voting epoch (proposalSnapshot function returns voteStart - 1).
• Inflationary Mechanism (~10% target per active voting epoch):
  • Activation: An epoch becomes "active" for inflation calculation when the first StandardGovernor proposal targeting that epoch is created. This proposal action calls Power token.markNextVotingEpochAsActive(), which pre-calculates the target total supply for the end of that voting epoch based on a ~10% increase (participationInflation parameter in Power token).
  • Distribution Trigger: At the end of a Voting Epoch, the StandardGovernor identifies voting power (direct or delegated via voter_ address in _castVote) that participated in every single proposal during that epoch. For each fully participating delegatee address, it calls Power token.markParticipation(delegatee).
  • Distribution Execution: Inside Power token, _markParticipation calculates the inflation amount based on the delegatee's current voting power (_getVotes). This amount is immediately added to the delegatee's tracked voting power (_votingPowers) and the overall token supply (_totalSupplies). Crucially, the actual token balance (_balances) increase for the underlying holders is deferred until their next interaction with the token (e.g., transfer, delegate, sync) which triggers the internal _sync function to realize the inflation.
  • Incentive Rationale: This system directly rewards consistent participation in standard governance. Missing even one vote means forfeiting the ~10% inflation for that epoch, resulting in dilution relative to fully active participants. Holders whose delegates participate fully benefit from this inflation.
• Dutch Auction for Unallocated Inflation:
  • Source: The difference between the target supply (calculated at the start of the Voting Epoch) and the actual total supply after inflation distribution. This gap arises primarily from voting power that didn't fully participate. The amountToAuction() function calculates this difference.
  • Timing: Auctions are active only during Transfer Epochs.
  • Price Mechanism: Uses a Dutch auction format (getCost() calculates the price in CashToken per POWER). The 15-day epoch is divided into 100 periods (_AUCTION_PERIODS). The price starts high and decreases linearly within each period. The starting price for each period is half the starting price of the preceding period, creating an overall exponential decay curve. Pricing is relative to the previous epoch's total supply to ensure consistent price dynamics over time.
  • Purchase: Users call buy() providing the active CashToken (e.g., WETH) and specifying amounts and expiry. Requires CashToken allowance.
  • Proceeds Destination: The collected CashToken is transferred directly to the DistributionVault.
• Transfer & Delegation Restrictions: Transfers (transfer, transferFrom) and delegation (delegate) are only permitted during Transfer Epochs, enforced by the notDuringVoteEpoch modifier. These actions also trigger _sync() to update the account's balance with any pending inflation.
• Bootstrapping: The constructor or a ZeroGovernor reset (resetToPowerHolders, resetToZeroHolders) initializes the Power token state. It distributes an INITIAL_SUPPLY of 1,000,000 tokens proportionally based on the balances of a specified bootstrapToken (like PowerBootstrapToken.sol, a previous Power token version, or the Zero token) at the bootstrapEpoch (the epoch before deployment/reset). Initial delegatee is self.

Zero token (ZeroToken.sol)

It all starts at zero.

The apex token for meta-governance and claiming protocol-generated revenue.

• Standard & Properties:
  ERC-20 compatible. Implements IEpochBasedVoteToken which includes:
  • Epoch-based snapshots for historical balances/votes.
  • ERC-5805 for voting and delegation (delegate, getPastVotes, pastBalancesOf, pastTotalSupplies).
  • ERC-3009 for transfer authorization (transferWithAuthorization).
  • 6 decimals.
• Supply Dynamics:
  Generally static. The total supply increases only when the StandardGovernor explicitly mints new ZERO tokens as rewards for governance participation. The initial supply (e.g., 1,000,000,000) is determined at deployment via the constructor minting to initial accounts.
• Minting Mechanism (Rewards):
  • Minting is controlled exclusively by the active StandardGovernor contract, enforced by the onlyStandardGovernor`` modifier on the Zero token.mint() function.
  • Triggered when ``StandardGovernor._castVote processes the final vote for a voter (voter_) in an active Voting Epoch (i.e., they voted on all proposals).
  • The reward is minted to the voter_ address provided in the ``StandardGovernor._castVote context, which corresponds to the address whose voting power was utilized (this is typically the delegatee's address if power was delegated). This incentivizes becoming an active delegate.
  • The reward amount is calculated proportionally to the POWER voting power used (weight_), but capped at a maximum total of 5 million ZERO per epoch (maxTotalZeroRewardPerActiveEpoch in StandardGovernor). Formula: reward = (maxTotalZeroRewardPerActiveEpoch * weight_) / totalSupply(epoch - 1).
• Voting Usage:
  The voting token for the ZeroGovernor (threshold-based). Vote weight is determined by the ZERO balance snapshot taken at the end of the epoch before the voting epoch (proposalSnapshot).
• Core Utility:
  • Grants voting rights on fundamental meta-governance proposals within the ZeroGovernor (system resets, CashToken changes, threshold adjustments).
  • Entitles holders to claim a pro-rata share of various assets accumulated in the DistributionVault. Claiming is based on ZERO holdings in past epochs.
  • Provides an indirect economic benefit from Power token auctions, as the proceeds (CashToken) flow into the DistributionVault.