SEDA Verification Modules are built to plug into any existing interop provider, upgrading security models with specialized verification available for all routes.
2025 is the year of Interop 3.0, the next chapter for interoperability. As more blockchains are deployed, interoperability providers must scale in parallel to reduce asset fragmentation and siloed blockchain experiences. The journey from Interop 1.0’s basic bridge models to Interop 2.0’s expanded cross-chain token standards and various bridge designs has arrived at Interop 3.0, the emergence of dedicated verification modules powering Interop security for all routes.
Web3’s lightning-speed development has rendered the current default verification used in interoperability outdated. Demand for interoperability will only increase in 2025 as deploying blockchains becomes easier and more specialized chains, such as app chains, are deployed. To effectively serve the industry, interoperability has begun to modularise tech stacks, decoupling verification. This has opened up a new market for dedicated verification projects, like SEDA, to plug hyper-specialized secure verification modules into existing interop stacks.
This article will explore how SEDA’s Verification Modules are bringing the needed upgrade for interoperability, making them available for all routes across any VM.
Understanding Current Message Bridge Verification Models
Common Message Bridge Flow
Cross-chain asset transfers require third-party infrastructure because blockchains cannot natively communicate outside their execution environments. Using a lock-and-mint bridge, users can transfer assets by locking tokens on the origin chain and minting equivalent tokens on the destination chain, enabling seamless cross-chain transactions. Although various bridge designs exist, this article will focus on a standard message bridge framework using a lock-and-mint process.
Scenario: You want to bridge $100 USDC on Chain A to your address on Chain B
When a user initiates the swap, their $100 USDC is locked in a bridge contract on Chain A, and a software called a relayer sends a message to Chain B to mint $100 USDC and transfer it to the user’s destination address.
Common Message Bridge Security Stacks
In this model, a relayer transports the message “User has locked their funds on Chain A” to Chain B, where assets can be minted and sent to the user, facilitating the transaction across two chains. In this system, new tokens cannot be minted on the destination chain until the message with verification is received on the destination Chain (Chain B).
The modularization of interoperability stacks is decoupling two primary components.
- The Message Relayer
- The Message Verifiers
The Relayer is responsible for transporting the message between Chain A and Chain B. The Verifier is responsible for issuing proof that the user funds were locked on Chain A. Without verification, a message could be hacked to say a user’s funds were locked, even if they weren’t, allowing a malicious actor to mint tokens on a destination chain without locking on an origin chain.
Common Verification Models Use With Multi-sigs (Multiple Signatures)
Scenario: You want to bridge $100 USDC on Chain A to your address on Chain B
When a user initiates the swap, their $100 USDC is locked in a bridge contract on Chain A, and a software called a relayer sends a message to Chain B to mint $100 USDC and transfer it to the user’s destination address.
Common Message Bridge Security Stacks
In this model, a relayer transports the message “User has locked their funds on Chain A” to Chain B, where assets can be minted and sent to the user, facilitating the transaction across two chains. In this system, new tokens cannot be minted on the destination chain until the message with verification is received on the destination Chain (Chain B).
The modularization of interoperability stacks is decoupling two primary components.
- The Message Relayer
- The Message Verifiers
The Relayer is responsible for transporting the message between Chain A and Chain B. The Verifier is responsible for issuing proof that the user funds were locked on Chain A. Without verification, a message could be hacked to say a user’s funds were locked, even if they weren’t, allowing a malicious actor to mint tokens on a destination chain without locking on an origin chain.
Common Verification Models Use With Multi-sigs (Multiple Signatures)
Each bridge setup uses slightly different verification mechanisms under various names, such as Decentralized Verifier Networks (DVNs) or Interchain Security Models (ISMs), among other variations. These verifiers are multi-sig setups. A multi-sig is a mechanism that requires one or more entities to sign a transaction stating that an event occurred. Multi-sigs can be 1/1 (one entity), 2/3 (two of three entities), or more. Generally, the greater the number of signers and the higher the signature threshold required, the greater the level of decentralization.
Multi-sig concerns
1/1 and 2/3 multi-sigs raise centralization concerns, creating situations where the interop provider is responsible for verifying their messages. Additional concerns include downtime when a verifier goes offline, halting the bridge operations, and collusion, where multi-sigs can be hacked or bribed to act maliciously.
Down Time: Occurs when a verifier goes offline due to unexpected traffic, halting the bridge’s function and freezing transactions.
Collusion: When private key owners work together or hackers gain majority control of a multi-sig and sign malicious messages, resulting in attacks such as an “infinite mint” of tokens on a destination chain.
It is necessary to state that leading interoperability providers have made an increasing number of non-protocol-managed verifiers available to app builders. However, the data suggests that over 70% of apps opt for default, protocol-managed multi-sigs.
You can read more about the complexities of deploying custom verifier stacks of multiple multi-sig setups here:
Scaling Interop Verification Across Any Route, All VMs.
Decentralized Validator Verification
There are other verification systems beyond multi-sigs, such as dedicated validator sets similar to the Guardian Network within the Wormhole setup. However, these sets require a slow expansion to new networks where whole validator sets must update endpoints, among other things.
SEDA’s Interoperability Verification Modules | A Standard For Secure Verification Across All Routes
Current monthly bridging volumes are around
per month and rising. With interoperability PMF firmly secured in the blockchain industry, it’s the perfect moment for providers to decouple their default multi-sig models and integrate robust, hyper-specialized verification by SEDA. By modularizing the stack and collaborating, SEDA and interoperability providers will ensure bridges and solver networks can securely scale their services to every route.
Comparing SEDA Verification To Multi-Sig Setups
SEDA Overlay
Compared to a typical multi-sig where 1 to 3 entities are responsible for signing proof of transaction state to issue verification messages, SEDA leverages a decentralized Overlay Node Network built to eventually run 10s of thousands of non-protocol managed nodes. Overlay Compute Nodes form secret committees that query a range of public and private Chain RPC data providers to return transaction state results to SEDA’s main chain.
Overlay nodes drastically reduce the possibility of collusion and downtime experienced by multi-sigs. If a subset of specific nodes were to go down during a specific data request, idle nodes are able to step in and replace them. While it is theoretically much more likely to gain majority control over a multi-sig with 1 to 3 keys, hackers would need to gain control of more than 50% of the entire SEDA main chain and overlay node network before being able to manipulate verification proofs issued to destination chains. By combining SEDA Verification with current multi-sigs, where SEDA is a mandatory signer, app security is hugely improved.
Note: SEDA v1.0 will not form secret committees but rather a set of Overlay Nodes run by professional main chain node operators.
SEDA Main Chain
All data results are batched on the main chain and encrypted with cryptographic proofs signed by the main chain validators. This ensures that Solvers relaying verification proofs to destination chains cannot manipulate the data during the process, adding further protection and security to verification via SEDA.
SEDA Modules | Leading The Emerging Verification Market
SEDA Verification Modules are not only the most secure option for verification but also provide additional benefits, such as customization, scalability to any route, and verification for all tokens.
Customization
SEDA is a fully programmable Oracle infrastructure that allows protocols integrating verification modules to add configuration to their modules. As each chain, ecosystem, and bridge model has variations, SEDA Modules can be programmed to suit the bridge needs for whatever route. This may include data validity, time constraints, or various RPC endpoints.
Scale To Any Route
SEDA Verification can verify the state on any chain as long as there is a SEDA prover contract and an available RPC to query. Prover contracts are permissionless to deploy and will be made available in any blockchain language, empowering networks and interop to deploy provers where they want to service them on day one.
Verification For All Tokens
SEDA can query any data type from any source, ensuring bridge providers can program verification through SEDA to any token on any chain. While current verification is capped at around 320 routes and 11 tokens, SEDA’s design for horizontal scalability and a data-agnostic environment allows bridges to support any route for all token pairs.
Learn More
SEDA Scaling Verification To Any Route:
