-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proof of Contributions discussion #2729
Comments
alternative example (model B): PoS with modified stakingSo two problems with PoS are inflation and gamable governance (liquid staking may be another). If inflation is acceptable, the gamable governance seems easy to solve. Bob stakes 1000 GNOT. His voting power is near 0 on day 1 (voting deadline can be in a few days). After 1 year of staking, Bob finally has 100% voting power. Discussion model A (PoC) vs model B (PoS w/ vesting voting power)You may argue with model B (PoS with vesting voting power) outsiders may gain voting power. I'd argue it's actually good for adoption: You're a Solana or Ethereum developer1; you did well financially. But now, you believe gno.land may be a thing.
We will also need the successful people, the lucky, the visionnaries, the doers. A lot of them have money. Footnotes
|
I'm sorry, but the proposals are too far from what we currently have in mind. It's too difficult to try recycling small parts. It's our fault - we need to communicate more about the current plan so that people can start working on smaller components. That's what we're focusing on. |
Thanks @moul, this makes a lot of sense, actually. |
Description
This is a follow-up to the latest contributors' calls, where we discussed the topic of Proof of Contribution.
Goal
To build a time-resistant, sybil-resistant, and fair compensation algorithm for Gno contributors and creators.
Proposal
This is a draft and is open to feedback, criticism, and dismissal.
When building and deploying a new decentralized state machine — a blockchain — a few roles can be identified:
These roles contribute in different ways, either through time invested in the project or by the importance of their contribution.
Contribution Algorithm
I am proposing the following contribution algorithm:
Ascribing Value to Contributions
As decaying occurs, the lost value is transferred downwards from Founders to Builders and from Builders to Maintainers.
For example, if the split is 1/3 for each role at genesis, once the decaying starts, Founders will transfer what they lost down to Builders, and Builders will transfer what they lost down to Maintainers, based on the decaying algorithm for each role.
If Founders lose, say, 2% of their contribution, that 2% is passed down and added to the Builders' share. Builders' decay is then calculated, and what they lost is passed down to Maintainers.
In absolute terms, the rewards pool remains the same. What changes is the percentage allocated to each group of roles. The influence of the roles can be adjusted at genesis by selecting appropriate reward pool percentages for each role (see Conclusion below).
Contribution Timeframes
Each contribution has a contribution timeframe, which is the period in which their contribution is considered valid for earning rewards.
Active and Passive Roles
The Founder role is passive, meaning Founders don't need to do anything to maintain their status.
The Builders and Maintainers roles are active. Those who wish to assume these roles must submit a specific transaction signaling their interest. These transactions carry a cost in GNOT to prevent spamming. Once confirmed by governance, the role is assigned, and rewards begin.
Validators are a special subset of Maintainers and must signal their availability every 30 days through these proposals (see Proposed Timeframe).
Decaying Intervals
The decaying intervals should be set at genesis for all three roles and should not be subject to governance.
Examples
This is an example of the Founders' decay curve, showing a slow decay for the first third of the projected chain lifetime, followed by a medium decay for the remaining time.
This is an example of the Builders' decay curve, with a fast decay in the first 1/5 of the builders' contribution timeframe, followed by a slow decay for the remaining time.
This is an example of the Maintainers' decay curve, with a relatively constant decay over the maintainers' contribution timeframe.
Simple Simulation
Rewards pool: 12,000 GNORT / month
Rewards split: 29.17% Founders, 29.17% Builders, 41.67% Maintainers
Genesis time: 10 Founders, 10 Builders, 30 Maintainers
Founders: 12,000 * 0.2917 = 3,500 GNORT
Builders: 12,000 * 0.2917 = 3,500 GNORT
Maintainers: 12,000 * 0.4167 = 5,000 GNORT
1 Founder = 3,500 / 10 = 350 GNORT
1 Builder = 3,500 / 10 = 350 GNORT
1 Maintainer = 5,000 / 30 = 166.67 GNORT
After four years: 10 Founders, 20 Builders, 90 Maintainers
Founders' reward decays by 2%, which is transferred to Builders. Builders' reward decays by 9%, which is transferred to Maintainers.
New rewards split: 27.17% Founders, 20.17% Builders, 53.67% Maintainers
Founders: 12,000 * 0.2717 = 3,267 GNORT
Builders: 12,000 * 0.2017 = 2,420 GNORT
Maintainers: 12,000 * 0.5367 = 6,440 GNORT
Governance and Heirs
Voting power is determined by GNORT holdings, meaning your voting influence is proportional to your GNORT balance. If you bridge GNORT out for GNOT, you lose voting power, effectively cashing out into the liquid GNOT.
An account can designate another account as their heir if they want to exclude themselves from voting or for other reasons. The heir designation process involves burning the renounced GNORT and minting the same amount of GNORT for the heir's account. Heirs cannot be designated within the first four years after genesis. Heir designation can occur only once every four years, or every 1/7th of the chain's projected lifetime.
Proposed Chain Lifetime
The chain lifetime could be projected to 28 years. Voting to accept new Builder applications should happen every 90 days. If there is no proposal for a new role to be assigned, the Builder voting round can be skipped. Voting to accept new Maintainers should happen every 30 days. Founders' roles are fixed at genesis and are not dependent on governance.
Conclusion
This approach is based upon and tries to model chain usage patterns while avoiding manipulation of the token supply. It can enforce the Founders' vision for a reasonable amount of time, while still allowing enough incentives for Builders and Maintainers.
The rewards pool split (how much percentage is assigned to Founders, Builders, and Maintainers at genesis) is the key parameter.
In the simple simulation above, the chosen split favors a Builder and Maintainer-driven chain with limited Founder power.
If the split were 50%, 25%, 25%, Founders' influence would decay slower, allowing for greater control and a more conservative chain that maintains the Founders' vision for a longer period.
The text was updated successfully, but these errors were encountered: