# Protocol Overview

Pod uses a Byzantine fault-tolerant protocol that can tolerate up to 1/5 of validators acting adversarially. Unlike traditional blockchains, Pod's core protocol does not totally order transactions. This relaxation is what allows Pod to confirm transactions in a single network round trip, achieving latencies of \~150ms, bounded only by network propagation delay.

Pod does not have blocks or chains. Clients send transactions directly to the validator set. Each validator independently validates, timestamps, and signs the transaction, streaming attestations back to the client. Once attestations from a sufficient quorum are collected, the transaction is final. This entire flow completes in one round trip. See [Transaction Flow](/documentation/core/transaction-flow.md) for a detailed walkthrough.

## Why Pod is Fast

Consensus protocols totally order transactions, which requires a leader to propose blocks and multiple rounds of communication between validators to commit them. This coordination is expensive - every additional round adds at least one network hop of latency, and the leader becomes a throughput bottleneck since all transactions must flow through it. Pod avoids this by being coordination-free: validators do not communicate with each other to process a transaction. Instead, application-level invariants - double-spend prevention, balance checks, auction deadlines - are designed so they can be verified independently by each validator without requiring a shared global order. This is possible because Pod's core primitives (payments, token transfers, order submissions) are commutative or deadline-bound, so their correctness does not depend on the order in which validators see them. The result is that confirmation takes a single network round trip, bounded only by propagation delay.

Not every application can be built fully coordination-free. This is a new paradigm, and applications must be carefully designed to exploit it. Pod's enshrined primitives are built this way from the ground up. Applications that require strict global ordering can use [ordering gadgets](https://youtu.be/1aCiPb266Uw?si=AMAfRAOw6Y5WD5PK) - sequencers that transactions pass through before reaching validators. The sequencer is trusted only for liveness, not for equivocation - it can go offline but it cannot reorder or censor without detection.

## Design Principles

**Streaming** - Pod uses a publish/subscribe model over persistent connections. Validators stream attestations, state updates, and events to clients as they become available, rather than batching them into blocks at fixed intervals.

**Enshrined Market Primitives** - The protocol includes a built-in [order book](/documentation/markets/orderbook.md) with batch auction matching, [perpetuals](/documentation/markets/perpetuals.md), [optimistic auctions](/documentation/markets/optimistic-auctions.md), liquidation and margin engines, pricing oracles, and a [token](/documentation/markets/fungible-tokens.md) model. All expose standard Ethereum interfaces.

**MEV-Free** - Transactions are finalized without going through a centralized entity (e.g. leader or sequencer). All validators receive transactions simultaneously. The matching engine uses batch auctions where orders compete on price alone, independent of submission time or latency. This [eliminates MEV](/documentation/markets/markets-overview.md#why-pod-has-no-mev) structurally.

## Navigating the Docs

**Network** - the core consensus and infrastructure layer:

* [Network Architecture](/documentation/core/network-architecture.md) - entities in the network and how they interact
  * [Transaction Flow](/documentation/core/transaction-flow.md) - submission, attestation, finality, and recovery
  * [Local Ordering](/documentation/core/local-ordering.md) - per-account ordering, nonces, and the partial order model
  * [Censorship Resistance](/documentation/core/censorship-resistance.md) - how the leaderless design guarantees liveness
* [Native Bridge](/documentation/core/native-bridge.md) - deposit and withdrawal flows between Ethereum and Pod

**Markets** - the enshrined market primitives:

* [Overview](/documentation/markets/markets-overview.md) - enshrined market infrastructure and MEV elimination
* [Orderbook](/documentation/markets/orderbook.md) - the enshrined CLOB, order types, and batch auction matching
* [Perpetuals](/documentation/markets/perpetuals.md) - margin, funding, liquidation, and ADL
* [Optimistic Auctions](/documentation/markets/optimistic-auctions.md) - censorship-resistant auctions with off-Pod settlement
* [Tokens](/documentation/markets/fungible-tokens.md) - the native token model


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.v2.pod.network/documentation/readme.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.