Introduction

At its core, a blockchain is a decentralized ledger––a public record of transactions that anyone can read and write to, provided they follow the rules.

Each new transaction is added in a block, and these blocks are chained together in the order they were confirmed. This structure guarantees transparency and trust, even when the network is made up of unknown participants.

Well-known platforms like Bitcoin, Ethereum, Solana, and Algorand all rely on this blockchain technology. They differ in how they validate transactions, mainly in how fast they operate, and how decentralized they are, but they all share the same fundamental trait, which is that every transaction must be recorded in a single, agreed-upon sequence.

However, FastSet takes a different path.

FastSet is a decentralized network optimized for massively parallel payments and claim settlement, on which the next wave of blockchains and verifiable computing applications can be built.

In this blog post, we’ll explore what makes FastSet fundamentally different from a blockchain. We’ll explain why it abandons total ordering, how it achieves parallel settlement without strongly consistent consensus, and why that unlocks a new class of scalable, decentralized applications.

On blockchains

To understand where FastSet diverges, it helps to look closely at how blockchains traditionally work.

As earlier stated, blockchains function like a public ledger. Anyone can submit a transaction, and once accepted, it’s grouped into a block and added to the chain—a continuous, immutable sequence of blocks that all participants agree on.

Each block contains a set of transactions and is cryptographically linked to the one before it, forming a verifiable history that cannot be altered.

Figure 1: Blockchain, in an oversimplified view.

In the diagram above, the colored lines represent transactions from two different accounts waiting to be settled, with yellow and red originating from the same account and with blue being the first transaction initiated, and yellow being the last. The rectangles at the top denote the blocks settled on the chain, with the light purple rectangle being the genesis block of the chain, and the yellow rectangle the last one settled. The left arrows depicts the links between blocks. The vortex icon represents the consensus or settlement algorithm (e.g., Proof of Work, Delegated Proof of Stake, or Pure Proof of Stake) used to decide which transactions get settled. The boxes represent the nodes of the network and the colorful stacks to their right denote the order in which transactions are appended to their local copy of the blockchain, with the one on the bottom representing the first transaction.

There are three major properties a blockchain is expected to satisfy: decentralization, security, and scalability.

• Decentralization means that anyone should be able to participate in deciding the next page of transactions to be written into the ledger.
• Security ensures that malicious actors cannot rewrite or corrupt the ledger’s history.
• Scalability means that as the number of transactions and users increases, the time it takes to write them to the ledger should remain somewhat constant.

Until recently, it was widely believed that a blockchain could only satisfy two out of these three properties at a time—a concept known as the blockchain trilemma and introduced by Ethereum co-founder Vitalik Buterin.

For example, Bitcoin started as a highly decentralized blockchain. However, it relies on Proof of Work (PoW) to determine who gets to write the next block, and this process only occurs roughly every ten minutes.

Over time, solving the PoW puzzle has become so computationally expensive that only a few large mining pools can currently compete, leading to reduced decentralization. Additionally, the ten-minute delay per block is a clear scalability limitation.

Ethereum attempted to address this with Delegated Proof of Stake (DPoS), selecting a fixed group of 21 delegates to decide which transactions are added next. While this speeds things up, having just 21 validators in a network of hundreds of thousands limits decentralization. Ethereum still struggles with scalability, and transactions remain slow and expensive to settle.

Blockchain trilemma and Algorand

The blockchain trilemma has been challenged in recent years by newer designs, most notably by Algorand, a blockchain developed at MIT by Turing Award winner Silvio Micali.

Algorand introduces a novel approach that aims to satisfy decentralization, security, and scalability without compromise, using a cryptographic tool called Verifiable Random Function (VRF).

VRF is a type of cryptographic function that transforms arbitrary input into a random-looking output, using a secret seed. The result is both random and verifiable, so much so that anyone can check that it was honestly generated, without learning the secret behind it. Algorand uses VRFs to randomly select who gets to participate in the next round of transaction settlement.

