2. Beamer Contracts

2.1. Architecture

The following figure shows the Beamer contract architecture:

digraph "Beamer contracts" {
    graph[rankdir=TD, ranksep=6, splines=ortho, nodesep=1.2, pad=1]
    node [shape=box, width=1.5, height=1, fontname="Liberation Mono"]
    edge [fontname="Liberation Mono"]
    subgraph L1 {
        nodesep = 1.0
        l1dummy [style=invis]
        Resolver [label="Resolver"]
        L1Messenger [label="L1Messenger", color="purple"]
    subgraph L2 {
        l2dummy [style=invis]
        RequestManager [label="RequestManager"]
        FillManager [label="FillManager"]
        L2Messenger [label="L2Messenger", color="purple"]
        # restricted calls
        edge [color=red]
        FillManager -> L2Messenger [headlabel="sendMessage()"]
        Resolver -> L1Messenger [xlabel="sendMessage()"]

        # restricted calls crossing the L1/L2 boundary
        edge [color=red, style=dashed]
        L2Messenger -> Resolver [headlabel="resolve()"]
        L1Messenger -> RequestManager [headlabel="resolveRequest()"]

        # unrestricted calls
        Resolver -> L1Messenger [headlabel="callAllowed()"]
        RequestManager -> L2Messenger [headlabel="callAllowed()"]
    l1dummy -> l2dummy [style=invis]
    l1dummy -> Resolver [style=invis]
    l2dummy -> RequestManager [style=invis]

Beamer contracts

Contracts in purple rectangles are chain-dependent. Red lines indicate restricted calls. Dashed red lines indicate restricted calls that cross the L1-L2 boundary. Black lines represent ordinary, unrestricted calls.

Here, “a restricted call” means “a call that only a specific caller is allowed to make”. For example, the L1Messenger contract may only be called by the Resolver contract. In this way, a chain of trust is established to ensure that L1 resolution is safe. The complete trusted call chain is:

FillManager -> L2Messenger -> Resolver -> L1Messenger -> RequestManager

The Resolver contract is deployed on L1 and is used by all L2 chains.

Messenger contracts are specific to L2 chains and are responsible for

  • sending messages to the other side (an instance of L1Messenger is deployed on L1 and sends messages to the L2 chain it is related to; similarly, an instance of L2Messenger is deployed on its L2 chain and sends messages to L1)

  • answering the question “where did this message really come from?” (this is because the msg.sender will be the chain’s messenger contract that relayed the message, not the original message sender)

The following tables list Beamer contracts. It should be noted that the interfacing contracts are chain-dependent and are mostly used to facilitate message transfer between L1 and L2.

Core contracts (chain-independent)


Deployed on







Interface contracts (chain‑dependent)


Deployed on





2.2. Parameters

Core contracts parameters






Minimum amount of source chain’s native token to claim in WEI.


Additional time given to claim a request in seconds.


The period for which the claim is valid in seconds.


Additional time given after challenge in seconds.


PPM to determine minLPFee profit for liquidity providers.


PPM from transfer amount to determine LP`s fee.


PPM from transfer amount to determine protocol`s fee.


Minimum validity period of a request in seconds.


Maximum validity period of a request in seconds.


Maximum validity period of a request.


Counter to calculate request and claim IDs.


Maps chain IDs to chain information.


Maps request IDs to requests.


Maps claim IDs to claims.


Maps ERC20 token addresses to tokens.



Used to send proofs to L1.


Resolver contract address to use for L1 Resolution.


Maps request IDs to fill IDs.



Maps source chain IDs to source chain infos.

2.3. L1 Resolution

For a working L1 resolution we need to transmit data about the filler of a given request. In general chains provide mechanisms for data exchange which are often used to implement their own L1/L2 bridges. Optimism has some documentation here.

Given the possibility to transmit information, there are two problems that need to be solved: how to route the information to the correct source chain and how to make this information trustworthy.

2.3.1. Routing

The proof of request fulfillment will always be written by the FillManager contract on the target chain and, in case a L1 resolution is triggered, must be submitted to the RequestManager contract on the source chain.

This process is started by the liquidity provider who fills a request. This writes a proof on that chain. This proof includes information about the filler, the chain id of the source chain and the request id. The proof is basically an encoded transaction to the resolver, which can be executed on L1.

The central role for routing this information correctly has the Resolver contract, which is deployed on the shared base chain of both chains. The resolver holds a mapping of chain ids to the contract address of the RequestManager on that chain.

When a proof transaction sent by the target chain is executed, the resolver can find the correct request manager in the mapping and forward the information about the filler. This again happens in form of a transaction, that can be executed on the source chain.

2.3.2. Trust

To make sure that the resolved information is correct, only trusted contracts must be allowed to take part in the message forwarding scheme. Otherwise, bad actors could freely write invalid proofs on the target chain or even on the L1 chain.

Avoiding this requires whitelisting valid senders in all contracts on the path of information.

  • On the target chain, the messenger contract must only be callable by the FillManager contract.

  • On L1, the resolver must only accept messages sent by a whitelisted L2 messenger for the given chain id.

  • On the source chain the request manager must only accept transactions that have been sent by the L1 messenger.

2.4. API Reference

Please see the section Contracts API Reference