Proof-of-work challenges: stopping bots without annoying humans
Nobody enjoys clicking traffic lights to prove they are human. Proof-of-work challenges take a different approach: make the work invisible to you and expensive for whoever is sending a million requests.
The CAPTCHA is a strange piece of technology when you think about it. To prove you are not a robot, you perform a task that robots are now measurably better at than you are, while a company harvests the labour to train image recognition models. Meanwhile the actual bot operators pay a solving service a fraction of a cent per puzzle and carry on.
Proof-of-work challenges come at the problem from a completely different direction, and the shift is worth understanding because it changes what you are actually defending.
Stop identifying, start charging
A CAPTCHA tries to answer "is this a human?" — a question that gets harder every year and was never really answerable in the first place.
Proof-of-work does not ask. It assumes it cannot tell, and instead makes every request cost a small amount of computation. Your browser is handed a puzzle that takes a little CPU to solve and almost nothing to verify: find a value that, when hashed together with the challenge, produces a hash starting with a certain number of zeros. There is no shortcut; you try values until one works.
For one visitor that is a few hundred milliseconds of a background thread, entirely unnoticed. For someone sending a million requests it is a million puzzles, and the arithmetic that made the operation worthwhile stops working.
This is an economic defence rather than a detection one, and that is its real strength. It does not need to be clever about fingerprinting, does not degrade as bots improve, and cannot be outsourced to a human solving farm — because the cost is CPU time, and a human clicking buttons does not help.
How it actually runs
The sequence is short. A visitor requests a protected page. The edge returns a lightweight challenge page instead, carrying a puzzle and a difficulty parameter. JavaScript in the browser solves it, usually in a Web Worker so the page stays responsive. The solution is submitted, verified in microseconds, and the visitor receives a signed cookie that admits them for a configured period — commonly a day — so they are not challenged again on every click.
Difficulty is a dial rather than a switch. A low setting is imperceptible; a high one takes a couple of seconds and makes automation dramatically more expensive. Raise it for a login page under active attack, keep it low for general browsing, and most visitors never learn the feature exists.
Invisible mode
- Solves silently in the background
- Visitor sees a brief blank moment at most
- Right default for general protection
Interactive mode
- Shows a short progress indicator
- Better for high difficulty, where the delay is noticeable
- Still nothing for the human to actually solve
Against a CAPTCHA
| CAPTCHA | Proof-of-work | |
|---|---|---|
| Effort for the human | Solve puzzles | None |
| Accessibility | Frequently a barrier | No interaction required |
| Defeated by solving farms | Yes, cheaply | No — cost is CPU, not clicks |
| Third-party data sharing | Usually | None required |
| Cost to a legitimate visitor | Seconds of attention | Milliseconds of CPU |
| Stops a targeted, low-volume attacker | Somewhat | Not really |
What proof-of-work does not do
That last row deserves expanding, because a defence you misunderstand is worse than one you do not have.
Proof-of-work raises the cost per request. If an attacker only needs a handful of requests — testing one specific stolen credential, exploiting one known vulnerability, scraping one page — the cost is negligible and they will pay it without noticing. It is a volume defence, and against a determined targeted attacker it does very little.
It also imposes a real cost on visitors with slow devices. A ten-year-old Android phone takes considerably longer than a current laptop, so difficulty settings that feel instant on your machine may not be. And it requires JavaScript, which means anything you want to reach your site without executing scripts — some accessibility tooling, some legitimate integrations, RSS readers — needs an exemption path.
Always exempt verified search crawlers before turning challenges on. Googlebot does not solve JavaScript puzzles the way a browser does, and challenging it is an efficient way to remove yourself from search results. Verify by reverse DNS rather than trusting the user-agent, then allow it through unchallenged.
Common questions
What is a proof-of-work challenge?
A proof-of-work challenge requires a visitor's browser to solve a small computational puzzle — typically finding a value that produces a hash with a required number of leading zeros — before the requested page is served. Solving takes measurable CPU time while verifying is near-instant, so the cost falls on whoever is making large numbers of requests rather than on individual visitors.
Is proof-of-work better than CAPTCHA?
For blocking high-volume automation, generally yes: it requires no interaction from the visitor, presents no accessibility barrier, shares no data with a third party, and cannot be defeated by human solving farms because the cost is CPU rather than clicks. It is weaker against a targeted attacker making only a handful of requests, where the added cost is negligible.
Do proof-of-work challenges slow down real visitors?
Slightly, and usually imperceptibly. At a typical difficulty setting a modern browser solves the puzzle in a few hundred milliseconds in a background thread, and a signed cookie then admits the visitor for a configured period so they are not challenged again on each page. Older or low-powered devices take longer, which is worth accounting for when choosing difficulty.
Will a proof-of-work challenge block Googlebot?
It will if you do not exempt it, and that would remove pages from search results. Verified search crawlers should be allowlisted before challenges are enabled, identified by reverse DNS verification of their IP addresses rather than by their user-agent string, which is trivially forged.
The framing worth keeping: a CAPTCHA tries to tell humans and machines apart, and gets less able to every year. Proof-of-work stops trying, and charges for the request instead. It is a smaller claim, but it is one that keeps being true.
See how NordicCDN does this for your site:
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
