Proof of Authority (PoA)

Consensus where trusted authorities validate blocks instead of open participation.

TL;DR: Validators are pre-approved (often identity-verified) and take turns proposing/validating blocks using a Byzantine Fault Tolerant (BFT) engine (e.g., Clique, IBFT). This delivers fast finality and low fees but concentrates power in a small, permissioned set. Security derives from institutional accountability (contracts, reputation, legal recourse) rather than anonymous economic stake or energy.

How PoA works

PoA replaces open, permissionless validator sets with a curated list of authorities (entities you can identify and hold accountable). A consensus engine coordinates them to propose and finalize blocks. Two common families:

Clique (Geth-style): a simple, turn-based engine where authorized signers “seal” blocks. If more than half of signers are honest and online, the chain progresses. Finality is eventual (after enough confirmations) unless paired with extra finalization rules.
IBFT / QBFT (BFT engines): round-based consensus with proposals, prepares, and commits. Tolerates up to f faulty validators out of n = 3f+1. Reaches immediate finality once a block is committed by a supermajority.

Validator set (whitelist) → Leader proposes block → Others validate/sign
Enough signatures (quorum) → Block is final (IBFT) / considered safe (Clique)
On misconduct or downtime → Committee governance removes/replaces validator

Security basis: rather than burning electricity (PoW) or risking stake (PoS), PoA relies on external guarantees: contractual obligations, audits, regulator oversight, and reputational damage if a member cheats. It’s closer to a consortium ledger than a public, credibly-neutral chain.

Governance & onboarding

The validator list is the heart of PoA. Healthy PoA networks make the criteria for joining, operating, and removal explicit and verifiable.

Admission policy: Who may apply (licensed entities, audited firms, public institutions)? What documents and attestations are required (KYC, legal agreements, uptime SLO, incident reporting commitments)?
Key custody: Validators should use HSMs or hardware signers, with rotation procedures and disaster recovery (dual-control, out-of-band backups).
Voting & updates: Many PoA chains manage the validator set with an on-chain governance contract: a threshold of existing validators approves additions/removals. For IBFT/QBFT, changing the set is itself a consensus event to avoid splits.
Transparency: Publish validator identities, endpoints, client versions, and uptime dashboards. Provide a public escalation path for abuse or censorship reports.

Mental model: Think of PoA as a joint-venture database with cryptographic integrity. Governance paperwork (who’s in, who can be kicked out, SLAs) is as important as the code.

Threat model & mitigations

Collusion or cartelization: A small set of validators could censor transactions, freeze accounts, or rewrite short history.
Mitigate: expand and diversify the validator set across jurisdictions; require independent operators; embed clear, automatic removal rules; publish inclusion/censorship metrics.
Key compromise: An attacker who steals a validator key can propose invalid or censoring blocks.
Mitigate: HSMs/hardware wallets, rate-limited signing, out-of-band key rotation, multi-sig or threshold signing where supported.
Regulatory capture: A court order or regulator may coerce validators to censor or alter rules.
Mitigate: cross-border composition of validators; formal policies requiring public notice; technical controls that require supermajority for changes.
Client monoculture & bugs: If all validators run the same client/build, a single bug can halt or split the chain.
Mitigate: client diversity (Geth/Besu/Nethermind variants where applicable), staged rollouts, canary validators, chaos drills.
Availability outages: Because the set is small, a few nodes offline can stall consensus.
Mitigate: IBFT-style fault tolerance with adequate n, redundant infrastructure, SLOs and penalties for downtime.

Performance, finality & availability

Latency: PoA targets sub-second to a few seconds per block; IBFT gives instant finality upon commit (no reorgs). Clique provides fast confirmations but may rely on multiple blocks for “practical” finality.
Throughput: With few validators and predictable networking, PoA supports high TPS relative to public L1s—bounded by node hardware and block gas limits.
Fees: Often near-zero or fixed, since there’s no permissionless fee market competing for block space. Some deployments subsidize gas or abstract it away entirely.
Data retention: Enterprises may run archival nodes or integrate with off-chain databases/warehouses for analytics. Event schemas and deterministic indexing are important for audits.

When PoA makes sense (and when it doesn’t)

Great fit:

Consortium/enterprise workflows where participants are known (banks, logistics firms, regulators) and need shared, tamper-evident records.
Regulated data requiring identity, audit trails, and the ability to reverse operational mistakes via governed processes.
Testnets & sandboxes where high speed and controlled membership matter more than adversarial neutrality.

Poor fit:

Public, credibly-neutral finance where any user should be able to enter/exit without gatekeepers.
Censorship-resistance as a primary goal (e.g., global money). PoA’s social/legal levers are features for enterprises, bugs for permissionless systems.

Examples

VeChain — PoA for supply chain.
Ethereum testnets (historically Rinkeby, Kovan) used PoA engines to provide fast, stable testing environments.

Other enterprise/EVM stacks often ship PoA modes (e.g., Clique/IBFT in various clients) for private networks and sandboxes.

Builder checklist

Consensus choice: Need immediate finality? Choose IBFT/QBFT. Need simplicity? Clique may suffice.
Validator sizing: For IBFT, target n ≥ 4 and grow (7, 10, 13…) across independent operators to tolerate faults while keeping latency low.
Genesis & permissioning: Encode the initial validator set and permissioning rules in genesis and/or on-chain governance contracts. Test add/remove flows.
Key management: HSMs, dedicated signing hosts, periodic key rotation, incident runbooks, and SLAs.
Observability: Public dashboards showing block times, missed proposals, client versions, inclusion rates, gas usage. Alerting for drift or censorship signals.
Upgrade strategy: Staged rollouts, maintenance windows, and a documented emergency procedure (halt/resume). Practice drills.
Legal wrapper: A consortium agreement defining responsibilities, penalties, dispute resolution, and exit conditions.

User playbook

Know who runs it. Read the validator list and governance docs. If they’re private, assume the chain is effectively a company database with cryptographic proofs.
Interpret finality correctly. On IBFT-style networks, once a block is committed, it shouldn’t reorg. On Clique-style PoA, wait a few confirmations before treating data as settled.
Check inclusion & availability. If your transactions are delayed or filtered, raise it through published channels; monitoring sites should show per-validator performance.
Mind custody & KYC. PoA deployments often require identity for access or special API keys. Understand those obligations before integrating.

Quick Check

What replaces staking in PoA?
Why is PoA efficient but centralized?
Name two concrete mitigations for validator collusion or censorship.
When would you pick IBFT-style PoA over Clique?

Show answers

A permissioned validator list backed by off-chain accountability (legal contracts, reputation, audits).
Few, pre-approved validators coordinate easily → low latency and high throughput, but power concentrates in that small set.
Diversify validators across jurisdictions and operators; publish inclusion metrics and remove offenders via on-chain governance; require supermajority to change rules.
When you need instant, BFT finality with explicit fault tolerance (e.g., regulated workflows), not just fast confirmations.

Go deeper

Next: Proof of History (Solana) →