Solana Bridge: High-Throughput Bidirectional Cross-Chain Liquidity

This paper details the technical specifications of the ZERA-Solana Liquidity Bridge, exploring how ZERA's consensus integrates with Solana's high-speed state machine for instant asset transfers.

1. Relayer Architecture

To establish high-speed communications between ZERA and Solana, the bridge relies on a network of bidirectional validator relayers:

+------------------+                   +------------------+
|                  |  State Proofs     |                  |
|  ZERA Consensus  | ----------------> |  Relayer Network  |
|                  |                   |  (3/4 Consensus)  |
+------------------+                   +------------------+
         ^                                       |
         |                                       v
         | State Updates                +------------------+
         +----------------------------- |  Solana Program  |
                                        |  (Seahorse/WASM) |
                                        +------------------+

1.1 Multi-Sig Thresholds

Relayers register public keys on both chains. A bridge transaction is validated only when a threshold of 75%75\% (3/43/4) relayer signatures is registered within a window of 30 slots.

1.2 State Relay Mechanics

Instead of relying on centralized custodial wrappers, ZERA relayers submit cryptographic state roots of ZERA blocks directly to a specialized program on Solana, which verifies block header validity using SPV (Simple Payment Verification) light-client proofs.

2. Dynamic Liquidity Locks

The bridging process maintains strict asset backing:

  1. Locking Phase (ZERA): The user deposits native ZRA tokens into the bridge state vault.
  2. Relay Proof Generation: Relayers sign a lock receipt containing the transaction hash and recipient address on Solana.
  3. Minting Phase (Solana): The Seahorse bridge contract mints wrapped wZRA tokens directly into the user's Solana Associated Token Account (ATA).

This transaction completes in under 2.5 seconds due to the parallel consensus optimization of both networks.