# Slots, epochs and the beacon chain

> The consensus clock of QRL 2.0 — what slots and epochs are, and what the beacon chain does.

QRL 2.0's [Proof-of-Stake](/learn/proof-of-stake-on-qrl2) runs to a strict clock kept by the **[beacon chain](/learn/glossary#beacon-chain)**. Two units define that clock: **slots** and **epochs**. Getting them straight makes validator and consensus data on this explorer far easier to read.

## Slots: the 60-second heartbeat

Time on QRL 2.0 is chopped into **[slots](/learn/glossary#slot)** of **60 seconds**. In each slot:

- exactly one validator is chosen to **propose** a block, and
- a committee of validators **attests** (votes) on what they see.

If the chosen proposer is offline or misses its turn, the slot can simply be **empty** — there's no block for that slot. That's normal, especially on a quiet test network, and it's why block heights and slot numbers aren't always one-to-one.

## Epochs: 128 slots at a time

Slots are grouped into **[epochs](/learn/glossary#epoch)** of **128 slots**. At 60 seconds per slot, that's:

```
128 slots × 60 seconds = 7,680 seconds ≈ 2.1 hours per epoch
```

Epochs are the bookkeeping unit of Proof-of-Stake. At epoch boundaries the protocol:

- assigns validator duties for the coming period,
- tallies attestations, and
- advances **finality** — the point at which past blocks become effectively irreversible.

> A note for the technically curious: QRL 2.0's epoch length (128 slots) and slot time (60 seconds) differ from Ethereum's (32 slots × 12 seconds ≈ 6.4 minutes). So a QRL 2.0 epoch is roughly two hours, not a few minutes. Don't assume Ethereum's numbers carry over.

## What the beacon chain does

The **beacon chain** is the consensus layer that runs this clock. On QRL 2.0 it's operated by the `qrysm` client (a fork of Ethereum's Prysm). Its responsibilities:

- maintain the **validator registry** — who's active, their stake, their keys,
- **schedule** which validator proposes and which committees attest each slot,
- process attestations and drive **finality**, and
- record validator-affecting events like [slashings](/learn/slashing-explained).

The beacon chain works alongside the `gqrl` execution layer, which handles the actual transactions and balances. Consensus on one side, execution on the other.

## Seeing it on the explorer

Quantascan indexes the beacon chain directly, so you can browse [beacon blocks](/beacon), the [validators](/validators) registry, and [epochs](/epochs). When you see a slot with no block, that's an empty slot — expected behaviour, not an error.

## Where to go next

- [Validators and staking](/learn/validators-and-staking) — who fills these slots.
- [Withdrawals explained](/learn/withdrawals-explained) — how validator rewards are paid.
- [Proof-of-Stake on QRL 2.0](/learn/proof-of-stake-on-qrl2) — the bigger picture.