Interop Verification Module for Message-Based Bridge Protocols
Last updated
Last updated
SEDA plugs into the existing interoperability frameworks providing a decentralized alternative to commonly centralized co-signers that usually manage message attestations. SEDAβs interoperability programs can be used to add a layer of decentralization to any bridge route, resulting in:
additional security
support for any token, instantly
permissionless deployments
liveness guarantees*
interoperability with any network
support for any route
The diagram below outlines an example of the flow of data and actors powering the SEDA IVM. In this framework the SEDA Network is tasked with verification of chain state and message passing from the Origin Network (e.g., Ethereum) to the target network (e.g., Solana). The Interop Program drastically improves the experience for bridge developers by removing the need for building and maintaining the Relayer and attestation piece of the stack, while reducing centralization risk.
The SEDA IVM is a customize framework that is built utilizing the SEDA Oracle Program toolkit. This programmable infrastructure allows providers to:
Define what routes are included
Define the data sources and RPCs queried
Upgrade modules to include new routes and tokens
Specify what data on source chains are required
Instruct how data is returned for consumption
Create a custom replication factor for Overlay Node secret committees
This programmability enhances IVM compatibility across all virtual machines and bridge designs. While limited customization may result in developers opting for default verification, SEDA's day-one configurability is designed to enable any provider to enhance their service with IVMs, supporting all application types. To learn more about the architecture of the SEDA Network please follow along in the Litepaper Section of our docs.
*Liveness Guarantees - ensure a system will continue to provide data, and that no single centralized entity can shut down or limit access to data. In the case of SEDA, a data request that has been submitted, with the transaction fee paid, will always reach consensus. In this context, βLiveness Guaranteeβ is a technical term and the term βguaranteeβ should not be construed as any kind of legal guarantee.