[report] Crowdloans Contributors State Report #4
Conversation
Since slot auctions are not used anymore, we can keep the existing lease slots without needing the slot deposit to exist for the rest of the period. To keep things simple, we can refund all crowdloan funds to the contributors and apply a lock on it that expires at the expiration of lease. I think vesting pallet can manage this if am not wrong. To summarise:
These balances would then be migrated as part of |
|
Ankan beat me to it, I think we spoke about this in one of the calls recently - I agree that it's not worth keeping the pallet around on Asset Hub as long as we can faithfully represent the side effects of it (locked funds). Should look into that to make sure we can do it the right way with vesting as is, otherwise we can add to it. |
|
@Ank4n @seadanda |
Fair point. The good side effect I believe is that it would allow crowdloan contributors to be able to participate in voting, which is anyways a behaviour we wanted to have. The bad side effect: It would also allow staking which we don't want. Vesting as it is, won't prevent that since it uses locks. So two options:
May be staking reward + voting would be good offset against this. :) In general though I agree the final behaviour with this approach might not be 1-1, but may be acceptable. |
|
@Ank4n most probably the were |
|
@joepetrowski do you know who would be the best person to confirm that we can let the crowdloan contributors to stake and vote with those assets? @Ank4n @seadanda |
|
Good points, yeah it's unintended that these funds could be used in staking, but governance availability is really nice plus I can see how it simplifies things. I don't think allowing them to stake is such a bad side effect. Maybe @jonasW3F @kianenigma or @shawntabrizi have an opinion here? |
You mean crowdloans are ended but not completely refunded? Pretty sure because they just don't know. Generally parachain teams do this for them: i.e. permissionlessly refund all the contributors. |
With crowdloan contributions comprising only 0.24% of the currently staked tokens, this issue is less about economic impact and more about the cost of upholding principles. Allowing these funds to be staked would fundamentally (and in hindsight) alter the terms that people agreed to. Many individuals might have been more inclined to participate if they had known they would bear only a fraction of the anticipated costs, especially for crowdloans that are only a few months old. There is no clear answer here and depends on the philosophical perspective you take. I think we all agree that the optimal solution would be to keep the original contract and disallow funds to stake. But including considerations about costs could have us go for something more practical. Time to equip my amateur philosophy hat! From the deontological perspective, we could argue that a shortcut would change the terms everyone agreed on retrospectively, somewhat violating the social contract people accepted when contributing (or not contributing) in the crowdloans. This could have an impact on the trust participants place in these mechanisms that rely on commitment and long-term planning. Individuals that participated in the crowdloans would have their pledge rewards, now obtain the ability to earn staking rewards. The rewards they get would be taken away from the stakers currently in the system. From a practical and utilitarian perspective, however, one could argue that the resources saved from not pursuing a complex solution here could be better spent improving the protocol, potentially benefiting all users more than this situation disadvantages them. I think going for a quick and easy solution that only vests the tokens could be fine given the previous argument and the fact that it seems rather complex and convoluted to try to fix this properly. Additionally, this will only be a proposal, which still needs to be ratified by OpenGov. Given the fact that these funds still cannot vote, we could see it as a vote by the people most disadvantaged by this deciding whether they are willing to accept the new terms. |
|
I agree with @jonasW3F, I would also rather not change the contract. It also gives a higher confidence that we are doing things right and we wont have some unexpected issues. I would suggest to move forward with my initial proposal (if no other proposals). I think we can even simplify it and drop XCM communication. We should know in advance the RC block numbers when every lease will end. |
|
Sounds good. I agree with this on a high level. |
|
I think it will be simpler to almost replicate it, with some part being disabled. The funds are hold by fundraising account, not by individual contributors, and individual contributors are storred in child tree, not the usual API we use. Plus some multi condition logic when an individual contributor can withdraw. But whoever will implement it can decide. Someone needs to try to pick the simplest path. |
|
We wont need any XCM communication. The crowdloan pallet will be fully migrate to AH (it does not hold any balances, only keeps info about contributors, their account ids and contribution amounts). Every contribution transferred to the fundraising account (keyless). The slots pallet holds reserves for every lease on a specific to that lease allocation account (fundraising account in case of crowdloans). We release the funds from fundraising accounts and transfer to the AH to the same account id. For simplicity we keep them liquid (no concern since accounts are keyless). We provide an implementation of the |
Polkadot currently has multiple open and active leases for parachain slots funded by crowdloans (in Kusama, all leases have ended). The crowdloans were open to all stakeholders, with a minimum contribution requirement of 5 DOT. Contributions for the winning bid that secured the slot lease are locked until the lease expires (note 1).
Upon reviewing the current state, we observe that each active crowdloan has hundreds of contributors, with contributions starting from 5 DOT. Some associated leases will end in 6 months, others in a year, and the latest in 18 months. This likely means that, to transition to the Asset Hub (AH), we would need to transfer the crowdloan data, along with associated balances and locked funds, to AH.
Note 1.
Contributions can be withdrawn before the lease ends if the leases funded by a specific crowdloan (the one including the contribution) have already started (fund.first_period) and the crowdloan has enough free balance. However, our report and test show that there isn’t enough free balance to refund to all contributors in all crowdloans. With the upcoming lease expirations, there won’t be any additional free balance in the crowdloan accounts, as each lease of every crowdloan requires the same amount of locked funds.
https://github.com/paritytech/polkadot-sdk/blob/5f782a4c5836f9bd8f279e8dd8d3a0d03a88a64f/polkadot/runtime/common/src/crowdloan/mod.rs#L724
Possible Solution
There are two pallets responsible for lease and crowdloan management: slots and crowdloan. The slots pallet is used by the system to manage leases and must remain on the Relay Chain (RC). It also tracks the total balances held for each lease and releases them when the lease ends. The crowdloan pallet manages contributions and withdrawals once a lease concludes. Although crowdloan is loosely coupled with slots, it checks certain lease details, such as the lease status.
To transition to AH, we would migrate the state of these two pallets, including balances, to AH and configure them there. On the RC, we could retain only part of the slots state (without balances) and would not need the crowdloan pallet. When a lease ends, RC would send an XCM message to the slots pallet on AH to signal the lease conclusion. At that point, contributors would be able to withdraw their tokens via the crowdloan pallet on AH.
State Inspection Results
Raw Data: One Record per Contributor
polkadot_crowdloan_contributors.csv
Test Output
You can obtain this data by running the test from this PR with the snapshot uploaded with try-runtime cli