Most users get a single click and never notice they were verified. The 5–15% with ambiguous signals get a real challenge — and only the kind they'll actually pass. The risk engine decides; you don't have to.
The default. A frictionless checkbox that the user clicks once. Behind it, the widget collects pointer entropy, dwell time, TLS fingerprint hints, and seven other passive signals to build a risk score.
About 85% of legitimate traffic clears this in under a second without seeing anything else. The rest get escalated automatically to whichever challenge mode best fits their risk profile.
A 4×4 selection grid: "Pick all images with a bicycle." Images are AI-generated (DALL-E) or stock-curated and moderated through an admin queue. URLs are HMAC-signed and single-use per challenge, so the image set isn't scraped.
Triggered when smart-click signals are ambiguous and the user hasn't opted into audio-first accessibility mode.
"What is 7 × 4?" Simple arithmetic, generated server-side, never reused. Accepts both digit answers ("28") and spelled-out variants ("twenty-eight") with Levenshtein tolerance for typos.
Cheap to render, hard to automate without an actual parser, friendly to screen readers.
Multiple choice with four options. "Which of these is a fruit?" Pulled from a curated moderated pool — questions are vetted to avoid cultural specificity and ambiguity.
For users who prefer not to do math under stress, and for sites in markets where math-as-CAPTCHA feels patronising.
"Type what you hear." A spoken phrase generated via TTS, served as a short MP3. Levenshtein-tolerant matching for words; exact match for digit strings.
WCAG 2.2 AA accessibility. Available as a fallback button on every other mode for users who can't see the visual challenge.
No UI. Browser solves a SHA-256 proof-of-work in a Web Worker — about 200–500 ms on modern hardware, longer on phones, much longer on bots running at scale.
Best for low-stakes forms (newsletter signups, contact pages). Pair with smart-click for sensitive forms.
Every challenge gets a 0.0–1.0 score before the mode is even picked. The score determines whether smart-click is sufficient, whether to escalate to a visual mode, or whether to hard-fail without burning a slot in the human's day.
Tor exits, residential proxies, known datacenter ranges, and recent rate-limit offenders. Truncated to /24 or /64 before being stored.
Cloud, residential, mobile, datacenter, ISP. Mobile and residential IPs from consumer ISPs get more trust than VPS pools.
Modern browsers send predictable header sets. Headless Chrome and curl don't. We measure the inconsistencies.
How fast this IP, ASN, or sitekey has been minting challenges. A burst of 500 in 60 seconds is suspicious regardless of the IP.
Movement before the click. Bots either don't move the mouse or move it in unnaturally straight lines. We use a low-bandwidth fingerprint that doesn't survive after the challenge.
Timezone, language preference, viewport size, hardware concurrency. A bot pretending to be in Tokyo on a 4K monitor with 1 CPU core gets flagged.
JA3-style classification of the client's TLS handshake. Older bots use distinctive cipher orderings that real browsers don't match.
Known bad IPs (Stop Forum Spam, Spamhaus DROP) and specific abuse signatures get hard-failed without ever showing a challenge. They don't waste user time, they just don't pass.
The widget fills the same hidden form fields that those three services use — g-recaptcha-response, h-captcha-response, cf-turnstile-response — plus its own trustedcaptcha-response. Existing server code that reads any of these keeps working.
The verify endpoint accepts the same parameters as reCAPTCHA's siteverify and returns the same JSON shape: success, score, challenge_ts, hostname, error_codes. Migration is typically a one-line change to the script tag and a domain change in the verify URL.
