Link Search Menu Expand Document

Modular Bridge Spec

Our bridge is modular by design with simple, small pieces. The goals for this include:

  • Understandability: Getting to an easier to understand, simple design
  • Flexibility: Having a design that supports seperation of incentives/guarantees with the ability to have different bridge designs with different fees and guarantees
  • Customizability: Having decoupling between pieces that allow different designs to depend on those pieces in whichever way they choose.

This page describes the concepts and components we use.

General Concepts


A message is used by an application on one chain to call a function with parameters on another chain. You may be familiar with that concept as a remote procedure call or RPC. A message contains data to identify the source application, target application and a payload which the target application is expected to understand.


A channel is a concept used as part of the bridge which facilitates the delivery of messages in a single direction. A channel consists of a sender and a receiver, each being a piece of business logic that runs on opposite chains, as well as a feature set as described below. Any user or system wanting to send a message across the bridge must submit it to the channel. Different channels may exist that provide varying deliverability guarantees to a message, such as replay protection across multiple messages.

For more ideas around channels, see Channels


A bridge is a pair of two channels in opposite directions.


A relayer is a piece of software running offchain that watches two blockchains and relays messages across them. The implementation of the relayer in our bridge is not part of the core protocol, as it is offchain and so is untrusted. Of course, some relayer still needs to be running in order for the bridge to function, but it only needs to conform to the protocol defined by on-chain requirements. We provide relayer software that will be run by incentivized relayers to keep the bridge active, but the specifics of the relayer are not relevant for understanding the trustless bridge protocol.

For more details on the relayer, see Validating and Relaying

Deliverability and Delivery

In the context of these docs, we often use the words guaranteed deliverability and guaranteed delivery. They both refer to different kinds of trust in the bridge.

Guaranteed Deliverability

If a bridge has Guaranteed Deliverability it means that it is trustlessly possible for a message to be delivered across that bridge, ie, so long as someone is willing to run the software to relay the message and pay gas fees, it will be processed successfully and go through. Guaranteed Deliverability does not mean that someone will actually do so - only that it is possible to do so without permission.

With Guaranteed Deliverability, the sender of the message can always deliver the message themself if they are willing to run a relayer and pay gas prices to do so, and so does not need to trust any third party if they don’t want to.

Guaranteed Delivery

Guaranteed Delivery on the other hand means that in addition, there are strong incentives or requirements for messages to be delivered such that based on economic assumptions, some third party will actually run software to relay messages and pay for gas and so messages will in fact be delivered even if the sender does not relay themself.

Core Components

Ethereum-to-Polkadot Direction

Polkadot RPC

A Polkadot RPC is a data structure that is used to represent asynchronous calls that an Ethereum smart contract wants to make on a remote Polkadot parachain. They are generated by an Ethereum smart contract and then sent over the bridge to a consuming pallet. They are asynchronous, one-way calls that do not require any response. They are received and processed by Polkadot Parachain Pallets.

Under the hood, we use ethereum events as the medium for sending messages data from Ethereum to Polkadot.

