Abstract
We present AlltheX: a stateless, deterministic verification protocol for distinguishing legitimately constructed requests from those that were not. Unlike existing approaches — which rely on behavioral heuristics, device fingerprinting, or biometric signals — AlltheX verifies structural correctness according to a defined protocol.
Verification outcomes are binary. No probabilistic scoring is performed. No user-identifying data is collected or retained. The protocol makes no claims about the intent or identity of the sender, only about whether the request was constructed according to specification.
Motivation
Current verification mechanisms — CAPTCHA variants, behavioral biometrics, and device fingerprinting — share a fundamental architectural assumption: that the system can learn to distinguish "legitimate" from "illegitimate" request origins through accumulated signal.
This assumption has several consequences. First, it requires ongoing collection of user-observable data. Second, it produces probabilistic outcomes, making false positive and false negative rates permanently non-zero. Third, as synthetic agent capabilities improve, the signal becomes increasingly indistinguishable from genuine human activity.
AlltheX rejects this framing entirely. The question is not whether the sender appears human. The question is whether the request was constructed according to a protocol that requires deliberate, compliant participation by the client.
Design Goals
Verification must produce the same outcome for the same input regardless of server state, load, or time. No scoring function, no threshold, no calibration.
The verifier must not require per-user state. The only permissible persistent state is a consumed-nonce store, which contains no identity information.
The protocol must not collect, infer, or retain any information about the sender's identity, device, or behavior as a side effect of verification.
A successfully verified frame must not be reusable. Capture-and-replay attacks must be prevented by protocol, not by rate limiting or heuristic detection.
Protocol Construction
The protocol operates in two phases: frame construction (client) and frame verification (server).
Phase 1: Frame Construction
The client SDK constructs a canonical frame — a deterministic serialization of the interaction — from the following fields:
The nonce is a cryptographically random 128-bit value generated fresh per request. The timestamp is bound to a configurable window (default: ±30s).
Phase 2: Verification
The server receives the canonical frame and signature. It performs the following checks in order:
INVALID_SIGNATURE on mismatch.
FRAME_EXPIRED.
NONCE_CONSUMED if present.
Otherwise, record the nonce with TTL equal to the timestamp window.
If all checks pass, verification succeeds. The consumed-nonce store is the only write operation and contains no user data.
Threat Model
In scope
Out of scope
AlltheX does not protect against a compliant client that constructs valid frames programmatically. The protocol verifies construction correctness — it makes no claim about the nature of the client. Access control, rate limiting, and authorization are the responsibility of the application layer.
Security Assumptions
The secret key is not disclosed to parties outside the client SDK and the verification server. Compromise of the secret key breaks the signing guarantee.
HMAC-SHA256 is a pseudorandom function family under the assumption that SHA-256 is collision resistant. No claims are made about post-quantum resistance.
The nonce store is available and consistent. In distributed deployments, consistency must be enforced at the storage layer.
Client-side nonce generation is cryptographically random. The SDK uses the platform's secure random API.
Limitations
AlltheX is not a general-purpose access control system. It verifies request construction, not request authorization. Applications must implement their own authorization layer.
The protocol does not prevent an adversary who has obtained the client SDK from constructing valid frames programmatically. It provides a verifiable compliance signal, not an unbreakable barrier.
Post-quantum key agreement and signing schemes are not currently supported. The threat model does not include adversaries with quantum computing capabilities.