Optimistic Project Funding

[ndkazu]

Description

This PR is related to this issue .
Through the introduction of the OPF pallet and the DISTRIBUTION pallet, we are handling the Optimistic Project Funding.
It allows users to nominate projects (whitelisted in OpenGov) with their DOT. This mechanism will be funded with a constant stream of DOT taken directly from inflation and distributed to projects based on the proportion of DOT that has nominated them. The nominations are handled by the OPF Pallet, while the project rewards distribution is handled by the Distribution Pallet.
The Distribution Pallet receives the list of Whitelisted/Nominated Projects with their respective calculated rewards. For each project, it will create a corresponding Spend that will be stored until the project reward can be claimed. At the moment, the reward claim period start corresponds to: [beginning of an Epoch_Block + BufferPeriod] (The BufferPeriod can be configured in the runtime).

User’s conviction has been implemented.

The voting round timeline is described below for someone voting for a project with no conviction round_0 and
for another project with a conviction of 1x in round_1:

|----------Voting_Round_0-----------|----------Voting_Round_1-----------|
|----user_votes----|--funds0_locked-|----user_votes----|--funds1_locked-|
|------------------|--Distribution--|------------------|--Distribution--|

Integration

Review Notes

Terminology

The constants available in the runtime for the OPF Pallet:

• MaxWhitelistedProjects: Maximum number of Whitelisted projects that can be handled by the pallet.
• VoteLockingPeriod: Period during which voting is disabled.
• VotingPeriod: Period during which voting is enabled.
• TemporaryRewards: For test purposes only ⇒ used as a substitute for the inflation portion used for the rewards.

The constants available in the runtime for the Distribution Pallet:

• PotId: Pot containing the funds used to pay the rewards.
• BufferPeriod: minimum required buffer time period between project nomination and reward claim.

Checklist

pallet-distribution

• Pallet Config
• Helper functions
• Extrinsics
• Events & Tests
• Benchmarking & weights
• Remove Dev-mode
• Proper documentation

pallet-opf

• Pallet Config
• Helper functions
• Extrinsics
• Events & Tests
• Benchmarking & weights
• Remove Dev-mode
• Proper documentation

[marcuspang]

Do you mind writing briefly how the voting would work? I feel this is quite a big deviation from what I had in mind

[ndkazu]

Do you mind writing briefly how the voting would work? I feel this is quite a big deviation from what I had in mind

The Voting Logic would be managed in a different pallet (pallet_vote for example).
The main difference is that the result of the voting process would be a whitelisted project of type ProjectInfo (which is defined in pallet_distribution). Then, through coupling of pallet_vote & pallet_distribution (this would be done in the Pallet::Config of pallet_vote), pallet_vote could populate the storage Projects found in pallet_distribution.

[lolmcshizz]

Do you mind writing briefly how the voting would work? I feel this is quite a big deviation from what I had in mind

The Voting Logic would be managed in a different pallet (pallet_vote for example). The main difference is that the result of the voting process would be a whitelisted project of type ProjectInfo (which is defined in pallet_distribution). Then, through coupling of pallet_vote & pallet_distribution (this would be done in the Pallet::Config of pallet_vote), pallet_vote could populate the storage Projects found in pallet_distribution.

Just to be clear here - "whitelisting" a project is done via OpenGov and creates a list of "projects" (addresses) that can be funded via OPF.

"Voting" as part of OPF implementation is users locking their DOT at some conviction to allocate funding to projects that are on the whitelist - this is not done through OpenGov and should be handled through the implementation of OPF.

Is this what you are implementing?

[ndkazu]

Do you mind writing briefly how the voting would work? I feel this is quite a big deviation from what I had in mind

The Voting Logic would be managed in a different pallet (pallet_vote for example). The main difference is that the result of the voting process would be a whitelisted project of type ProjectInfo (which is defined in pallet_distribution). Then, through coupling of pallet_vote & pallet_distribution (this would be done in the Pallet::Config of pallet_vote), pallet_vote could populate the storage Projects found in pallet_distribution.

Just to be clear here - "whitelisting" a project is done via OpenGov and creates a list of "projects" (addresses) that can be funded via OPF.

"Voting" as part of OPF implementation is users locking their DOT at some conviction to allocate funding to projects that are on the whitelist - this is not done through OpenGov and should be handled through the implementation of OPF.

Is this what you are implementing?

simple pallet that locks DOT & distributes to nominated projects based on locked amount from the pot

What I did/understood:
I understood "locks DOT in the pot". So I implemented what comes after the amount attributed to each whitelisted project is known (opf_voting step is over), and the rewards are now distributed to respective projects => opf_voting is managed by another pallet in my understanding...

[ndkazu]

@lolmcshizz and @marcuspang , I added a bare-bone pallet_opf (types are there, Config is set, but no storage or function) coupled with the pallet_distribution to demonstrate what I have been saying in polkadot-fellows/runtimes#375.

[kianenigma]

I am now thinking that this idea can probably be better implemented as a smart contract? should be possible within the next 6-12 months in Kusama/Polkadot.

Managing the merge of this, in the midst of moving the governance apparatus around is also likely not a great idea.

Given the idea having been approved via W4C, once EVM contracts are present, one can implement a contract equivalent of thie distribution pallet.

As per the W4C, the only change needed in the Polkadot runtime would be to forward a small part of its inflation to this contract.

[kianenigma]

This cannot really work once the govenrance is on AH, as the we cannot afford to use too much of the block space anymore..

In general, in light of moving the governance to AH, it is best to design this pallet as lazy as possible, ideally without using on_initialize: All operations should be triggered via transactions.

[ndkazu]

@kianenigma , is there the same concern when using on_idle instead of on_initialize ?

[ndkazu]

I am now thinking that this idea can probably be better implemented as a smart contract? should be possible within the next 6-12 months in Kusama/Polkadot.

Managing the merge of this, in the midst of moving the governance apparatus around is also likely not a great idea.

Given the idea having been approved via W4C, once EVM contracts are present, one can implement a contract equivalent of thie distribution pallet.

As per the W4C, the only change needed in the Polkadot runtime would be to forward a small part of its inflation to this contract.

Roger that, I will still apply the corrections but keep in mind that the smart contract route might be adopted instead.