Progress on EarthBucks 2.0

Two weeks ago, I wrote that work had begun on EarthBucks 2.0.

At that point, the main story was the Rust consensus library. EarthBucks 2.0 needed a serious Rust foundation before the mine network could be built on top of it.

That foundation is now much further along, and the work has expanded from library code into the mine, the database, the peer network, the mining pool, and the next EarthBucks web application.

This is not a launch announcement. EarthBucks 2.0 is not live yet. But the project has moved from design and isolated components toward working system substrate.

That is important progress.

The Rust Mine Is Taking Shape

The biggest change since the last update is that earthbucks_mine has become a real service.

It now has the basic pieces a mine needs:

• service scaffolding;
• configuration loading;
• tracing;
• a landing page;
• OpenAPI metadata;
• MySQL connection pooling;
• SQLx migrations;
• a migration command;
• database models for chain state and transactions.

This is the unglamorous part of EarthBucks 2.0, but it matters. The mine is the core server in the EarthBucks network. It has to validate transactions, track chain state, communicate with peer mines, accept mining work, and eventually serve users and pools.

The current mine is not finished, but it is no longer just an idea. The service, database, and core model layers exist.

Transaction Validation and UTXO Handling

The mine can now do more than store raw transaction bytes.

We added the transaction validation workflow around the Rust EarthBucks library. That includes planning validation, finding the inputs needed for a transaction, running the verifier, and recording validation outcomes.

We also added the substrate for atomic UTXO spending. This is one of the critical parts of any UTXO-based electronic cash system. Two transactions cannot spend the same output. The database and validation flow have to enforce that under real concurrent conditions, not just in a happy-path test.

This is the kind of work that makes EarthBucks 2.0 feel much more concrete. Transactions are moving through a real mine workflow instead of only existing as library objects.

Merkle Ordering and Finality

One of the most important EarthBucks 2.0 design decisions is that mines synchronize transaction ordering.

Mines do not need to send full blocks around the network in the normal fast path. They should already agree on ordinary transactions and their order before a block is found. Then a block announcement can be compact.

Since the last update, we built a lot of the substrate for that idea:

• local Merkle assignment;
• peer Merkle order ingestion;
• peer promotion;
• global Merkle streams;
• validation and Merkle fact replication;
• transaction vote propagation;
• transaction finality facts;
• double-spend rejection fixtures.

This is a major step toward the actual EarthBucks network model.

The goal is not simply to build “a blockchain node.” The goal is to build mines that converge on transaction order, validate consistently, and produce finality facts without Bitcoin-style reorganizations.

That system is starting to take shape.

Mine-to-Mine Networking

The mine network also made significant progress.

We added authenticated mine identity, mine-to-mine authentication pieces, peer streams, durable producer event logs, transaction event relay, and three-mine propagation tests.

In practical terms, this means we can run multiple mines and watch transactions move across them. We can test fanout, ordering, validation, Merkle state, compact block propagation, double-spend behavior, and finality behavior.

That does not mean the peer network is finished. It does mean that EarthBucks 2.0 now has working multi-mine substrate instead of only diagrams.

That is a big difference.

Mining Pool and Work Templates

EarthBucks separates mines from miners.

Mines are the professional servers that validate and coordinate the network. Miners perform proof-of-work. The practical bridge between them is the mining pool.

Since the last post, we added a lot of pool-related infrastructure:

• authenticated work templates;
• real work template construction;
• solved-work persistence;
• pool reward key decisions;
• a dev pool;
• a CPU mining loop;
• a mine-submit command;
• pool transaction submission.

This is still early, but it points toward the future user experience: browser miners and pool clients should be able to get real work, solve it, submit it, and have the mine account for that work correctly.

That path is now much clearer.

Performance and Throughput Testing

We also spent a lot of time pushing the system under load.

We tested simulated latency, transaction fanout, burst submission, submit-path performance, SQL hot paths, Merkle persistence, sustained benchmarks, and multi-mine propagation.

Some experiments passed. Some failed. That is exactly what these experiments are for.

The aggressive 1000 tx/s target was not achieved in the current design. But the system did reach realistic three-mine operation above 100 tx/s, and the testing made the real bottlenecks much clearer.

That is useful information. It is better to learn the shape of the system under pressure now than to discover it during launch.

The New EarthBucks App

EarthBucks 2.0 also needs a new web app.

The current EarthBucks app is live and will keep running. EarthBucks 2.0 should not break EarthBucks 1.0. But the next version needs a cleaner app foundation.

We started that work with a new TypeScript project called www-pool.

It now has:

• a TanStack Start application;
• EarthBucks branding;
• generated icons and light/dark favicons;
• an Astrohacker footer;
• a separate @earthbucks/db package;
• encrypted environment files;
• KeyPears-style proof-of-work authentication.

The authentication flow is important. Creating an account and logging in both go through proof of work. The server signs a challenge, the client solves it, and only then does the server write to the database.

This keeps the authentication system aligned with the KeyPears protocol while also fitting the needs of EarthBucks 2.0.

We also hardened this scaffold before building on top of it. The public federation APIs remain stubbed for now, but the future federation fetch path is already guarded in the same way as the latest KeyPears implementation.

Infrastructure Cleanup

There was also a lot of cleanup work around the TypeScript projects.

We updated dependencies, fixed a Pow5 WebGPU issue exposed by newer Chrome behavior, modernized TypeScript source imports to use .ts and .tsx extensions, added missing lint and format scripts, enforced pnpm release-age protection, and removed obsolete experimental Tauri projects.

That work is not as exciting as mine networking, but it matters. A cleaner workspace makes the next round of development faster and safer.

What This Means

The last post said EarthBucks 2.0 had begun.

Now the message is stronger: EarthBucks 2.0 is becoming a working system.

The Rust mine exists. The mine database exists. Transaction validation exists. UTXO spending exists. Merkle ordering exists. Mine-to-mine networking exists. Mining pool substrate exists. The new app has started.

None of this means EarthBucks 2.0 is ready to launch tomorrow. There is still a lot to do. But the work is no longer only foundational library parity. The parts are starting to connect.

That is the real progress.

What Comes Next

The next priorities are to keep hardening the mine network, connect the pool and app more deeply into the mine behavior, and continue turning the working substrate into a product users can actually run and use.

The Bitcoin Cash wallet and atomic swaps are still future milestones. They remain important. They are part of the bigger EarthBucks 2.0 path. But the mine network and pool substrate have to be solid first.

That is where the work is now.

Conclusion

EarthBucks 2.0 has made substantial progress since the last update.

Most of it is infrastructure. That is expected. Real electronic cash needs boring things to work correctly: validation, ordering, persistence, networking, finality, authentication, and mining work.

Those pieces are now much further along.

The goal remains the same: Rust mines, domain-based peer-to-peer consensus, practical mining pools, a new EarthBucks app, and eventually a path to liquidity through Bitcoin Cash.

EarthBucks 2.0 is not done. But it is much more real than it was two weeks ago.