Towards One Million Transactions Per Second: Progress on EarthBucks 2.0

EarthBucks 2.0 now has a design target of at least one million transactions per second, with a final answer to each transaction in less than one second. Recent work on the Rust Merkle tree implementation has reached approximately 1.2 million updates per second in local benchmarks. That result gives us a concrete reason to pursue the larger target.

It is a component benchmark. We have not yet demonstrated a global network validating and finalizing one million transactions per second. The next stage is to make validation, communication, consensus and persistence work together at that scale.

EarthBucks 1.0 remains live. The plan is to preserve its history and funds while migrating to a much higher-performance network written in Rust.

Why aim for one million?

We do not need one million transactions per second today. I do not expect to need that much capacity when EarthBucks 2.0 launches, either. We will size the initial deployment for actual demand.

The reason to design and test for one million is room to grow. I want an architecture that can handle substantially more traffic by adding cores, memory, network capacity and database capacity, before we need to change its fundamental structure again.

The target means one million unique, ordinary payment transactions per second across the network. Replicating one transaction to three mines still counts as one transaction. Updating three Merkle trees does not turn it into three.

For planning, we assume ordinary transactions average about 500 bytes and have a couple of inputs and outputs. Larger transactions and more complicated swap scripts may reduce throughput. We will measure their costs separately. The requirement to give each permitted transaction a final accepted-or-invalid answer within one second remains the same.

What the Merkle benchmark proves

A Merkle tree combines transaction hashes into a single root hash. It also allows a wallet to verify that its transaction belongs to a block without downloading every other transaction in that block.

The tree has to preserve transaction order, but that does not mean every part of its construction must happen on one CPU thread. We can divide the work into batches, compute independent portions in parallel, and overlap work on the next batch with completion of the current one.

Our latest Rust implementation does this while preserving EarthBucks’ existing Merkle roots, growth and padding rules, and inclusion-proof format. It also produces a proof-capable snapshot for every successive transaction prefix. We are measuring more than a final root produced after all the data arrives.

With batches of 1,024 updates and 16 workers, the confirmation runs reached approximately 1.19–1.21 million updates per second. The trees started with 600,000 or one million leaves. The pipelined implementation improved throughput by roughly 12% over the best sequential-batch control in those comparisons.

These tests start with transaction hashes. They do not include transaction signature verification, global networking, voting or database persistence. They also do not establish that the same rate holds at the size of an entire block containing hundreds of millions of transactions. Those distinctions define the work ahead.

The useful result is that we have a much faster implementation of the same Merkle structure. Wallet inclusion proofs remain part of the design.

Three mines to start

EarthBucks 2.0 separates the validating mines from the public application. Initially, we plan three mines in Virginia, London and Tokyo, using domains such as mine1.earthbucks.com, mine2.earthbucks.com and mine3.earthbucks.com. The network can grow over time; our planning includes configurations up to roughly 21 mines.

The mines are permissioned and identifiable. Astrohacker will operate them initially, and operation may later be transferred to other responsible entities. This is an intentional part of the design. We know which mines are participating, and misbehaving operators can be removed.

No mine is the designated network leader. Each mine independently verifies transactions and publishes its own validation results and transaction order. A transaction becomes final when agreement exceeds half of the network’s voting power. Voting power follows the proportion of blocks attributed to each mine in the previous 1,000 blocks.

The pool at earthbucks.com will obtain work from all active mines and distribute it to users in round-robin order. Solved work returns to the originating mine. This lets us allocate approximately equal work across the mines, although actual block counts, and therefore voting weights, will fluctuate.

Finality before the next block

The goal is for a user to submit a transaction and receive its final result within one second, including the time needed for communication between mines. We do not want users to wait for the next proof-of-work block to know whether a payment has been accepted.

Every pair of mines will maintain a persistent, authenticated connection and stream transactions and votes. Many messages must be in flight at once. Waiting for an acknowledgment before sending the next transaction would waste the time it takes messages to travel around the planet.

The mines will use protobuf and gRPC interfaces. Each mine will maintain its own Merkle tree and reproduce the transaction order and tree of every other mine. When a new mint transaction and its header arrive, peers that already have the transactions and their order can complete that candidate block without downloading the whole block again. Missing data still has to be recovered, and the mint transaction and header still have to be validated and receive majority agreement.

Transaction finality and block inclusion are separate events. Wallets can obtain the finality result first, then obtain an inclusion proof against the block header once the transaction is included in a finalized block. Mines must produce and serve these proofs so that independent SPV wallets can verify their own transactions.

