# FastPay: The Consensusless Protocol By [Cryptolytic](https://paragraph.com/@cryptolytic) · 2025-08-05 --- Introduction ------------ Recently there has been a lot of hype around the topic of parallel execution, and today we are going to dive into one of the approaches that can also be used to achieve it, the consensusless protocol called FastPay. You might not have heard this name before, but you may be surprised to learn that many projects such as Sui, Linera, and Pod have adopted its concepts to reduce latency, enable parallel processing, and allow horizontal scalability. In this post, we will explore the idea behind consensusless protocols and explain how FastPay works as our main example. Let’s dive in. Overview: The Idea of Consensusless Protocols --------------------------------------------- ### Consensus and Double Spending Let’s take a step back and talk about why consensus is needed in decentralized systems. It is quite intuitive to think that in a system without a central authority, there must be some way for the nodes maintaining the network to agree on what is valid. This is where a consensus protocol comes in. It allows nodes to agree on a value or the state of the system. In Bitcoin, for example, the consensus protocol ensures that there is only a single total order of transactions or a single canonical chain. This prevents the double spending problem, where a malicious user may try to spend the same funds twice. To be more specific, assume Alice has 1 BTC. She sends 1 BTC to Bob, which we will call transaction $$t\_{AB}$$, and also sends the same 1 BTC to Carol, which we will call $$t\_{AC}$$. If Alice initiates $$t\_{AB}$$ and $$t\_{AC}$$ at the same time but sends each transaction to different nodes, say node $$X$$ and node $$Y$$ respectively, then without a consensus protocol, node $$X$$ and node $$Y$$ would not have a way to agree on the order of $$t\_{AB}$$ and $$t\_{AC}$$. They would not know which transaction to approve first. Even worse, suppose there is a network issue where node $$X$$ can communicate with Alice and Bob but not with Carol and node $$Y$$. In this case, Bob would think he received 1 BTC from Alice, and Carol would also believe she received 1 BTC from Alice. Alice has now spent the same 1 BTC twice. But if node $$X$$ and node $$Y$$, along with the rest of the network, have a way to totally order every transaction sent to the system, then they can solve the double spending problem. Here, a total order of transactions means that every transaction is ordered relative to every other transaction. You can determine whether transaction A happened before or after transaction B, even if they are unrelated. So the network can decide whether $$t\_{AB}$$ came before $$t\_{AC}$$. If $$t\_{AB}$$ is ordered before $$t\_{AC}$$, then the transfer from Alice to Bob would succeed, and the transfer to Carol would fail due to insufficient funds. ### Well, Do We Really Need Consensus? Even though consensus protocols help prevent double spending and allow nodes to agree on the same state, there is a deeper issue. The core limitation of consensus is that it tries to totally order every transaction and produce a single global sequence that everyone agrees on, even when some transactions are causally independent. For example, consider the following situation: 1. Bob does not own any BTC but wants to send 0.25 BTC to Carol. 2. Alice sends 0.5 BTC to Bob. 3. David sends 0.1 BTC to Eve. From the above, we can see that Bob cannot send BTC to Carol until he receives it from Alice. So transaction 1 depends on transaction 2. However, David's transfer to Eve is completely independent of what Alice and Bob are doing. Transaction 3 is causally independent from transactions 1 and 2. It can be processed in parallel, without waiting for anything else. But with total ordering, the system must still impose a single sequence on all three. For example: * If the system orders them as 3, 2, 1, then transaction 3 is processed first, followed by 2 and then 1. * If the order is 2, 1, 3, then transactions 2 and 1 are handled before 3. This kind of global ordering forces unnecessary serialization, even when some transactions do not interact at all. And that is just one problem. Consensus also introduces other performance issues, such as: * Validators typically require several rounds of communication to agree on a single value. * If the communication layer is not well optimized, it may take time for validators to receive a proposed block from the leader or from their peers. * In leader-based consensus protocols, a malicious leader can stall progress. So if consensus is this inefficient, why do researchers and projects still keep developing new versions of it? Do we really need consensus? The answer is yes, but not always. Let’s first discuss when we do not need consensus. ### When We Can Avoid Consensus As we discussed earlier, consensus and total ordering are necessary to prevent double spending. But total ordering is often too strong. In many cases, a partial order is enough. A partial order allows the system to define the relative ordering of only those transactions that are causally related, while letting unrelated ones remain unordered and processed independently. With this idea, validators can process independent transactions immediately, in parallel, as soon as they receive them. There is no need to communicate with other validators first to agree on a global order. This eliminates a major source of overhead. But what about transactions that are causally dependent, like the case with Alice, Bob, and Carol? Validators still need to agree on their order to prevent double spending. Could we allow validators to agree on such an order without directly communicating with each other? Surprisingly, yes. This can be done by allowing the initiator of a transaction or the fund owner to propose the order. The proposed order must then be independently approved by a supermajority of validators before it is accepted by the network. ### When Consensus Is Unavoidable The previous examples involved simple transactions, where asset owners want to spend their own funds or coins. In these cases, they can propose the order of their transactions by themselves. But in more general use cases, such as decentralized applications like DeFi, it is not that straightforward. Consider a liquidity pool. No single user owns the state of the pool, yet many users might interact with it at the same time. The problem is that transactions on shared state usually do not commute. One transaction changes the state, and any following transactions are affected because they interact with the updated state. Since no single party owns the state, there is no natural way to determine the order of transactions without first agreeing on it. This is where consensus becomes necessary. It provides a reliable mechanism for multiple parties to agree on a single, consistent state when they interact with shared data. I hope this gives you a better sense of when we need consensus and when we can avoid it. In the next section, I will walk you through the FastPay protocol, which brings this concept to life. By the end, I hope you will have a much clearer picture of how the system works and a deeper understanding of consensusless protocols in general. The Introduction to the FastPay Protocol ---------------------------------------- Now it is time to see how the concept of a consensusless protocol can be put into practice by understanding how FastPay works. In the FastPay paper, FastPay is introduced as a side chain of a main blockchain, referred to as the Primary. FastPay consists of two types of participants: users (or account owners) and authorities. Users are individuals who maintain accounts on FastPay and use them to send and receive funds. Authorities, as the name suggests, are responsible for authorizing payments and keeping track of all accounts in the system. You can think of them as similar to validators. In FastPay, a payment is initiated by a sender who creates a transfer order and broadcasts it to each authority individually. The sender then aggregates the signatures from authorities that approve the validity of the transfer. Once approvals from at least two-thirds of all authorities are collected (also referred to as a quorum of authorities), a transfer certificate can be formed. This certificate is sent to the receiver and can be used as proof to finalize the transfer. After that, either the sender or the receiver can broadcast the certificate to all authorities to complete the process. FastPay is designed to be Byzantine fault tolerant. It can tolerate up to one-third of the authorities being faulty or malicious, while still operating correctly and safely. How Does It Work in Detail -------------------------- ![Figure 1: This figure illustrates the transaction flow in FastPay.Source: arxiv.org/pdf/2003.11506.pdf](https://storage.googleapis.com/papyrus_images/986b66a68194ab04a1d9c57bd32d17c33aaf67d55f4e4d0fe85a387fbe650da2.png) Figure 1: This figure illustrates the transaction flow in FastPay.Source: arxiv.org/pdf/2003.11506.pdf Now that we understand the roles of users and authorities, let’s take a closer look at the transaction flow inside FastPay. Instead of relying on a validator to batch user transactions into a block and broadcast it to other nodes, as traditional blockchains do, FastPay revolves around the user who initiates the transaction. Assume Alice wants to send some funds to Bob. She first creates a transfer order ➊ by specifying Bob’s FastPay address, the amount to send, a sequence number, and finally her signature on the data. The sequence number starts from 0 and increments with each new transaction. It acts like a nonce in blockchains and helps prevent replay attacks by ensuring each transaction is unique. Alice then sends the signed transaction to all authorities. When an authority receives Alice’s request, it checks the validity of the transaction ➋ by ensuring: 1. The signature is valid. 2. Alice has no pending transactions. 3. The amount is positive. 4. Alice's balance is sufficient. 5. The sequence number matches the expected value (that is, if her last successful transaction was number _N_, the new transaction must have sequence number _N + 1_). If the transaction passes all checks, the authority marks the transaction as pending and sends back their signature to Alice ➌. Condition 2 is effectively a locking mechanism, as the validator will not accept a new transaction request from Alice until the pending status is cleared. Once Alice collects signatures from a quorum of authorities (at least two-thirds of the total), she can form a certificate for the transaction. To finalize the payment, Alice has two options: * She can broadcast the certificate to all authorities herself ➍, or * She can send the certificate to Bob ➎, who may then broadcast it on her behalf ➏. Upon receiving the certificate, each authority proceeds to finalize the transaction ➐ by: 1. Verifying that the certificate contains a sufficient number of signatures. 2. Deducting the transfer amount from Alice’s balance. 3. Increasing her sequence number by one. 4. Clearing the pending status on her account. 5. Storing the certificate in their local record. 6. Adding the transferred amount to Bob’s balance. This completes the transfer from Alice to Bob within FastPay. Horizontal Scaling ------------------ ![](https://storage.googleapis.com/papyrus_images/f2dd71fd8ca48f60c489a63c667d7bd394da6645153e2f7a71a18968398bb2aa.png) Each payment that occurs in FastPay requires minimal state sharing. An independent transaction, such as a transfer from Alice to Bob or from Charlie to Dave, involves only two accounts. This means each transaction can be processed separately without interfering with others. For simplicity, let’s imagine that one computer handles one transaction at a time. Since these transactions are asynchronous and independent, they can be distributed across different machines. To make this more efficient, each authority can split its workload into shards, where each shard is a lightweight processing unit that handles a separate stream of transactions. This allows authorities to scale horizontally by assigning shards to different CPUs or cores, so transactions can be processed in parallel. In practice, one can simply scale up the number of CPUs to handle more transactions instead of adding more machines. Some Results ------------ The fact that this architecture is horizontally scalable makes FastPay seem like a promising protocol for supporting a large number of transactions at the same time. There are also many variables that affect performance. The number of authorities and shards is one of the most obvious ones. Even though scaling up the number of shards leads to higher system throughput, increasing the number of authorities, on the other hand, slows down the confirmation process. ![Figure 2: The confirmation order throughput plot with the number of shards and the in-flight parameter (the maximum number of transactions that are allowed into the system at any time).](https://storage.googleapis.com/papyrus_images/6a9a4e61ce5daffe2ecf035a37eca5613abd0f34bd0c07115ad8e4e6242d3f32.png) Figure 2: The confirmation order throughput plot with the number of shards and the in-flight parameter (the maximum number of transactions that are allowed into the system at any time). Figure 2 shows that the system’s throughput increases linearly with the number of shards, which is what we would expect. Then it plateaus after around 48 shards, which makes sense since they ran the experiment on a 48-core physical machine. ![Figure 3: The confirmation order throughput plot with the number of authorities for 45 and 75 number of shards, where in-flight parameter is fixed to 1,000.Source: arxiv.org/pdf/2003.11506.pdf](https://storage.googleapis.com/papyrus_images/9f7a05037fb8b9e28c172d60a56e7e486af979bf66a87b8909e667cd91617ef3.png) Figure 3: The confirmation order throughput plot with the number of authorities for 45 and 75 number of shards, where in-flight parameter is fixed to 1,000.Source: arxiv.org/pdf/2003.11506.pdf Figure 3 is quite interesting. It shows that system throughput drops significantly when the number of authorities increases. This behavior is intuitive because a user needs more time to interact with more authorities in order to form a certificate. Summary ------- In this post, we explored the idea behind consensusless protocols and walked through how FastPay brings that idea to life in the form of an efficient payment system. Unlike traditional blockchains that rely on global consensus to totally order all transactions, FastPay takes a different approach. By allowing users to initiate transactions and propose their own ordering, transactions can follow a partial order based on their causal relationships. This enables parallel processing and horizontal scaling. Furthermore, since users are the ones who drive the protocol forward, it removes the need for validator-to-validator communication and helps reduce protocol latency. However, protocols like FastPay are limited to basic payment transactions and are not designed for situations where users interact with shared state, such as a liquidity pool. In such cases, where transaction ordering must be globally agreed upon, consensus is still necessary. Although FastPay may not be suitable for general-purpose applications on its own, many modern blockchains such as Sui, Linera, and Pod have extended and incorporated its core ideas into their architectures. For example, Sui combines a consensusless fast path with a traditional consensus mechanism, allowing certain types of transactions to bypass the consensus layer. This helps reduce latency while improving scalability and flexibility. FastPay may not be a complete solution for every problem, but it shows that by rethinking the role of consensus, we can unlock powerful new design spaces for building high-performance decentralized systems. --- *Originally published on [Cryptolytic](https://paragraph.com/@cryptolytic/fastpay-the-consensusless-protocol)*