Zen Protocol Documentation
WebsiteTelegramBlogForum
Search…
⌃K
Links

Common Goods Pool

This protocol upgrade creates a 'Common Goods Pool' (or 'CGP'), which would hold assets, and distribute its funds according to an on-chain vote open to ZP holders.
The CGP contract is a custodian contract which can unlock ('pay out') some of its available assets to a specified recipient - a PK address or a contract.
For each block - some portion of the coinbase transaction (called "allocation") will be locked to the CGP contract instead of the miner.
Since the CGP is a contract, users would also be able to donate any amount of any asset they own to the CGP, allowing the CGP to hold tokens of any kind of Zen Protocol asset.
Users will be able to vote on the portion of the coinbase outputs locked to the CGP contract ("allocation" vote), and on the recipient and spends (assets and amounts) of each payout ("payout" vote).
Voting for allocation could be done anytime during the voting phase, however - voting for payout is split into 2 phases - nomination phase and voting phase.
  1. 1.
    The Nomination Phase - in which payout contestants are trying to become valid payout nominees.
  2. 2.
    The Voting Phase - in which valid payout nominees are trying to get the payout.

Interval blocks

  • Blockchain Interval:
    From 10,000 * (N-1) + 1 to 10,000 * N (including boundaries)
    The whole process takes places in intervals of 10,000 blocks starting from the genesis.
  • Voting Interval:
    From 10,000 * (N-1) + 9,001 to 10,000 * N (including boundaries)
    The actual voting takes place here.
    Split into 2 phases:
    1. 1.
      Nomination Phase:
      From 10,000 * (N-1) + 9,001 to 10,000 * (N-1) + 9,500 (including boundaries)
      Nominating contestants for the payout
    2. 2.
      Voting Phase:
      From 10,000 * (N-1) + 9,501 to 10,000 * N (including boundaries)
      Voting on which nominee gets the payout
  • Snapshot Block:
    10,000 * (N-1) + 9,000
    All the votes are weighted and validated by using the state of the UTXOs set at this block.
  • Payout Block:
    10,000 * N + 100
    The payout and allocation change takes place at this block.

Payout

The CGP Contract execution will return a valid transaction only if the following conditions hold:
  1. 1.
    There are sufficient funds for the CGP contract to cover all the outputs of the payout transaction.
  2. 2.
    The payout transaction contains at least 1 output and no more than 100 outputs.

Allocation

With each mined block, in the coinbase transaction, a percentage of the reward of that block will be sent by the miner to the CGP contract.
This percentage is called “The Coinbase Allocation”.

Voting

Users cast a ballot by sending the voting data (using the contract message body) to the Voting contract.
The Tally will count the votes, and determine the winner.
Users may vote for 2 independent items:
  • Allocation: Users vote on the % of the block reward to be allocated to the CGP each block. (Nodes will not build on top of a block that does not contain a coinbase transaction with sufficient allocation output)
  • Payout: Each voting interval users can vote on the recipient and the list of assets & amounts the recipient will receive

Tally Calculation

At the end of the voting interval the tally will calculate the votes.
The Tally will only count the 1st vote for each PK, and only when it is executed within the voting interval. The vote also has to have a valid ballot to count.

Allocation Ballot Validation

An allocation ballot is considered as valid as long as the following conditions hold:
  1. 1.
    It doesn’t exceed the upper allocation bound (90%).
  2. 2.
    It is no bigger and no smaller than the allocation correction cap (15%) relative (proportional) to the allocation of the last block.

Payout Ballot Validation

Voting on payout is done in 2 phases, each with its own validity rules:
  1. 1.
    Nomination Phase:
    A payout ballot will become a valid nominee if the following conditions hold:
    a. At the snapshot the CGP contract has enough funds to cover it
    b. The spend list length is between 1 and 100 elements
    c. The spend list must be sorted in lexicographical order (over the asset ids) and the assets must to be unique
    d. The aggregated vote weight of the contestant is at least 3% of the total issued ZP at the snapshot block
  2. 2.
    Voting Phase:
    During the voting phase payout votes can only be made for a valid nominee.
    There is a special nominee which is always valid as long as there are sufficient funds in the CGP regardless of the results of the nomination, which is a payout of 1 kalapa to the CGP itself - this is the default vote which a user can vote on to effectively prevent a payout.
​
Previous
Named Token Tutorial
Next
Block Validation
Last modified 2yr ago