Wisp Protocol


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}
RDestination R_{Destination}
. The newly updated L1 state can be used later for message delivery. The message relayer job is to trigger the
transaction. These transactions prove the inclusion of the
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. 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. 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.
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
. For example, for Optimism Bedrock rollups the proof for inclusion of a
  • 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
    is part of the
    contract on
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
    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.