Introduction

Payment systems have been around for centuries, evolving with society’s needs and technology. In prehistoric times, barter allowed goods and services to be exchanged without a common ground. As societies evolved, precious metals became the standard for trade, followed by metal coins, and by the late 15th century, banknotes emerged in Europe. The 20th century brought credit cards, and today, blockchain-based payment systems are shaping the next era of transactions.

Blockchains introduced a decentralized way to verify and record payments. To ensure trust, they enforce a strict total order on all transactions, requiring every node in the network to process them in the same sequence. This ordering solves the double-spending problem, preventing an account from making two payments with the same coins. However, it also entails every transaction to be chained to the next, preserving history at the cost of speed and scalability.

In our previous post, we explored the broader differences between FastSet and blockchains. In this post, we zoom in on one crucial aspect: transaction ordering. We’ll look at why FastSet moves away from the blockchain convention of total ordering, how the concept of weak independence makes this possible, and what that means for building faster and scalable payment systems.

Payment systems and transactions

The most intuitive way to describe a payment system could be as a mapping between a list of accounts to their balances. The payment system has a state, specifying the amount of coins in an account at a given time.

Figure 1: Payment system state.

The payment system can transition into a new state whenever a payment transaction takes place, as two account balances are updated: the one of the payment initiator and the one of the payment receiver.

Figure 2: A successful transaction changes the state of the payment system.

When Alice initiates a payment transaction, she creates a message in which she mentions the recipient of the payment, together with the number of coins she wants to send him, and then she signs the message: transfer(Bob, 80)_Alice.

If Alice has more than 80 coins in her account, then the transaction succeeds and Bob’s balance gets updated by 80 coins more, while Alice’s by 80 coins less. 

So far, so simple. But what if Alice initiates at the same time a transaction to Charlie transfer(Charlie, 65)_Alice?  It’s clear that Alice doesn’t have enough coins to perform both transactions, so in this case, how is double-spending avoided, or how are both transactions prevented from succeeding? The traditional solution is by ordering payments. 

In blockchains, all nodes agree on the exact sequence of transactions to be processed. If Alice tries to double-spend, one of her transactions will be placed first in the sequence and after it will be processed, it will render the second one invalid since her balance is updated.

Blockchains and total order

In the physical world, you can only spend what you own. In digital systems, however, there’s always the risk of double-spending.

To prevent this, blockchains enforce something that’s natural in physical payments: a strict, global ordering of transactions. Each transaction is processed in sequence, and once validated, it’s added as a block in the chain, linked to the one before it.

Figure 3: Blockchain nodes (purple boxes) process transactions (colored stripes) in the same order.

Consider the following sequence of transactions: 

transfer(Bob, 80)_Alice, transfer(Charlie, 20)_Dave, transfer(Dave, 18)_Bob , and transfer(Charlie, 6)_Alice. 

From the transactions above, two originate from Alice, while the other two originate from Bob and Dave, respectively.

In a blockchain, every node will process these transactions in exactly the same agreed order, for example as in Figure 4.

Figure 4: Payment system state change during processing a sequence of four payment  transactions.

But this raises a question: why should payments from different accounts be forced into a single global sequence? The answer is they shouldn’t.

FastSet and any order

Recent developments, such as The consensus number of a cryptocurrency, FastPay, and pod, reveal new insights supporting this statement: enforcing a total order on transactions is unnecessary, especially when they originate from different accounts.

For example, the order in which a specific account receives payments is irrelevant and it does not affect its final balance because addition (of payments) is commutative. Likewise, the order in which different accounts send payments is also irrelevant, provided their balance covers them all and there is no double-spending.

FastSet embraces this revelation and enforces any order on payments originating from different accounts, as they are considered unrelated. The reasoning is that if two payment transactions are unrelated-enough, then processing them in any order will lead to the payment system to be in the same state. And this is what we call weak independence. 

We generalize weak independence to any independently verifiable statement, which we call a claim, and we further extend this property to any set of unrelated claims. A claim could represent a vote, an auction bid, a balance change, or even the output of an AI model. In this view, a payment transaction would be one of the simplest types of claim about the balance change.

In FastSet, we allow any processing order on claims originating from different accounts, but we preserve a processing order on claims originating from a particular account. We enforce this by requiring the claims initiated from the same account to carry an increasing nonce, meaning, for example, claim c1 has nonce 1, claim c2 nonce 2, etc.

As such, the FastSet network prevents the double-spending issue by not processing claims if they don’t carry the expected nonce. In this way, a total order is only required on each account, but validators do not need to agree on a single total order.

Figure 5: Processing the same four transactions in Figure 4 in a different order leads to the same state.

Transactions from Alice have been processed in the same order, but transactions from Dave and Bob can be processed in any order and still lead to the same final state. Any interleaving of these transactions is valid for processing as long as the order is preserved for Alice’s transactions.

Because it allows for this flexibility in claims processing order, FastSet doesn’t enforce strong consensus, but strong eventual consensus. This means that eventually, nodes in the FastSet network will reach the same final state after having processed the same set of weak independent claims.

Figure 6: Nodes (purple boxes) in FastSet eventually converge to the same final state after processing the same set of claims (colored stripes).

Conclusion

By removing the need for a global transaction order, FastSet focuses on what actually matters: per-account sequencing and the safe parallel execution of weakly independent claims.

This approach allows nodes to process far more transactions in less time, without sacrificing the guarantees that prevent double-spending or inconsistent state. It’s a model built for speed, scale, and flexibility, not just for payments, but for any verifiable statement.

The result is a foundation for decentralized applications that can keep pace with modern demands.

To learn more about FastSet and how it works under the hood, you should check out our core concepts section of our docs and if you’d love to keep up with all our recent updates, follow us on X.