How the Tor Directory System Automatically Evaluates Relays

A Tor relay does not join the network through a conventional account-registration or manual approval process.

The Tor directory system continuously discovers, evaluates, measures, and publishes relay information through a distributed protocol operated by Directory Authorities and supporting measurement infrastructure.

1. There Is No Central Relay Registration Database

A new relay does not submit:

name
IP
application form
identity documents
approval request

to a central Tor administrator.

Instead, the relay generates its own cryptographic identity and publishes signed network information.

2. Server Descriptors

Each relay periodically publishes a signed server descriptor.

A descriptor contains information needed by the Tor network, including:

relay identity
OR addresses
supported protocols
exit policy
bandwidth information
software information
optional nickname
optional operator contact

Because the descriptor is signed, the directory system can verify that updates come from the same relay identity.

3. Directory Authorities

Tor relies on a small set of trusted Directory Authorities.

They do not forward ordinary Tor user traffic as a centralized router.

Their primary role is to maintain a shared view of which relays exist and what status those relays should have.

Each Authority independently receives descriptors and maintains its own view of the relay network.

4. Automatic Reachability Checks

Directory Authorities automatically test relay reachability.

This allows an Authority to determine whether a relay’s advertised ORPort is actually usable from the Internet.

A relay cannot simply claim:

Running

for itself.

The network must independently observe its availability.

5. Automatic Flag Assignment

Most relay flags are calculated according to protocol rules.

Examples include:

Running
Valid
Fast
Stable
Guard
HSDir

Each Authority creates its own view according to observed relay behavior, bandwidth data, and network-wide thresholds.

6. Bandwidth Measurement Infrastructure

Independent bandwidth scanners test relay capacity.

A simplified workflow is:

scanner discovers relay
       ↓
measurement traffic generated
       ↓
throughput estimated
       ↓
bandwidth result produced
       ↓
Directory Authority receives result

This prevents operators from obtaining excessive path-selection weight merely by claiming unrealistic bandwidth.

7. Voting

Tor’s Directory Authorities periodically generate signed votes.

Each vote contains that Authority’s current view of the network:

Relay A Running Valid Fast
Relay B Running Valid
Relay C Running Valid Stable Guard
...

The votes also contain bandwidth-related information and network parameters.

No human needs to trigger this process every hour.

It is part of the directory protocol’s automatic schedule.

8. Consensus Formation

Authorities exchange their votes and compute a common network consensus.

The consensus becomes a compact, signed description of the active Tor relay network.

It includes information such as:

• relay identity
• address
• ORPort
• flags
• bandwidth value
• protocol capabilities

Multiple authorities sign the resulting document.

9. Why Consensus Exists

Without a consensus, different clients could have radically different ideas about which relays exist.

The consensus provides a common reference:

Tor Client A ─┐
Tor Client B ─┼─→ shared consensus
Tor Client C ─┘

This greatly reduces opportunities for arbitrary or isolated directory manipulation.

10. Clients Download the Consensus

Tor clients and relays periodically obtain the current network consensus.

They use it to determine:

• available Guards
• eligible Middle relays
• suitable Exits
• relay weights
• network parameters

Path selection therefore occurs locally on the client according to the shared consensus.

11. Onionoo

Onionoo is a Tor Metrics service that transforms relay and bridge data into a convenient queryable format.

It is not the system that decides whether a relay is Running or Fast.

Instead:

Directory data
     ↓
Onionoo
     ↓
API-friendly relay information

12. Relay Search

Relay Search is a human-facing interface built on this public information.

It provides convenient views of:

• flags
• addresses
• bandwidth
• uptime
• history
• family relationships
• consensus weight

Its data may lag behind the relay’s current local state because several processing stages exist between the running daemon and the public website.

13. What Is Automated?

Normal relay operation is overwhelmingly automatic:

Descriptor publication          automatic
Reachability testing            automatic
Bandwidth measurement           automatic
Authority voting                automatic
Consensus generation            automatic
Client consensus downloads      automatic
Path selection                  automatic
Onionoo processing              automatic

14. Where Humans Still Matter

Human operators remain essential for:

• maintaining Directory Authority infrastructure
• deploying Tor software updates
• maintaining bandwidth scanners
• reviewing suspected Sybil attacks
• investigating malicious relays
• assigning administrative exclusions
• responding to serious security incidents

Normal honest relays, however, generally require no individual manual review.

Conclusion

Tor’s directory system functions like an automated distributed control plane:

Relay publishes
     ↓
Authorities observe
     ↓
Scanners measure
     ↓
Authorities vote
     ↓
Consensus is produced
     ↓
Clients download it
     ↓
Paths are selected automatically

This design allows thousands of independently operated relays to participate without requiring a central administrator to approve or manage each machine individually.