Peerplays Improvement Proposal #1 – Gamified Proof of Stake (GPoS)

Peerplays_PIP_Inforgraphic (1)

The first Peerplays Improvement Proposal, or PIP, has been uploaded to the Peerplays community repo on Github. Regarding Gamified Proof of Stake, or GPoS, we created this infographic to better help everyone understand GPoS and what it proposes.

After the graphic, you’ll find the PIP in full.


Author: Jonathan Baha’i


The original intent of Peerplays was to operate as a Decentralized Autonomous Cooperative (DAC) where DPOS enables the voting collective of core token holders to determine whom would act as Advisors, Witness, and Proposals within Peerplays. However, the challenges of voter turnout continue to plague Peerplays like other DPOS based blockchains such as Bitshares, Steem, and EOS. This proposal aims to resolve this issue by attaching a rewards mechanism in the blockchain directly to the voting activity.

This protocol change will convert Peerplays blockchain from a DPOS consensus to a GPOS consensus, Gamified Proof of Stake. The PPY token will continue to operate as a core token to the Peerplays blockchain essential for all core blockchain operations.

All fees that the Peerplays Blockchain charges for smart contract operations and peer-to-peer transactions are currently burned as a means of deflation of the PPY token. The ‘rake’ in games are distributed among PPY holders proportional to their token holdings. This mechanism would have all or a portion of those fees and ‘rakes’ become part of participation rewards.

Being a DPOS consensus blockchain, the importance of voter participation of PPY holders is paramount to the security of the blockchain. In this proposal, we introduce a protocol change; where only holders of vesting PPY tokens will receive a ‘participation reward’ by securing the blockchain and its governance through voting on the operations of the blockchain including things such as witnesses, advisors, proxies, peerplays proposals, or other features that require decentralized stakeholder approval.

PPY Token holders will be able to vest or “stake” their tokens and only be eligible to vote through their vested balance after a predefined period (proxy voting will still be allowed).

Active voting in governance of the blockchain will be necessary in order to receive participation rewards. When a user participates in voting activity within the distribution period (typically 30 days), their staking time will be set to 100%. However, with each interval of participation rewards that are paid out, there will be a staged linear decay to their voting power, and thus their reward over a predefined period which can be voted on by the PPY token holders via the Advisors.

Hence, each vesting balance will have a linear weight applied to it when voting. This weight will be 100% initially, and then in alignment with the monthly participation reward will step down in linear decay towards 0% only if the user does not participate in voting. At this point, rewards will no longer be paid to the owner of the vesting balance, and their voting influence in the blockchain will cease until they participate again. This voter decay mechanism ensures that voting power doesn’t extend beyond six months. It ensures that participation rewards require ongoing participation, while also ensuring the network is secure in the event of lost accounts still voting for inactive witnesses and/or other operations that require stakeholder voting.

The contributors recommendation is to make this a six month period to start with the understanding that the Advisors may change this parameter later if it’s seen fit. Any rewards which would have been provided to participants which has decayed in their participation will be sent to the worker proposal reserve where it will be available for improvements to be made on the Peerplays blockchain. This ensures that participation rewards are only shared with those that participate actively, and any rewards that went unused are later available for other types of work in the blockchain.

For other tokens within the blockchain, such as UIAs, if this feature is enabled with the participation rewards option then the participation that takes place with the PPY token will qualify the user to receive participation rewards in the UIA they carry. This ensures that those who wish to utilize the UIAs distribution mechanism for participation rewards also become active participants in the blockchains governance.

This will benefit the community by having more engaged voters and compensating those who are active users in the Peerplays blockchain. The result is a more stable and active community surrounding the Peerplays ecosystem, and a more secure blockchain in comparison to original DPOS consensus.


Key issues in Peerplays governance are: Who should have input on how Peerplays runs? Who should receive participation rewards from the Peerplays Blockchain? All the accounts? Only the Witnesses? How can we use incentives to increase the activity of the Peerplays blockchain to make it more secure?

Compensating users who are vesting or ‘staked’ their tokens with the ability to vote and receive revenue from the blockchain aligns the need for participation in voting on the various operations of the DPOS blockchain, with the desire of the user to be compensated for the work that goes into the activity. Voting in DPOS blockchains has been found to be difficult due to the amount of research necessary to make voting choices. Those that are involved in the Peerplays Blockchain receive more of a “say” in what will happen; decreasing the apathy that affects all governance of a Peerplays Blockchain.


Peerplays blockchain has implemented the profit sharing code that was engineered in 2016. Other changes will need to be made changing the ‘profit sharing’ to ‘participation rewards’ for governance. A “vesting” user is one who has a “vesting balance” in the blockchain for a length of time that is equal to or longer than the “vesting period” (i.e. 30 days which is equal to when participation rewards are paid out).

