Fast Protocol
Fast is a distributed protocol for parallel claim settlement. In short, it allows a set of clients to settle verifiable claims consistently, using a set of validators. Clients broadcast their claims to all validators. Validators validate the received claims and replicate the system state based on the order in which they receive the claims. The Fast validators do not need to communicate with each other, nor directly achieve consensus on any values, orders, blocks, or computations. More specifically, in Fast, we achieve strong eventual consensus due to the weak independence on claims we require.
If you're interested in what types of claims one can settle in Fast and how to express them head to our Claims section. Weak independence is the property we require claims to satisfy, and which allows Fast to process them in any order, which facilitates decentralization and scalability. Read about it in our section on Weak independence. In this section, we will focus on the inner workings of Fast.
Figure 1 below depicts the participants and steps of the protocol. In the following, we’ll discuss each in more detail.
Participants
Agent (Client)
A client is any account or address holder who can make claims. Clients can be more than individual users; they can be apps (such as contracts, web2, or games), L1s, L2s, micro-chains, AI agents, service providers, oracles, provers (such as mathematical or zero-knowledge), verifiers (such as execution, semantics, and/or zero-knowledge proof based), etc.
Each client possesses a key pair consisting of a private signature key sk and its corresponding public verification key pk. The private key is used to sign messages
⟨msg⟩sk
while the public key is used to publicly verify the authenticity of the signatures. Similarly to blockchains, the public key of a client also serves as its public account number, or its address.
Validators
Validators are responsible for processing the claims made by the clients, while at the same time maintaining consistency in the global knowledge about the overall system, or, more specifically, in the global state of the system.
Validators maintain a local copy of the global state, which they update independently based on the side effects of the claims they process. Due to the eventual consistency consensus we achieve in Fast, local states of validators may temporarily diverge when processing the same set of claims. However, by the time they process the entire claim set, their states converge to the same final state, achieving determinism.
For example, for a payment system, validators keep balances of all tokens and additional data/state of all clients, global state of the entire protocol, like the set of all the claims that were settled, etc.
Verifiers
Verifiers are specialized clients that perform customizable verification of claims and their proofs before those claims are processed by validators.
They serve as the trust layer of Fast, confirming that a claim’s data, logic, or cryptographic proof is correct, without requiring validators to do the heavy lifting.
Verification can happen in real time and is highly flexible, supporting a wide range of mechanisms such as:
TEE attestation, ensuring claims originated from trusted hardware environments
Zero-Knowledge (ZK) proof verification, confirming private computations without revealing inputs
Semantic verification, validating that a computation or execution trace follows expected logic (e.g., Python semantics)
Off-chain verification, for workloads that are better handled outside the main network
Verifiers are optional.
Most claims can be directly validated by the Fast validators. However, in cases that involve heavy computation, domain-specific checks, or off-chain verification workloads, verifiers play an essential role in offloading that process and providing signed verification proofs back to the network.
Once a verifier confirms a claim and issues its signed verification result, the claim is broadcast to validators. Validators then validate and settle it as part of the Fast protocol, achieving consistency without consensus.
This two-step approach: verification first, validation second, lets Fast process complex or high-demand verification workloads in parallel, maintaining scalability and security without global coordination.
Proxy
The proxy is responsible for two services: broadcasting messages to validators and aggregating verifier signatures (#{sig1 , sig2 , ...}).
Proxy is optional.
Just like the verifiers, the proxy is not required for protocol functionality. It simply acts as a helper in the protocol. The proxy can be a client (the sender of the original message containing the claim sequence, or a different client such as a beneficiary or a verifier or a service provider), a validator, or any combination of these.
Protocol steps
Claim
Client A signs a sequence of claims c1 c2 ... ck and sends the signature m = <c1 c2 ... ck,T>A to the proxy.
Verify
The set of verifiers T requested by the client verifies the message m and signs it individually <m>t1, <m>t2, … <m>tl.
Validate
The proxy receives the signatures from the verifiers and computes an aggregated signature <m>#T, which it sends to the validators.
Sign
Validators validate the signature by checking that the signatures are valid and the quorum specified by the client has been reached. Then they send their responses <m>v to the proxy.
Confirm
As more validators sign the message, a collection of their signatures continues to grow and eventually forms a quorum.
Once the required quorum is met, the proxy issues the certificate <m>#.
Technically, at this stage, the claim settlement request is final in the sense that it cannot be cancelled.
Pre-settle
Upon receipt of <m>#, each VSL validator checks the signature and the quorum # of the settlement certificate.
Settle
Each VSL validator settles the claim and updates its internal state.
Guarantees and properties
Safety from double-spending
As stated in the previous section, Fast prevents double-spending through its validator design and local state checking. If an actor issues two conflicting claims such as trying to spend the same tokens twice, validators will detect the conflict during validation.
Because each validator independently checks whether a claim is valid before signing it, conflicting claims cannot both reach quorum. Only one of the claims will gather enough validator support to be certified, while the other will be rejected or remain unfinalized.
This approach ensures that only one version of a conflicting action can become part of the global state, even without needing all validators to agree in advance or coordinate execution.
Quorum-based settlement
In Fast, a claim is not considered settled just because it was received or validated by a single party. Settlement only happens when a claim gathers enough validator signatures to meet a quorum threshold. These signatures are bundled into a certificate, which proves that the claim has been accepted by a sufficient portion of the network.
This model makes it easy to distinguish between claims that are pending and those that are final. Any system or client can rely on a certified claim with confidence, without needing to verify the state of the entire network. The quorum size and validator set can also be configured to meet the trust or decentralization goals of a specific deployment.
No forks or reorganizations
Fast’s design avoids the possibility of forks and chain reorganizations, issues that often arise in blockchain systems that rely on longest-chain rules or probabilistic finality.
Because Fast does not operate on a chain of blocks, and because a claim becomes final once certified by a quorum, there is no risk of an already settled claim being reversed. There are no rollbacks or reorganizations of the system state. Once a claim is certified, it is final and immutable.
This adds a level of predictability and stability that is particularly important in high-stakes applications like payments, AI verification, or data access control.
Verifiability and auditability
Every settled claim in Fast includes a certificate, which is simply a cryptographic proof that the claim was accepted by a quorum of validators. These certificates can be verified by any third party without needing access to the full validator set or network history.
This gives developers and system designers a reliable way to track and audit changes, verify outcomes, and build systems that can interface with Fast as a source of truth. Whether you are proving a payment happened, confirming an attestation, or recording the result of a verifiable computation, certificates provide tamper-proof, portable evidence.
In summary
Although Fast gives up traditional consensus and global ordering, it maintains clear, strong guarantees. It ensures that honest validators eventually converge to the same state, prevents double-spending, enforces finality through certificates, and eliminates the possibility of forks or rollbacks. All while enabling fast, parallel processing and cryptographic verifiability.
These properties make Fast a powerful protocol for modern decentralized applications, especially those that demand scale, reliability, and trust without consensus overhead.