How we prove consent

1. What we capture

At the moment a consumer consents, each record binds together:

• The exact disclosure the consumer saw — a snapshot of the request/wording in the same form and format it was presented (the TSR's core requirement).
• Identity fields — name, email, phone as submitted.
• Context — page URL, campaign/form identifiers, and user agent.
• Origin forensics — the visitor's IP and edge geolocation signals (country, region, city, postal code, approximate lat/long, EU flag, ASN), observed server-side at the edge. These are network-origin signals — not GPS geofencing or device GPS.
• A precise timestamp from server time, with clock-skew handling.
• Bot-screen result — a dual human screen recorded as a verified verdict: a leading human-verification result and an independent invisible proof-of-work the browser solves at capture, so the record reflects a screened human, not an automated submission.
• Optional — watermarked video and rendered proof images of the interaction.

2. How we make it tamper-evident

• Content hashing. The captured payload is hashed; the certificate references that hash, so any later alteration is detectable.
• Hash chain. Records are linked so a record can't be silently inserted, removed, or reordered after the fact.
• Independent RFC 3161 timestamps. Records are folded into the append-only CapchaChain ledger. Each new block hash is submitted independently to multiple independent commercial timestamp authorities, and every returned timestamp token is retained as its own witness. A temporary provider outage does not stop the block from sealing; a scheduled anchor sweep retries missing witnesses without changing the sealed block.
• External Bitcoin anchor (async). The same block hash is submitted to multiple independent OpenTimestamps calendar servers and anchored asynchronously to Bitcoin. The standard, downloadable .ots proof can be checked offline for its commitment to the block hash and decoded for pending calendar attestations or matured Bitcoin block heights. Confirmation matures within hours; it is not instant Bitcoin finality.
• Verification endpoint. A certificate can be re-verified against its stored hash at any time; share links are revocable. Live anchor status: /api/v1/transparency.
• Sign-ins are sealed too. Every sign-in is sealed into a tamper-evident, publicly-verifiable auth-evidence certificate the same way consent records are — part of CapchaID, the identity product this covers.

Don't take our word for any of this — verify it yourself, offline. Download the verifier (zero dependencies, Node 18+ built-ins only) and run it against any evidence bundle:

curl -O https://capchacloud.com/verify-evidence-bundle.mjs
curl -o bundle.json "https://capchacloud.com/api/v1/public/evidence-bundle/<id>"
node verify-evidence-bundle.mjs bundle.json

Full walkthrough and the chain-level verifier (re-derives every block in the append-only ledger): Public chain explorer — verify offline.

3. CapchaSign's embedded PDF signature (PAdES-B-T)

Every CapchaSign document sealed after July 15, 2026 carries a real CMS/PKCS#7 detached signature embedded directly in the PDF's own /Type /Sig dictionary, RFC-3161 timestamped — the same mechanism Adobe Reader and any standard PDF validator recognize natively. This is stronger than a hash you have to fetch from our API: open the PDF in Adobe Reader or any compliant validator and it checks the signature itself, completely offline, with zero calls to CapchaCloud.

• Honest disclosure — self-signed today. The signing certificate is self-signed, not yet issued by a CA on Adobe's Approved Trust List (AATL). Adobe Reader will show the signature as cryptographically valid and unmodified since signing, but the signer identity as untrusted until we complete the AATL upgrade (a real, separate procurement step — tracked, not hidden).
• Published fingerprint. SHA-256 of the current signing certificate (DER): d9d953e0fa36e2d16e4426833a8370680e873f55f9ab6da26c93b0381e38257c. Compare this against the certificate embedded in any CapchaSign PDF's signature dictionary to confirm it was signed with CapchaCloud's actual key — not a substitute.
• Detached signature, standard OIDs. SubFilter: ETSI.CAdES.detached; signed attributes include contentType, messageDigest (SHA-256 of the document bytes outside the signature slot), and signingTime; the RFC-3161 token is embedded as the unsigned signatureTimeStampToken attribute (PAdES-T, not just -B).

4. How long we keep it

Every consent record is retained for a 5-year hard floor — meeting the FTC Telemarketing Sales Rule's recordkeeping requirement and outlasting the TCPA's 4-year statute of limitations. Retention cannot be shortened or deleted early, even by the account owner. Records are billing-independent: lapsed billing never deletes evidence. Legal holds can extend retention indefinitely.

WORM (write-once-read-many) storage. Evidence objects are held in immutable object storage protected by retention locks: once written, a record cannot be modified, overwritten, or deleted before its retention period elapses — the protection is enforced by the storage layer itself, not just by application logic, so it holds even against a compromised operator. All objects are encrypted at rest with AES-256.

5. Inspect a sample certificate

A representative certificate (with synthetic data) shows the full evidence record and verification result. Request a live sample for evaluation via support, or generate one in your own tenant from the dashboard.

Note: CapchaCloud provides recordkeeping infrastructure designed to support TCPA/TSR compliance. It is not legal advice; consult counsel regarding your specific obligations.

Related comparisons

CapchaID vs Clerk · CapchaCloud vs TrustedForm