This change to the Peerplays Blockchain will not cause issues for the wallet and other pieces that use the Blockchain. However, some modifications will need to be made to the Peerplays Core Wallet and any other wallets which enable voting in order to accommodate properly reporting separate vesting balances and decay periods in order to have the end user aware of their current voting status.

There also needs to be support for UIA management of features and showing of participation reward payouts. There will be a slight increase in the load of the maintenance interval due to the vote decay mechanism, while there will be a slight decrease in the load due to the reduction of participation reward calculations.


  • This protocol will benefit active members of the Peerplays blockchain community by
    rewarding them for participation at every distribution interval.
  • Voters who are vested will be more engaged in the community and ensure the Peerplays blockchain operates as it was intended (Decentralized Autonomous Cooperative).
  • Members balances will be better protected in the event of personal private key hack, attempts to withdraw balances that are vested would not be possible and likely responded to in time before an attempt was successful.
  • The GPOS consensus ensures a higher degree of security for the blockchain through rewarding active voting.
  • Rewards are solely based on distribution of actual volumes generated by blockchain activity and not through ongoing token generation the same way block rewards are produced for witnesses.
  • Incentives for active end users utilization of blockchain operations are better aligned.


With the change to the Peerplays blockchain some functionality will need to be added to support the proposed protocol change. Distribution logic will need to be changed to compensate just those accounts with vesting balances. Chain libraries will need to reflect this change, as well. Current ability to vote and enable proxy voting should be replicated based on your vesting balance, in order to qualify for the blockchain rewards mechanism. This helps the user differentiate their account between an active and an inactive one. Change the vesting period to match the payout schedule (this can be changed by the community). Voter decay mechanism parameters would be Advisor controlled as part of this proposal. Peerplays documentation will be updated to reflect the proposed change.

To keep things flexible, the distribution (dividends) feature should be modified in a way that only *EVER* allows to distribute according to vesting balance *IF and only if the ‘target asset’ is PPY. Then, we can still have other distribution schemes that do not require vesting. Maybe have this as a flag on the asset.


Vesting – means the ability of an account to lock its balance (all or only the  part of it) for the standard term (common for the whole network). The duration of this term is a parameter (variable) determined by the vote of the Advisors. If account has vesting balance ​it gains​:

(a)   the ability to participate in voting for proposals
(b)   part of commissions for transactions.

Vesting Period and Vesting Subperiods:

The Vesting Period  (by default-6 months) can be changed by Advisor voting. The vesting period should always be divided into N equal subperiods. At the end of each subperiod  the accounts with vested balance obtain their calculated fracture of collected commissions for transactions (provided, that the account participated in the voting).

At the end of the vesting  period, the account balance is automatically transferred from the Vesting- i.e. gets unlocked  (the account can be disposed again).

Vesting Factor (coefficient):

Vesting coefficient-or weight of the vesting balance-the value multiplied by the  “award” received directly by the account with Vesting Balance. The vesting coefficient can be in the range of [0:1].

The vesting coefficient decreases if the account did not participate in the voting for proposals during the vesting subperiod. In this situation, the account will receive a reduced Reward for the next subperiod. The reduction occurs by multiplying its reward by the vesting coefficient.

For example, having a total period of vesting in 6 months, divide it on 6 subperiods on 1 month. In the first month the account did not participate in voting. As a result, at the end of the first month (when N Equal to 6), the Vesting account ratio becomes equal to (6-1)/6 = ⅚ = ​0.83​. In this case, the reward received by them for the second subperiod will be multiplied by ​0.83​. Remaining 17%, Not Received by Them, Sent to Separate Account (look Worker proposals).

If an account participates in a vote during a given subperiod-at the end of this subperiod, the current vesting account ratio returns to 1 with the beginning of the next subperiod.

In case of the drop of the coefficient to zero all rewards that must be received by the account with a coefficient of 0, are sent to a separate account.

Vesting Balance:

Vesting Balance – account balance, Located in Vesting. The default is zero. An account can send any portion of its balance to vesting.

Vesting balance cannot be sent to another account (you will need to withdraw it from vesting).

Collection of Transaction Fees:

Commission Transactions committed in the Vesting subperiod must be collected on a separate account from which the awards will be awarded later.

Distribution of Transaction Fees:

Commissions for transactions are distributed among accounts once per vesting sub-period (at the moment of its termination). Distribution is based on the vesting balances of accounts relative to the total vesting balance across the network.


Networkvestingbalance = 1000 PPY
account1vestingbalance = 100 PPY
Account2vestingbalance = 200 PPY
Account3vestingbalance = 700 PPY
Awardpool = 50 PPY

Account1award = Awardpool * (Account1vestingbalance/ Networkvestingbalance) = 50 * (100/1000) = 50 * 0.1 = 5 PPY

