Message Bridging

Introduction

Projects can send messages across chains by deploying via Lucid their own Message Controllers in every chain they want to send or receive a message. These controllers contracts are deployed and controlled exclusively by the Project, and Lucid has no control over them.

Message Controllers are bridge-agnostic, meaning they leverage Adapter contracts to relay or receive messages across chains using a single or multiple bridges. As new Adapter contracts are created and deployed by Lucid to support new chains and new bridges, existing Message Controllers can use these new Adapters to access new ecosystems.

Message Controller contracts also incorporate several security features, such as whitelisted message originators, a consensus mechanism for received messages, timelock and veto functionality before message execution, pausability, amongst others.

Security model on message receipt

When a message is received by a Message Controller on the destination chain, the sender (or msg.sender ) of the message needs to be verified, as only a bridge Adapter is allowed to call the receiveMessage function and register a message. There are two ways for projects to specify the Adapter contracts that are allowed to call this function.

Specify Registry

Specify local Adapters

Roles and Permissions

Message Controllers utilise an access control system, with different roles. This ensures that only authorized accounts can perform specific actions within the contract, enhancing security.

Admin Role (DEFAULT_ADMIN_ROLE)

This is the highest authority within the contract. Accounts with this role can grant and revoke any role, including the default admin role itself. Admins have the following privileges:

• Grant or revoke accounts with the Message Originator role

• Pause/Unpause the contract (temporarily stop sending and resending messages, executing received messages)

• Update the timeock delay for message execution

• Update the vetoer address that can cancel message execution while on timelock

• Add/remove message controller contract addresses in other chains, hence allow the sending and receipt of messages from & to this new chain

• Update the local Registry address (TODO: Link)

• Update the local Adapters

For more details on how to call each function please check:

Message Originator Role (MESSAGE_ORIGINATOR_ROLE)

Accounts with this role can initiate the sending of messages from the Message Controller which are then relayed to other chains.

Vetoer

An account with the vetoer role can block the execution of a message received in the destination chain, while the message is within the timelock period. There can only exist a single vetoer per Message Controller contract in a chain.

Upgradeability

Message Controller contracts are designed to be upgradeable. It uses the OpenZeppelin's Proxy Upgrade pattern, allowing the contract to be upgraded over time without compromising its state. The initial implementation contract was created and deployed by Lucid, however the Proxy Admin which is set and controlled by the Project, can choose to upgrade to a newer version as these are released by Lucid in the future.