A Tale of Cross-Chain Verification

Special Thanks to
Matt, Peter, Jasper and Mario from SEDA team, &
Nam, Paul from Hyperlane team for a detailed review & feedback on the articles.

The cross-chain world is evolving faster than you think.

We have now officially entered the era of Interop 3.0.

An era of modular stacks and abstracted apps.

An era where we improve our existing interop stacks with chain abstraction, intent-solver systems, and modular stacks — and let builders build secure omnichain apps.

But there is something wrong with the way we build cross-chain products in this era.

There’s a critical piece of the modular stack that is often overlooked, i.e., Cross-Chain Verification.

In simple terms:

How can Chain B securely confirm and trust
an important action that occurred on Chain A?

Cross-chain verification is critical because the effectiveness of an interop system relies on:

• how quickly it can verify an action between chains - a.k.a speed
• how reliable and decentralized is the verification process - a.k.a security

In the early days of cross-chain, we overlooked the significance of verification with centralized entities, multi-sigs, and trusted relayers — and we paid the price of our ignorance with some of the largest hacks in web3 history.

But times have changed. Verification has evolved.

Verification is now customizable, programmable, and flexible.

However, there is a serious lack of awareness and development practices around verification in the modular era.

This is my effort to reignite the discussion on how to build in this modular era - specifically the verification part.

I did a deep dive into the past, present, and future of cross-chain verification — and in this article, I will cover all of it:

• The journey of cross-chain verification
• Comparison of different verification mechanisms
• Rise of Verification Specialists and Verification Marketplaces
• Deep-Dive into a Verification Specialist - SEDA's IVMs

By the end, you will understand:

verification is no longer an afterthought —
it’s a cornerstone of scalable, trust-minimized cross-chain communication.

And, the protocols or builders that fail to understand this will be left behind.

Let's get started.

Journey of Cross-Chain Verification

1. Trust-Based Cross-Chain Verification Models

Before modular interoperability became the norm, early cross-chain verification models were monolithic and tightly coupled with specific bridge designs.

These bridges relied on centralized/trusted entities for cross-chain verification such as:

1.1 Trusted Validators / Relayers

• A group of trusted validators (often controlled by the bridge’s team) monitored Chain A for specific events. Once an event occurred, the validators relayed the information to Chain B, triggering an equivalent action.
• Some systems added further modification of imposing a bond mechanism where validators/relayers must stake some bond which can be slashed if the actor behaves maliciously.

Examples: Binance Bridge, Trusted Wardens of Avalanche Bridge

1.2 Multi-Signature (Multi-Sig) Bridges

• Instead of a single trusted validator, cross-chain verification was handled by a group of pre-selected signers ( a.k.a - Multisig signer ). A transaction on Chain A required M-of-N signers (e.g., 3 out of 5 signers) to confirm before being relayed to Chain B.

Examples: Wormhole’s Guardians, PolyNetwork Bridge, etc

While these models provided cross-chain asset movement, they had some obvious security trade-offs like centralized control, liveness risks, and collision risks.

As a result, we witnessed some of the largest exploits in web3 exposing their vulnerabilities:

• PolyNetwork Hack (2021) – $600M stolen due to a compromised multi-sig.
• Multichain Hack (2023) – $125M stolen due to private key compromise.
• And many others

2.Rise of Trustless & Optimistic Verification Models

As cross-chain transactions grew, users demanded more trustless models.

With trustless verification models, interoperability stacks moved towards cryptographic primitives to validate cross-chain actions instead of trusting centralized actors to behave honestly.

We shifted from trusting humans to trusting code.

At this point, the industry realized that in a cross-chain world, trust is a spectrum.

We saw the rise of some crucial verification mechanisms during this era:

2.1 Light Client Verification

• A light client of Chain A was deployed on Chain B, allowing the smart contract on Chain B to verify events from Chain A without third-party intermediaries.
• These blockchain clients do not store the entire blockchain but instead maintain a minimal amount of data necessary to verify transactions. They rely on full nodes for the complete blockchain data but can independently verify the validity of transactions and blocks using cryptographic proofs.

Examples: Cosmos IBC

