# 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](/fast-archived/core-concepts/claims.md) 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](/fast-archived/core-concepts/weak-independence.md). 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.

<figure><img src="/files/h8uPE78IwoRY3Q8VtVKu" alt=""><figcaption><p><strong>Figure 1:</strong> Fast protocol.</p></figcaption></figure>

## 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

<p align="center">⟨<em>msg</em>⟩<sub><em>sk</em></sub></p>

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

{% hint style="warning" %}
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.
{% endhint %}

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 , ...}).

{% hint style="warning" %}
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.
{% endhint %}

## Protocol steps

{% stepper %}
{% step %}
**Claim**

Client A signs a sequence of claims c<sub>1</sub> c<sub>2</sub> ... c<sub>k</sub> and sends the signature m = \<c<sub>1</sub> c<sub>2</sub> ... c<sub>k</sub>,T><sub>A</sub> to the proxy.
{% endstep %}

{% step %}
**Verify**

The set of verifiers T requested by the client verifies the message m and signs it individually \<m>t1, \<m>t2, … \<m>tl.
{% endstep %}

{% step %}
**Validate**

The proxy receives the signatures from the verifiers and computes an aggregated signature \<m><sub>#T</sub>, which it sends to the validators.
{% endstep %}

{% step %}
**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><sub>v</sub> to the proxy.
{% endstep %}

{% step %}
**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><sub>#</sub>.

Technically, at this stage, the claim settlement request is final in the sense that it cannot be cancelled.
{% endstep %}

{% step %}
**Pre-settle**

Upon receipt of \<m><sub>#</sub>, each VSL validator checks the signature and the quorum # of the settlement certificate.
{% endstep %}

{% step %}
**Settle**

Each VSL validator settles the claim and updates its internal state.
{% endstep %}
{% endstepper %}

## 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.


---

# 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/fast-archived/core-concepts/fast-protocol.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.