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

Optimistic Project Funding #5162

Open
wants to merge 253 commits into
base: master
Choose a base branch
from
Open

Optimistic Project Funding #5162

wants to merge 253 commits into from

Conversation

ndkazu
Copy link
Contributor

@ndkazu ndkazu commented Jul 27, 2024

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

@ndkazu ndkazu requested a review from a team as a code owner July 27, 2024 03:25
@ndkazu ndkazu marked this pull request as draft July 27, 2024 08:06
Copy link
Contributor

@marcuspang marcuspang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

substrate/frame/distribution/src/lib.rs Outdated Show resolved Hide resolved
substrate/frame/distribution/src/lib.rs Outdated Show resolved Hide resolved
substrate/frame/distribution/src/lib.rs Outdated Show resolved Hide resolved
substrate/frame/distribution/src/lib.rs Outdated Show resolved Hide resolved
substrate/frame/distribution/src/types.rs Outdated Show resolved Hide resolved
substrate/frame/distribution/src/functions.rs Outdated Show resolved Hide resolved
substrate/frame/distribution/src/types.rs Outdated Show resolved Hide resolved
substrate/frame/distribution/src/lib.rs Outdated Show resolved Hide resolved
umbrella/Cargo.toml Outdated Show resolved Hide resolved
substrate/frame/distribution/src/functions.rs Show resolved Hide resolved
@ndkazu
Copy link
Contributor Author

ndkazu commented Jul 30, 2024

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
Copy link

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
Copy link
Contributor Author

ndkazu commented Jul 30, 2024

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

/// The block number from which the spend can be claimed(24h after SpendStatus Creation).
pub valid_from: BlockNumberFor<T>,
/// Corresponding project id
pub whitelisted_project: Option<AccountIdOf<T>>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this an option?

Copy link
Contributor

@kianenigma kianenigma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

// funds for created `SpendInfos`. the function will be use in a hook.

pub fn begin_block(now: BlockNumberFor<T>) -> Weight {
let max_block_weight = T::BlockWeights::get().max_block / 4;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines 108 to 117
// Update project storage
let mut bounded = BoundedVec::<ProjectInfo<T>, T::MaxProjects>::new();
Projects::<T>::mutate(|val| {
for p in projects {
// The number of elements in projects is ALWAYS
// egual or below T::MaxProjects at this point.
let _ = bounded.try_push(p);
}
*val = bounded;
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Update project storage
let mut bounded = BoundedVec::<ProjectInfo<T>, T::MaxProjects>::new();
Projects::<T>::mutate(|val| {
for p in projects {
// The number of elements in projects is ALWAYS
// egual or below T::MaxProjects at this point.
let _ = bounded.try_push(p);
}
*val = bounded;
});
// Update project storage
Projects::<T>::put(BoundedVec::<ProjectInfo<T>, T::MaxProjects>::try_from(projects).defensive())

@ndkazu
Copy link
Contributor Author

ndkazu commented Oct 29, 2024

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.

@ndkazu ndkazu requested review from a team as code owners November 1, 2024 12:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T2-pallets This PR/Issue is related to a particular pallet.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants