LogoLogo
  • Overview
    • SEDA Overview
      • SEDA Primer for Key Features
        • SEDA’s Intent-Centric Framework
        • Modular Design Benefits
        • Programmable Tooling and Permissionless Development
        • Fast Settlement & Horizontally Scalable
        • Fork-less Upgrades
      • RWAs, Price Feeds, AI and More
        • Custom Data Feeds
      • SEDA Token Primer
        • Network Utilization
        • Network Participation & Chain Security
        • Network Governance
      • Introducing SEDA's Flagship Product - The IVM
        • 🌉Intro to Interop 3.0 & Emerging Verification Markets
        • Programmable Modules
        • Triggering A Verification Data Request With An IVM
        • SEDA IVM Security
        • An IVM Summary
    • SEDA Network Architecture
      • Walking Through SEDA’s Architectural Features
      • The PoS SEDA Chain
      • Oracle Programs
      • The Overlay Network
      • Decentralized Solver Network
      • SEDA’s Prover Contract
  • For Developers
    • 📈Data Requests
      • ❓What is a Data Request?
      • 🔃Data Request Life Cycle
    • 💾Building an Oracle Program
      • Price Feed Example
        • 👋Getting Started: Price Feed
        • 🧪Testing Your Oracle Program
        • 🚀Deploying Your Oracle Program
      • 🌐Fetching Open Data
      • 🔐Advanced: API-key Gated Data
    • ⚡Access Data from Any Network
      • 🔎Access from EVM Networks
        • 🔧Using SEDA in a Contract
        • 🚀Contract Deployment
      • 🔜Access from other Networks
      • 🔜Advanced: Run your own Solver
    • 🏗️Deployments
    • 👽Interoperability Verification Module (IVM)
      • 🛸Interop Verification Module for Message-Based Bridge Protocols
      • Powering Intents and Chain Abstraction with SEDA
  • For Users
    • ⭐Getting Started
      • 🏦Wallet Overview
      • ⏬Installing Cosmos Hub on Ledger
      • ⛓️Adding SEDA Chain to Keplr
      • 🌌Delegating your SEDA
        • 📨Selecting a Validator
        • 📡Delegating to a Validator
    • 👐Tools and Dashboards
      • 🌐SEDA Explorers and Dashboards
      • 🔭Third-party Explorers
      • 📶Public RPCs + APIs
    • 🔵SEDA Token Info
      • 📈Token Charts and Tracking
      • 📊Exchanges
      • 〰️SEDA Distribution Schedule
  • For Data Providers
    • Data Proxy
      • ℹ️Introduction to Data Proxy
      • 💻System Requirements
      • 🔢Operating and Running a Data Proxy
      • 🔐Advanced: API-key Gated Data
  • For Node Operators
    • 📶SEDA Chain Guide and Requirements
      • 🎬Installation and System Requirements
      • 👟Operating and Running a Node
      • 🔗Linking to an External Node
      • 🏗️Validator Onboarding
      • 🔑SEDA Keys
      • 📸Joining Testnet Using Snapshot
      • 🤝Joining Testnet Using State Sync
  • Resources
    • 🛡️Audits
      • Trail of Bits Audit Report Repo Link - March 2024
      • Sherlock Audit of SEDA Network Full Feature Launch - April 2025
  • Legal
    • Privacy Policy
    • Terms
Powered by GitBook
On this page
  • What is a Bridge Relayer?
  • Why Relayers Alone Are Not the End Game for Message-Based Bridges
  1. Learn
  2. Powering a Permissionless Future for Interoperability

How SEDA Improves Security and Accessibility for Bridge Protocols

Learn how SEDA can power interoperability protocols, add routes, networks, and tokens.

Last updated 4 months ago

What is a Bridge Relayer?

Leading interoperability protocols today typically feature a "default" subset of Relayers to pass messages between networks. These Relayers are typically centralized software run by the bridge protocol as a form of multisig, or by a single third-party entity. Relayers sit as a middleware infrastructure between contracts on the origin and destination chain. The Relayer monitors the chain state and listens for smart contract events from the origin bridge contract. When an event is triggered on the smart contract, the Message within the arbitrary payload is forwarded by the relayer to the target contract on the destination network. In the case of bridge protocols, this arbitrary payload contains the target network, receiving address, token, amount, and sometimes other information.

Why Relayers Alone Are Not the End Game for Message-Based Bridges

Centralized relayers hold all of the power in this dynamic and are responsible for forwarding a user's message between networks. If the Relayer acts maliciously, it could forward incorrect messages, potentially leading to funds being sent to an unauthorized address, or worse create an infinite mint of an asset.

Current efforts to enhance security to Relayers involve (in most cases) a subset of co-signers to choose from that would attest to a Relayer's message being valid. In practice, this creates a bottleneck for adding new chain support (need co-signers to support new networks manually), and creates security risks as many protocols opt for a signer's set of 3 or 5 co-signers. Most developers just accept the default option provided by the message protocol.

With the interoperability space growing rapidly and over $250 billion in volume annually, this attack vector is growing every day. To learn more about how SEDA is increasing security and accessibility for interoperability, please check out .

this section next