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).
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
Last updated