Rather than relying on PoW or DPoS, Algorand uses a Pure Proof of Stake (PPoS) consensus algorithm. In this system, 1,000 users are randomly selected to validate transactions in each round. The chance of being selected is proportional to the number of tokens a user holds, but the selection is unpredictable and private, which makes the system resistant to manipulation.

This design helps Algorand achieve the three goals of the trilemma:

• Security, because attackers cannot predict or influence who will be selected.
• Decentralization, because any token holder can be chosen to participate.
• Scalability, because selection takes just a microsecond and does not require global coordination.

Algorand’s approach shows that it’s possible to challenge the trade-offs that defined early blockchains.

However, while it solves many problems, one key limitation still remains and that’s where FastSet draws a different line.

No total order and FastSet

Algorand makes impressive strides toward solving the blockchain trilemma. However, it still holds on to one of blockchain’s most rigid features: the idea that transactions must be totally ordered.

A total order means that every transaction is placed in a single, global sequence. Every participant in the network must agree not only on which transactions happened, but also on exactly when each one happened relative to the others. This ordering is essential for preventing double-spending and ensuring consistency but it comes at a high cost.

In reality, most transactions are independent of each other. If Alice sends tokens to Bob, and Carol sends tokens to Dave at the same time, the two transfers don’t conflict, they could happen in any order. Enforcing a global order in such cases is unnecessary overhead.

FastSet takes a different approach.

Rather than using a list of transactions (or ledger) as blockchains do, FastSet maintains a set of transactions whose processing order is not as strict, as long as they don't originate from the same accounts. More specifically, FastSet enforces total order on transactions originating from the same account, but no restrictions on transactions from different users.

Note that although we refer to transactions, FastSet isn't just for payments. It supports any kind of decentralized operation, from voting and identity verification to verifiable computations. And to capture the entire range we use the term claims, with transactions being a special type thereof.

From further on we are going to refer only to claims, instead of just transactions, to capture the whole capabilities of FastSet.

Figure 2: FastSet, in an oversimplified view.

In the diagram above, the colored lines represent claims from two different accounts waiting to be settled, with yellow and red originating from the same account and with blue being the first claim initiated, and yellow being the last. The vortex icon represents the settlement process. The boxes represent the nodes of the network and the colorful stacks to their right denote the order in which transactions are processed, with the one on the bottom representing the first one. Each node processes the claims independently and while they may follow a different sequence, they all converge to the same final state. Note that the red transaction is always going to be processed before the yellow one, as both originate from the same account and transaction order in this case has to be preserved. This behavior works because FastSet does not rely on a strong consistency consensus algorithm, but on eventual consistency.

In FastSet, any node can act as a validator and unlike in classical blockchain protocols, they do not need to talk to each other. There’s no mining, staking, or leader election. Claims are simply broadcast, and validators independently verify them. 

Once enough validators approve a claim, it becomes certified, meaning it’s accepted by the network and safe to apply to the validator’s local state.

So how does FastSet achieve consistency without enforcing a strict order on transactions?

It builds on a clever insight: most claims are not related, as they originate from different users. And if claims waiting to be settled are "unrelated-enough" then they can be processed in any order by different nodes and still end up in the same state. This is one of the core innovations of FastSet, which we call weak independence.

Scalability in FastSet comes not just from the weak independence of claims, but also from validator independence. Rather than coordinating globally, each validator checks claims on its own. Certification replaces consensus and only certified claims are applied to the local state.

It’s not a blockchain. It’s better

Blockchains brought us a new way to coordinate trust in a decentralized world but they came with trade-offs.

Every improvement in scalability or speed has traditionally meant giving up something else, whether it’s decentralization or security. Even with modern designs like Algorand, the assumption that all transactions must be globally ordered still limits how far these systems can scale.

FastSet challenges that assumption entirely. By settling claims without global consensus and letting validators work in parallel, it unlocks a new model for decentralized applications, one where throughput increases naturally as more validators join. No bottlenecks. Just massively parallel settlement at the speed of the network.

If you’re curious about how it works under the hood or want to see how it fits into your applications, check out the whitepaper, explore our docs, or follow us on X (Twitter) to stay in the loop as we continue building with FastSet.