Validators and consensus

How Gora validators run, who can launch one, and how a consensus round produces an attestation.

Validators and consensus

A Gora validator is a process that participates in producing and verifying app results. Validators are off-chain. The Gora network is not a blockchain — it agrees on app outcomes and writes attestations to whichever chain the result targets.

The short version

A request enters Gora
        ↓
Validators run a consensus round
        ↓
The round produces a result + a committee-signed attestation
        ↓
The attestation can be returned off-chain or verified by a chain contract

Each round picks a small committee out of all active validators. The committee runs the app, agrees on the result, and signs it. Anyone with the validators’ public keys can verify the signatures.

Who can be a validator

Anyone who stakes GORA on a supported chain can launch a validator. The MVP supports three entry chains:

Chain	Where you stake	What you sign with
Solana	gora-staking Solana program	Solana ed25519 wallet
Base	GoraValidatorStaking Base contract	Base secp256k1 EOA
Algorand	gora-staking Algorand app	Algorand ed25519 wallet

You stake on the chain you already use. Your voting power is the sum of any stake you have committed across all three chains.

Two keys, two roles

Key	Lives where	Used for
Owner key (cold)	Your wallet on Solana, Base, or Algorand	Stake, register a validator, authorise a participation key
Participation key (hot)	The validator process	Sign VRF proofs and votes inside each round

The owner key signs a delegation certificate once. The certificate binds a participation key to your on-chain identity. From then on, the validator process can sign votes and proofs without ever touching the cold key.

If a participation key is compromised, the owner rotates it. Stake is unaffected.

Launching a validator from mobile

The Gora mobile apps (iOS and Android) include a Validators screen. The flow is:

1. Pick a chain (Solana, Base, or Algorand) — only chains where you already have a wallet are offered.
2. Pick a stake amount.
3. The app asks the Gora node manager for a fresh participation key.
4. The wallet signs a delegation certificate binding that participation key to your address.
5. The wallet builds and signs the stake transaction for the chosen chain.
6. The manager spawns a validator process for you on a Gora-provided host (during MVP) or on your own host (after MVP).

You can stop a validator at any time. Unbonded stake becomes withdrawable after the chain’s cooldown.

How a consensus round runs

Each round is short — usually under a few seconds — and proceeds in fixed phases.

1. Each active validator computes a VRF output for this request
2. Every validator gossips its VRF output to peers
3. The collected VRFs are combined into a stake-weighted score
4. The lowest-scoring committee members are selected;
   the lowest one of all becomes the proposer
5. The proposer runs the app and gossips the result
6. The other committee members independently re-run the app
   (or evaluate the result, for AI-mediated requests)
7. Each committee member signs YES or NO and gossips the vote
8. If at least two-thirds of committee voting power says YES,
   the round commits with a signed attestation
9. If a phase times out, the network round-fails and retries
   with a new sequence

Validators outside the committee for a round are observers. They learn the outcome through gossip and record it in their own audit log.

Networking model

Validators communicate over a gossip transport — push fan-out plus an anti-entropy pull every few seconds. There is no central coordinator. When a new validator joins, it bootstraps from a small list of well-known peers and diffuses its own signed announcement through gossip.

During MVP, validators run on Gora-provided hosts as separate processes inside Linux network namespaces. From their own point of view, each validator is on its own machine: separate IP, separate routing table, separate ports. The same gossip code paths work for both local-isolated and remote deployments, so the eventual transition to user-hosted validators does not change the protocol.

Safety assumptions for MVP

Assumption	Status
Up to one-third of committee voting power may be malicious	Tolerated
All committee members may be offline for one request	Round-fails and retries with a new sequence
A validator that double-signs is detected	Equivocation is logged and the voter is excluded from the tally
Slashing on detected misbehaviour	Deferred (logged, not enforced, in MVP)
Validator stake on more than one chain	Sums to a single voting power

What this means for app developers

You do not need to know which validator ran your request. You do need to know:

• Your request is processed by a committee — typically five validators — not by one node you can trust unilaterally.
• The result you get back is accompanied by an attestation that any supported chain can verify.
• Deterministic apps (same input → same output) are checked by re-execution. Non-deterministic apps (AI-mediated) are checked by independent evaluation against your declared policy.

See Randomness and VRF for verifiable randomness from your app or contract, and External calls for how off-chain apps make HTTP requests while staying agreeable across validators.