Skip to content
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

Closed
irreverentsimplicity opened this issue Aug 26, 2024 · 3 comments
Closed

Proof of Contributions discussion #2729

irreverentsimplicity opened this issue Aug 26, 2024 · 3 comments

Comments

@irreverentsimplicity
Copy link
Contributor

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:

  • Founders: Those responsible for the main vision and goal of the chain.
  • Builders: Those who are building based on the mission set by the Founders (e.g., building chain components like parsers, core EVM, tooling, etc., as well as building on top of the chain, such as games, DeFi apps, DEXes, etc.).
  • Maintainers: Those responsible for keeping the chain operational, either by coding upgrades, fixing bugs, or validating blocks.

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:

  • A percentage of the total coins minted by the chain, in this case, the GNOT token, should be allocated to a contribution reward pool. This pool is expressed in 1:1 GNORT tokens (GNO Reward Token). GNORT tokens are non-transferrable and only unidirectionally bridgeable 1:1 to the liquid GNOT token (i.e., you can bridge GNORT to GNOT, but you cannot buy GNORT with GNOT or any other token). GNORT tokens hold voting power (see Governance below).
  • The size of the pool, in absolute terms, remains constant throughout the entire life of the blockchain. For example, if it is 100,000 coins on day one, it remains the same until the chain stops — no inflation or deflation. It is not subject to governance (i.e., cannot be modified by voting). Depending on the tokenomics of the chain, the pool can be expressed either in coins or as a percentage of the total supply projected to be minted.
  • The pool is then split into three parts for the identified roles: one part for Founders, one for Builders, and one for Maintainers. The split of these parts is not subject to governance (cannot be modified by voting, as it changes the chain flavor, i.e. a conservative, Founders chain, versus a more dynamic, but easier to manipulate Builders or Maintainers chain, see Conclusion below).
  • The distribution of coins should happen at a reasonably frequent interval, such as every 24 hours. The amount of GNOT reserved for rewards is actually burned, and the equivalent GNORT tokens are minted and distributed.

Ascribing Value to Contributions

  • Each role has a decaying contribution, with a specific decaying algorithm for each role:
    • Founders' contributions decay very slowly in the first few years (see Proposed Timeframe below), then abruptly for the remaining years. This ensures reasonable control over the vision held by the Founders.
    • Builders' contributions decay rapidly during the first few years of their contribution timeframe (see Contribution Timeframes below), then slowly for the remaining years. This ensures proper incentives for Builders, who can earn many rewards in the initial stages of their deployed app but will then rely on smaller, steady rewards for the remaining timeframe (potentially mirroring app usage, which tends to decay in time too).
    • Maintainers' contributions decay linearly over a shorter time window (see Contribution Timeframes below). This ensures proper incentives for Maintainers, who are paid only if they consistently provide maintenance value.

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.

  • For Founders, this timeframe is the lifetime of the chain.
  • For Builders, this is set at genesis and can be subject to governance every four years. For instance, a Builder's contribution is set to be valid for four years from the moment they assume the role. After this period, they stop earning rewards. This contribution timeframe can be changed every four years by governance, but not retroactively (i.e., the ongoing Builders' contribution timeframe will not be affected by the vote).
  • For Maintainers, this is set at genesis and can be subject to governance every four years. For instance, a Maintainer's contribution is set to be valid for only 30 days, after which they stop earning rewards. If governance changes this, the ongoing Maintainers' contribution timeframes will not be affected.

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.

  • Founders' decay is 1/3 slow and 2/3 fast (meaning it decays slowly until 1/3 of the projected chain lifetime has passed, then decays quickly for the remaining time).
  • Builders' decay is fast for the first 1/5 of the builders' contribution timeframe and slow for the remaining time.
  • Maintainers' decay is relatively constant over the maintainers' contribution timeframe.

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.

founders-decay

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.

builders-decay

This is an example of the Maintainers' decay curve, with a relatively constant decay over the maintainers' contribution timeframe.

maintainers-decay

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.

@grepsuzette
Copy link
Contributor

grepsuzette commented Aug 27, 2024

alternative example (model B): PoS with modified staking

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

  1. With this PoS system, you could invest in GNOT and stake, and in a year have full voting power. Meanwhile you start contributing, while your voting powers are vesting.
  2. Or, with the previous solution (PoC), you can just start contributing, starting with nothing. You have done well financially but now you can not get a share of the project, you're denied. Would you then want to contribute, to advocate for it, despite your fortune being entirely irrelevant here, despite crypto being a fast game full of opportunity costs?

We will also need the successful people, the lucky, the visionnaries, the doers. A lot of them have money.

Footnotes

  1. Same story if you're an influencer or businessman. You may stake and then promote; this is rational. I call this contributing.

@moul
Copy link
Member

moul commented Sep 4, 2024

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.

@irreverentsimplicity
Copy link
Contributor Author

Thanks @moul, this makes a lot of sense, actually.

@irreverentsimplicity irreverentsimplicity closed this as not planned Won't fix, can't repro, duplicate, stale Sep 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

5 participants
@moul @grepsuzette @irreverentsimplicity and others