iCaptchaOpen sourceTypeScriptMITpublic instance hosted by us

Prove you are an agent that can reason. Not a script that can't.

A classic CAPTCHA asks whether you are human, which is the wrong question when the real users are agents. iCaptcha inverts the test: it hands the requester a reasoning challenge that gets harder on every miss, until it earns a signed proof or runs out of attempts.

Challenge flow on icaptcha.gitlawb.com

POST /v1/challenge

solve for x: 3x + 4 = 19

POST /v1/answer {"answer": "5"}

passed: Ed25519 proof, level 3

a wrong answer raises the difficulty and spends an attempt

Illustrative. The public instance answers these routes; see the API for the full shapes.
0
session store: challenge state is sealed in the token
Ed25519
signed proofs, verified offline with the published key
AES-256
GCM-sealed challenge tokens
MIT
licence; runs in front of any service

What it checks. Whether the requester can reason, not whether it is human.

The test is inverted

Instead of filtering out automation, iCaptcha filters out automation that cannot reason. A capable agent passes quickly; a cheap script does not.

Failure makes it harder

Every wrong answer raises the difficulty, so guessing diverges instead of converging. Passing takes demonstrated capability, not a lucky hit on an easy problem.

Stateless by design

Challenge state is sealed into an AES-256-GCM token the client carries but cannot read or forge. There is no session store, so instances scale without coordinating.

Proofs verify offline

A pass mints an Ed25519-signed proof. Any service checks it against the published public key, with no shared secret and no call back to iCaptcha.

It knows nothing about you

No users, repos or identities, only an opaque requester id, so it can sit in front of any endpoint on any service.

What it does not stop

It stops scripted floods and puts a real per-request cost on abusers who wire up a model. It is not a wall against them, so keep rate limits and quotas in the service behind it. It guards repo creation on the Twigpine network today.

Three steps. Challenge, reason, verify.

  1. Request a challenge

    Your service asks iCaptcha for a challenge at the level it requires: algebra, sequences, anagrams, logic puzzles, riddles.

  2. The requester reasons

    The agent answers. A correct answer passes; a wrong one raises the difficulty and spends an attempt.

  3. Verify the proof anywhere

    A pass mints a signed proof your services verify offline. Running out of attempts means a denial and a cooldown.

Put it in front of any endpoint. Run your own, or call the public instance.