What is a Bitcoin Teranode? The 1,000,000 TPS Engine That Eats the Old Internet
By Kurt Wuckert Jr.
Visa, the largest payment network on Earth, processed 329 billion transactions in its most recent fiscal year.¹ Run the math. That averages out to about 10,400 transactions per second across the entire global network of 220+ countries, $16.7 trillion in volume, 175 million merchants, and 4.9 billion cards.
Last year, a single Teranode test cluster running on AWS just sustained 1,000,000 transactions per second, with zero loss, for two solid weeks across six countries.²
This is validated and confirmed in a peer-validated benchmark from a 2026 case study published on the AWS Web3 Blog and authored by an AWS Senior Solutions Architect.² One Teranode network. Ninety-six times the throughput of Visa's actual daily traffic. The argument over whether Bitcoin can scale is over. It just got buried under a million transactions a second.
*If you would rather watch the video Livestream of this article, watch here.
By the time you finish reading this you will know what a Bitcoin node actually does, why the old monolithic design hit a wall at thirteen thousand transactions per second, and what "containerized blockchain workers" means in plain English. We are going to walk through the entire stack.
If this is your first time on the site, start with the beginners guide to Bitcoin and come back. Everyone else, let's go for a ride!
One Teranode test cluster sustained 1,000,000 transactions per second with zero loss across six AWS Regions for two consecutive weeks. Source: AWS Web3 Blog.²
What a monolithic Bitcoin node is actually doing
Notably, this section is treating Bitcoin Core, and its downstream baggage in Bitcoin Cash and the SV Node implementation as the reference, which has some philosophical and technical baggage in the absolute sense, but in the interest of clarity and practicality, all bitcoin-based blockchains function the way they do as a downstream effect of Bitcoin Core's engineering decisions in the BTC reference client, which truly should be differentiated from Satoshi Nakamoto's engineering decisions in the original bitcoin protocol, but that is out of scope for this article.
A Bitcoin node is the world's most paranoid bookkeeper. It does five jobs, all at once, all the time:
It listens for new transactions coming in from peers across the P2P network.
It checks that every one of those transactions is valid: real signatures, no double-spends, no nonsense scripts, the sender actually owns the coins they are trying to move.
It holds the valid ones in a waiting room called the mempool until a miner is ready to put them into a block.
It builds candidate blocks if it is a miner, or verifies brand-new blocks coming in from other miners if it is not.
It tells every other node in the network what it just learned.
That is the entire job. Listen, check, hold, build or verify, broadcast. Five threads of work, running in lockstep, on the same machine, inside the same binary and only capable of doing all 5 threads using the resources on the machine where it lives. This is the design Satoshi shipped in 2009 and it is the design that every reference node, including Bitcoin Core and BSV's existing SVNode, has inherited for over fifteen years.
That word, monolithic, is doing real work. Remember it, because we are about to break it open.
How a monolithic Bitcoin node works under the hood
Imagine one engineer running a small accounting firm out of one office. They answer the phone, open the mail, log every transaction in the ledger, double-check the math, file the paperwork, and write the monthly report. Add ten clients and the office still works. Add ten thousand and the engineer is on the phone while the mail piles up while the ledger goes unchecked while the report runs late.
The monolithic node: one office, five jobs, shared fate. SVNode peaked at exactly 13,614 transactions per second before the architecture itself became the bottleneck.²
A monolithic Bitcoin node is exactly that office. One binary running on one server. Inside the binary: a network thread chatting with peers, a validation thread checking signatures, a mempool sitting in RAM, a UTXO database tracking unspent outputs, a block builder grinding on candidate templates. They share memory. They share locks. They share fate.
When transaction volume goes up, every one of those threads competes for the same CPU, the same RAM, the same disk. Validation slows down propagation. Block building stalls validation. The whole node becomes a traffic jam where nothing on the road is moving because everything on the road is in everyone else's way. Anyone who lived through the 2017 bull run can confirm what it's like to lose transactions on the BTC network. It's terrifying, especially when the Bitcoin pamphlet talks about "uncensorable, sovereign money" at every tweet...
According to the AWS case study, BSV's existing SVNode reference software, the most performant monolithic Bitcoin node in production, peaked at exactly 13,614 transactions per second before the architecture itself became the bottleneck.² That is not a small number. It is roughly the same throughput as Visa's average daily load.¹ But it is the ceiling. There is no version of "tune the binary harder" that gets a single-process node to a million per second. The walls of the office are the walls of the office.
What Teranode does differently, in simple terms
Same five jobs, but a vastly different way of doing them.
Instead of one binary doing all five, Teranode runs each job as its own program on its own hardware. Listening is a service. Validating is a service. Holding the UTXO state is a service. Building blocks is a service. Talking to peers is a service. Each one can be scaled independently. If validation is the bottleneck, you spin up more validators. If transactions are flooding in from one region, you add more propagators just there. No more traffic jam. You just add lanes where they're needed.
That is the structural shift, and it is the one most people miss, but it is not even the biggest one.
The biggest one is philosophical.
The old node is episodic. Transactions sit in a mempool. Nothing happens to them as a block. Then a miner finds a block, the network floods with verification work, things settle, the mempool refills, and the cycle repeats every ten minutes. Burst, idle, burst, idle. A heart that only beats when it absolutely has to.
Teranode, on the other hand WAAAAY over there, is continuous. Transactions are validated and packed into Merkle subtrees the instant they arrive. Those subtrees, each one capable of holding up to a million transaction IDs with full Merkle path connectivity, are broadcast across the network every second.² By the time a block is "found," its contents are already pre-agreed across the network, bypassing the concept of "the mempool" completely.
Block validation collapses from minutes to seconds, regardless of how big the block is: Thank you Ralph Merkle!
This is the actual breakthrough. As BSV Association CTO Siggi Óskarsson put it bluntly in the AWS case study: "A lot of the blockchain stuff is based on assumptions. So if you work from those assumptions, you get to some conclusions, and you get stuck. And we had to break some of those assumptions."²
Breaking the right assumptions is the entire game.
Episodic mempool blockchains versus Teranode's continuous Merkle subtree broadcast. The mempool stops being a waiting room.²
How a containerized system works
Step out of Bitcoin with me for one paragraph. We need a clean analogy.
A monolithic server is a one-chef food truck, or a food cart outside of a pub. The chef takes the order, preps the food, cooks the food, plates the food, runs the food, washes the dishes, and bills the table. It works fine when you have four customers or low expectations of volume. It collapses when you have a Saturday night line out the door.
A containerized system is a real restaurant. There is a host on the door, a server taking orders, a prep cook chopping, a line cook on the grill, an expediter plating, a runner delivering, a dishwasher in the back, and a bookkeeper at the till. When the grill gets slammed on a Saturday night, you do not rebuild the restaurant. You add a second grill cook. When the dish pit falls behind, you add a second dishwasher. Every job is a specialist. Every specialist can be cloned on demand, and the efficiency can be scaled up to the limits of the space, or even by building more restaurants that use the same systematic model.
In computing, those specialists are called containers. A container is a tiny self-contained bundle of one program plus everything it needs to run. The manager that decides how many of each container to run, where to run them, and what to do when one dies is called Kubernetes. Amazon sells managed Kubernetes as EKS, which is great, but it can also deployed locally like we have done at GorillaPool. Containers talk to each other through high-throughput message buses like Apache Kafka. They store hot data in memory-resident databases like Aerospike or even a local postgres database.
If that paragraph felt like an information dump, that is because it is (sorry). Every name in it shows up in the actual Teranode architecture. The reason the BSV Association built Teranode on AWS is that the cloud-scale tooling for running a containerized fleet has matured to the point where you can deploy a thousand specialized workers across six continents and have them act like one node. That capability did not exist in 2009. It does now, and it has, so far, been insane not to use them in the blockchain space.
The specific Teranode workers, named
The official Teranode documentation names sixteen distinct services that make up a Teranode deployment.³ I am going to walk every one of them, grouped by what they actually do, so you can hold the map in your head.
The intake crew: transactions arriving
Asset Server: the front door for clients submitting new transactions and for apps querying state. Think of it as the receptionist.
Propagation Service: the firehose. Distributes incoming transactions across peers and across the cluster so that every validator sees them as soon as possible.
Validator Service: checks the basics on every individual transaction. Signatures valid? Inputs unspent? Scripts well-formed? No double-spends? This is the bouncer.
The assembly line: turning transactions into blocks
Subtree Validation Service: validates the Merkle subtrees as they are continuously assembled. This is the Teranode-specific innovation. Each subtree can hold up to a million transaction IDs with full Merkle path connectivity, and they are broadcast across peers every second.²
Block Assembly Service: packs validated subtrees into a candidate block. Because the subtrees are already pre-validated and pre-agreed, block assembly is no longer a frantic last-second job. It is just stitching.
Block Validation Service: when a peer publishes a brand-new block, this service verifies it. In seconds. Regardless of size.
Blockchain Service: keeps the canonical chain state and arbitrates reorgs.
The persistence layer: memory and storage
UTXO Store: the spendable-coins database, backed by Aerospike running on EC2 instances with NVMe SSDs (or local database of your choice). This is the hottest path in any Bitcoin node and Aerospike was chosen specifically for low-latency, memory-buffered access at very high volumes.²
UTXO Persister and UTXO Seeder: long-term archival of UTXO state and bootstrap of new nodes joining the network.
Block Persister: durable archive of finalized blocks.
Blob Store: bulk storage for transaction and block blobs, backed by S3 and FSx for Lustre for shared access across services.²
The network and ops layer
P2P Service: talks to other Teranodes.
Legacy Service: speaks the old Bitcoin protocol so that a Teranode can sit on the same network as an existing SVNode and trade blocks with it. This is the migration path. Teranode does not fork. It joins.
RPC Service: the JSON-RPC API for miners and applications.
Alert Service: internal "something is wrong" broadcaster for the cluster.
Sixteen services. Every single one of them is its own scalable container, deployed and managed by a custom Kubernetes operator that the BSV Association engineering team built specifically for this stack.² If your hot path is signature validation, you spin up more Validator pods. If propagation in Frankfurt is the bottleneck, you spin up more Propagation pods in Frankfurt. The monolithic node had one knob: buy a bigger machine. Teranode has sixteen knobs and a thousand levers.
Sixteen specialist services. Subtree Validation is the Teranode-specific innovation.³
The funny thing is, this is what serious software has looked like for fifteen years. Netflix runs on containerized microservices. Amazon runs on containerized microservices. Google runs on containerized microservices. Facebook runs on containerized microservices. The only blockchain that ever bothered to actually do this work for the base layer is BSV, because it is the only one that needs to scale on-chain instead of pretending the problem can be solved on a layer two.
How Teranodes replace monolithic nodes, and what the upgraded network looks like
This is the part that lots of people assume or have said is a hard fork. It is not, but I'll spend some time explaining.
Teranode speaks the same Bitcoin protocol that the old SVNodes speak. That is what the Legacy Service is for. A Teranode and an SVNode can sit on the same network today and trade blocks without anyone noticing. There is no flag day. There is no fork. There is a public TeraTestNet running right now for anyone who wants to point a node at it.⁴ If you mine, you can run Teranode tomorrow and the network does not care.
The benchmark is on the record. Six AWS regions. A 1,000,000-transactions-per-second sustained load. Two consecutive weeks of zero transaction loss. 66.67 times the throughput of SVNode² according to a peer-reviewed AWS case study, written by an AWS Senior Solutions Architect named Jordan Kramsky, sitting on the AWS Web3 Blog with the URL printed on the byline. Read it yourself.²
The design does not stop at a million. The official BSV Association protocol page describes Teranode as having "no built-in limits" and notes that operators can scale to roughly 5,000,000 TPS by simply adding more resources.⁴ For context: Visa's stated peak capacity is around 65,000 TPS.⁵ The Bank of England's published throughput target for a UK digital pound CBDC is 30,000 TPS, with potential for 100,000 TPS.⁶ Teranode laps every one of them by a factor of ten to a factor of a hundred.
Where Teranode sits against the rest of the global payments stack. The orange bars run off the edge of the slide on purpose.¹²⁴⁵⁶
The upgrade path is the unsexy part that matters most. As individual miners migrate from SVNode to Teranode, the network's effective throughput ceiling rises with every operator who flips the switch. There is no community vote, no soft fork, no developer holding a key to the gate. A miner who wants more capacity runs the new software. The network becomes Teranode the same way the internet became broadband: one upgrade at a time, until the old way looks absurd. The BSV Association calls the broader vision of this fully-Teranode-native network the Mandala design.² Block validation in seconds means competing miners stop bleeding compute on verification and get back to actually mining valid blocks. Fees stay honest. The network stays honest. The economics are restored to the model Satoshi actually wrote in 2008.
The Mandala network: what the upgraded BSV network looks like once Teranode is fully deployed.²
I have been pointing at this AWS case study since the day it dropped because it is the cleanest validation any blockchain project has ever received from a hyperscaler. AWS does not blog about projects that do not work. They blog about reference architectures that other engineering teams should learn from.
Closing thoughts
Every other Bitcoin team spent the last decade arguing whether the network should scale. The BSV Association, with help from GorillaPool and other parties in the BSV ecosystem, spent the same decade quietly building the thing that does. While BTC partisans were busy promoting Lightning Network as a cope for the small-block decision, Siggi Óskarsson and the Teranode team were five years deep into the actual engineering problem, breaking the architectural assumptions that everybody else accepted as gospel, working with AWS engineers in Zurich, and grinding through scaling iterations from 50,000 TPS in 2021 to a million TPS in 2026.² One generation of Bitcoiners spent the same period selling JPEGs, asking Jeffrey Epstein for money, and arguing about ETF inflows.
A million transactions per second is not a stunt. It is the entry fee for the actual job Bitcoin was designed to do: global peer-to-peer cash, machine-to-machine micropayments, on-chain commerce that does not need a custodian. Visa's whole network, every Black Friday in every country in every year, is a rounding error against one Teranode region.
The monolith served Bitcoin honorably for fifteen years. Now it is a museum piece. The future is containerized, continuous, and counted in millions per second.
If you build, point something at TeraTestNet today and find out what your application looks like when fees go to fractions of a penny and confirmations come in under a second.⁴ If you are still trying to figure out which Bitcoin is the real one, I will save you the trouble: it is the one you can actually use.
Footnotes
¹ Visa Inc., Visa Fact Sheet, FY25 Q4: 329 billion total transactions for the 12 months ending September 30, 2025; $16.7 trillion total volume; 220+ countries; 175 million merchant locations; 4.9 billion payment credentials worldwide. Average TPS calculated as 329,000,000,000 ÷ (365 × 86,400) ≈ 10,433 TPS. Source: https://usa.visa.com/dam/VCOM/download/corporate/media/visanet-technology/aboutvisafactsheet.pdf
² Jordan Kramsky, "How the BSV Association built a million-TPS blockchain node using AWS," AWS Web3 Blog, March 31, 2026. Documents the 1,000,000 TPS sustained zero-loss benchmark across six AWS Regions over two weeks (one difficulty epoch); the 13,614 TPS peak of the prior monolithic SVNode; the AWS stack (EKS, EC2 NVMe, FSx for Lustre, S3, MSK/Kafka, RDS PostgreSQL); the BSV Association's custom Kubernetes operator; the use of Aerospike for the UTXO store; and direct quotes from BSV Association CTO Siggi Óskarsson. Source: https://aws.amazon.com/blogs/web3/how-the-bsv-association-built-a-million-tps-blockchain-node-using-aws/
³ Teranode official documentation, BSV Blockchain GitHub. Lists the sixteen named services: Asset Server, Propagation Service, Validator Service, Subtree Validation Service, Block Validation Service, Block Assembly Service, Blockchain Service, Alert Service, Block Persister Service, UTXO Persister Service, P2P Service, Legacy Service, RPC Service, Blob Store, UTXO Store, and UTXO Seeder. Confirms tech stack of Kafka, gRPC, Aerospike, and Postgres. Source: https://bsv-blockchain.github.io/teranode/
⁴ BSV Association, "Teranode" protocol page. Describes Teranode as a microservices-based architecture with "no built-in limits," confirms minimum design capacity of 1,000,000 TPS and headroom to roughly 5,000,000 TPS, references the public TeraTestNet, and contains the direct quote "Teranode parallelises network nodes and microservices, enabling limitless scalability." Source: https://bsvassociation.org/protocol/teranode/
⁵ Visa Inc., "A deep dive on Solana," official Visa crypto thought leadership page. States that Visa's network has the capacity to execute more than 65,000 transactions per second. Source: https://usa.visa.com/solutions/crypto/deep-dive-on-solana.html
⁶ Bank of England, "Response to the digital pound Technology Working Paper," 2024. Establishes a throughput design target of approximately 30,000 transactions per second for the digital pound, with potential to scale to approximately 100,000 transactions per second, and an uptime target of 99.999%. Source: https://www.bankofengland.co.uk/paper/2024/response-to-the-digital-pound-technology-working-paper