If you add to this formula the vesting coefficient, the account balance actually received by the account multiplied by this coefficient, and the remaining amount is sent to a separate account. Take the coefficient 0.6 (for example).

Account1award = Awardpool * (Account1vestingbalance/ Networkvestingbalance) * Account1vestingweight = 50 * (100/1000) * 0.6 = 50 * 0.1 * 0.6 = 3 PPY

The rewards received are sent to the vesting balance of the account that received the award, and can be withdrawn from there manually or after the vesting period has expired.

Changing the Vesting Period:

The vesting period and the number of gaps in it can be changed voting committee. In this case, all subperiods necessarily retain the same duration. The obvious exception is the change in the coefficients in the case of a change in the number of sub-periods.

Manual Vesting Balance Withdrawal:

Any account can at any time withdraw its vending balance or part of the vesting (to regain the opportunity to spend it at their discretion). Withdrawn vested balance can then be spent in any way a user sees fit. At the end of the subperiod, the reward will be calculated based on the current vested balance.

For calculation of fee distribution:

A hardfork date will be selected for this change whereas before this date the distribution will be normal as it is now if it exists in the Peerplays network. When the date passes the new system will be used to pay participation rewards and to calculate votes.


Current Purpose:

Schedules payouts from a dividend distribution account to the current holders of the

dividend-paying asset. This takes any deposits made to the dividend distribution account since the last time it was called, and distributes them to the current owners of the dividend-paying asset according to the amount they own.

Changes necessary:

The method currently considers all users with balances, and all users with vested balances, then loops through calculating how to distribute the dividends. This would be reworked to only consider the users with a vested interest after hardfork date passes.

For Vote Calculations:

db_maint – struct vote_tally_helper

Changes Needed:

Currently this calculates the voting_stake by taking into account total balance, balance tied up in orders, etc. and then adds on the vesting stake.  For this change only the vesting stake would be used.

A new function should be called to calculate current coefficient for each account with vesting. Variable voting_stake need to be calculated according to:

For example, having a total period of vesting in 6 months, divide it on 6 subperiods on 1 month. In the first month the account did not participate in voting. As a result, at the end of the first month (when N Equal to 6), the Vesting account ratio becomes equal to (6-1)/6 = 5⁄6 = ​ 0.83​. In this case, the reward received by them for the second subperiod will be multiplied by ​ 0.83​. Remaining 17%, Not Received by Them, Sent to Separate Account (look Worker proposals).

Asset object:

Flag on the asset to allow non core assets to paid dividends according to vesting balances and vote participation.

Account object:

Last_vote_time should be added to account objects(https://github.com/bitshares/bitshares-core/issues/1393) with the date of last voting activity in order to calculate coefficient.

Wallet changes:

The CLI and GUI wallets will need to reflect the need to vest for voting participation. The CLI will need to be updated with a new function that specifically places the balance in the predefined vesting balance that is intended to participate in voting. The GUI will require some changes to enable this process as well. The most ideal location would be to have it as the first tab available under ‘Vote” prior to voting on other current elements of the blockchain including the option to set proxies, vote for witnesses, advisors, and Peerplays proposals.


The Wallet CLI should remain unaffected. Votes placed for a advisor member will only be counted if the user has a vested balance. Votes reside within your user/account and are only counted/weighted during the vote tally process – at which point votes from members without a vested balance would be ignored.

Estimates for Work

C++ changes to the blockchain:

25-30  days to:

  • Setup test environment and accounts and develop scenarios to thoroughly test the results of the changes
  • Make changes to the blockchain code and redeploy to the server
  • Work through the designed tests to ensure functionality
  • Work through major issues as they arise
  • Have code ready for more thorough testing by QA

5 days to:

  • Have QA test and work through issues as discovered

Peerplays GUI app:

5 days to:

  • Make changes to the React/Redux app, adding in new tabs and functionality to better indicate to users how voting works with vested balances

3 days to:

  • Process through QA, resolve minor issues as discovered


1) Bitshares blockchain repository. https://github.com/bitshares/bitshares-core=
2) BSIP-019 Draft: “Introducing profit sharing/dividends to Bitshares” https://steemit.com/bitshares/@cm-steem/bsip-019-draft-introducing-profit-sharing-dividends-to-bitshares
3) Peerplays Profit Sharing Code. https://steemit.com/bitshares/@xeroc/peerplays-providing-code-for-profit-sharing-1467622607-0030067
4) Graphene Improvement Proposal DPOS2GPOS https://bitbucket.org/exeblock/improvement-proposals/downloads/Graphene-Improvement-Proposal-DPOS2GPOS.pdf


Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

Subscribe To Our Newsletter

More To Explore

Download the latest Peerplays Core Wallet