> 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/seda-overview/secure-and-trustless-verification-the-seda-ivm/seda-ivm-security.md).

# SEDA IVM Security

### **Liveness Guarantees**

<figure><img src="/files/3IQjhlQqcr2G3JFenj9z" alt=""><figcaption></figcaption></figure>

A typical Multi-Sig Setup, with inherent downtime risks.

<figure><img src="/files/CWlsoKNYa2gzjZILiSjp" alt=""><figcaption></figcaption></figure>

SEDA IVMs mitigate downtime risk with built-in liveness guarantees.

Downtime experienced by multi-sig verification models have become more prevalent as interoperability stacks are stressed and tested with increasing throughput. Compared to a multi-sig verification model, where the bridge halts when one verifier goes offline, SEDA consists of thousands of overlay nodes. In the event that some nodes were to go offline, there would theoretically be other nodes to step in. The same is true for the main chain validators. Downtime risk is effectively mitigated by operating with over 100 main chain validators and tens of thousands of overlay nodes.

### **Minimized Collusion Risk**

<figure><img src="/files/3Ee4sbkMaUc3mhM1TU36" alt=""><figcaption></figcaption></figure>

Another attack vector for multi-sig models occurs when private key owners collude or malicious actors gain control of most private keys. With control of verification, bad actors can trigger events on target chains such as infinite mints. SEDA inherits base layer security from the SEDA Main Chain built using the Cosmos SDK and PoS Consensus model. In the multi-sig model bad actors only need to comprise a few keys, as with SEDA it would require a 66% attack of the SEDA Chain to manipulate chain state data.

### Single Security Zones

<figure><img src="/files/qs3BdCDQk4cMg2QRwyDh" alt=""><figcaption></figcaption></figure>

Custom multi-sig stacks require independent configuration for each stack on each new route.

<figure><img src="/files/GKiCIllBpjQ9KKK0J9qA" alt=""><figcaption></figcaption></figure>

SEDA IVMs require a single deployment to access a single security zone across all chains and all routes.

Security zones refer to networks within an interop stack that leverages the same verifiers. Some interoperability providers offer third-party, multi-sig verifiers that allow builders to create a “verification combination stack” of multiple providers. As not all verifiers can verify across the same networks, builders must arrange different combinations to cover all the routes they may want to include. A security zone is all the routes verified by the same verifiers, and therefore, protocols operate across multiple zones when using different combinations of verifiers across chains.

SEDA mitigates the complexities and inefficiencies associated with the deployment and management of custom verification stacks by creating a single security zone wherever the permissionless SEDA Prover Contract is deployed. Where a chain has a prover, SEDA proofs can be passed. As the Prover Contract is permissionless and available in any blockchain language across any virtual machine, the SEDA security zone creates one single standard for verifying all routes.


---

# 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/seda-overview/secure-and-trustless-verification-the-seda-ivm/seda-ivm-security.md?ask=<question>&goal=<endgoal>
```

`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.
