Light Client Messaging Protocol


LCMP, short for Light Client Cross-Chain Messaging Protocol, is a protocol meticulously designed and developed by the Darwinia core team. It is currently being actively utilized within Darwinia's chains. This protocol enables seamless communication between different blockchains by establishing messaging channels between them.
Image without caption
The LCMP protocol consists of two layers, as shown in the diagram above. The first layer, known as the truth layer, incorporates the light client functionality. This layer is responsible for ensuring the integrity and validity of the cross-chain messages. The protocol derives its name from this layer, which plays a crucial role in maintaining the trustworthiness of the communication. The second layer of the LCMP protocol is the message layer. This layer is specifically designed to handle various aspects related to cross-chain messages. It takes care of issues such as message formatting, transaction fees, and other relevant considerations. By addressing these concerns, the message layer streamlines the process of sending and receiving cross-chain messages, enhancing the overall efficiency and effectiveness of the protocol.

Message Flow

To facilitate a comprehensive understanding of the message flow, it is important to establish the assumption that the truth layer is functioning as intended. Without a properly functioning truth layer, it becomes impractical to delve into the intricacies of the message layer. This is because the truth layer plays a critical role in providing essential validation services for the message layer. If the truth layer is compromised or broken, it renders the execution of cross-chain messages on the target chain impossible, even if the messages successfully reach their intended destination.
Image without caption
Let's break down and expand upon the steps depicted in the diagram:
  1. Dapps in the application layer initiate a cross-chain message transaction by invoking the send_message(message) function provided by the Message Layer in the source chain. This function allows Dapps to transmit the desired message across chains, enabling interoperability between different blockchain networks.
  1. Upon receiving the cross-chain message transaction, the source chain's message layer performs necessary validations on the message. These validations include checks for staleness or duplication of the message. By conducting these validations, the source chain ensures the integrity and reliability of the cross-chain messaging system. Once the validations are successfully passed, the message is saved in the source chain, making it available for further processing.
  1. A crucial role called the "relayer" actively monitors the movement of messages within the source chain. When a new cross-chain message is detected in the source chain, the relayer initiates the process of relaying this message from the source chain to the message layer in the target chain. Acting as a bridge between the two chains, the relayer facilitates the seamless transfer of cross-chain messages, enabling communication and interaction between different blockchain networks.
  1. Once the target chain receives the cross-chain message from the relayer, it undergoes a validation process to ensure the authenticity and integrity of the message. It's important to note that some of these validations rely on the truth layer, which helps ensure the accuracy and trustworthiness of the message contents. If the message validations are successfully passed, the cross-chain message information is decoded and subsequently executed in the target chain. At this stage, the message that the Dapp initially sent has been executed in the target chain, regardless of whether it was successful or not.
  1. Once the message is executed in the target chain, an event is triggered to inform the relayer. This event serves as a signal for the relayer to confirm the execution result and the latest status back to the source chain. This confirmation process is crucial for the source chain to accurately detect stale or duplicated messages and enables features like message flow control. By confirming the execution result and status, the source chain can maintain an up-to-date view of the cross-chain message's progress and take appropriate actions based on the outcome.
  1. Upon receiving the confirm message from the target chain regarding the initial message, the source chain marks the end of the cross-chain message's lifecycle. This signifies the completion of the message's journey across different chains. At a predetermined time, the source chain clears the stored messages, making space for new incoming messages. This process ensures the efficient handling of subsequent cross-chain messages and helps maintain the scalability and performance of the overall system.

Message Status

  • MessageAccepted - Message has been accepted and is waiting to be delivered.
  • MessagesReceived - Messages have been received from the bridged chain.
  • MessageDispathed - Message has been executed in the target chain.
  • MessageDelivered - Messages in the inclusive range have been delivered to the bridged chain.

Message Fee

When discussing cross-chain message protocols, an important aspect to consider is the fee associated with these transactions. The fee calculation process is complex, involving various factors such as the tokens used in the source and target chains, the involvement of third-party entities like relayers, and the mechanism for incentivizing and collecting fees.
Traditionally, fee systems have relied on integrating with an oracle to provide up-to-date token prices from the market. This information is then used within the message protocol to establish fee logic, including conversions based on the oracle's data. However, this approach has inherent flaws, as integrating an oracle introduces additional vulnerabilities and potential attack vectors.
To address these challenges, the Darwinia Core team has designed a sub-protocol called FeeMarket. The FeeMarket protocol aims to tackle the issue of cross-chain fees in a different way. It provides a solution that reduces the reliance on oracles and mitigates the associated risks. By implementing the FeeMarket protocol, the Darwinia Core team aims to provide a more secure and efficient mechanism for determining and handling fees within the cross-chain message ecosystem.


Here are the two implementations of the LCMP that we discussed:
  • Solidity LCMP
    • This implementation achieves the truth and message layer using smart contracts written in Solidity. It provides cross-chain capabilities for chains that are Ethereum Virtual Machine (EVM) compatible. By leveraging the power of smart contracts, the Solidity LCMP enables secure and reliable cross-chain communication between different EVM-compatible chains.
  • Substrate LCMP
    • This implementation achieves the truth and message layer using a substrate pallet written in Rust. It provides interaction capabilities for parachains and solo chains within the Polkadot system. It allows chains to send and receive messages, exchange data, and perform operations across the Polkadot ecosystem.
These two implementations cater to different blockchain ecosystems and provide cross-chain capabilities tailored to their specific requirements. The Solidity version focuses on EVM-compatible chains, while the Substrate version targets the Polkadot system, enabling interaction between various chains in that network.