Contributing to Snowbridge

Processes for making changes to the Snowbridge pallets and runtimes for BridgeHub and AssetHub

Writing New Code

Any new code will be added to the Snowfork repositories:

Merging New Code

Internal Snowfork Review

For both repositories mentioned above, pull requests (PR) should be made to the respective main branches. The Snowfork team members will review. Once the PR has been reviewed by 1 of more team members and all Github Actions pass, the pull request should be merged.

Parity Review

For any changes made to the Snowfork/polkadot-sdk, these changes should be contributed back to the original repository, paritytech/polkadot-sdk.

To create an upstream pull request, do the following steps:

  1. Switch to the branch you would like to contribute upstream

  2. Run `./bridges/snowbridge/scripts/ my-changes`, where `my-changes` is the name of the new branch that will be created with your changes. The reason why this script creates a new branch is because we replaced Parity’s CI with our own, and so we need to clean up the changes that we have made to contribute the code back upstream. A new branch is created so it does not affect our CI and local development processes, but cleans the code so not to make irrelevant changes in the upstream PR.

  3. Open the pull request on paritytech/polkadot-sdk.

  4. If the change is a minor change that doesn’t require release notes or greater awareness in Parity, ask on the PR in a comment for label R0-silent to be added to the PR. If the change is a larger change that requires awareness, add a file called `pr_xxx.prdoc` in the `prdoc` directory, where xxx is the PR number. Describe the changes in the prdoc file (look at examples in that directory - it is fairly straightforward).

  5. Usually, the Parity bridges team will review the PR within a day or two, without needing to prompt. For urgent reviews, post the link to the PR in the Builders <> Snowfork Matrix Room Builders <> Snowfork Matrix Room, asking for reviews.

  6. If the change needs to be deployed to Rococo immediately (outside a regular release cycle), also update the relevant runtime spec version. This is typically the BridgeHub or AssetHub runtime spec version. This spec version will automatically be incremented by Parity for release cycles.

Crate Updates on

As part of the paritytech/polkadot-sdk release cycle, crates are published on No extra action is required from the snowfork team to publish the Snowbridge crates. The crates are published by parity-crate-owner.


Snowbridge pallets should be audited before releasing to Kusama and Polkadot. Audits should ideally be anticipated at least a month or two in advance, so that auditors can be engaged and booked in time. Since the overall codebase was audited, incremental audits will typically run for a week or less, with a week or two to address the findings, if necessary.

Audit fixes are usually done on a branch, so as not to interfere with other new features being built and to allow the auditors to easily verify fixes.

Rococo Runtime Upgrade & Deployment Processes

Rococo deployments are done after the polkadot-sdk release. If out-of-cycle deployments need to be done, they can be arranged in Chain Infrastructure: Rococo DevOps.


Runtime Upgrade

Once a new version of the polkadot-sdk is released, the polkadot-sdk crates should be updated in a PR to the fellowship runtimes repository. An example of such a PR is Upgrade to latest polkadot-sdk@1.5 release #137. Parity usually handles this and will push the release forward from the Fellows runtime PR to the execution of the upgrade on Polkadot.


To deploy the change, extrinisc parachainSystem.authorizeUpgrade is called.


A proposal to upgrade the runtime is created and can be viewed on Polkassembly (e.g.


Once the referendum receives enough votes, parachainSystem.enactAuthorizedUpgrade can be executed to enact the upgrade.

The above steps are handled by Parity devs.

Last updated