67,751 Challenges, Not One Attempt.

"WebAssembly versus Argon2id" is a category error

This comparison is usually framed as WASM against Argon2id, and that framing is confused before the argument starts. WebAssembly is how the solver reaches the browser. Argon2id is what the solver computes. Both of the schemes below ship as WebAssembly - the Argon2id one is a compiled WASM build of the reference algorithm, delivered by the widely used hash-wasm library.

The real axis is which resource the puzzle bills:

• Compute-bound. Search for a nonce whose SHA-256 digest has N leading zero bits. Each probe is one cheap hash. The cost is CPU cycles, and it scales with how many probes you demand.
• Memory-hard. The same leading-zero search, but each probe is one full Argon2id evaluation, which pins a large block of RAM and walks it several times. The cost is memory bandwidth and capacity, and it is already present in a single probe.

Everything that follows comes from that one difference. The parameters I used are Argon2id at about 19 MiB with two passes and one lane, which is roughly what a browser challenge can afford without spinning a low-end phone. They are illustrative figures chosen for the benchmark, not a description of anyone's deployment, and RFC 9106 gives its own recommended parameter sets for the general case.

What one probe costs

Every number in this article was measured on 7 August 2026, on the machine that serves this site, using the same solver code a browser runs: a compiled WebAssembly SHA-256 searcher, and the hash-wasm Argon2id build. Running both under the same WebAssembly engine matters - comparing a browser-side scheme against a native-Go baseline would flatter one side by a factor of two or more.

That is a ratio of about 184,000 to one. It is the entire argument, and everything else is a consequence of it.

Why the bit counts run backwards

A leading-zero search at N bits needs 2^N probes on average. Because a compute probe is nearly free, a compute-bound scheme has to demand an enormous number of them before the total is worth anything. Because a memory-hard probe is already expensive, a handful is enough.

So the difficulty settings look inverted. The memory-hard tier runs at two to four bits. The compute tier needs twenty or more to impose comparable friction. That is not weakness on the memory-hard side - it is where the cost sits. In Argon2id the cost is in each probe, not in the count, and every extra bit still doubles the expected number of probes.

Here is the compute side, computed from the measured per-probe cost:

And here is the memory-hard side, where each row is fifteen complete searches rather than arithmetic:

Median probe counts sit below 2^N because the number of trials is geometrically distributed: at two bits the mean is four but the median is three. Quote the median for what a person experiences and the mean for cost arithmetic, and say which one you are using.

The tail nobody quotes

At four bits the median solve was 620 ms. The slowest of the same fifteen runs took 6,960 ms. That is not measurement noise and it is not a slow machine - it is the shape of the distribution. A leading-zero search has no upper bound, and a geometric tail means a minority of perfectly legitimate users will wait an order of magnitude longer than the median.

Any honest description of a proof-of-work challenge has to carry that number next to the median. "Sub-second" is true for most people at four bits and false for some of them, every time, forever. Publishing only the median is how a challenge that occasionally strands users gets described as invisible.

It also sets a practical ceiling that has nothing to do with attackers: each additional bit doubles both the median and the tail. The tail reaches unacceptable before the median does.

Why 26 bits is not a harder challenge, only a crueller one

Both schemes are symmetric. Your client and one attacker node run the same search. So the maximum difficulty you can set is bounded by your slowest legitimate device, and never by what would actually deter a bot. That is the trap in the obvious lever.

Follow the compute curve up and watch it break. At 20 bits a real user waits 405 ms, which is defensible. At 26 bits the same user waits 25.9 seconds, which nobody does - they close the tab. Meanwhile a machine renting parallel hashing capacity has barely noticed, because SHA-256 is the single most parallelised operation in computing: thousands of lanes on a commodity graphics card, and dedicated silicon sold by the shelf. Push the difficulty high enough to inconvenience that, and you have already locked out every phone you serve.

Memory-hardness changes which curve moves. Each parallel Argon2id lane needs its own block of RAM, so an attacker's concurrency is capped by memory capacity divided by block size rather than by core count, and memory bandwidth saturates long before the cores do. Solving many in parallel makes each one slower, because the lanes contend for the same bus. The hardware advantage that made the compute puzzle cheap is the thing being charged for.

There is one more reason this matters, and it is the one that is easy to miss. TLS and JA4 fingerprinting works well until an adversary drives a real browser engine, at which point the fingerprint is a real browser's fingerprint because it is one. A memory-hard cost does not care what the handshake looked like. It bills the hardware, which is where the asymmetry actually lives.

