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.
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.
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:
Signature — the client's signature is valid
Nonce — matches the validator's expected next nonce for this account
No equivocation — the validator has not already signed a different transaction from this account at this nonce
Verifier quorum — if verifiers are specified, their aggregated signatures are valid and meet the required threshold
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:
Nonce ordering — all prior transactions from the same account have already settled
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:
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
Validator 1
AMD EPYC 9454P
256 GB
10 Gbps
FSN1-DC22
Validator 2-4
AMD EPYC 9454P
256 GB
10 Gbps
FSN1-DC21
Load Generator 1
AMD EPYC 9454P
128 GB
10 Gbps
FSN1-DC19
Load Generator 2
AMD Ryzen 9 7950X3D
128 GB
10 Gbps
FSN1-DC16
Load Generator 3
AMD Ryzen 9 7950X3D
128 GB
1 Gbps
FSN1-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 — full formal treatment with proofs
Last updated
Was this helpful?