# Ethereum to Supra Security

SupraNova is designed not just for operational efficiency, but also for deep, protocol-level security through its modular components like HyperNovaCore, Relayers, and Committee Updates. It actively addresses several major risk factors that traditional bridges often fail to solve.

Each component plays a distinct role in minimizing attack surface, validating cryptographic proofs, and to maintain liveness under adversarial conditions.

### Long-Range Attack Risks

A potential vulnerability in trustless bridges using the Sync Committee model is the possibility of a long-range attack:

* A malicious Sync Committee could collude to forge signatures on a fake block.
* If unchecked, this could allow them to fool external chains like Supra into believing invalid transactions are real.

#### **Protocol Response:**

* SupraNova requires more than 90% of Sync Committee members to sign a block for it to be considered valid.
* Even if signatures are forged, the fork would not be accepted unless justified by Ethereum’s fork choice rule(LMD-Ghost).
* The probability of randomly selecting a colluding majority is astronomically low (studied by [Succinct](https://www.gnosis.io/blog/succincts-ethereum-zk-light-client-and-the-road-to-trust-minimzed-bridges-with-hashi), Snowfork, [T3rn](https://www.t3rn.io/blog/exploring-eths-altair-light-client-protocol-t3rns-vision), etc.).
* Even if a malicious Sync Committee existed, they could not fork Ethereum itself ,  only mislead a bridge verifier if the bridge does not validate correctly.
* HyperNovaCore on-chain verifier checks proof authenticity and threshold participation before accepting any event.

#### **Security Insight:** 

* **Ethereum’s primary consensus remains intact even if a Sync Committee misbehaves.** 
* **SupraNova’s HyperNovaCore piggybacks on Ethereum’s finality guarantees by verifying Sync Committee signatures and ancestry root on-chain.** 

***

### Liveness Threats: Missing Sync Committee Signatures

Sometimes, an Ethereum block may have:

* Very low Sync Committee participation
* No signatures at all
* Delay in event availability

This could disrupt timely proof verification.

#### **Protocol Response:**

* If the bridge event’s block lacks signatures, Relayers submit Ancestry Proofs; to trace back to a recent block that is signed with more than the threshold number of Sync Committee members. HyperNovaCore validates them to maintain liveness.
* Supra’s verifier can validate bridge events indirectly through a valid child block, maintaining liveness even during Ethereum anomalies.

#### Relayer Safety: What if Relayers Misbehave?

* The relayer is permissionless.
* Anyone can pick up events and submit proofs.

#### **Possible issues:**

* A relayer could submit incomplete proofs
* A relayer could submit tampered proofs

#### **Protocol Response:**

* The on-chain HyperNovaCore verifier rejects any invalid or incomplete submission. No service level bridge minting of assets can occur unless full proof validation passes on-chain.
* Invalid proofs are rejected;at worst, relayers incur gas cost without affecting protocol state.
* Relayer rewards are structured such that relayers have economic incentives to behave correctly, but even if they don’t behave correctly no safety violation can happen

#### Committee Updater Safety

* Ethereum’s Sync Committee rotates every \~27 hours.

#### **If the public keys are not updated on Supra:**

* New blocks cannot be verified
* Bridge operations stall
* This would also prevent the verifier from recognizing new finalized blocks, effectively pausing new bridge actions.

#### **Protocol Response:**

* Committee Updaters are funded through protocol-collected fees and operate independently to refresh Sync Committee public keys on Supra approximately every 27 hours. 
* This automation maintains decentralization and system continuity.
* If an updater becomes inactive, others can be permissionlessly added to resume key publishing and restore liveness.

***

### Summary of Security Layers

| Threat                    | Mitigation Mechanism                              |
| ------------------------- | ------------------------------------------------- |
| Long-range attacks        | High signature threshold (>90% required)          |
| Missing signatures        | Ancestry Proofs fallback                          |
| Malicious relayers        | On-chain proof validation rejects bad submissions |
| Stale Sync Committee Keys | Permissionless Committee Updater mechanism        |


---

# Agent Instructions: 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:

```
GET https://supraoracles.gitbook.io/supra/supranova/ethereum-to-supra-security.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.