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, Snowfork, T3rn, 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