Zen Protocol Documentation
WebsiteTelegramBlogForum
  • Zen Protocol Docs
  • Apps
    • Headless Full Node
      • Full Node NPM Package
      • Build from Source
      • CLI
      • API
        • Wallet
        • Contracts
        • General
        • Blockchain
        • AddressDB
      • Deploy
        • Systemd
        • Shell script
        • Docker
      • Technical Model
      • AddressDB
    • Wallet
      • Desktop Wallet
        • Installers
      • Web Wallet
        • Run Locally
      • Wallet User Guide
        • Connect a Wallet
          • Create a Wallet
          • Import a Wallet
          • Watch Mode
        • My Wallet
          • Navigation Bar
          • Portfolio
          • Receive
          • Send / Execute
          • Transaction History
        • Contracts
          • Active Contracts
          • Execute a Contract
            • Message Body Field
          • Extend a Contract
          • Activate a Contract
        • Voting
          • Common Goods Pool
            • Generating a Ballot ID
          • Governance
        • Signer
        • Settings
          • Account Settings
          • Node Connectivity
      • Deprecated Desktop Wallet
        • Executable Installers
        • Wallet Structure
          • Video Tutorials
    • Explorer
    • Zen.js
      • Payment Processing
    • Oracle
      • Oracle GUI
      • Oracle Service
      • Oracle's API
      • Deploy
        • Systemd
        • Docker
      • How the Oracle contract works
      • How to create an Attestation token
    • Dex
      • Dex User Guide
        • Traded Pairs
        • Search Pairs
        • Order Book
        • Operations
        • My Wallet
        • Settings
      • How DEX contract works
    • Fixed Payout
      • Fixed Payout Generator User Guide
        • Issue
        • Redeem
        • Cancel
        • Verify
        • Settings
      • How the FP Contract works
      • How are the asset named?
  • Smart Contracts
  • Contract Structure
  • Contract Cost
  • Contract Activation
  • Contract Examples
  • Smart Contracts SDK
  • Contracts Language ZF*
  • Named Token Tutorial
  • Consensus
  • Common Goods Pool
  • Block Validation
  • Transaction Validation
  • Serialization
  • Use Cases
    • Create Unsigned Transaction
    • Secure Sign Transaction
    • Cold Storage using Full Node
  • Troubleshooting
    • Responsible Disclosure
    • Bug Bounty
    • Known Bugs
  • For Miners
    • Pools
    • GPU Mining
    • GPU Bounties
  • Check Crowdsale Contribution
  • Alpha call option
Powered by GitBook
On this page
  • Interval blocks
  • Payout
  • Allocation
  • Voting
  • Tally Calculation
  • Allocation Ballot Validation
  • Payout Ballot Validation

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. The Nomination Phase - in which payout contestants are trying to become valid payout nominees.

  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. Nomination Phase:

      From 10,000 * (N-1) + 9,001 to 10,000 * (N-1) + 9,500 (including boundaries)

      Nominating contestants for the payout

    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. There are sufficient funds for the CGP contract to cover all the outputs of the payout transaction.

  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. It doesn’t exceed the upper allocation bound (90%).

  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. 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. 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.

PreviousNamed Token TutorialNextBlock Validation

Last updated 4 years ago