Security

What we hold, what we never touch, and who has looked.

402Signal is a checker, not a custodian. This page lists the boundaries, the controls that enforce them, the automated checks that run on every change, and the reviews completed so far. It does not claim a completed independent audit.

Custody boundaries

Buyer keys: Never sent to the service. The client hooks and the local guard hold no keys, sign nothing and never retry a payment. The checking fee is paid by the buyer's own wallet through its own x402 client.
Checking-fee treasuries: Receive-only addresses on Base, Solana and Algorand, pinned in code. The service refuses to boot with an unreviewed override; rotations ship as reviewed changes and are verified with a paid check.
Transparency log key: An Ed25519 log key on the service signs receipts; the Falcon-1024 anchoring key lives on a separate machine with no public address and is never on the service host.
Replay authority: Managed PostgreSQL reached only by a reader login through owner-defined functions. The service holds no owner credential. Any instance change stops paid admission until an operator re-pins with a recorded attestation.
Seller responses: Treated as untrusted data. Probes go to public addresses only, with pinned DNS, redirects refused and bounded budgets; no arbitrary URL proxy exists.

Controls in the payment and evidence paths

Success-only billing: a checking fee is settled only for a qualifying observation; completed misses are never settled.
Exactly-once economic identity per payment authorization, with identity expiry once the authorization can no longer settle on any rail.
Payer quotas on unsettled attempts, an admission engine with customer key digests, and rate limits per path.
Fail-closed verification in the guard: unsupported, changed, malformed or expired evidence refuses; a refusal never falls through to an unguarded payment.
Strict Content Security Policy on every page (no remote scripts, styles or fonts), no wallet code in the browser, and no inline event handlers.
Test-support modes refuse to boot on any Fly machine; production identity requires the MainNet epoch, origin and Falcon address.

Checks that run on every change

Python fixture suites (payment, replay, receipt, SSRF and XSS paths) and the zero-dependency Node guard suites on every pull request; PostgreSQL 16 and 17 compatibility jobs for the replay functions.
Browser evidence across seven widths in Chromium and WebKit, including no-script rendering and no external requests.
CodeQL for Python and JavaScript, OpenSSF Scorecard, pinned action digests, hash-locked Python dependencies and lockfile audits for the integration packages.
Reproducible package builds with pinned digests recorded in capabilities.json; npm publishes carry provenance and PyPI publishes carry attestations.
An external monitor every ten minutes that opens a public incident issue on failure; see status.

Workflow runs · Security advisories and Scorecard

Reviews so far

September 2026, engineering review: A full review of the service, packages, repository and hosting. Classes fixed: replay identity expiry on every rail, external monitoring with public incident issues, repository hygiene (pinned actions, hash-locked dependencies, Scorecard), and the paid-path capacity work below. Findings are not published; the fixes are in the changelog.
September 2026, replay authority capacity: Measured on Managed PostgreSQL before and after the sharded-counter migration: about 450 admissions per second from four processes, with every guard, the identity primary key and exact quota enforcement unchanged. The harness is private; the number is the commitment.
Controlled MainNet qualification: Dated lab runs on Base, Solana and Algorand for the supported profiles, repeated after every replay authority change. The profiles and package digests are public in capabilities.json; the lab records are private.
Independent audit: None completed yet. The public source, tests and evidence are offered for review; an external audit will be listed here when one is done.

Report a problem

Email ross@402signal.com with a concise description, the affected version and a safe reproduction. Please keep sensitive details out of public issues. Do not send private keys, seed phrases, payment headers or unredacted customer records. The security policy and security.txt carry the same contact and scope.