Validators & Staking

Validators (also called executors) are the nodes that execute Vara.eth programs off-chain and commit results to Ethereum. The current testnet phase uses a controlled validator set (PoA). Permissionless staking is planned for a later phase.

Role of Validators

Validators perform three critical functions:

1. Execute programs — Download WASM code, process messages, compute state transitions
2. Sign pre-confirmations — Participate in FROST threshold signatures for sub-second results
3. Commit batches — Submit StateTransition data to the Router contract on Ethereum

Execution Flow

L1 block with messages
        |
Validators detect new messages (monitor Router events)
        |
Fetch program WASM + current state
        |
Execute messages sequentially per program
        |
Compute new stateHash
        |
FROST threshold signature for pre-confirmation
        |
Batch commitment to Router (one validator submits, all sign)
        |
Router verifies and updates Mirror state

Staking

How Staking Works

Validators participate in the executor set through Symbiotic — a liquid restaking protocol on Ethereum. The system uses:

• Middleware Contract (IMiddleware.sol) — Manages validator registration, stake vaults, slashing, and rewards distribution
• Stake Vaults — Operators stake wVARA through Symbiotic vaults with configurable epochs and slashing parameters
• Operator Registry — Validators register as operators and opt-in to the Vara.eth subnetwork

Staking serves two purposes:

• Sybil resistance — Prevents spam validators
• Economic security — Slashing for misbehavior ensures honest execution

This approach enables liquid restaking — staked wVARA can participate in multiple networks simultaneously, improving capital efficiency compared to isolated staking pools.

Staking Parameters

Exact values are governance-controlled and may change. Check Network Endpoints for current parameters.

Validator Onboarding Status

During the current PoA testnet phase, validator onboarding is not open to the public.

The expected permissionless flow (register operator, register vault, run node) will be enabled in later phases once parameters and rollout milestones are announced.

Validator Election

Each era, the Middleware selects validators through makeElectionAt(timestamp, maxValidators):

• Operators are ranked by their total stake across all registered vaults at the election timestamp
• Top N operators (up to maxValidators) are selected for the next era
• Stake is calculated via getOperatorStakeAt(operator, timestamp) which queries Symbiotic vaults
• The selected validator set is committed on-chain and used for FROST signature verification

Rewards

Revenue Sources

Validators earn from:

• Execution fees — wVARA consumed from programs' Executable Balances during message processing
• Era rewards — Additional wVARA distributed per era from network inflation or fee pool

Distribution

Execution fees are distributed proportionally based on:

• Participation in batch commitments
• Pre-confirmation signing participation
• Uptime and responsiveness

Fee Flow

Program's Executable Balance
        |
Message executed (wVARA consumed at wvaraPerSecond rate)
        |
Fee pool for the batch
        |
Distributed to validators who participated in the batch

Slashing

Validators can be slashed (lose part of their stake) for:

• Incorrect execution — Committing a wrong stateHash that doesn't match the program's actual state
• Equivocation — Signing conflicting state transitions for the same block
• Extended downtime — Failing to participate in consensus for extended periods

The Router contract verifies batch commitments. If a committed state is challenged and proven incorrect, the submitting validator's stake is slashed.

FROST Threshold Signatures

Validators use FROST (Flexible Round-Optimized Schnorr Threshold) signatures for pre-confirmations:

• A threshold (e.g., 2/3) of validators must sign to produce a valid pre-confirmation
• No single validator can forge a pre-confirmation
• The aggregated signature is verifiable on-chain
• Enables sub-second response times without waiting for L1 finality

Pre-Confirmation Security

Pre-confirmations are backed by the economic security of the validator set. To forge a false pre-confirmation, an attacker would need to control the threshold of validators and risk their combined stake being slashed.

The BLS12-381 Built-in Actor on Vara Network provides native BLS cryptographic operations used for efficient signature aggregation in the bridge's ZK proofs.

Validator Economics

Revenue Estimation

A validator's revenue depends on:

• Total wVARA consumed across all programs (network activity)
• Number of active validators (more validators = smaller share)
• Validator's uptime and participation rate

Cost Structure

• Hardware — Server with sufficient CPU, RAM, and storage for WASM execution
• Bandwidth — P2P networking and Ethereum RPC access
• ETH for gas — Batch commitment transactions cost ETH
• Opportunity cost — Staked wVARA is locked during the unbonding period

Profitability

Validators are profitable when:

Execution fee rewards + Era rewards > Hardware costs + Gas costs + Opportunity cost

As network activity grows (more programs, more messages), the total fee pool grows, making validation more attractive.

Current Status

To prepare for mainnet validation:

• Monitor testnet development
• Set up and test executor nodes
• Understand the staking and slashing mechanics
• Join the Vara community for validator coordination