Optimistic Project Funding #375
Comments
|
@lolmcshizz so what is the idea here? You will search for someone that wants to implement this? |
|
I assume the "flexible inflation" is probably achieved by this pr: #364? |
|
Yes, the part about
Is contained in #364 and RFC89. The purpose of this issue otherwise should be for someone to be able to understand what needs to be implemented, reach out to @lolmcshizz, and for the fellowship to be aware. Ideally these wish for change ideas should be not in the fellowship repo, but for now since there is only, we can track it here. I pointed out in twitter and PBA already that these wish for change impls are great starting point for those that already know FRAME and Polkadot a bit, and are looking for an impactful contribution. |
|
Please see a suggestion here: kudos-ink/portal#103 (comment) |
|
I've made a public element room where anyone wishing to have a more sync chat with @lolmcshizz or I to join: https://matrix.to/#/#wish-for-change-impls:parity.io |
|
The Pallet is only responsible for locking and distributing Dots, my assumptions are therefore:
This leads me to think that another pallet will manage parameters such as
Question 3: The Pot should take into account the existential deposit |
|
|
Just to clarify @marcuspang - DOT holders can issue both "fund" and "not fund" votes, but they don't have to do both. |
|
@lolmcshizz and @ndkazu thank you for the feedback and response. Here is my revised spec for the pallet, which is much more simplified now. I realised that there is a "scheduler" trait in substrate, which removes the need for manual distribution as discussed above. Also, I am not sure if there's a better way of keeping track of votes + conviction, but for now I am keeping the values in the pallet as a first draft :) Pallet ConfigurationConstants
Types
Storagestruct VoteInfo {
amount: Balance, // Perhaps combine with `conviction` to some auxiliary type like pallet_democracy::Voting
conviction: Conviction,
is_fund: bool, // Whether the vote is "fund" / "not fund"
}
struct ProjectInfo {
whitelisted_block: BlockNumber,
total_votes: u32,
}
ExtrinsicsPublic
|
|
I am not sure if conviction makes sense here. I don't follow the whole discussion so can someone explain why it is a useful thing? The cons I have:
It is always good to start with something simple, with the possibility to extend in the future, than try to get the ultimate version done in V1. |
|
From the additional information received here: https://matrix.to/#/#wish-for-change-impls:parity.io, I feel that different things are being mixed up together, so @kianenigma and @lolmcshizz correct me if I am wrong:
For me, this means the following:
|
I agree that this is a good first step. Initially, I assumed that the voting of distribution amount would work similar to OpenGov, with conviction / delegation. In which case it would be better to rely on the existing logic in pallet_democracy, but I wasn't sure if this was the best approach. |
CommentInspired by what @marcuspang did, this is another suggestion for the pallet configuration, which reflects my understanding of the task. Pallet ConfigurationConstants• MaxWhitelistedProjects: u32 ⇒ The maximum number of projects that can be whitelisted Types• ProjectId: AccountId ⇒The identifier of a project Enums/// Reward distribution plan (Optional)
pub enum DistributionPlan {
OneDayUpFront,
ThreeDays,
FiveDays,
}
/// Payment status
pub enum PaymentState {
/// Unclaimed
Unclaimed
/// Claimed & Pending.
Pending,
/// Claimed & Paid.
Completed,
/// Claimed but Failed.
Failed,
}Storages & Structs/// Information relative to a given payment/distribution
pub struct PaymentInfo{
/// The asset amount of the spend.
pub amount: Balance,
/// The beneficiary of the spend.
pub ProjectId: ProjectId,
/// The block number from which the spend can be claimed
pub valid_from: BlockNumber,
/// The status of the payout.
pub status: PaymentState,
/// Payment Plan (Optional)
pub plan: SpendingPlan,
/// Amount already paid
pub paid: Balance>,
}
struct ProjectInfo {
whitelisted_block: BlockNumber,
requested_amount: Balance,
distributed: bool,
}WhitelistedProjects: BoundedVec<ProjectId, MaxWhitelistedProjects>⇒ The list of whitelisted projects ExtrinsicsPublic
|
|
@ndkazu - yes to be clear, the "funding" part is outside of the scope - we only need (as described in the channel by @kianenigma) a key-less account that the pallet controls.
We will need some storage containing all whitelisted projects, which can be added/ removed using some track on OpenGov - I don't know where this "list" needs to be but it needs to be somewhere.
Can you clarify what is meant by
Is this adding more complexity? I am fine with just daily distribution the same we have in staking right now.
The cons I have: It makes things more complicated. @xlc the conviction is important here in the same way as in OpenGov - higher conviction means a longer lock so your votes carry more weight. Yes projects would receive more funding if their votes are of higher conviction than those of other projects - but imo this is a positive feature. |
I don't disagree, this storage was even defined as follows by @marcuspang, and I kept it: WhitelistedProjects: BoundedVec<ProjectId, MaxWhitelistedProjects>⇒ The list of whitelisted projects My point here is that it should be populated by an external source/pallet, but we will probably need a function to populate it for the pallet testing.
@lolmcshizz , you are correct, it should be
I think you are also right here: let's keep it simple. |
|
Ok, I prepared the main structure of the pallet with a few modifications compared to the plan described above. The next steps are:
|
|
Hello, I would like to know your opinion on the following: Motivation
Please let me know what you think. |
|
As this is more of a technical implementation question than impacting how it works for users, I would defer to @kianenigma here for guidance |
|
@lolmcshizz , what do you think about the following timeline for opf_voting: |
|
I am glad to see this, but let's note that this pallet can also live elsewhere, perhaps here or in anyone's repo, given that we have proper releases now :)
I don't have strong opinions about whether reward should be in a separate pallet or not, but I would probably reside to one of possible.
Automated solutions are generally more hairy. I suggest doing a claim-able only impl for now, and later on you can always use If more specific tech questions, let's continue in your draft PR as it is easier to review the whole code. |
|
@ndkazu here is what I imagined the pallet would roughly look like paritytech/polkadot-sdk#5225. After your recent changes, I think the main difference now is storage and how claims are being kept track of |
|
Hello, I recently noticed & reverted unwanted changes, probably added by the command |
|
@kianenigma, for now, I am using a constant defined in the runtime for the total reward to be distributed from the pot to the selected projects during each round, but I am guessing there will be (or already is...) a pallet/function to get the portion of inflation to be distributed. Is this correct? |
|
Re-posting something I have discussed with @lolmcshizz: I genuinely think that merging and getting this to production in the midst of moving everything outside of the relay chain to AH will be very, very hard. A more forward-looking suggestion: Implement this as a solidity contract. Once Solidity contracts are live (~mid-2025), all that the fellowship would then have to do is to forward a small part of the inflation to this contract's account. |
This is a tracking issue for the implementation of Optimistic Project Funding - which was approved by DOT holders in Referendum #712.
Implementation of this feature appears to be achievable in two separate parts:
flexible inflationto drip some % of funds into a “pot” for distribution (achieved through RFC #89)Relevant links:
Full description of the mechanism that was approved: https://docs.google.com/document/d/1cl6CpWyqX7NCshV0aYT5a8ZTm75PWcLrEBcfk2I1tAA/edit#heading=h.hh40wjcakxp9
Polkadot's economics Forum post: https://forum.polkadot.network/t/polkadots-economics-tools-to-shape-the-forseeable-future/8708?u=lolmcshizz
Project discussion TG: https://t.me/parachainstaking
The text was updated successfully, but these errors were encountered: