Protection Stack
Capcat verifies humans without image puzzles, tracking, or cookies. Instead of interrogating your users, it stacks independent layers that each make automated abuse more expensive. Most layers are on by default; the rest are one switch in the console.
Proof of work — the base layer
Every verification requires the browser to solve a SHA-256 proof-of-work challenge, powered by the open-source Cap engine. It runs silently in the background: a real user notices at most a sub-second delay, while bulk abuse has to pay CPU time for every single attempt.
Environment attestation
Alongside each challenge, Capcat ships a dynamically generated attestation program that must run to completion where the solving happens. It confirms the solve took place inside a real browser — a script that calls the API directly (curl, Python, a Node bot) cannot redeem a token even if it computes the proof of work correctly. The program is generated fresh and randomized per challenge, so there is no fixed checklist to hardcode around. On by default for every site.
Automated browser blocking
Off-the-shelf automation tooling — Selenium, Playwright, Puppeteer, and headless browsers in general — is detected and rejected on both the client and the server. Capcat maintains and continuously hardens this detection on top of the upstream engine, with the highest-confidence signals checked on every challenge. On by default; you can switch it off per site if your audience includes real users running automation-style browser extensions.
Adaptive difficulty
Challenge difficulty is not a constant. A scheduled process watches each site's traffic and raises proof-of-work difficulty automatically when the pattern looks abusive, then lowers it back as things normalize. A quiet site stays as fast as possible for legitimate users; a site under attack hardens itself before anyone opens a dashboard.
Time-lock puzzles (RSW) — opt-in
For high-value endpoints — signup, checkout, promo redemption — you can enable an RSW time-lock puzzle: a computation that is inherently sequential and cannot be accelerated with more cores or GPUs. Every verification then takes a fixed wall-clock time regardless of hardware, capping any bot fleet at a constant per-client rate. Strength is tunable per site; the default adds roughly 0.5–2 seconds.
Service-layer controls
- Domain binding — a site key only works from the origins you allow; anything else is rejected before it can spend your quota.
- Single-use tokens — a verification token redeems exactly once; replaying it fails.
- Rate limits and quotas — per-key rate limiting and monthly quotas keep runaway or hostile usage from becoming your problem.
Honest limits
No CAPTCHA — commercial ones included — stops a determined attacker armed with patched stealth browsers and real hardware. The point of stacking independent layers is economics: CPU cost per attempt, constant-rate time locks, environment checks that break off-the-shelf tooling, and difficulty that rises exactly when abuse starts. We document that plainly instead of promising magic.
Everything above is configured per site in the console under the Protection card. Changes go live globally in about a minute.