Vara-Ethereum Bridge - Technical Overview

Security Audit Passed

The bridge architecture has undergone a professional security audit. All critical findings and edge cases have been fully addressed in the final implementation.

The audit confirms the safety of core components:

Message Validation & Token Logic
Relayer Incentives
Real-world condition stability

📄 View Full Audit Report (PDF)

Source Code

To explore the bridge implementation details, visit the official repository:

🔗 Bridge Implementation Repository

The Tech Behind the Bridge

The Vara ↔ Ethereum Bridge is the product of deep technical architecture and real-world experience in cross-chain interoperability and cryptography. It brings together a set of purpose-built technologies that prioritize security, scalability, and trustless execution — all while remaining compatible with existing Ethereum infrastructure.

At the foundation of the bridge lies a modern cryptographic stack, including Plonky2 for high-speed recursive zero-knowledge proofs and GNARK for zk-proof verification inside Ethereum contracts. These tools allow the bridge to verify validator consensus and message authenticity without revealing sensitive data — a critical feature for decentralized networks.

To ensure minimal gas costs and maximum verifiability, the system relies on Merkle Trees for compact message commitments, and integrates Ethereum’s Beacon Chain API and Sync Committee to independently validate Ethereum block finality on the Vara side. On Vara, the bridge logic is powered by the Gear runtime and a set of specialized programs and pallets that coordinate message queues, validator sets, and light client behavior.

This combined stack allows the bridge to operate without trusted intermediaries — every proof, message, and block is cryptographically verifiable on-chain, laying the groundwork for a secure and extensible messaging system between Ethereum and Vara.

Conceptual Flow: How the Bridge Works

From a user’s point of view, bridging tokens or data between Vara and Ethereum may feel like a simple operation — click, confirm, done. But under the hood, the system follows a strict flow that ensures only finalized, verified information is ever transmitted across chains.

From Vara to Ethereum

The process begins with finalized blocks. When a user performs an action that generates a message to Ethereum — such as locking VARA tokens. These messages are collected by the gear_eth_bridge pallet and stored in an outbound queue.

Every time a block is produced on Vara, a new Merkle root of the message queue is calculated. Relayers — permissionless, decentralized actors — then take over. They generate a zero-knowledge proof that this Merkle root was signed by the active validator set on Vara. This proof, along with metadata such as the block number and validator snapshot, is submitted to a Proof Verification Contract on Ethereum. This contract uses gnark to check the validity of the proof.

If the zk-proof is valid, Ethereum records the Merkle root and considers it an approved source of truth.

After that, any individual message from Vara can be submitted to Ethereum through the Bridge Message Contract, along with a Merkle proof of inclusion. The contract checks that the message:

Belongs to an approved Merkle root.
Has not already been processed.

If both conditions are met, the message is marked as used, and the corresponding action (e.g., minting tokens) is triggered.

From Ethereum to Vara

In the reverse direction, the system does not use zk-proofs. Instead, it relies on Ethereum’s native finality mechanism and event logs.

Relayers continuously monitor Ethereum’s Beacon Chain and Sync Committee — a rotating group of Ethereum validators that sign finalized block headers. Once a block is finalized, a relayer submits the block header and associated sync-committee signatures to Vara.

On the Vara side, a checkpoint light client program verifies that the submitted block was indeed finalized, using the aggregated BLS signatures from the sync committee.

Once Vara accepts the block as finalized, any relevant event emitted on Ethereum (e.g., a Burn event from the wVARA Manager contract) can be proven via a Merkle proof. These proofs are then consumed on the Vara side, such as the VFT Manager program, which performs the appropriate on-chain logic, like minting VARA tokens.

What is VFT Manager?

In simple terms, the VFT Manager acts as an intermediary between the bridge and the token contract:

Action: It receives commands from the Vara-Ethereum Bridge.
Execution: It triggers the corresponding actions in the token contract, such as minting or unlocking assets.

Example Transaction Flow

Let’s walk through an end-to-end example:

A user wants to move VARA to Ethereum.
They lock 100 VARA via the VFT Manager on Vara side.
This action generates a message, stored in the outbound queue.
After finality, the gear_eth_bridge takes a new Merkle root.
A relayer generates a zk-proof and submits it to the Ethereum Proof Verification Contract.
The root is accepted, and the message can now be submitted — typically by a relayer — along with a Merkle proof.
The wVARA Manager ERC-20 contract mints 100 wVARA to the user's address.

The reverse flow (burn wVARA on Ethereum → unlock VARA on Vara) follows the same structure in reverse, with checkpoints, events, and proofs flowing through Ethereum light clients and message verifiers on Vara.

The user sends wVARA to the wVARA Manager contract on Ethereum and triggers a Burn event.
The burn is recorded in a block finalized by Ethereum’s Beacon Chain.
A relayer submits the finalized header and signatures to Vara’s light client.
Vara accepts the block and processes the event via the VFT Manager.
Native VARA are minted or unlocked to the user’s account on Vara.

This dual-model architecture — zk-proofs in one direction, consensus/event-based validation in the other — ensures both efficiency and robustness.

Transport Layer

The transport layer is the core of the bridge — responsible for ensuring that messages are collected, verified, and delivered correctly across both networks. These components make sure each side of the system speaks the same language — securely and consistently.

Vara Side Components

The main actor here is the gear_eth_bridge pallet. It serves as the orchestrator for outbound and inbound messages:

Maintains the current validator set
Tracks finalized blocks and outbound message queue
Computes the Merkle root for finalized message batches
Stores metadata necessary for ZK-proof generation

