What do Relayers do?

There are two types of relayers in the system - state relayer and message relayer.

The state relayer job is to produce the computation integrity proofs (SNARK) - SNARKL1StateSNARK_{L1 State} - that updates the L1 state in CL1LightClientC_{L1 Light Client} on RDestination R_{Destination}. The newly updated L1 state can be used later for message delivery. The message relayer job is to trigger the CRCDeliveryCRC_{Delivery} transaction. These transactions prove the inclusion of the CRCmsgCRC_{msg} inside RSourceR_{Source}.

Importantly, both of the relayers' described ensure the liveness of the system and not the security of the system. The protocol security is derived from cryptography and verified through smart contracts. As long as there is at least one relayer willing to perform the job, the system will continue to be secure under the standard technological risks (circuits and smart contract bugs).

State Relayer

The job of the state relayer is to monitor the L1 and produce SNARKL1StateSNARK_{L1 State} proofs. In order to do so they need to monitor Ethereum L1 Consensus. Two types of ZK proofs are relayed by the state relayer - sync committee update proof and block header verification proof.

  1. Who should sign the Header? The sync committee update ZK proof proves to CL1LightClientC_{L1 Light Client} that the root of the 512 sync committee members for a given period is of a certain value X.

  2. Was the Header signed by the assigned validators? The header update ZK proof proves to CL1LightClientC_{L1 Light Client} that the inputted block header is signed by at least 2/3 of the Sync Committee members for the current period.

The CL1LightClientC_{L1 Light Client} deployed on each RDestination R_{Destination} is an on-chain implementation of the Ethereum Sync Protocol.

In order to perform this job, the State Relayers are incentivized with a fee in ETH sent by the message sender. The fee structure is not yet finalized but will either look like the Ethereum gas auction pre-EIP1559 or inherit the EIP1559 fee model.

Importantly, the role of a state relayer is permissionless and anyone can decide to be a relayer - monitor L1, produce proofs and earn fees. dApps can deploy their own Relayers and utilise the protocol without relying on external entities.

Message Relaying

The job of the message relayer is to automate the message delivery inside RDestination R_{Destination} once the state of L1 is relayed by a state relayer.

The process of message delivery involves multiple Merkle Inclusion Proofs and varies based on the specifics of RSourceR_{Source}. For example, for Optimism Bedrock rollups the proof for inclusion of a CRCmsgCRC_{msg} involves:

  • An Optimism State Root and other artefacts needed for the contract to construct an Optimism Output Root.

  • A Merkle Patricia Tree Inclusion Proof that an Output Root that contains the sent message in its State Root is present inside the Ethereum L1 Optimism L2OutputOracle contract.

  • A Merkle Patricia Tree Inclusion Proof that the intended CRCmsgCRC_{msg} is part of the COutboxC_{Outbox} contract on RSourceR_{Source}.

In order to perform this job, the message relayers are incentivized with a fee in ETH sent by the message sender. Importantly, the role of a message relayer is permissionless and anyone can decide to be a relayer and deliver messages and earn fees. Furthermore, any user can decide to pay 0 fees and be their own relayer of messages inside RDestination R_{Destination}.

Running a Relayer

The information below is based on the alpha version of the Wisp protocol in which ZK circuits are based on Proof of Consensus.

For the most up-to-date information on running the relayer check out the repo readme:


-Sync Committee ZKP (every 27 hours)Signed Header ZKP (every 6 min)

Witness Generation

28 seconds

135 seconds

Proving Time

126 seconds

62 seconds


2m 34s

3m 17s

Hardware Requirements

32 core 3.1 GHz; 256 GB RAM; 1 TB SSD; Currently using AWS r6a.8xlarge running Ubuntu 22.04


Two types of costs exist for the relayers.


Based on the hardware requirements above in AWS this costs ~$45/day

Transaction Fees

Secondly is the transaction costs inside the destination rollup.

  • CRCStateRelayCRC_{State Relay}cost 650k L2 gas + 23k L1 gas (example TX). The cost for which is split between all CRCmsgCRC_{msg}for a period of 6 minutes (the interval at which SNARKL1StateSNARK_{L1 State} are posted)

  • CRCDeliveryAckCRC_{Delivery Ack} cost 1.2M L2 gas + 150k L1 gas (example TX).

There are numerous improvements that could be made in both the ZKP and On-chain part, thus we expect this cost to drop with newer versions.

Last updated