PolkadotRPC {
    sourceContractAddress EthereumContractAddress
    targetPallet Int
    payload Bytes

Payloads for a PolkadotRPC can be anything in theory, but in practice they are expected to be understood by the receiving pallet, which handles and decodes the payload into the Rust types it needs. In our applications we use RLP-encoded payloads because they are easy and cheap to generate and send from Ethereum.

Ethereum Light Client Verifier

The Ethereum Light Client Verifier is a pallet that is responsible for performing light client verification of Ethereum consensus and state on-chain on the parachain.

It follows the heaviest Ethereum chain, verifies proof of work and tracks accepted and confirmed headers beyond a given number of confirmations.

It is also responsible for accepting and verifying incoming ethereum events. It does so using transaction receipt proofs which prove that a particular transaction to a particular Ethereum smart contract was in fact valid, was included in the chain, and did emit some event. It accepts and processes a proof, verifies it and then returns the set of Ethereum events that were emitted by the proven transaction receipt.

For more details, see Ethereum Light Client Verifier.

Polkadot-to-Ethereum Direction

Ethereum RPC

An Ethereum RPC is a data structure that is used to represent asynchronous calls that a Polkadot pallet wants to make on a remote Ethereum smart contract. Such RPCs are generated by a Polkadot pallet and then sent over the bridge to a consuming smart contract. They are asynchronous, one-way calls that do not require any response. They are received and processed by Ethereum Smart Contracts.

In practice, we use parachain message commitments, as described below, as the medium for sending Ethereum RPC data from Polkadot to Ethereum.

EthereumRPC {
    sourcePallet Int
    targetContractAddress EthereumContractAddress
    payload Bytes

Payloads for an EthereumRPC are expected to be ABI-encoded contract call data which have been encoded by the sending pallet before sending. The receiving smart contract will be called directly with that ABI-encoded call.

Snowbridge Parachain

With our bridge running on Polkadot, we aren’t just verifying and sending messages from and to the Polkadot relay chain. We also want to be able to send and verify messages on any parachain and parathread, to support assets and functionality that are not supported by the relay chain. Snowbridge runs its own parachain to facilitate this.

For more details, see Snowbridge Parachain

Parachain Message Commitment

Our parachain facilitates any parachain that wants to send messages out to Ethereum, and so is responsible for storing those messages in a way that can be verified trustlessly on Ethereum. It does so through creating custom message commitments on our parachain that can be easily and cheaply verified.

These parachain commitments are effectively the sending part of a channel for communication from Polkadot to Ethereum. We may rename/refactor this functionality for consistency in future.

For more details, see Parachain Commitments

Polkadot and Parachain Light Client Verifier

For trustless verification on Ethereum we need a Polkadot light client and a parachain light client for our parachain. We have a set of smart contracts that run on Ethereum to provide this.

For more details, see Polkadot Light Client Verifier

Basic Bridge

The basic bridge is a lower level bridge intended to act as a bootstrap and simpler alternative to the main bridge. It is not incentivized and so does not guarantee delivery. It does however guarantee deliverability and replay protection.

This bridge consists of 2 basic channels.

Basic Message Channel (Ethereum → Polkadot)

This is a channel for sending Polkadot RPCs out from Ethereum to Polkadot via events. It consists of a smart contract on the Ethereum side and a corresponding pallet on the parachain side.

The smart contract is responsible for accepting requests from other smart contracts for Ethereum RPCs to be sent over to Polkadot. It puts those requests into a channel that a corresponding pallet will receive on the Polkadot side.

For more details, see Basic Message Channel (Ethereum → Polkadot)

Basic Message Channel (Polkadot → Ethereum)

This is a channel for sending Ethereum RPCs out from the parachain to Ethereum. It is responsible for accepting requests from other pallets and parachains for messages to be sent over to Ethereum. It puts those requests into Parachain Message Commitments that will be included in the parachain header. The channel then processes those commitments and verifies them via the Polkadot and Parachain Light Client Verifier to extract Ethereum RPCs. Those Ethereum RPCs are then routed to their target contract by calling that contract.

For more details, see Basic Message Channel (Polkadot → Ethereum)

Incentivized Bridge

The incentivized bridge extends the basic bridge by adding a strict message ordering channels in both directions that enforce delivery of messages in the order that they are sent. It also adds incentives which provide guaranteed delivery with strong properties based on simple economic assumptions without the need for any kind of Oracle-based solution.

A common problem with bridges is in handling fluctuating gas prices and exchange rates across chains and assets. Often oracle-based solutions are used to deal with this. However, once we have a bootstrap bridge up, we now have access to cross-chain pegged assets, and so we can use those as part of our bridge incentive model. This means using SnowETH and SnowDOT to cover costs for relayers such that they are not impacted by changing exchange rates. Longer term, we consider adding a gas token which can be used to have fixed future gas costs. A gas token would act much like a future in a traditional stock market.

For more details, see Incentivized Bridge

Copyright © 2020 Snowfork