How Captxa actually works

What happens at POST /challenge/simp

Before any PoW is issued, the server runs four independent checks. Failing any one silently escalates the request to the complex path — the client is never told which check triggered it.

// Sent as JSON body to POST /challenge/simp
{
  "webglrenderer":           "NVIDIA GeForce RTX 4090/PCIe/SSE2",  // GPU string from WebGL
  "timezone":                "Europe/Barcelona",
  "hardwareconcurrency":     16,
  "innerw":                  1920,   "innerh": 1080,
  "availw":                  1920,   "availh": 1040,
  "devicememory":            8,
  "webdriver":               false,                // navigator.webdriver
  "ischromeruntimemissing":  false,                // chrome.runtime absent in Chrome = headless
  "errorstacktripwire":      false                 // stack trace contains puppeteer/playwright/selenium
}

SHA-256 Proof of Work

PoW is the economic firewall. A bot must do real CPU work for every challenge, making mass-automation orders of magnitude more expensive than simply blocking it.

// Worker receives: { challengeHex: "32 hex chars (16 bytes)", difficulty: 18 }
// Target: SHA256( challenge_bytes || nonce_uint32_LE || 0x00000000 ) must have
//         at least `difficulty` leading zero bits.

const buf  = new Uint8Array(40);   // 16B challenge + 4B nonce + 4B padding
buf.set(challenge_bytes, 0);      // challenge occupies bytes 0–15

let nonce = 0;
while (nonce < 0x100000000) {
  view.setUint32(32, nonce, true);  // little-endian nonce at bytes 32–35
  const hash = sha256(buf);
  if (leadingZeroBits(hash) >= difficulty) {
    self.postMessage({ type: "done", nonce });   // ✓ found
    return;
  }
  nonce++;
  if ((nonce & 8191) === 0) self.postMessage({ type: "progress", pct });
}

SHA-256 is implemented entirely in JavaScript inside the Worker blob — no crypto.subtle API, no external dependencies. The Worker is compiled on-the-fly from a Blob URL.

Challenge token design

The challenge token is a tamper-evident, IP-bound, time-limited container. It travels from server to browser and back — but the browser never knows what is inside it.

Multi-stage mouse trajectory ML pipeline

Every solve request includes the raw pointer trajectory as [x, y, timestamp_ms] triplets. This goes through five analysis stages. A bot score in [0.0, 1.0] is returned — lower is more human.

Ed25519 signed pass token

A passing solve emits a signed pass token in the x-captcha-token response header. Your frontend stores it and your backend validates it against POST /api/validate.

// Never call this from the browser.
const res = await fetch('https://api.captxa.com/api/validate', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    captcha_token: req.body.captchatoken,
    secret_key:   process.env.CAPTXA_SECRET_KEY
  })
});
const data = await res.json();
if (!data.Is_Correct) {
  return res.status(403).json({ error: 'Bot detected' });
}

// ✅ Valid
{ "Is_Correct":true, "RequestLimit":false, "requests":1 }

// ❌ Invalid / tampered
{ "Is_Correct":false, "reason":"invalid_token" }

// ⚠️ Reused too many times (HTTP 429)
{ "Is_Correct":true, "RequestLimit":true, "requests":12 }

Server architecture

Written from scratch in C on the H2O HTTP server with a libuv event loop backend. No GC, no managed runtime — every request is handled in a tight zero-allocation path.

What data is collected — and what isn't

Captxa is designed to answer one binary question: is this request from a human? — and then discard everything it collected to answer it.