SHA-256 Consent Hash
Hash the record at capture; any edit breaks the hash. Cheap math that converts 'our database says so' into verifiable evidence.
The evidentiary weakness of ordinary consent storage is mutability: whoever controls the database can change the record, so the record proves little. Hashing addresses it mathematically.
At capture, the consent record's contents — number, timestamp, form version, checkbox state, session reference — are run through SHA-256, producing a fixed 64-character digest. The digest is stored (and ideally distributed: shared with the consumer, published to a verification endpoint, or anchored externally). Recomputing the hash later and comparing proves the record is byte-identical to what existed at capture.
This is the mechanism behind "cryptographic consent receipts": the hash plus a public verification page lets anyone — carrier auditor, opposing counsel, the consumer — confirm a record's integrity without trusting the sender's database administration.
Frequently asked questions
Related glossary terms
A consent record is the stored evidence package for a single opt-in event: the consumer's identifier, the exact disclosure shown, the affirmative act, attribution data, and integrity protection that proves the record was not altered.
Consent proof is the evidentiary record that a recipient explicitly opted in to SMS — typically a timestamped, IP-logged, hash-locked record of what the user saw and when they consented.
An audit trail is the chronological, tamper-evident record of consent events — capture, modifications, revocations — that lets a sender reconstruct and prove the consent state of any number at any point in time.