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.

[ndkazu]

@kianenigma , I added Benchmarking for the Distribution Pallet, but I get the following error when trying to run the benchmark:

panicked at /home/kazu/Polkadot/polkadot-sdk/substrate/frame/system/src/lib.rs:1988:9:
assertion `left == right` failed: expected event <wasm:stripped> is not equal to the last event <wasm:stripped>
  left: <wasm:stripped>
 right: <wasm:stripped>    

I need your help please.

[ndkazu]

The CI is showing a cargo clippy error not related to the code added/modified in this PR 😞

[bkchr]

Okay, I gave this a really brief review. Sorry if I will now talk a little bit bullshit, but I did not read all the comments, nor I'm aware of the entire history of this project.

So, I would change the structure of this project:

• Use conviction-voting for doing the voting. This pallet is already battletested, audited and provides all the required functionality.
• For the project registration (which is not yet supported as far as I have seen?) I would propose that you take pallet-referenda and change it in the way we need it here. (Cloning it into a new pallet) We would need the functionality for registering projects via a special origin. Then we would need the this period functionality that removes all the votes after X amount of time. The handling of the pot (not sure why we need extra locking of the pot, as the pallet is the only one controlling this account). The payout logic.

All of that should not be that complicated to implement and parts of it already exists in pallet-referenda.

If we do the period for the user votes, we probably also want some period for the projects? Maybe longer like 1 year, but they should also not stay there forever.