Building L1 Blockchains with EigenLayer AVS: A Guide for Substrate Developers

In the ever-evolving blockchain ecosystem, scalability, validator incentives, and network security remain core challenges for Layer 1 (L1) blockchain developers. Substrate provides the perfect foundation for building customizable L1 blockchains, but integrating newer technologies like EigenLayer’s Autonomous Verifiable Service (AVS) can help bring additional value to a project. This article will explain how Substrate developers can leverage EigenLayer's AVS for validator selection while keeping project tokens on Ethereum for liquidity.

We will explore the major components of building a Substrate-based L1 blockchain with EigenLayer integration, focusing on how to choose validators, distribute rewards, and interact with Ethereum. This guide assumes you’re using Substrate Frame 2 and have a basic understanding of Substrate development.

Introduction to EigenLayer AVS

EigenLayer’s Active Validator Selection (AVS) system allows blockchain projects to leverage Ethereum validators through its decentralized re-staking mechanism. Essentially, this allows projects to "tap into" the security and validator set from Ethereum, incentivizing both Ethereum validators and other entities to participate in the new blockchain's network security. 

Importantly, in Eigenlayer, operators are not necessarily the same as Ethereum validators. Instead, they are anyone who decides to be a validator for an AVS on the Eigenlayer network. While Ethereum validators play a role in securing Ethereum through Proof of Stake  consensus mechanism, Eigenlayer's operators can be individuals or entities that choose to participate in the Eigenlayer network by validating and providing security for appchains or other decentralized services.

The process operates as follows:

  1. Validators offer their staked ETH to provide security to the new chain.

  2. Shared Incentives are created between Ethereum and the new blockchain.

  3. The new blockchain benefits from Ethereum’s validator set while maintaining its token economy and liquidity on Ethereum, where it enjoys access to a large pool of liquidity.

The integration of EigenLayer's AVS with Substrate can result in an L1 chain that attracts validators from Ethereum ecosystem but also keeps the project's tokens on Ethereum for high liquidity. This is a powerful way for new blockchains to bootstrap their security without needing to attract a new validator set from scratch.

Building an L1 Blockchain Using Substrate

Launching a new blockchain, one of the first questions you ask yourself is: Do we really want to manage our own validator set?

In most cases, the answer is no. Setting up and maintaining a decentralized validator network from scratch is a huge operational challenge. It requires building trust, bootstrapping incentives, and sustaining community engagement — all of which take time, resources, and significant liquidity to incentivize properly. Instead, most teams want to focus purely on product-market fit, innovation, and user experience without being bogged down by low-level infrastructure and validator coordination.

At the same time, you do want to launch your own native token — a token that represents the core of our network’s utility and governance. But launching that token natively on your own chain feels like a step backward from a liquidity and adoption standpoint. The reality is:

  • Most decentralized exchanges (DEXs) and centralized exchanges (CEXs) operate almost entirely on the Ethereum ecosystem — either mainnet or Layer 2s.

  • Token listings, integrations, and market-making infrastructure all exist on Ethereum.

  • Users and institutions are more familiar and comfortable with ERC-20 tokens than with bespoke tokens from isolated chains.

So, 1st strategic decision:

Your L1 blockchain will run on Substrate, but your token will live on Ethereum as an ERC-20.

This allows to:

  • Bootstrap deep liquidity immediately via DEXs like Uniswap, Balancer, or Curve.

  • Tap into Ethereum’s DeFi composability and tooling.

  • Get listed faster on CEXs that already support ERC-20s.

But What About Validators?

This is where it gets interesting.

We want our blockchain to be secure and decentralized, but Ethereum operators/validators don’t want to run extra infrastructure just for us. They’re busy, selective, and want everything — staking, delegation, and rewards — to happen on Ethereum.

This makes total sense. Ethereum has the capital, trust, and validator infrastructure already in place. So instead of asking validators to stake directly on our Substrate chain or run custom nodes, we leverage EigenLayer — a re-staking protocol that lets Ethereum validators opt-in to provide security to other networks.

Through EigenLayer, validators already staking ETH can opt in to also validate our chain, and we don’t need to build or recruit a validator set at all.

The Cross-Chain Coordination Challenge

Now, let’s talk about the cross-chain communication between Ethereum and our Substrate-based blockchain.

