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 not been implemented in this first pallet iteration.

Integration

Review Notes

The voting round timeline is described below:

|----------Voting_Round_0-----------|----------Voting_Round_1-----------|
|---users_votes----|--funds_locked--|---users_votes----|--funds_locked--|
|------------------|--Distribution--|------------------|--Distribution--|

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?

[xlc]

this check is unnecessary

[xlc]

this is invalid usage of expect. it should be a proof stating why it can never fail. in this case, it could be "pot_check already ensured enough funds; qed". However, it is still a bad code as people have to read the inner code of pod_check to check if this is true or not.

[xlc]

this is inefficient. you should just rewrite the loop to a filter