> For the complete documentation index, see [llms.txt](https://l1x-sdk.gitbook.io/l1x-developer-interface/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://l1x-sdk.gitbook.io/l1x-developer-interface/multi-chain-with-x-talk/start-building-with-x-talk/cross-chain-data-and-message-passing-xcdp/v1.1-latest/system-overview.md).

# System Overview

The L1X XTalk Protocol enables secure and reliable communication between different blockchains, initially supporting EVM-compatible chains and the L1X mainnet. It uses a combination of off-chain **XTalk Nodes** and on-chain **XTalk Smart Contracts** to validate, achieve consensus on, and execute cross-chain messages.

### Core Components

#### 1. XTalk Node 

An off-chain application that monitors, validates, and relays messages. It has three key validator roles:

* **Listener Validator:** Detects new cross-chain message requests initiated on a source EVM chain.
* **Signer Validator:** Cryptographically signs validated message details, contributing to a multi-signature consensus.
* **Relayer Validator:** Delivers the consensus-approved message and signatures to the destination EVM chain for execution.

#### 2. XTalk Smart Contracts 

**a. XTalkBeacon Contract (EVM Chains)**

Deployed on participating EVM chains:

* **Source Chain Role:** Allows users to register outgoing cross-chain messages and emits an event (`XTalkMessageBroadcasted`) to alert XTalk Nodes.
* **Destination Chain Role:** Receives messages from Relayer Validators. It verifies the aggregated signatures from Signer Validators and, if valid, executes the message by calling a predefined function on the target contract, delivering the payload.

**b. L1X Chain Contracts**

These contracts manage consensus and routing on the L1X mainnet:

* **Source Registry (`SourceRegistry`):** A directory that maps source chain IDs to specific L1X `FlowContract` addresses. This allows XTalk Nodes to determine the correct L1X contract for processing messages from a particular source chain.
* **XTalk Consensus Contract (`XTalkConsensusContract`):** The central hub for message validation and consensus:
  * **Listener Consensus:** Collects votes from Listener Validators about new messages. When enough listeners agree, the message is considered `ListenerFinalized`.
  * **Signer Consensus:** After listener consensus, it collects cryptographic signatures from Signer Validators for a specific message hash. When enough signers agree, the message is `SignerFinalized`, and their signatures are stored.
* **Flow Contract (`FlowContract`):** An intermediary processing contract on L1X:
  * **Stores Event Data:** After listener consensus, it receives and stores the validated event details from the source chain.
  * **Provides Data for Signing:** Generates a unique, deterministic hash for each message (based on its content and destination details) that Signer Validators must sign.
  * **Prepares Execution Payload:** Constructs the complete transaction data (including the original message and collected signer signatures) that Relayer Validators use to execute the message on the destination chain.

### High-Level Message Lifecycle

1. **Initiation (Source EVM Chain):** A user initiates a cross-chain message via the `XTalkBeacon` contract, which emits an `XTalkMessageBroadcasted` event.
2. **Listener Validation (L1X Chain):**
   * Listener Validators detect the event.
   * They consult the `SourceRegistry` to find the appropriate L1X `FlowContract` for this message.
   * They submit their observations as votes to the `XTalkConsensusContract`. Once consensus is reached, the message is `ListenerFinalized`.
   * The `XTalkConsensusContract` then instructs the designated `FlowContract` to store the validated event data.
3. **Signer Validation (L1X Chain):**
   * Signer Validators fetch a specific hash for the message from the `FlowContract`.
   * They sign this hash and submit their signatures to the `XTalkConsensusContract`.
   * Once sufficient signatures are collected and verified, the message is `SignerFinalized`.
4. **Relaying & Execution (Destination EVM Chain):**
   * A Relayer Validator retrieves the message details and the collected Signer signatures.
   * It uses the `FlowContract` to prepare the final transaction payload for the destination chain.
   * The Relayer submits this payload to the `XTalkBeacon` contract on the destination chain.
   * The destination `XTalkBeacon` verifies the multi-signature bundle against the message. If valid, it executes the message by calling the specified target contract with the original message payload.

This multi-stage process, involving off-chain nodes and on-chain smart contracts with distinct consensus phases, ensures the secure and reliable transfer and execution of cross-chain messages.