Sourcing Validators From Ethereum

We rely on EigenLayer's system. This means we need to:

  • Read validator participation commitments on Ethereum.

  • Import that validator list into our Substrate chain.

  • Use those Ethereum-sourced validators to validate our Substrate-based L1.

So our Substrate blockchain receives messages from Ethereum with information about which validators opted in. This validator list is then used by the chain's session pallet to update the active validator set.

Rewarding Validators on Ethereum

On the flip side, rewards can’t be paid on our chain — because our token is an ERC-20 on Ethereum. That means the actual reward distribution must happen on Ethereum.

But how does Ethereum know which validators did the work?

Here’s the key:

  • Our Substrate chain tracks validator performance and computes rewards.

  • Periodically, it generates a message saying: “Validator X earned Y tokens”.

  • This message, along with cryptographic proofs (e.g. via BEFFY), is sent to Ethereum.

  • On Ethereum, a smart contract verifies the message, and distributes ERC-20 token rewards accordingly.

Here’s a step-by-step breakdown of the changes to the Substrate runtime for validator selection and reward distribution.

Polkadot Versions and BEFFY Integration

Proper Ethereum–Substrate interoperability, especially for validator messaging and reward delivery, depends on BEEFY (Blind Efficient Finality Gadget) being supported in both directions. The following Polkadot SDK versions (Stable series) introduced key capabilities enabling this:

  • Stable 2407
    → Added runtime support for reporting BEEFY fork voting
    This introduced consensus-level capabilities to detect and report equivocation (i.e., double-signing) in BEEFY voting, a critical prerequisite for safe finality tracking and cross-chain bridging.

  • Stable 2409
    → Added BEEFY equivocation-related methods to BeefyApi
    These new RPC and runtime interfaces made it possible to programmatically inspect and respond to BEEFY-related consensus violations, paving the way for robust relayer implementations.

  • Stable 2412
    → Backport Snowbridge - Support bridging native ETH
    This milestone brought Snowbridge into broader use by enabling secure ETH bridging directly from Ethereum to Substrate, and vice versa, with finality guarantees. While not strictly BEEFY-specific, this version reflects the first production-ready bridging layer for native ETH and generalized messaging — anchored by BEEFY proofs.

A Brief History of Snowbridge

Snowbridge is a trust-minimized Ethereum–Substrate bridge originally developed by the Web3 Foundation and later maintained and extended by contributors like Moondance Labs and the Tanssi project. It operates using outbound queues, channel logic, and BEFFY-based consensus proofs, allowing:

  • Substrate → Ethereum: Messages like ReportRewards to be sent using finality-anchored proofs.

  • Ethereum → Substrate: Messages like ReceiveValidators to be trusted and executed only after on-chain validation.

Snowbridge forms the backbone of our cross-chain coordination — allowing staking and validator lifecycle events to stay Ethereum-native, while keeping the execution layer performant and flexible on Substrate.

1. Modifying the Session Pallet to Choose Validators

Substrate’s Session pallet controls the validator selection mechanism. By default, it selects validators based on staking preferences, but we need to modify this pallet to work with EigenLayer's AVS system.

In your Substrate runtime, you’ll need to:

1.1. Modify the Session Pallet Configuration

In our architecture, the Substrate-based blockchain does not pull validator data directly from an API like EigenLayer. Instead, it reactively receives validator information from Ethereum via a trust-minimized bridge.

These messages are relayed and processed through a custom implementation of the MessageProcessor trait (e.g., MessageProcessor), and injected into a pallet such as pallet_external_validators.

Here’s how the flow works:

Message Flow Overview

  1. On Ethereum, a governance smart contract (or AVS coordinator) emits a message containing:

    • A list of active validators.

    • An external validator set index (e.g. versioning).

  2. The bridge relayer picks up this message and packages it with magic bytes for verification.

  3. On Substrate, a pallet like message_processor verifies the message via:

    • Matching magic_bytes.

    • Validating the channel (e.g., governance-only).

  4. Upon successful verification, it invokes:

    pallet_external_validators::Pallet::<T>::set_external_validators_inner(validators, external_index)?;

  5. Finally, the updated validator set is picked up by the Session pallet during the session rotation to define the active validator set.

Example Code (Message Processor Flow)

