> For the complete documentation index, see [llms.txt](https://docs.seda.xyz/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.seda.xyz/home/archvie/powering-a-permissionless-future-for-interoperability/how-seda-improves-security-and-accessibility-for-bridge-protocols.md).
# How SEDA Improves Security and Accessibility for Bridge Protocols
## 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](/home/archvie/interoperability-verification-module-ivm/interop-verification-module-for-message-based-bridge-protocols.md).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.seda.xyz/home/archvie/powering-a-permissionless-future-for-interoperability/how-seda-improves-security-and-accessibility-for-bridge-protocols.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.