The conflict rule is also explicit. Concurrent conflicting spends detected before finalization are both invalid. A later conflicting spend cannot undo an already finalized transaction. Making that distinction hold under different message arrival orders is part of the consensus implementation work.

One second is our requirement for every permitted transaction, not merely an average. We still have to qualify it under load and specify behavior during overload, partitions and loss of a reachable voting majority. A timeout alone does not prove that a transaction is invalid.

Memory for computation, MySQL for persistence

The mines will validate transactions and construct their Merkle trees in Rust memory. MySQL will remain our database, with updates performed concurrently in batches. Each mine will have its own logical database, with sharding available as needed.

This does not mean forgetting durability. A restarted mine must recover its transactions, votes, spent-output state and ordering before it resumes voting. We will investigate a compact recovery log and determine exactly what must be durable before finality is announced. Having several copies in RAM is useful, but it does not guarantee survival of correlated failures.

Persistence must keep up over time. If it falls behind, admission must slow down; an ever-growing queue of unwritten data is not a sustainable design.

The memory requirements are large but concrete. At one million transactions per second, a ten-minute block contains 600 million transactions. At 500 bytes each, that is 300 GB of transaction bodies. A populated binary Merkle tree of that size contains roughly 38.4 GB of hashes per producer, before pointers, indexes, UTXOs, votes, queues and other overhead. Each mine can share one copy of the transaction bodies among its producer trees.

Multi-terabyte servers make this capacity plausible. We still need to measure the actual footprint, allow for blocks that take longer than ten minutes, and test proof serving and block transitions at full scale.

Mines will not be permanent archives. Spent transaction and output records are planned to disappear from mines after six months, while preserving the state needed for validation and consensus. Separate archival nodes will retain history and historical proofs. Initially, earthbucks.com will also serve as our archive and save all transactions.

Moving the protocol to Rust

Today, TypeScript defines the EarthBucks production protocol because that is what EarthBucks 1.0 runs. During development, it provides the compatibility reference for existing formats, cryptography and verification behavior, except where we explicitly approve changes.

At the production migration, the Rust mine implementation will become the authoritative implementation of EarthBucks 2.0. TypeScript will continue to support the wallet, pool and application, remaining compatible with the Rust network. Passing library parity tests is useful preparation; the authority changes when production actually moves.

We are preserving the existing transaction and block structures, the Merkle format and Pow5. The monetary schedule and reward allocation also remain: 95% of each block reward goes to Astrohacker, and the pool distributes the hashers’ 5% according to their contributed shares.

What users will see

The public application will remain earthbucks.com. Users will not need to choose among mine dashboards or move to a separate pool website. The existing application will connect to the new mine network in its pool and wallet roles.

We also plan a self-custodial Bitcoin Cash wallet and atomic swaps between EBX and BCH. The recent swap prototype already constructs and verifies transactions in offline simulations. Integrating it into a wallet and qualifying it against real networks remain ahead.

The swap goal is for both parties to receive the agreed exchange or recover their funds if it is abandoned. Wallet software must monitor both chains and submit claims or refunds within the required windows, including when the user closes the interface. BCH has its own confirmation rules; an entire cross-chain swap is not a one-second operation.

KeyPears and EarthBucks Pay 2.0 will provide secure messaging, an encrypted vault and federated payment and swap communication through existing accounts. Swap discovery will use a centralized order book, planned for earthbucks.com, while users retain their keys and sign transactions client-side.

Ordinary payments will merge the necessary UTXOs into one transaction by default. Users who pay an additional fee will be able to request merge avoidance: separate transactions spending individual UTXOs with fresh recipient keys. This avoids the direct link created by merging inputs, although it does not guarantee anonymity. The wallet will have to handle partial completion and retries without paying twice.

The next stage

The plan and project guidance now agree on the architecture, the application boundaries and the work that remains. We can build on the existing Rust mine and TypeScript application instead of creating another set of public apps.

Next comes integration and qualification: parallel validation, streaming consensus, recovery, batched persistence, full-scale trees and proofs, and the wallet features that make the network useful. We need to demonstrate sustained throughput and user-visible finality together, including failures and restarts. The migration itself must preserve existing funds and history, with zero downtime as the goal.

I am aiming for a launch in late 2026 or early 2027, with hardware sized for the traffic we actually have. The million-transaction target gives us a much larger design horizon. We now have a Merkle implementation fast enough to make that target worth pursuing, and a clearer plan for the rest of the system.