> ## Documentation Index
> Fetch the complete documentation index at: https://gora.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

```text theme={null}
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.

```text theme={null}
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](./randomness-and-vrf) for verifiable randomness from your app or contract, and [External calls](./external-calls) for how off-chain apps make HTTP requests while staying agreeable across validators.