Composable’s Implementation of the Crowdloan Rewards Pallet

Crowdloan pallet overview

The pallet operates in two main phases: the pre-initialization population and post-initialization association and claiming phases.


The population phase exists with the primary objective of populating the reward accounts of the crowdloan and eventually initializing the pallet. During this phase, the only transactions that will succeed are populate and initialize/initialize_at. For any of the transactions in this phase to succeed, they must be signed by an admin origin that is configured by the runtime. Once initialized, the pallet will move to its post-initialization phase.

Account Association and Claiming

Once in the claiming phase, the pallet’s primary objective shifts to enabling contributors to associate their reward accounts with their ETH or relay chain accounts and then allowing them to claim their reward. When contributors first associate their accounts, they will receive a percentage of their total reward. After this association, contributors can return once per vesting period to claim another portion of their reward. These vesting periods are measured in Vesting Steps, which are a number of blocks relative to the block that the pallet was initialized in. Successful calls to associate and claim will not incur a fee.

Unsigned Transactions and Spam Prevention

Generally, transactions are signed with some fee which ensures identity and prevents transaction spamming. However, in the case of the Piccaso Crowdloan, users won’t yet have PICA to sign transactions with until they associate their rewards and remote accounts. This means that the pallet must be able to accept unsigned transactions for calls to associate. Consequently, we need another method to handle the validation of our unsigned transactions.

  • The transaction payload contains the necessary information for validation (a reward account ID and proof) (#L518 in the codebase linked above)
  • The pallet has been initialized (#L523)
  • The reward account associated with the ID has not been associated with a remote account. If an account is already associated, their transactions should be signed (#L527)
  • That a remote account can be retrieved from the valid proof (#L530)
  • The reward account has a positive amount to claim (#L537)
Flowchart of our implementation of ValidateUnsigned


Yoachimik, O., & Ganti, V. (2022, January 10). DDoS Attack Trends for Q4 2021 [Review of DDoS Attack Trends for Q4 2021]. Cloudflare Blog; Cloudflare.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store