Building Fast and Fair Markets
Building Fast and Fair Markets
The Architecture That Makes Fast, Fair Markets Possible
TL;DR:
Building decentralized markets requires tackling challenges related to efficiency, real-time latency, market fairness, and censorship-resistance. Running black-box consensus at each step of the way won’t cut it. We discuss how Pod is utilizing a dual-architecture and enforceable market rules to provide fast and fair markets on decentralized networks on a global scale.
Decentralized Markets: What and why?
A market is a mechanism for exchanging assets, information, or risk through structured interaction. It consists of participants, rules, and infrastructure that together determine how value is discovered and transferred.
Decentralized markets have no single authority controlling participation, execution, or settlement. These functions are distributed across a network, with rules enforced by protocols and smart contracts rather than trusted intermediaries. Trust shifts from institutions to code.
This matters because centralized markets have centralized risks: a single party can censor participants, halt trading, or manipulate execution. Decentralized markets eliminate that single point of control—but only if the protocol enforces the right properties.
What Makes a Market Fair?
Before diving into architecture, we need to define what "fair" means for a market. Three properties matter:
Censorship-resistance. If you submit a valid order, it must be included. No party—not the exchange operator, not a validator, not a privileged trader—can selectively exclude your order.
No front-running or last-look. No participant should be able to see your order and race ahead of it. In traditional markets, market makers often have "last-look" privileges—they see incoming orders first and can then post their own orders accordingly. This is unfair to the counterparty.
Equal treatment. The same rules apply to everyone. A retail trader and an institutional player sitting across the world from each other, submitting identical orders at the same time, should receive the same execution.
These aren't just nice-to-haves. Without them, sophisticated participants extract value from unsophisticated ones, and trust in the market erodes. The challenge is achieving these properties without sacrificing speed.
Order Books: Submission vs. Execution
Most financial markets can be modeled as order books: participants submit bids and asks, and prices emerge from matching. We can decompose an order book into two operations:
Order submission: getting your order into the system. This is similar to making a payment—you're committing funds and expressing intent.
Order execution: matching orders and settling trades. This is where the market actually happens—determining who trades with whom, at what price.
These operations have fundamentally different coordination requirements. Conflating them is why many decentralized exchanges are either slow (waiting for consensus on every order) or unfair (giving sequencers unchecked power).
The Consensus Bottleneck
Decentralization requires coordination. The standard tool is consensus: protocols that let a network of nodes agree on state, even when some participants are faulty or malicious.
Consensus provides strong guarantees, but at a cost. It typically requires multiple rounds of communication and significant message exchange. This introduces latency (you wait for agreement) and throughput limits (one leader processes transactions sequentially).
Traditional blockchains embody this trade-off. A leader decides what goes into each block, processes it, and hands it off. Every transaction waits for this sequential step. The leader is a bottleneck—and often a point of unfairness, since they control ordering.
The question is: when and where do we actually need this much coordination?
Orders as Payments: Why Submission Can Be Fast
Here's a key insight: order submission doesn't need global consensus.
Consider a payment. To transfer funds from Alice to Bob, you need to ensure Alice's transactions are ordered correctly relative to each other (to prevent double-spends). But you don't need to order Alice's payment relative to some unrelated transaction by Carol. Per-account ordering is sufficient.
An order is essentially a payment with conditions attached: "I'll pay X if I receive Y." The submission step—locking funds and registering intent—has the same structure as a payment. It doesn't require knowing the global order of all events in the system.
This is what Pod's fastpath layer exploits. When you submit an order:
- Validators receive, verify, and timestamp it
- They lock your account (preventing double-spends)
- They broadcast attestations
- Once your order has sufficient attestations, it's finalized
No global coordination. No waiting for a leader. The network runs at network speed—orders finalize in the time it takes for messages to propagate and accumulate votes.
For the curious reader, notice that modifying and canceling existing orders are also local operations that similarly do not require global coordination.
Execution Needs Order: The Role of the Solver
Submission is fast because it doesn't require global ordering. But matching orders into trades does.
If two validators see orders in different sequences, they might match different trades and end up with inconsistent views of who owns what. The order book would fragment into conflicting local states.
Matching requires:
- Agreement: everyone sees the same set of matched trades
- Total order: a deterministic sequence for price-time priority
- Finality: executed trades cannot be undone
This is where the solver comes in. The solver is a designated role that takes the pool of finalized orders from the fastpath and produces batches: matched sets of orders with a defined execution sequence. For another dive into the notion of ordering gadgets and their composition with consensus-less primitives, take a look at Shresth’s past talk.
The solver is not a single everlasting leader; the role will be frequently transferred to different participants, via well-studied leader-rotation mechanisms.
But still—doesn't this reintroduce centralization? A single actor controlling order batching sounds like exactly the problem we're trying to avoid.
How batching progresses. Orders that arrive in time on the solver (with sufficient support) are included in the ongoing batch. Late orders (that arrive, or get support after the batch’s deadline) might be considered in future batches.
Pod's Two-Layer Architecture
Pod’s insight is that the solver's power can be bounded by the protocol. It sequences orders, but it cannot:
- Exclude orders that were finalized
- Insert orders that weren't attested in time
- Manipulate the sequence of orders (due to batch auction design)
The solver provides the global ordering that matching requires, but operates under constraints that prevent abuse.
Pod's architecture separates the fast path from the batching:
Layer 1: Fastpath (Speed)
- Handles order submission
- Validators independently verify and attest orders
- No global coordination required
- Orders finalize at network speed
Layer 2: Solver (Batch Agreement)
- Solver posts the batch of orders to be finalized
- Constrained by protocol rules that validators enforce
- Execute order matching and settlement
The roles of each layer are separate; the solver’s responsibility is to move the batching forward quickly and according to enforceable rules.
Enforcing Fairness
How exactly does Pod prevent the solver from misbehaving?
Mandatory inclusion (censorship-resistance)
The solver must include every order that achieved sufficient attestations before the batch deadline. Validators independently track which orders were attested and finalized. When the solver publishes a batch, validators check: did it include all the orders it was supposed to?
A valid, timely order that the solver omits is detectable. The solver cannot selectively exclude your order.
Attestation proofs (last-look protection)
What if a malicious solver colludes with some validators to insert unfair orders, such as orders that arrived too late or had lower support than required? The protocol handles this too.
To withdraw proceeds from a matched order, you must prove the order was properly attested—received by enough honest validators before the deadline. Orders that weren't properly attested can't satisfy this proof. The funds don't move.
Even if the solver inserts a fake order and "matches" it, the attacker can't extract the proceeds. The attack is unprofitable.
Batch auctions (front-running protection)
Pod uses batch auctions rather than continuous matching. Orders submitted within a batch window are matched together, with a single clearing price: the average of the best buy and worst sell that got matched. Moreover, the solver doesn’t even get a say in the ordering of the batch; there is a deterministic rule for ordering all orders within the same batch; all validators and the solver must follow this predetermined rule.
This eliminates front-running by design. There's no advantage to being microseconds faster—all orders in the batch get the same price. A retail trader and a high-frequency firm submitting in the same batch receive identical treatment.
Visual example of censorship resistance: V2, V3, V4 is the honest overlap subset. Their attestations for the finalized order, provide n-3f support for the order; thus, the solver will be enforced to include it in the batch.
Conclusion: Fast AND Fair
The traditional view is that decentralized markets must choose: either be fast (by trusting a sequencer) or be decentralized (by running consensus on everything to order events). Pod rejects this trade-off.
Fast Submission: Order submission runs at network speed. No leader bottleneck, no consensus latency. Finality in sub-seconds.
Batch Agreement: Each batch is provided by a single solver, which gives agreement, total ordering, and removes the need for validators running a slower consensus. Batch finality is also achieved in sub-seconds.
Fair: The solver is constrained by enforceable rules. Your order cannot be censored (mandatory inclusion), you cannot be front-run (batch auctions), and fake orders cannot extract value (attestation proofs against last-look).
The key is recognizing that different operations need different levels of coordination—and designing an architecture that applies coordination as needed at each step. Payments and order submissions don't need global order. Matching does, but the entity providing that order can be constrained.
The result is a decentralized market that's competitive with centralized exchanges on speed, while providing fairness guarantees that centralized exchanges cannot.