A flood arrived while this was being written

On the evening of 7 August 2026 this site took a distributed flood lasting 12 minutes and 20 seconds. It is a small event by any external standard, and that is part of why it is useful: it is fully captured rather than reconstructed.

The shape is worth as much as the totals. 387 of 525 networks contributed exactly one address, spread across 97 countries and mixing cloud providers with residential telcos. There is no subnet to block and no coherent fingerprint to match - which is precisely the case where the memory-hard argument has to carry the load on its own.

Two controls run against that same window. The verifier never saturated once, because verifying a solve is a single evaluation regardless of how long the search took - the asymmetry that makes this affordable to run. And while the flood was live, both a desktop and a Samsung S21 Ultra on 5G were served the same memory-hard challenge deliberately and solved it on the first attempt, fast enough that neither felt like waiting.

Where each one belongs

These are complements, not rivals. The useful split is breadth against depth.

Two things belong on the memory-hard side specifically. The parameters must be fixed by the server and carried in a signed token, never accepted from the client - if the client can negotiate the memory size down, the memory-hardness is optional and therefore absent. And the payload is larger, so the solver wants to be cached before it is needed rather than fetched at the moment of an attack.

The failure mode to design around is not a bot getting through. It is walling off people who cannot participate at all: clients without JavaScript, assistive technology, and machine clients like resolvers, which legitimately send no user agent and cannot run a WASM challenge. A proof of work is one tier among several, and treating it as a gate on everything blocks real traffic in the name of stopping fake traffic. We have made a version of that mistake before, when a blocklist update started banning search-engine crawlers that were behaving exactly as they should.

Measure it yourself in two minutes

Nothing here needs our stack. The Argon2id side needs only the public hash-wasm package and Node 18 or newer, and it reproduces the per-probe cost and the full-solve distribution in the same run.

# argon-bench.mjs - one probe, then a full leading-zero search
import { argon2id } from 'hash-wasm';

const SALT = new TextEncoder().encode('example-salt-value');
const P = { salt: SALT, parallelism: 1, iterations: 2,
            memorySize: 19456, hashLength: 32, outputType: 'binary' };

// leading zero bits of a byte array
const lz = a => { let n = 0;
  for (const b of a) { if (b === 0) { n += 8; continue; }
    for (let j = 7; j >= 0; j--) { if (((b >> j) & 1) === 0) n++; else return n; } }
  return n; };

// cost of a single probe - this is the whole point
let t = process.hrtime.bigint();
await argon2id({ ...P, password: 'token:0' });
console.log('one probe', Number(process.hrtime.bigint() - t) / 1e6, 'ms');

// a full solve at 4 bits - expect ~16 probes on average, and a long tail
t = process.hrtime.bigint();
for (let nonce = 0; ; nonce++) {
  const h = await argon2id({ ...P, password: `token:${nonce}` });
  if (lz(h) >= 4) { console.log('solved', nonce + 1, 'probes',
      Number(process.hrtime.bigint() - t) / 1e6, 'ms'); break; }
}

Run the solve loop fifteen times before believing any single figure. One run tells you almost nothing here - the distribution is geometric and individual runs land anywhere from one probe to fifty.

Verification is the other half, and it is the part that makes this affordable to operate: recompute the one hash for the submitted nonce, check the leading-zero count against the difficulty you issued, and confirm that the difficulty and parameters came from your own signed token rather than from the request. One evaluation, constant time in the size of the search.

These measurements are published under CC BY 4.0. Reuse the numbers and the tables freely, including commercially, as long as you credit dnsdoh.art and link back to this page.

The general lesson

When a symmetric defence is not working, the instinct is to turn it up. But a symmetric cost has a ceiling set by your weakest legitimate user, and turning it up walks you toward that ceiling faster than it walks the attacker toward theirs. Every doubling costs a phone more than it costs a rented server, because the phone was closer to giving up when you started.

The lever that works is not the magnitude, it is what you are charging for. Move the cost onto a resource where the attacker's advantage is smallest - here, memory bandwidth instead of hash throughput - and the same wall-clock friction for a real person becomes a genuinely different proposition for a farm. That reframing generalises well past proof of work: whenever a control is symmetric, look for the axis on which it stops being symmetric, rather than for a bigger number on the axis you have.

And keep the discipline about what the evidence supports. This site handed out 67,751 challenges in twelve minutes and received zero wrong answers. The satisfying conclusion is that the wall held. The supportable one is that nobody tried to climb it - which is a good outcome, and a different claim, and the difference is the sort of thing that turns out to matter later.