Modular Relayer Architecture

SupraNova’s architecture relies on a relayer framework built using a modular design that separates concerns for better scalability and resilience. The same framework serves both bridging directions, with each subsystem pointed at the opposite chain. Operators may run one direction, or both.

1. Event Listener:

• Monitors the source chain for HyperNovaCore bridge events.
• Pushes detected events into a secure message queue.

2. Relayer Driver:

• Consumes events from the queue and builds full proof bundles.
• Packages the proof bundle into a transaction and submits it to the destination chain’s HyperNovaCore verifier contract.

3. Committee Updater:

• Independently monitors the source chain to keep its consensus keys current on the destination chain.

This Modular flow allows any actor to permissionlessly run relayers, increasing redundancy and system liveness.

Relayer and Committee Updater in SupraNova

The SupraNova bridge architecture relies on off-chain actors to maintain a permissionless, decentralized, and verifiable flow of events and proofs.

There are two critical off-chain roles:

• Relayer: Responsible for monitoring source-chain events, generating the necessary proofs and submitting them to the destination-chain service contracts along with the event.
• Committee Updater: Responsible for refreshing the source chain’s consensus keys on the destination chain, so that new proofs remain verifiable.

Both are incentivized economically through SupraNova’s fee model to perform their tasks reliably.

Relayer Architecture

The Relayer is a permissionless component made up of modular subsystems.

Ethereum to Supra

Event Listener

• Connects to an Ethereum node.
• Subscribes to bridge-related event logs (filtered by contract address and event topics).
• On event detection, publish it to a message queue.

Relayer Driver

• Consumes events from the message queue.
• Uses the Ethereum fullnode RPC APIs to:

1. Fetch block headers
2. Fetch full transaction and receipt data

Then it constructs a proof bundle which includes:

1. Sync Committee signature aggregate
2. Receipt inclusion proof
3. Ancestry Proof

Transaction Sender

• Builds a bridge request transaction.
• Attaches the full proof bundle as calldata.
• Submits the transaction to Supra’s HyperNovaCore verifier smart contract.

Supra to Ethereum

Committee Updater Architecture

The Committee Updater makes sure that each chain’s verifier can always validate the other chain’s blocks against the current consensus keys.

Ethereum to Supra: Sync Committee Keys on Supra

Every 27 hours (approximately 8192 slots):

• Ethereum’s Beacon Chain rotates its Sync Committee members.
• Their aggregate public key and 512 public keys set must be updated on Supra.

Tasks of the Committee Updater:

• Monitor Ethereum’s finalized epochs.
• When a new Sync Committee becomes active:

1. Fetch the new sync committee public keys.
2. Submit an on-chain transaction to update Supra’s trusted keys inside HyperNovaCore.

Supra to Ethereum: Supra Committee Keys on Ethereum

Supra’s active committee rotates at epoch boundaries, and the permissionless Committee Updater registers each new committee on Ethereum:

• The updater submits a Committee Authorization Certificate together with the full new committee. HyperNovaCore recomputes the committee hash from the submitted committee and requires it to match the hash inside the certificate, then verifies the certificate’s signature against the current committee’s BcftQuorum threshold key.
• This forms a hash chain of committees: each committee is admitted only by a signature from the committee already trusted on Ethereum, anchored at the genesis committee installed at deployment.
• The new committee’s epoch must be strictly greater than the latest known epoch, so stale or replayed committee updates cannot roll the verifier backwards.
• Only the BcftQuorum and ClanMajority threshold keys are retained in storage, since those are the only two used in verification. A committee that does not supply both is rejected.
• The updater is reimbursed the configured committee-update reward cr in ETH from fees collected on Ethereum, which is what makes the role economically self-sustaining and permissionless.
• An admin path exists to set the latest committee directly. It is used to install the first committee, and as a recovery mechanism if committee updates have been missed for many epochs, so that the verifier can jump straight to the current epoch instead of replaying every intermediate one.

Rewards and Incentives

Both rewards are settled atomically inside the operator’s own transaction. There is no periodic treasury disbursal to wait on.

Without these actors:

• No proof would be submitted.
• No committee keys would update.
• Bridge verification would halt.

SupraNova keeps liveness and decentralization by rewarding these permissionless participants

Failure Handling

Thus, the system is resilient and non-reliant on any single actor. The two directions also fail independently: an issue with one path does not stop the other from operating.