Browsercoin Dev Update: We Redesigned our Proof-of-Work from Scratch to be Browser-First, after GPU farms took over our Browser based Coin.

TL;DR: browserCoin is meant to be mined competitively in a browser tab, but GPU farms took over our old Argon2id PoW and killed that. So we built a new proof-of-work, Sandglass, that's memory-latency-bound instead of bandwidth-bound the one thing GPUs can't brute-force with parallelism. Result: a browser tab on a normal consumer CPU out-hashes a rented H100, and barely loses to an RTX 5090 that burns 262 W to get there. Even writing a native C miner buys you almost nothing over the browser. So mining in the browser is truely a good way to mine now.

The vision, and where it broke

The whole idea of browserCoin is that you can be a full node in a browser open a tab, verify the chain, and mine, no install, no farm, fully decentralized. Make it so easy that everyone can be part of a decentralized network just open a tab and you are a full node. For that to mean anything, mining in a browser has to actually be competitive. A regular tab has to earn a meaningful share and utilize your hardware to the maximum.

A few weeks ago we saw a big influx of hashrate the network jumped from ~25 kH/s to nearly 1 MH/s in about two days, while the number of unique miners actually shrank. Single addresses were implying 100+ kH/s each, which is thousands of browser-tabs' worth of work. That's not browsers. That's GPU farms.

https://preview.redd.it/717joxky19eh1.jpg?1080&format=pjpg&auto=webp&s=d87af3db672b31f85bb22eae83dbe86fb5c6cc44

That's exactly the outcome the project exists to avoid. Once farms dominate, there's no point mining in a browser anymore and the browser tab is the entire point.

Why the old algorithm wasn't enough

Our PoW was Argon2id, 32 MB, one pass. It was chosen as a middle ground: memory-hard, runs fine in a browser via WASM, and supposedly hostile to GPUs.

It wasn't hostile enough. Argon2id is memory-bandwidth-hard it streams a large buffer, and that's precisely the workload GPUs are built for: thousands of cores and enormous memory bandwidth chewing through many hashes in parallel. A GPU farm was getting something like a 10–20× edge over a browser tab. The idea was right; the algorithm wasn't the right fit for the mission.

So we designed a new one specifically around this coin's goal: a browser-first PoW where running it in a browser tab is within a hair of the theoretical best, and specialized hardware buys you almost nothing. We call it Sandglass.

How we achieved that latency, not bandwidth

The key switch: instead of being memory-bandwidth-hard, Sandglass is memory-latency-hard.

Each hash walks a long chain of dependent random reads and writes over a small (512 KiB) buffer. Every step's memory address depends on the result of the previous step so you literally cannot start step N+1 until step N has come back from memory. Two consequences:

1. You can't parallelize within a hash. The work is inherently serial, so a GPU's thousands of cores can't team up on a single hash they just stall waiting on each other.
2. The buffer is small enough to live in fast CPU cache (L2). A browser/CPU serves each dependent random access in a few nanoseconds. A GPU can run many hashes side-by-side, but each one is still bottlenecked on the latency of a dependent random memory access and a GPU's latency to its own memory isn't meaningfully better than a CPU's L2. The one thing GPUs are great at (parallel throughput and bandwidth) simply doesn't apply.

The net effect is that a browser tab is bound by the exact same thing the fastest hand-written native miner is bound by: memory latency. There's no bandwidth lever left for a farm to pull.

Our tests

We didn't want to take our own word for it, so we benchmarked hard:

- Cross-implementation determinism: browser WASM, native C, and CUDA/HIP GPU kernels all produce bit-identical hashes (required for consensus every node must agree).

- 90+ real devices, community-submitted plus hardware we rented: phones, laptops, desktops, and datacenter GPUs including A100, H100, and an RTX 5090.

Results:

- Browser WASM lands within ~10% of hand-optimized native C on the same machine. Writing a miner in C buys you almost nothing over a browser tab.

- A top-end GPU (5090) drops from the old ~10–20× advantage down to roughly ~1.6–3× and it burns an order of magnitude more power to get there. On hashes-per-joule, CPUs/browsers beat every GPU we tested. Building a farm stops making economic sense.

- Full local + across-the-fork end-to-end runs (difficulty reset, mixed-algorithm chain validation, resync) before shipping.

https://preview.redd.it/4gdj55gp49eh1.png?716&format=png&auto=webp&s=74719217c8c0e770af70b6299a3056a15afb09ec

Being honest about the limits

- iOS/Safari is currently weak (Safari's JS/WASM codegen throttles the walk). It's a known soft spot; a later reward-smoothing change will let weak devices still earn proportionally.

- We're fighting hardware with algorithm design, which history says is an ongoing effort, not a one-time win. We know that and we're committed to it.

Rollout

This is a hard fork that preserves everything same chain, same balances, same full history. It's height-gated: it activates at block 33,550 (~July 22). If you run a tab, just open the site once before then and it auto-updates. No action needed on balances.