Optimistic Project Funding #6994
Conversation
| spend_created, | ||
| }; | ||
|
|
||
| WhiteListedProjectAccounts::<T>::insert(project_id, project_info); |
There was a problem hiding this comment.
I think it is better to keep the modification of a storage to only one type, here both ProjectInfo and Pallet are tapping into WhitelistedProjectAccounts, I think it is a bit confusing.
It would make the code clearer if a storage item was used by only one type.
| pub trait Config: frame_system::Config { | ||
| type RuntimeCall: Parameter | ||
| + UnfilteredDispatchable<RuntimeOrigin = <Self as frame_system::Config>::RuntimeOrigin> | ||
| + From<Call<Self>> | ||
| + Into<<Self as frame_system::Config>::RuntimeCall> | ||
| + Into< | ||
| <Self::Governance as traits::ReferendumTrait< | ||
| <Self as frame_system::Config>::AccountId, | ||
| >>::Call, | ||
| > + GetDispatchInfo; |
There was a problem hiding this comment.
Note that you don't need an additional associated type add bounds to a type in a supertrait you can do:
| pub trait Config: frame_system::Config { | |
| type RuntimeCall: Parameter | |
| + UnfilteredDispatchable<RuntimeOrigin = <Self as frame_system::Config>::RuntimeOrigin> | |
| + From<Call<Self>> | |
| + Into<<Self as frame_system::Config>::RuntimeCall> | |
| + Into< | |
| <Self::Governance as traits::ReferendumTrait< | |
| <Self as frame_system::Config>::AccountId, | |
| >>::Call, | |
| > + GetDispatchInfo; | |
| pub trait Config: frame_system::Config< | |
| RuntimeCall: Parameter | |
| + UnfilteredDispatchable<RuntimeOrigin = <Self as frame_system::Config>::RuntimeOrigin> | |
| + From<Call<Self>> | |
| + Into< | |
| <Self::Governance as traits::ReferendumTrait< | |
| <Self as frame_system::Config>::AccountId, | |
| >>::Call, | |
| > + GetDispatchInfo | |
| > | |
| { |
| ) -> DispatchResult { | ||
| T::AdminOrigin::ensure_origin_or_root(origin.clone())?; | ||
| //let who = ensure_signed(origin)?; | ||
| Self::round_check()?; |
There was a problem hiding this comment.
I don't really see the reason for writing the VotingRoundInfo of the new round in multiple step when there is only one possible way to initialize the VotingRoundInfo of a new round.
Let me explain, AFAICT register_projects_batch is the only way to start a new voting round. And what it does is:
fn round_check: if round index is 0 or if previous rounds has ended then start a new round with:round_ending_block==round_starting_blockbatch_submitted== falsetime_periods== None
- then it ensures
batch_submittedis false and set it to true (regardless if the batch is empty or not) - then in this function body if there is at least one project it does: set
round_ending_blockto the correct value, andtime_periodsto some value.
So in conclusion if the batch is empty we have a session with batch_submitted == true but round_ending_block == round_starting_block and I don't else where in the code where we can actually setup the round. on_idle doesn't modify the round if round_ending_block == round_starting_block.
Maybe there is something I miss, or maybe you didn't intend to write batch_submitted = true when batch is empty. But something seems not good. If there is a use case for a 2 phase process then we should make it clearer in the type. (Or maybe I miss something)
substrate/frame/opf/src/lib.rs
Outdated
| WhiteListedProjectAccounts::<T>::mutate(project_id, |value| { | ||
| *value = Some(new_infos); | ||
| }); |
There was a problem hiding this comment.
| WhiteListedProjectAccounts::<T>::mutate(project_id, |value| { | |
| *value = Some(new_infos); | |
| }); | |
| WhiteListedProjectAccounts::<T>::insert(project_id, new_infos); |
| WhiteListedProjectAccounts::<T>::mutate(project_id.clone(), |val| { | ||
| *val = Some(infos.clone()) | ||
| }); |
There was a problem hiding this comment.
| WhiteListedProjectAccounts::<T>::mutate(project_id.clone(), |val| { | |
| *val = Some(infos.clone()) | |
| }); | |
| WhiteListedProjectAccounts::<T>::insert(&project_id, &infos); |
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.
Integration
Review Notes
Terminology
The constants available in the runtime for the OPF Pallet:
Spends.Functions
register_project: Register by OpenGov, should take AccountId and project Purpose.unregister_project: Unregister by OpenGovclaim: To claim a spendChecklist
pallet-opf