The Substrate-side message processor might look like:

match message {
    Message::V1(InboundCommand::ReceiveValidators {
        validators,
        external_index,
    }) => {
        // Only allow messages from the primary governance channel
        if envelope.channel_id != PRIMARY_GOVERNANCE_CHANNEL {
            return Err(DispatchError::Other("Invalid channel"));
        }
        // Forward the validator set to the external validator pallet
        pallet_external_validators::Pallet::<T>::set_external_validators_inner(
            validators,
            external_index,
        )?;
        Ok(())
    }
}

And your custom validator pallet (pallet_external_validators) implements logic to store the validator set and provide it to the Session pallet.

Integrating with the Session Pallet

To use this validator set for consensus, your chain's Session pallet must be configured to pull validators from the pallet_external_validators:

impl pallet_session::Config for Runtime {
    type ValidatorId = AccountId;
    type ValidatorIdOf = ExternalValidators;
    // ...
}

Where ExternalValidators is a struct that implements:

impl pallet_session::SessionManager<AccountId> for ExternalValidators {
    fn new_session(index: SessionIndex) -> Option<Vec<AccountId>> {
        Some(pallet_external_validators::Pallet::<Runtime>::current_validators())
    }
    // ...
}

This ensures that each session rotation reflects the validator set as provided by Ethereum through the bridge.

2. Reward Distribution via ERC20 Tokens on Ethereum

In addition to validator selection, another critical part of the integration is the reward distribution mechanism. Validators on your Substrate blockchain will expect rewards for their work, but since you want to use ERC20 tokens on Ethereum for liquidity, the rewards need to be sent from Substrate to Ethereum.

To achieve this, you’ll modify the reward distribution logic in Substrate, specifically in the Staking Pallet.

2.1. Modify the Staking Pallet to Send Rewards

In our design, validators do all their work on the Substrate-based blockchain — but the rewards are paid in ERC-20 tokens on Ethereum. To achieve this, the staking pallet itself sends reward information as a message to Ethereum using a trustless outbound messaging channel (e.g., via Snowbridge).

How it Works

At the end of each era:

  1. The pallet calculates reward points earned by each validator.

  2. A Merkle root is created from the list of (ValidatorId, Points) pairs.

  3. A cross-chain Command::ReportRewards message is constructed, containing:

    • The Merkle root.

    • Total rewardable points.

    • Total token supply (inflation) to be distributed.

    • Era index.

    • The external validator set index (from Ethereum).

  4. This message is sent over the governance bridge channel to Ethereum.

  5. On Ethereum, the message is validated and used to distribute ERC-20 rewards directly to participating validators via Merkle proof claims.

This ensures:

  • Rewards are minted once per era on Substrate into a sovereign account.

  • No tokens are transferred cross-chain — only the message and proof data move.

  • Ethereum remains the canonical source of rewards and staking state.

let command = Command::ReportRewards {
    external_idx: T::ExternalIndexProvider::get_external_index(),
    era_index,
    total_points: utils.total_points,
    tokens_inflated,
    rewards_merkle_root: utils.rewards_merkle_root,
    token_id,
};

let outbound_message = Message {
    id: None,
    channel_id,
    command: command.clone(),
};

