Frostgate: A ZK-Agnostic Modular Architecture for Trustless Interoperability

Frostgate proposes a new architecture for cross-chain interoperability, one that does not rely on light clients, centralized bridges, or multisig committees, instead, it offers a modular, verifiable system for message passing across blockchains, primarily grounded in cryptographic soundness and composable design.

At it’s core, Frostgate fuses Succint State Validation (SSV), zero-knowledge proofs and chain abstraction for a fully programmable and extensible interop stack that any chain, valid proving system, or application can adopt, all without compromising decentralisation.

Modular by Construction
Frostgate breaks down interoperability into well-defined and composable components:

1. ICAP (Interoperable Chain Abstraction Protocol): ICAP defines how ChainAdapters expose chain-specific logic to Frostgate. It abstracts key components of participating chains, including, finality rules (Ethereum’s FFG, BEEFY, Solana’s voting), event log formats, message encoding and decoding, along with chain-specific light validation (without relying on state replays or full nodes).

Adapters implement a shared trait ChainAdpater and output a unfied FrostMessage structure. This design benefits Frostgate’s architecture as it means new chains can be supported independently, by communites, not centralised bridge operators.

1. ZKPlug, Frostgate’s zk-Agnostic Backend Interface: Frostgate isn’t tied to a single proving system, instead, the ZKPlug trait defined how zero-knowledge backends
2. Load and compile circuits
3. Generate state proofs from messages
4. Verify proofs succintly on-chain The current implementation integrated SP1 zkVM, but this design fully supports pluggable backends, including RiscZero, Halo2 or Groth16, with minimal overhead. Chains or apps can select backends based on trust model, performance, or cost, which in turn enables ecosystem flexibility.

Message Flow: How Data Moves Trustlessly
Here’s how Frostgate handles cross-chain event propagation:

1. Emit: A finalized event occurs on Chain A, processed by a ChainAdapter
2. Normalize: The adapter converts this into a standardised FrostMessage
3. Prove: A prover bundles messages into a batch and generates a succint zk proof attesting to correctness.
4. Relay: A relayer submits the batch and proof to the target chain (Chain B)
5. Veify: A smart contract on the destination, Chain B verifies the zk proof on-chain and processes the message.

ZK proofs are tradtionally expensive by nature, so Frostgate employs batch proofs to aggregate messages into a single succint proof. All actors are stateless, all assumptions are cryptographically-based, no chain replication or state replay is required and no multi-signature committes are required for central coordination.

Security without Multisigs
Multisigs practically introduces centralisation, failure points, and governance complexity. Frostgate bypasses this entirely by
Relying on native chain finality (via adapter enforcement)

• Leveraging zk-proof soundness for message correctness
• Using proving key attestation to prevent circuit forgery
• Enabling proof-level replay protection through batch nounces (IDs) and timestamps

With this approach, Frostgate’s security should practically scale with the source chain’s consensus, not with off-chain signers.

Governance and Registry Deisgn
Frostgate’s modularity allows anyone to implement new components that would extend it’s functionality, but trustless interoperability needs standards. To tackle this, Frostgate introdces a Registry Layer.
With our current design, anyone can submit a new adapter or plug in a new zk backend, thus each sumission must be verification-gated, this means:

• Each submission must pass determinsitic conformance tests.
• Match zk circuit constraints and output schema
• Provide proving/verifying key hashes or attesation
• All protocol spec changes are handled via a Git-based workflows with lightweight DAO-ready extensions for full transparency Our goal is to avoid gatekeeping, just testable and verifiable compliance.

Actor Roles in the Ecosystem
Frostgate defines three distinct roles in it’s ecosystem:

1. Provers: Provers are repsonsible for generating zk-proofs off-chain for message batches. Provers are incentivized for correct proof provision.
2. Relayes: Relayers are responsible for monitoring source chains, transporting proofs and messages to the target chains. Relayers can be somewhat regarded to as messengers for the Frostgate ecosystem.
3. Verifier: Verifiers are on-chain contracts repsonsible for validating zk proofs and executing the payloads from the coresponding source chain.

All roles are stateless and interchangable, thus any actor can spin up roles without permission or staking. Incentives are provided for these actors (fees paid by message senders should cover gas costs on the destination chain and incentives for the paritipating actors), however this protocol remains open by design.

Final Thoughts
Frostgate aims to not be just another interoperability bridge. It’s a reimaging of what cross-chain messaging could look like when verifiability, modularity and decentralisation are first principles, not afterthoughts.

By separating consensus replication from interoperability, and replacing trust with proof, Frostgate offers a desgin that’s lean, extensible and ready for a multi-chain future.

No light clients. No multisigs. No committees.
Just math, messages and modularity.