# FastSet Protocol *Note: This page describes how the underlying protocol of Fast works. If you are building with the SDK, you do NOT need to understand any of this — the SDK handles all protocol interactions for you.* FastSet is the settlement protocol that powers the Fast network. It enables parallel claim processing across independent validators — without consensus, block production, or validator-to-validator communication. *** ### Design Principles Traditional settlement systems — blockchains, payment networks, clearinghouses — serialize transactions into a single ordered sequence. This creates a bottleneck: every transaction waits for every other transaction, even when they are unrelated. FastSet takes a different approach. It observes that most real-world transactions are **independent**: Alice paying Bob has nothing to do with Carol paying Dave. Independent transactions can be processed in any order with the same result. FastSet exploits this property — called **weak independence** — to settle claims in parallel, with no global ordering and no consensus protocol. The result: sub-second finality, zero fees, and throughput that scales with the number of validators rather than being bottlenecked by a single leader. ### Participants #### Clients (Agents) A client is any entity that submits claims to the network: a user, an AI agent, a smart contract, an L2 rollup, a bridge, or an oracle. Each client holds an Ed25519 key pair. The public key doubles as the client's account address. #### Validators Validators process claims and maintain a local copy of the global state. They validate incoming claims, sign those they accept, and apply state changes when claims are settled. The protocol assumes **3f+1** total validators, of which at most **f** may be Byzantine (malicious or faulty). A **quorum** is any subset of **2f+1** validators. A claim signed by a quorum becomes a **certificate** — the protocol's unit of finality. Validators never communicate with each other. Each validator independently receives claims, validates them against its local state, and signs those it accepts. Despite this independence, the protocol guarantees that all honest validators converge to the same final state. #### Verifiers Verifiers are specialized clients that perform domain-specific verification before a claim reaches validators. They are optional — most claims are validated directly by validators. Verifiers are useful for heavy or specialized workloads: zero-knowledge proof checking, TEE attestation, semantic verification of execution traces, or off-chain computation. A client specifies which verifiers must approve its claim and the required quorum. Verifiers sign the claim independently, and their signatures are aggregated before the claim is broadcast to validators. #### Proxy The proxy is a convenience layer that handles message routing between clients and validators. It broadcasts claims, collects validator signatures, and assembles certificates. The proxy is **not trusted** — it cannot forge signatures, alter claims, or affect correctness. Anyone can run a proxy. The protocol functions identically without one; it exists purely to simplify network operations. *** ### The Protocol: Seven Steps The following describes the lifecycle of a single transaction — from creation to settlement. {% code fullWidth="false" %} ``` FastSet Protocol: 7 Steps +----------+ 1. Claim +----------+ +------------------------+ | Agent |------------>| |------------->| Validators | +----------+ | | | | | | | +----+ +----+ +----+ |-------------+ +----------+ 2. Verify | | | | | | | | | | 3. Validate | | Verifier |------------>| Proxy |------------->| +----+ +----+ +----+ |<------------+ | | | | | +----+ +----+ +----+ | | +----+ | | | 4. Sign | | | | | | | | | | | | | |<-------------| +----+ +----+ +----+ | | +----+ | | | 5. Confirm | | | +----+ | | |------------->| . . . . . . . . . |-------------+ | | | | | | | | 6. Presettle| | +----+ | | | | +----+ +----+ +----+ |<------------+ | . . . | | | | | | | | | | | | +----+ | | | | +----+ +----+ +----+ |-------------+ | | | | | | | | 7. Settle | | +----+ | | | | |<------------+ +----------+ +----------+ +------------------------+ The 7-Step Flow: 1. Agent submits Claim to Proxy 2. Verifier sends verification proofs to Validators (via Proxy) 3. Validators validate the claim 4. Validators sign and return signature to Proxy 5. Proxy confirms transaction to Validators 6. Validators presettle (prepare state) 7. Validators finalize settlement ``` {% endcode %} #### Step 1 — Transaction Creation A client say an agent `a` constructs a transaction: a sequence of one or more claims, bundled with a nonce (a per-account counter that prevents replay and enforces ordering). The client signs the entire transaction with its private key. ``` m = ⟨c₁, c₂, …, cₖ, nonce⟩_a ``` #### Step 2 — Verification (optional) If the transaction requires verifier approval, the designated verifiers each independently verify and sign it. Their signatures are aggregated into a single compact proof. #### Step 3 — Validation Each validator receives the transaction and checks: 1. **Signature** — the client's signature is valid 2. **Nonce** — matches the validator's expected next nonce for this account 3. **No equivocation** — the validator has not already signed a *different* transaction from this account at this nonce 4. **Verifier quorum** — if verifiers are specified, their aggregated signatures are valid and meet the required threshold 5. **Claim validity** — each claim in the transaction is valid against the validator's current local state (e.g., sufficient balance for a transfer) #### Step 4 — Validator Signature If all checks pass, the validator signs the transaction and returns its signature to the proxy. It also records the transaction as *pending* for this account, preventing itself from signing a conflicting transaction at the same nonce. #### Step 5 — Certificate Creation Once the proxy collects signatures from a quorum of validators (2f+1 out of 3f+1), it assembles them into a **certificate**. The certificate is cryptographic proof that the transaction has been accepted by the network. At this point, settlement is guaranteed — the transaction cannot be reversed. #### Step 6 — Pre-settlement The certificate is broadcast to all validators. Each validator verifies the quorum and adds the transaction to its *pre-settled* set — acknowledged but not yet applied to state. #### Step 7 — Settlement A validator settles a pre-settled transaction when two conditions are met: 1. **Nonce ordering** — all prior transactions from the same account have already settled 2. **Claim validity** — the claims remain valid in the validator's current local state Upon settlement, the validator increments the account's nonce, applies the state changes, and moves the transaction to its *settled* set. *** ### Weak Independence Two claims are **weakly independent** if processing them in either order produces the same final state — whenever both are individually valid. Formally: claims c₁ and c₂ are weakly independent if, for any state s where both c₁ and c₂ are independently valid, the sequences c₁→c₂ and c₂→c₁ both produce the same resulting state. Examples: * **Weakly independent:** Alice pays Bob; Carol pays Dave. Different senders, no shared state — order does not matter. * **Not weakly independent:** Alice pays Bob 5; Alice pays Carol 5 (and Alice has only 7). The order determines who gets paid. FastSet requires that claims from *different* accounts are weakly independent. Claims from the *same* account are ordered by nonce, so they never run concurrently. This property is what eliminates the need for consensus. Validators process claims in whatever order they arrive. Because independent claims commute, all validators converge to the same state — regardless of arrival order. *** ### Correctness Guarantees Under the assumption that more than two-thirds of validators are honest, the protocol provides four guarantees: | Property | Guarantee | | ---------------- | ---------------------------------------------------------------------------------------------------------- | | **Safety** | At most one certificate exists per account per nonce. Double-spending is impossible. | | **Determinism** | The order in which a validator receives messages does not affect the final state. | | **Monotonicity** | Once a transaction becomes settleable, it remains settleable regardless of other accounts' activity. | | **Liveness** | If any honest validator makes progress, all honest validators eventually do. The network cannot get stuck. | These properties hold without global ordering, without a leader, and without validators communicating with each other. They are a direct consequence of weak independence. *** ### Eventual Consistency Validators do not maintain identical state at any given moment. They converge over time as certificates propagate and settle. This is **eventual consistency** — the same model used by globally distributed databases and CDN networks. The guarantee: if no new transactions are submitted, all honest validators will eventually reach the same state. In practice, with continuous transaction flow, validators may always have slightly different views — but the weak independence property ensures these differences are harmless and always resolvable. *** ### Performance Benchmark Our latest load test demonstrated sustained throughput of approximately **160,000 transactions per second (TPS)**, with a peak of **\~168,000 TPS** observed. #### Machine Specs
CPURAMBandwidthData Center
Validator 1AMD EPYC 9454P256 GB10 GbpsFSN1-DC22
Validator 2-4AMD EPYC 9454P256 GB10 GbpsFSN1-DC21
Load Generator 1AMD EPYC 9454P128 GB10 GbpsFSN1-DC19
Load Generator 2AMD Ryzen 9 7950X3D128 GB10 GbpsFSN1-DC16
Load Generator 3AMD Ryzen 9 7950X3D128 GB1 GbpsFSN1-DC12
#### Validator Configuration 4 validators (quorum of 3). The primary validator persists all transactions to a database, while the remaining three operated without database persistence. Note that persistence is not required for running a validator and is not part of the protocol. Validators configured with persistence can be considered an "archive node" in the traditional sense. The observed CPU utilization on validator 1 reached 100%, while the other three remains stable at around 80%. #### Load Generator Configuration * Load generator1: Two load generator programs, each with 40 threads and 200 concurrent accounts. Each of them generated 40-45k TPS. Observed CPU utilization was 80-90%. * Load generator 2: Three load generator programs, each with 15 threads and 256 concurrent connections. Each of them generated around 15k TPS. CPU utilization was > 95%. * Load generator 3: A single load generator program with 16 threads and 256 concurrent connections. It generated 10k TPS and it was limited by the external bandwidth *** ### Further Reading * [FastSet whitepaper](https://arxiv.org/abs/2506.23395) — full formal treatment with proofs --- # 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.fast.xyz/advanced/fastset-protocol.md?ask= ``` 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.