// Validate and send the message to Ethereum
match T::ValidateMessage::validate(&outbound_message) {
    Ok((ticket, _fee)) => {
        T::OutboundQueue::deliver(ticket)?;
        Self::deposit_event(Event::RewardsMessageSent {
            message_id,
            rewards_command: command,
        });
}

3. Verifying Validator Selection on Ethereum Using BEEFY

In our architecture, Ethereum validators opt-in via EigenLayer to validate our Substrate-based L1. However, the validator set and their actions (e.g., producing blocks, accumulating points) occur on the Substrate side. To make Ethereum aware of who the active validators are — and more importantly, to trust that these validators were correctly selected and operated on a finalized chain — we use BEEFY and an on-chain light client.

This means:

  • The validator selection message originates from Substrate.

  • But the verification of that message's validity happens on Ethereum, using BEEFY finality and Merkle proofs.

  • This enables Ethereum smart contracts to trustlessly accept messages from the Substrate chain, such as reward reports or validator participation updates.

Let’s break this down.

BEEFY Finality Verification on Ethereum

At the heart of this process is a BEEFY light client implemented in Solidity. This light client maintains:

  • The latest finalized block roots of the Substrate chain.

  • The MMR (Merkle Mountain Range) root used to verify historical validator-set messages.

When a reward message or validator update is submitted to Ethereum:

  1. It must reference a finalized Substrate block hash, attested by BEEFY validators.

  2. A Merkle proof is included that proves the message was part of the state of that finalized block.

  3. The BeefyClient contract on Ethereum verifies this using:

    • The validator signature set from BEEFY.

    • The MMR root representing the BEEFY consensus state.

    • A proof that links the message to the finalized block.

This allows Ethereum to confirm:
✅ “Yes, this message was part of a valid and finalized Substrate block.”

Why This Matters

  • Validator selection is completely trustless: Ethereum validators can be sure the data about who did what (and who gets rewards) is accurate and tamper-proof.

  • No need to track every Substrate block: Thanks to BEEFY’s finality + MMR model, Ethereum only needs sparse updates.

  • Smart contracts enforce consensus rules: Even malicious relayers can’t inject false data, as the Solidity client will reject messages that fail verification.

Conclusion

By integrating EigenLayer's AVS into a Substrate-based blockchain, you can attract Ethereum validators while keeping the liquidity and user base on Ethereum. The process involves integrating the Session pallet for validator selection, utilizing off-chain workers for ERC20 token distribution, and verifying the BEFFY signatures for validator validation.

With this approach, your new blockchain can benefit from the security and validator network of Ethereum, while keeping the token economy within the Ethereum ecosystem for maximum liquidity.

This architecture not only enhances security but also positions your project to tap into Ethereum’s vast liquidity, giving your blockchain an initial advantage when attracting users and validators.

Comments

Post a Comment

Popular posts from this blog

Proof of solvency and collateral

Image
Centralized exchanges (CEXs) are a critical part of the cryptocurrency ecosystem, but they also pose a significant risk to users. In the event of a hack or bankruptcy, users can lose all of their funds. One way to mitigate this risk is to require CEXs to provide regular proof of solvency. Proof of solvency is a way for CEXs to demonstrate that they have enough assets to cover all of their user deposits. There are a number of different ways to implement proof of solvency. One simple approach is for CEXs to simply publish a list of all of their addresses and the corresponding balances. This approach is transparent and easy to verify, but it does not provide any privacy for users. Zero-knowledge Proofs A more secure approach would be for CEXes to use zero-knowledge proofs (ZKPs) to prove their solvency. ZKPs allow exchanges to prove that they have a certain amount of assets without revealing any other information about their balance sheets. This would make it much more difficult fo...
Read more

Deep dive into Elliptic Curve Signatures

Image
To popular demand, I have decided to try and explain how the ECDSA algorithm works. We've discussed a bit eliptic curve signatures before and a little bit more afte that , but it seems it's never enough. Admitedly, I've been struggling a bit to understand it properly and while I found a lot of documentation about it, I haven't really found any ECDSA for newbies anywhere. So I thought it would be good to explain in simple terms how it works so others can understand it better. Let's give it a stab ECDSA stands for Elliptic Curve Digital Signature Algorithm and it's used to create a digital signature of data (a file for example) in order to allow you to verify its authenticity, without compromising its security. Think of it like a real signature, you can recognize someone's signature, but you can't forge it without others knowing. The ECDSA algorithm is basically all about mathematics. But these maths are fairly complicated, so while I'l...
Read more

Zero-Knowledge Proofs with Circom and Noir

Image
Zero-knowledge proofs (ZKPs) are a powerful cryptographic tool that allow you to prove that something is true without revealing any additional information. ZKPs are finding a wide range of applications in blockchain, including privacy-preserving transactions, scaling solutions, and decentralized gaming. In the previous article, we've discussed about some of the fundamentals behind SNARKs and STARKs , so make sure to read those if you want more details behind the tech. ZKP Languages One of the most important components of a ZKP is the circuit. A circuit is a mathematical representation of the computation that is being performed by the ZKP. Circuits are typically written in a specialized language, such as Circom or Noir. Circom is a circuit description language that is developed by the Zcash project. It is a powerful and flexible language that allows users to write circuits for a wide range of applications. However, Circom can be difficult to learn and use, and it requires a ...
Read more