ALTCHA: a self-hosted proof-of-work CAPTCHA alternative

The problem ALTCHA solves, and who actually has it

Traditional CAPTCHAs ask users to classify images or transcribe distorted text. That work is friction for a human and, increasingly, training data or free labour for the vendor. ALTCHA takes a different position: the browser should spend CPU time instead of human attention. The README describes the mechanism as background proof-of-work, which means the visitor's machine computes a solution while the page is otherwise idle, and the server checks the answer.

The audience is narrower than the marketing suggests. If your forms are public, unauthenticated, and regularly hit by scripted submissions, ALTCHA is aimed at you. If you are a European operator who has to answer questions about cookies and consent, the cookie-free design removes one category of problem. If you have an accessibility obligation under the European Accessibility Act, the project claims WCAG 2.2 AA conformance and ships an audio fallback for its code challenge. Those three groups have a real reason to look at this repository. Everyone else should read the limitation section first.

How the proof-of-work flow actually runs

The widget is a Web Component, so it is a custom element you drop into a form. According to the README, the element takes a challenge attribute, which is either challenge data or a URL from which to fetch one. The browser solves that challenge using the Web Crypto API, specifically crypto.subtle, and the widget writes the result into a hidden input whose name defaults to altcha. Your form posts that payload alongside everything else. Nothing leaves the user's machine except the solution, and your server validates it with one of the language libraries.

The v3 release notes describe native support for Argon2 and Scrypt, which the README calls memory-bound algorithms intended to raise the cost for ASICs, GPUs and bot farms. That is the interesting design choice. A plain hash-based proof of work rewards whoever has the fastest silicon, which is exactly the attacker. A memory-hard function makes parallel hardware less of an advantage. The trade-off is that memory-hard functions are also harder on the honest visitor's phone, and the README does not quantify that cost anywhere I could find.

Server integrations are separate repositories, listed for TypeScript, Dart, PHP, Go, Python, Java, Ruby, Elixir, Rust and C++. There is no single server package; you pick the one matching your backend. That is a deliberate split, and it means the widget and the verifier can version independently, which is convenient until they drift.

Installing ALTCHA and wiring a first form

The README gives two distribution paths. The npm package is the one most projects will use. Install it, then import it once in your entry file so the custom element registers.

npm install altcha

import 'altcha';

If you are not using a bundler, the README shows a script tag pointing at a self-hosted copy of the built file.

<script async defer src="/altcha.js" type="module"></script>

With the element registered, add it inside the form you want to protect. The challenge attribute points at your own endpoint that issues challenges, or carries the challenge data directly.

<form>
	<altcha-widget challenge="https://..."></altcha-widget>
</form>

For anything beyond the basic attributes, the README recommends the programmatic route over HTML attributes. The widget exposes a global $altcha object, and an existing instance can be reconfigured with .configure().

$altcha.defaults.set({
	challenge: 'https://api.example.com/challenge',
	debug: true
});

const widget = document.querySelector('altcha-widget');
widget.configure({
	workers: 2,
	language: 'fr'
});

The supported HTML attributes listed in the README are auto, challenge, configuration, display, language, name, theme, type and workers. The configuration attribute takes a JSON-encoded string, which is how you pass objects that attributes cannot express. On the server side, the README points to the separate server documentation rather than inlining a verification example, so you will need to open the library for your language before you can complete the loop.

Where ALTCHA is the wrong tool

Proof-of-work is a cost multiplier, not a wall. It makes each automated submission expensive in CPU time, and the README's own framing is that it raises the cost of attack. A well-resourced attacker with a botnet absorbs that cost. If your threat model includes a targeted, funded adversary rather than opportunistic form spam, this mechanism alone will not hold, and the project does not claim otherwise.

The second problem is the browser requirement. The README states ALTCHA needs the Web Crypto API, specifically crypto.subtle, and lists Internet Explorer 11 and older as unsupported. That is a reasonable line in 2026, but it is a line, and any audience still on legacy browsers will not see the widget work.

The third is the server side. There is no hosted verification endpoint. You must run one of the language libraries and issue challenges from your own infrastructure. Teams that chose reCAPTCHA precisely to avoid backend work are not the audience for this, and the README does not pretend they are.

Finally, the README does not document a fallback story when the proof-of-work cannot complete, and the repository has no dedicated troubleshooting document. If a visitor's solve fails, the README gives no rollback or degradation path.

ALTCHA against reCAPTCHA and Turnstile

The comparison that matters is architectural, not feature-by-feature. reCAPTCHA and hCaptcha are hosted services. You embed their script, they collect signals from the visitor's browser, and their servers decide whether the visitor is human. The vendor sees your traffic and your users. Turnstile follows the same hosted model with a lighter footprint.

ALTCHA inverts that. The widget runs on your page, the challenge is issued by your server, and the verification happens on your server. The README's privacy claim rests on this: no cookies, no fingerprinting, no data collection, because there is no third party in the loop to collect it. The README also gives bundle sizes, listing ALTCHA at 34 kB gzipped and 52 kB with all translations, against 85 kB or more for Cloudflare Turnstile, 250 kB or more for hCaptcha, and 300 kB or more for reCAPTCHA. Those are the project's own published figures, not independent measurements.

The honest summary is that you are trading a vendor's detection signal for your own CPU cost and your own operational burden. The hosted services bring behavioural data that a proof-of-work challenge simply does not have. ALTCHA brings the absence of a third party. Which one you want depends on whether your problem is privacy compliance or a determined attacker.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-20, the same day as the v3.2.3 release. Before that, v3.2.2 landed on 2026-08-19 and v3.2.1 on 2026-07-12, so the release cadence over the past few months has been roughly monthly. That is a real signal of ongoing work, and it is worth noting that the version numbers are patch-level, which suggests stabilisation rather than churn.

The licence is MIT, declared in both the repository and package.json. For most adopters that is the least restrictive option available and imposes no copyleft obligation on your application. The MIT grant covers the code; it says nothing about the compliance claims. The README asserts GDPR, HIPAA, CCPA, PIPEDA/CPPA, LGPD, DPDPA and PIPL compliance, and separately WCAG 2.2 AA and EAA compliance. Those are the project's assertions. If you are relying on them for a regulatory filing or an accessibility audit, your own counsel and your own audit are what count, not the README.

Upgrade cost is the part to plan for. The README ships a MIGRATION-v2.md for the v2 to v3 transition, which tells you the project does break compatibility at major versions. The v3 notes list performance changes to the proof-of-work mechanism, new Argon2 and Scrypt support, new themes, and improved TypeScript support. If you are on v2 and your server library has not tracked the widget, that is where an upgrade will bite.

Editorial conclusion

Adopt ALTCHA if you control your own backend, need a cookie-free widget that meets WCAG 2.2 AA and EAA claims, and are defending forms against scripted spam rather than a funded adversary. Do not adopt it if you want a hosted service with no server-side work, or if you need CAPTCHA-grade resistance to a determined human-backed attacker. Before committing, verify two things: that your stack has a server library in the list (TypeScript, PHP, Python, Go, Java, Ruby, Elixir, Rust, C++, Dart), and that your users' browsers support crypto.subtle, since the README excludes Internet Explorer 11 and older. Then read the CSP section, because the default bundle inlines styles and workers.

Frequently asked questions

Official sources

1. altcha-org/altcha on GitHub
2. License: MIT
3. Project website
4. README
5. Releases