2.2 Optimistic Relayers & Fraud Proofs

Instead of instantly accepting cross-chain messages, an optimistic approach assumes messages are valid but provides a dispute period where anyone can submit fraud-proof.

Examples: Hop Protocol (Ethereum L2s), Connext Amarok (xCall Standard)

2.3 ZK Proofs

• Zero-knowledge proofs are cryptographic methods that allow one party to prove to another that a statement is true without revealing any specific information about the statement itself.
• In the context of proving actions from Chain A to Chain B, ZK Proofs enable solvers/relayers to demonstrate that a transaction or action occurred on Chain A without disclosing the details of that transaction.

3.Customizable Verification in the Modular Era

First things first, if you have no clue what Modular Interoperability Thesis is, read the primer 👇

By 2022, the modular interoperability thesis gained traction, leading to verification mechanisms that are more customizable and secure.

A key advantage of this modular approach is that applications can now optimize verification based on their specific needs—whether prioritizing security, speed, or cost.

Most modern interoperability protocols now integrate customizable verification models into their stack.

Mentioned below are some of the most significant advancements of this era:

3.1 Decentralized Verifier Networks (DVNs) – LayerZero

• LayerZero V2 introduced Decentralized Verifier Networks (DVNs) to eliminate vendor lock-in at the security level. This approach allows applications to mix and match different verification methods—including zero-knowledge proofs, multi-sig models, and native bridges —into their security stack.
• Each DVN consists of a set of verifiers that collectively verify cross-chain data packets. Instead of relying on a single verification method, LayerZero’s modular design lets developers configure their security model dynamically.

3.2 Interchain Security Modules (ISMs) – Hyperlane

• Hyperlane’s Interchain Security Modules (ISMs) represent another modular approach to verification, offering developers full control over their security configuration.
• Hyperlane’s Mailboxes act as on-chain APIs for sending and receiving messages across chains, while ISMs govern how those messages are verified.
• A Multisig ISM could be configured with validators sourced from the application’s community. A Composed ISM could combine Hyperplane’s default multisig with verification from Wormhole’s validator set for extra security.
• For instance:
  • An interesting use case can already be seen with OpenUSDT, an interoperable version of Tether’s USDT designed for the Optimism Superchain, which relies on Hyperlane’s ISMs for security customization.
  • Hyperlane’s modular security design is what enables compatibility with evolving verification methods, such as Chainlink CCIP and upcoming native Superchain interoperability frameworks. good times.

3.3 Axelar's Amplifier

• Axelar is another example that provides customizable verification schemes via Amplifier.

Comparison of Cross-Chain Verification Mechanisms

While every verification technique in the comparison table has its strengths and weaknesses, modular verification unlocks a new paradigm.

With modular verification, developers can now mix and match verification layers, choosing security, speed, and cost parameters that fit their needs. Frameworks like DVNs, and ISMs enable this flexibility, moving beyond rigid, one-size-fits-all models.

I bet this is what the future is going to look like 👇

modular systems with
customizable & programmable verification layers.

But I won’t just make that claim without backing it up.

Let me dive into why:

• customizable verification is inevitable, and
• why verification marketplaces are poised for exponential growth.

Modularization Creates Specialists

The rise of modular interoperability has specialized each component, allowing protocols to excel at one function rather than being forced to handle everything.

Instead of a single entity managing all aspects of interoperability, today’s modular stack consists of multiple protocols working together, each specializing in what they offer.

This shift has not just improved security and efficiency but also allowed customization, where applications can select the best solutions for their specific needs.

This can already be seen in different stacks of interoperability architectures:

