-
Notifications
You must be signed in to change notification settings - Fork 678
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
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this 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
Co-authored-by: Marcus Pang Yu Yang <[email protected]>
Co-authored-by: Marcus Pang Yu Yang <[email protected]>
Co-authored-by: Marcus Pang Yu Yang <[email protected]>
Co-authored-by: Marcus Pang Yu Yang <[email protected]>
Co-authored-by: Marcus Pang Yu Yang <[email protected]>
Co-authored-by: Marcus Pang Yu Yang <[email protected]>
The Voting Logic would be managed in a different pallet ( |
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? |
let pot_id = T::PotId::get(); | ||
pot_id.into_account_truncating() | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// 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>>, |
There was a problem hiding this comment.
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?
There was a problem hiding this 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; |
There was a problem hiding this comment.
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.
// 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; | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// 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()) |
} | ||
return false; | ||
}) | ||
.map(|x| x.clone()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.map(|x| x.clone()) |
|
||
projects = projects | ||
.iter() | ||
.filter(|project| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could rewrite this with .retain
// https://paritytech.github.io/polkadot-sdk/master/frame_support/attr.derive_impl.html | ||
#[derive_impl(frame_system::config_preludes::TestDefaultConfig)] | ||
impl frame_system::Config for Test { | ||
type BaseCallFilter = frame_support::traits::Everything; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a lot of the lines here can be removed as per TestDefaultConfig
Roger that, I will still apply the corrections but keep in mind that the smart contract route might be adopted instead. |
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:
Integration
Review Notes
Terminology
The constants available in the runtime for the OPF Pallet:
The constants available in the runtime for the Distribution Pallet:
Checklist
pallet-distribution
pallet-opf