SupraNova 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. The same design philosophy holds in both directions: the destination-chain verifier trusts no off-chain actor and re-derives validity from the source chain’s own consensus signatures. Only the consensus being verified changes, Ethereum’s Sync Committee when moving to Supra, and Supra’s committee threshold signature when moving to Ethereum.

Consensus Forgery: Long-Range Attacks and Committee Collusion

The foundational risk in any trustless bridge is a colluding validator set on the source chain signing a fraudulent block, in order to convince the destination chain that an event occurred when it did not.

• Ethereum to Supra: 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.
• Supra to Ethereum: a colluding Supra committee could produce a threshold signature over a fraudulent block in order to drain the Ethereum-side vault.

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.
• On the Supra side, committees are admitted only through a hash chain: each is authorised by a BcftQuorum signature from the committee already trusted on Ethereum, so an unauthorised committee cannot install itself, and committees older than the configured epoch tolerance are rejected.
• Supra committee collusion would already constitute a full consensus safety failure of the Supra network itself, a far larger and more visible event than a bridge-specific compromise.
• Released amounts are bounded by the vault’s actual locked balance and per-asset limits, so no forged event can move more than has genuinely been locked.
• The HyperNovaCore on-chain verifier on the destination chain checks proof authenticity and threshold participation before accepting any event.

Security Insight:

• Each chain’s primary consensus remains intact even if its bridge-facing committee misbehaves.
• SupraNova’s HyperNovaCore piggybacks on the source chain’s own finality guarantees by verifying its consensus signatures and inclusion proofs on-chain.

Liveness Threats: Missing Signatures and Unverifiable Blocks

Bridging stalls whenever the destination chain cannot verify the block that carried the event.

• Ethereum to Supra: an Ethereum block may have very low Sync Committee participation, no signatures at all, or a delay in event availability.
• Supra to Ethereum: a certificate can only be verified while the committee that signed it is registered on Ethereum and within the epoch tolerance.

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.
• No ancestry proof is needed in the Supra to Ethereum direction: the certificate names the exact block height, so there is never a wait for a later block to be signed.
• Permissionless Committee Updaters keep both verifiers current, so the window in which a block is unverifiable stays bounded.

Relayer Safety: What if Relayers Misbehave?

• The relayer is permissionless in both directions.
• 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 on the destination chain rejects any invalid or incomplete submission. No minting on Supra or asset delivery on Ethereum 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
• A stalled or absent relayer is not a safety issue either: any other relayer can pick up the same event and submit the proof.

Committee Updater Safety

Each chain’s verifier must know the current keys of the committee it is verifying:

If the public keys are not updated:

• New blocks from the source chain cannot be verified
• Bridge operations in that direction 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 the keys on both chains.
• This automation maintains decentralization and system continuity.
• The role is permissionless: if an updater becomes inactive, others can be permissionlessly added to resume key publishing and restore liveness.
• On the Ethereum side, if updates are missed for many epochs, an admin path can set the latest committee directly rather than replaying every intermediate epoch.

Message Replay Protection

A verified proof is valid evidence forever, so the same proof must not be usable twice. Each verifier records consumed messages by (source chain id, consumer, message id) and rejects any repeat, so a replayed submission cannot mint or release a second time.

Summary of Security Layers