1. User Intent Settlement Specialists
   1. Across: An intent settlement specialist that supports the settlement of any cross-chain intent ( provided that it's recognized by Across’s SpokePools ). It provides an optimistic verification method using UMA's Optimistic Oracle and also provides solver’s cross-chain inventory management repaying solvers on their choice of chains.
   2. Everclear: Aims to provide infra for efficient and fast settlement of solvers using a netting mechanism
2. Solver Coordination and Intent Fulfilment Specialists
   1. Khalani Network: A collaborative framework for solvers, addressing limitations in the traditional competitive landscape of intent-solving systems.
   2. Nomial: Designed to specifically address liquidity challenges in intent-based bridging systems. It introduces a network of cross-chain liquidity pools accessible to fillers on demand.
3. Verification Specialists
   1. Polymer:
      1. Polymer takes a different approach to verification by eliminating the need for traditional cross-chain messaging protocols. Instead of relying on third-party messaging standards, Polymer introduces proof-based interoperability, where state updates between rollups happen natively and efficiently.
      2. With its Prove API, it allows developers to generate cryptographic proofs for any event, transaction, or storage slot across rollups.
      3. The idea of proof-based verification using Polymer has already seen some early adoption by chai abstraction teams like Openfront as well as intent-based systems like  Spicenet and Epoch.
   2. SEDA IVMs:
      1. Interoperability Verification Module (IVM) is a decentralized, programmable verification framework that is designed to offer customized Oracle programs that can enable verification across all VMs to provide secure and specialized inter-chain communication.
      2. IVMs are a new framework that aims to further improve the verification game using programmability, horizontal scalability, and improved security with its existing SEDA Main chain.
      3. Unlike rigid verification models, IVMs can be tailored to fit various interoperability frameworks, allowing protocols to deploy IVMs as standalone verifiers or integrate them into existing verification models like DVNs or ISMs.

I wrote a deep dive on SEDA IVMs to better understand how it works. Check it out below 👇

Deciphering SEDA IVMs - A Verification Specialist

A guide to understanding how SEDA IVM verification mechanism works and what makes it unique.

Decipher ClubZaryab Afser

We will continue to see such specialists emerge as we move toward a modular future.

In this article, however, we shall focus on the verification specialists.

Rise of Verification Specialists and Marketplace

Unlike the early monolithic interop era, today’s modular interop stack allows verification to operate as an independent, specialized service.

The core responsibility of the verification specialists is to ensure the validity and accuracy of the data moving between chains.

This shift has given rise to a new paradigm—the Verification Marketplace.

A verification marketplace is a decentralized network of providers offering verification as a standalone service to cross-chain applications, bridges, messaging protocols, app-specific chains, etc. Rather than relying on a one-size-fits-all security model, it allows protocols to select from multiple verification options, ensuring that their security model aligns with their specific needs —a level of flexibility that was previously impossible.

For instance:

1. a cross-chain payments protocol handling frequent, low-value micro-transactions may prioritize speed and cost-efficiency over absolute security. It might choose a fast, lightweight verification mechanism.
2. On the other hand, a high-value cross-chain liquid staking protocol—where millions of dollars in assets are at stake—must prioritize security above all else, opting for cryptographic attestation through zero-knowledge proofs or multi-layer decentralized validation.

This shift is transforming verification into a marketplace of providers, each optimizing for different trade-offs such as security, speed, and cost, rather than a single, rigid mechanism dictated by the bridge or interoperability protocol itself.

There are some notable benefits of including verification specialists in an interoperability stack:

• Customizable Security Models: Developers can choose and configure the verification method that best suits their needs.
• Elimination of Vendor Lock-In: Applications are no longer forced to rely on a single security provider; they can integrate multiple verifiers (e.g., Google Cloud, Polyhedra, or community validators).
• Greater Decentralization & Fault Tolerance: Multi-source validation (e.g., ISMs combining multisig and zkProofs) reduces single points of failure and enhances network security.
• Reduced Cost & Optimized Performance: Applications can dynamically adjust their verification settings—favoring cost-efficiency, security, or speed depending on the nature of the cross-chain interaction.

Why Verification Marketplaces Matter

As cross-chain activity scales, the need for specialized and modular verification solutions becomes inevitable.

As the number of blockchains, cross-chain applications, and messaging volumes grow, a single-provider verification model cannot scale—but a marketplace where protocols can choose and switch between verifiers ensures long-term resilience.

There are a few key reasons why we will witness a rise in the Verification Marketplace:

• Scalability & Adoption – With thousands of chains live today and more being deployed, bridge providers struggle to keep up with deploying verification stacks for each new network. Verification marketplaces offer a scalable solution, allowing networks to plug into existing verification providers instead of building their infrastructure.
• Decentralization & Security – Instead of forcing protocols to trust a single provider, verification marketplaces will enable applications to select high-assurance, decentralized verifiers tailored to their specific risk profiles.
• Flexibility & Customization – Different applications have different security needs. A cross-chain gaming protocol prioritizing speed and low fees might choose a lightweight verification method, while a high-value staking protocol may require multi-layered cryptographic proofs. Verification marketplaces allow protocols to optimize for security, cost, or performance based on their requirements.
• Shifting Developer Priorities – Developers should focus on building applications, not securing bridge infrastructure. Verification marketplaces offload the burden of managing cross-chain security, ensuring that high-value transactions are properly verified while allowing developers to scale without security trade-offs.
• Adoption - There is a high demand for permissionless and open verification options that allow developers to integrate without relying on centralized providers. Many interoperability protocols are actively modularizing verification. Solutions like DVNs, ISMs, and IVMs showcase the industry’s shift toward flexible, decentralized verification layers.

Potential Hurdles for Verification Marketplaces

While verification marketplaces present a significant leap in cross-chain security, I couldn’t overlook the potential challenges that they could face:

Adoption of Verification Marketplaces

• Perhaps the biggest challenge is the adoption of decentralized verification marketplaces. Historically, developers tend to default to the easiest and most cost-effective verification option, which is why multi-sig verification still dominates the cross-chain landscape.
• Many teams opt for simpler solutions that require less research, configuration, and ongoing maintenance, even if they come with security trade-offs.

For verification specialists and the marketplace to thrive, they must solve a major coordination problem:

• How can developers easily compare security guarantees across different verifiers?
• How do verification modules ensure seamless integration without overwhelming developers with complexity?
• How do they encourage teams to move away from default verification schemes that "just work" for now?

A Lack of Dev-Friendly Approach

I currently see a lack of developer-friendly approaches to integrate modular verification layers to an interop stack — hence adoption challenges mentioned in step 1.

Most verification providers either lack developer-friendly guides or completely fail to educate builders on the significance of customized verification models.

While verification providers support the required flexibility and programmability (e.g. SEDA's IVMs) or proof-based verification (e.g. Polymer ), the developer docs aren't yet adequate and they still need to be improved to provide easy-to-follow integration guides for easy integration.

I will write more on how to improve the DevX for modular interop era.

I just want to see more cross-chain abstracted secure apps
and devs focusing on things that matter.

Wrapping it Up

The rise of modular interop and verification marketplaces marks a significant evolution in how cross-chain security is designed. Instead of relying on centralized multi-sigs or opaque verification models, protocols now have the flexibility to customize their security layers based on their unique needs.

Customizable verification solutions like LayerZero DVNs, and Hyperlane ISMs and verification specialists like SEDA's IVMs are paving the way for programmable, decentralized, and trust-minimized verification—a step forward in making cross-chain interactions more resilient.

However, adoption remains the biggest hurdle.

Developers often default to the simplest and most cost-effective verification methods, even if they introduce long-term security risks. As Web3 scales, the need for secure, modular verification stacks will only grow.

I believe the time to rethink cross-chain security is now.

If you are a developer, hear me out:

Instead of relying on legacy verification models, you must actively explore and integrate decentralized verification solutions.

With modular frameworks like DVNs, or ISMs, applications can stop trusting centralized verification and start building with programmable, scalable security—ensuring that the future of interoperability is both secure and permissionless.

Remember
Verification is no longer an afterthought —
it’s a cornerstone of scalable, trust-minimized cross-chain communication.

Check out the 2nd part of this article below, where we deep dive into one such verification specialist, i.e., SEDA IVM. 👇

Deciphering SEDA IVMs - A Verification Specialist

A guide to understanding how SEDA IVM verification mechanism works and what makes it unique.

Decipher ClubZaryab Afser

For Further Readings

1. The State of Interop ( 2025)
2. Introducing: The SEDA IVM
3. Modular Interoperability Protocols
4. LI.FI: With Bridges, Trust is a Spectrum
5. What I Talk About When I Talk About Bridges
6. Interop 3.0 - Fundamental is Built, Its Time for Application