What is TPS?
TPS is short for transactions per second. It's the most common performance benchmark for blockchains.
But there's a lot of smoke and mirrors around how it's calculated —There's no one standard benchmark, what it implies, and what the number actually means for dapp developers and end users.
What is TPS?
TPS stands for transactions per second and is a common metric for blockchain performance. It’s often cited, and has become an important metric for blockchain comparison.
However, it is an extremely misleading metric as: (1) there is no universal method for obtaining TPS, and (2) it is trivial to boost the metric using simplified environments, and/or simplified transactions such as transfers.
What is a Transaction?
A transaction is the generic term for an on-chain action that results in updated state.
Different types of transactions include a transfer, the execution or deployment of a smart contract, and data processing or updates.
Transactions can range in complexity and time to execute, many of them requiring substantially more computing power and state resources than simple transfers.
What is a Transfer?
A transfer refers to the transfer of digital asset balances from one wallet address to another. A transfer is also the simplest form of a transaction, which means all transfers are transactions. But not all transactions are transfers.
How is TPS misleading?
TPS is misleading for two primary reasons: (1) there is no universal method for obtaining a TPS metric, and therefore (2) it is trivial to boost the metric using simplified environments, and/or simplified transaction data such as transfers.
For now, we’ll focus on (2).
Recall that transfers are the simplest type of transaction. If one were to benchmark a blockchain’s performance based off of transfers alone, you could expect to get very high TPS numbers. Why? Because executing transfers is trivial.
To cite a TPS metric born of transfers alone is extremely misleading as it does not properly represent the full scope of transactions. Instead, this would yield a vanity metric, or a “theoretical TPS” metric. And notably, while the acronym technically works, TPS is not short for transfers per second.
Transfers are a subset of transactions, which means that all transfers are transactions.
However, it’s important to note that not all transactions are transfers. And in fact, recent transaction history of live smart contract networks reveals that transfers are just a small subset of all transactions.
What is Theoretical TPS?
Theoretical TPS typically refers to the highest number of transactions a chain could possibly produce in the most ideal of scenarios: i.e. transfer-only transactions and very centralized nodes.
Theoretical TPS has been used as the basis of “max TPS” metrics for many years now. We’ve seen claims of 1,000 and 10,000 and upward of 100,000 max TPS metrics across various blockchains.
But these are theoretical for a reason! We don’t see these performance numbers in the wild. Production environments do not reflect ideal conditions which renders theoretical TPS a meaningless, misleading metric. A meaningful metric would be one that reflects “Real” TPS.
What is Real TPS?
Real TPS is in direct opposition to the theoretical and hypotheticals, but is instead based on real-world, live-production data.
Using recent historical data gives a far more realistic, accurate view into true blockchain performance, and what users can expect to see!
Why? Because the types of transactions on-chain also change over time. The first several million blocks on Ethereum included very basic transactions, but more recent transactions are far more complex, calling intricate smart contracts with multi-step calculations like atomic transactions!
Monad gives you Real TPS. Monad uses real and recent Ethereum data, published on-chain to give actual, usable meaning to TPS.
Build on the fastest EVM-compatible layer 1 blockchain.
Join the Monad ecosystem and bring your vision to life. Build cutting-edge applications, access advanced resources, and receive support to grow your project.
Featured Blogs
Dive into our latest blogs for cutting-edge insights and industry trends.
Frequently Asked Questions
Yes! The Monad blockchain is 100% EVM compatible at the bytecode level — meaning contracts from ETH mainnet, or other fully EVM compatible networks will work out-of-the-box without requiring any code changes.
Simply deploy your EVM smart contracts on the Monad blockchain to experience game-changing cost reduction and performance.
MonadDb is the world’s first database purpose-built for the EVM. The EVM requires data to be stored in a special cryptographic data structure, known as a Merkel Patricia Trie (MPT), which allows for succinct verification of blockchain data.
MonadDb leverages the latest advancements in Linux kernel technology to support parallel state access, greatly reducing the overhead of database access and allowing system resources to be used elsewhere during parallel execution.
In contrast, off-the-shelf databases are largely suboptimal for storing MPT data, which may result in applications downloading significantly more data for verification, or otherwise pose significant challenges to blockchain scalability.
The Monad client is built with a modular software architecture, separating the tasks of consensus and execution between two software modules: the consensus client and execution client respectively.
The consensus client is written in Rust which is a memory-safe language that allows for low-level optimizations. The execution client is written in C/C++, well-established and battle-tested languages for developing low-level system critical code.
The Monad network is a full stack solution for developers, allowing access to a highly composable ecosystem without compromising on real-time censorship resistance.
While L2 solutions may offer one way to compress data stored on the base layer, the Monad blockchain is a scalable base layer for the EVM itself at it's most fundamental layer.
A highly-performant base layer gives application developers the best of both worlds, with a high degree of composability and real-time censorship resistance in the name of scalability.