---
# System prepended metadata

title: Parachain Crowdloan Campaign

---

# Parachain Crowdloan Campaign

Module to help fund a deposit to secure a parachain slot, since parachains need to obtain a slot ID in the relaychain. This is usually done by locking DOT/KSM. These locked amount can be sourced in different ways:

## Single Account
In this case a single account sources the bid amount for the parachain slot. The owner of this account can be a core-team member (if it has the necessary amount) or a custodian (through off-chain coordination with the parachain community members).

Obviously working with a custodian makes sense if contributors need to go through KYC process, but obviously comes at the price of having to trust the custodian to issue contribution rewards and unlocking the contributed amount once the parachains lifecycle finishes.

## Crowdloan module
In this case we make use of the crowdloan module to crowdsource the required DOT/KSM. The Crowdloan module allows to create a fund, contribute, and unlock contributions in a decentralized manner through on-chain transactions. Although the crowdloan module does not specifically cover rewards, moonbeam should reward (probably in the native RIVER token) contributors that have contributed to secure the parachain slot.

## Lifecycle
1. An entity creates a fund that accepts contributions. b entity can be a core team member or a custodian in the case of single account
2. Contributions are made to bid for a parachain slot. In the case of a single account these contributions are made by the custodian, but in the case of crowdsourcing contributions can be done by any entity. Additionally, the crowdloan module allows to set a verifier that needs to sign contributions in order to be accepted.
3. Auctions have two main stages:
    3.1 Pre-ending: Period on which contributions are accumulated but bid is raised. This is done to avoid having one bid raised everytime the fund receives one cotribution.
    3.2 Ending: Period on which one bid per slot is raised, but only if there was a contribution in this slot.


![](https://i.imgur.com/Vx6RHlh.png)

4. If the bid was succesfull, the parachain is assigned a slot id and the wasm validation data for the parachain can be deployed. The onboard process cannot complete if such validation data is not set.
6. If the bid was unsuccesful, we enter the pre-ending stage again if we did not reach the 'end' block number.
7. If we reached the 'end' block number and the bid was unsuccessful, then every contributor can retrieve its funds.
8. If a succesful parachain is removed from its slot, then the retirement phase begins.
    8.1 Contributors can withdraw their founds while they are 'inretirement' period.
    8.2 After 'inretirement' period non-withdrawn contributions are transferred to treasure through the 'disolve' function
    ![](https://i.imgur.com/GTJDHnX.png)


## Open questions
- How often to distribute the Moonriver tokens (RIVER) ? Monthly/Daily...
    - I would do it together with the block rewards (e.g., every 'era')

- Is it going on/off-chain mechanism to distribweute RIVER ?
    - I would prefer if this is on-chain

- How to map addresses from Kusama to Moonriver ?
    - Assuming ECSDA keys were used to generate the account in Kusama, this should be doable if we have a signature (I think we do since the tx to register for the rewards should be signed). With the signature we should be able to retrieve the non-compressed and compressed public keys. With that, based on what sub-key generates, it shold be as simple as doing a blake2 hash to the compressed version and check whether it is the same as the address that contributed the amount.

- How to whitelist who can particiate in Crowdloan ?
    - This can be done through the verifier parameter (e.g., the verifier signs only contributions from participants in a whitelist). The question is whether this is sufficiently ergonomic.

(Legal) How to register user information ?