Other important modules are programs:

Checkpoint Light Client — A minimal Ethereum Beacon Chain client that stores finalized block headers and Sync Committee sets. It:

Accepts newly finalized headers and stores them after verification.
Enables trustless validation of Ethereum-side data.

Ethereum Event Client — This program processes Ethereum-side events by:

Cross-checking data with the Checkpoint Light Client
Verifying Merkle Patricia proofs that confirm a transaction is part of a block
Decoding transaction receipts and events

Historical Proxy — A routing layer between users and multiple versions of the Ethereum Event Client. It chooses the correct version of the event client to handle a given request based on Ethereum’s slot number.

Why is Historical Proxy needed?

Ethereum evolves over time, and its data structures or client versions may change.

The Historical Proxy ensures seamless compatibility by automatically selecting the correct client version based on the specific block’s slot, allowing the bridge to process historical data without errors.

Ethereum Side Components

Ethereum hosts a few key contracts that handle the bridge logic. Each of these components plays a focused role in message handling and state verification:

Proof Verification Contract — Verifies zk-proofs submitted by relayers using the gnark proof system.

Relayer Contract — Accepts proofs and Merkle roots from relayers and emits events when they’re accepted.

MessageQueue Contract — Verifies messages included in a Merkle root and ensures they haven't been used before.

ProxyUpdater Contract — Processes system-level updates, such as governance-approved changes to bridge components.

Event Submission Interface — A helper contract for relayers to submit finalized Ethereum blocks and event data, used when sending messages from Ethereum to Vara.

Relayers

Relayers play a crucial role in the bridge’s cross-chain communication model. These are independent, permissionless actors that deliver messages, block headers, and proofs between Ethereum and Vara.

Relayers do not validate or interpret the data they carry. Instead, they act as messengers that:

Submit zk-proofs and Merkle roots from Vara to Ethereum
Submit finalized Ethereum headers and transaction data to Vara

Because the bridge is fully permissionless, anyone can run a relayer — no special access is required. This ensures decentralization and availability across different network conditions.

Relayers may also be economically incentivized. Each successful message delivery or header submission can result in a reward, ensuring that relayers are motivated to stay online and maintain service availability.

They are replaceable, stateless, and independent by design — if one stops, another can continue without any coordination. Many can run simultaneously.

Bridging Payment Mechanisms

To ensure network liveness, the system supports optional bridging payment contracts on both sides:

Automatic: Users pay a small fee during message initiation, which relayers claim as an incentive.
Manual: Users can relay messages themselves without an automatic fee, though in practice, professional relayers require incentives to operate.

This dual approach provides flexibility while maintaining relayer incentives for a smooth user experience.

What happens if relayers go offline?

Because all bridging data is stored on-chain (using Merkle Trees), the system is inherently resilient:

Persistence: No data is lost during downtime.
Recovery: Any new or returning relayer can simply retrieve the proofs and resume transmission.
Security: This design ensures liveness and eliminates central points of failure.

Smart Contract Layer: Token Logic & Extensibility

On top of the transport and validation infrastructure lies the token logic layer — responsible for handling tokens and business logic on both chains.

On both sides of the bridge, the architecture is built around two elements:

Asset managers (e.g., ERC20Manager, VFT Manager)
Asset contracts (e.g., ERC-20 tokens or FT programs)

Managers are responsible for:

Coordinating token logic — minting, burning, locking, or unlocking
Validating and processing verified bridge messages

These managers coordinate with multiple components in the system — such as gear_eth_bridge on Vara, or MessageQueue on Ethereum — to ensure that only verified and authorized operations take place.

The asset contracts are independent and modular.

Developer Extensibility

The bridge was built to be extensible and permissionless. Developers can:

Build their own token managers or message handlers
Extend the bridge with custom asset (NFTs, game assets, or DeFi primitives)

Integration is subject to DAO governance — allowing the community to review, approve, and add new logic to the bridge registry

This ensures the bridge is not limited to any specific asset type and can adapt to the needs of the evolving ecosystem.

Governance Layer

The governance system ensures that the bridge remains secure, upgradeable, and adaptable to ecosystem needs — all without requiring disruptive hard forks.

At its core, the bridge uses a customized version of Substrate’s OpenGov pallet, adapted specifically for cross-chain infrastructure. This system allows the community to submit and vote on proposals that can directly influence the bridge’s behavior through on-chain execution.

Through proposals the bridge allows:

Expanding bridge functionality - Add new tokens, assets, or modules without interrupting operations.
Smart contract upgrades - Seamlessly upgrade Ethereum contracts using a proxy pattern, and update logic on Vara via trusted admin messages.
Tuning economic parameters - Adjust fees, relayer incentives, and operational limits through proposals.
Emergency control - Pause or restrict bridge activity in response to critical threats, based on transparent community consensus.

Governance in Practice

The bridge’s DAO logic is natively integrated with its transport layer to ensure secure upgrades:

Mechanism: Administrative messages sent through governance are automatically recognized by both smart contracts and pallets.
Benefit: This allows for controlled updates and parameter tuning without bypassing the on-chain security protocols.

What Does This Mean for Users?

Governance makes the bridge resilient and future-proof:

Community-Driven: Any member can propose improvements or architectural updates.
Seamless Execution: Once a proposal is approved via the DAO, changes are implemented automatically with no downtime or manual intervention.

This ensures the bridge evolves alongside the needs of the ecosystem while maintaining total transparency.

Vara ↔ Ethereum Bridge Technical Overview