Permissionless BEEFY Proofs

[dharjeezy]

Currently, Tesseract's BEEFY prover generates consensus proofs (ZK/Naive/FiatShamir) and the BEEFY host submits them on-chain to destination EVM chains for all finalized messages. This means Hyperbridge bears the full cost of proof generation submission and gas fees for every message batch, regardless of which application originated the messages.

This approach doesn't scale well as message volume grows across more chains and applications.

1. Index consensus proofs : Continue generating consensus proofs via the BEEFY prover, but instead of submitting them on-chain immediately, store and index them in a publicly queryable service (e.g., a DB or storage layer). Proofs would be indexed by block range, state machine, and validator set ID.

2. Let applications submit consensus proofs for their own messages : Applications that need their cross-chain messages delivered would query the proof index, fetch the relevant consensus proof covering their message range, and submit it on-chain themselves.

Motivation

• Cost reduction: Hyperbridge no longer pays gas for submitting every consensus proof on-chain
• Scalability: Proof submission scales naturally with application demand rather than requiring Hyperbridge to keep up with all message volume
• Decentralization: Removes Hyperbridge as a bottleneck in the message delivery path, any application (or user) can submit proofs independently

[seunlanlege]

We're pivoting to instead indexing the proofs onchain (technically proof data will be stored in offchain db). Allowing anyone produce proofs of newly finalized messages & authority set rotations. The role will be fully incentivized

[seunlanlege]

This is completed