How it works
How a consent becomes proof
A record in a database can be changed by whoever runs the database. OptProof records consent so that changes are visible: every event is chained to the one before it, signed, and sealed every night in storage nobody can rewrite.
9f2c…c93e
3ad8…68d2
c71b…72e8
5e09…17b2
26 Oct 2026Write-once storage
a4e1…7c30
Receipt code OP-7K2M-9QXD
Try it
Make a choice, get a receipt
This is the flow your customers see, running in your browser. Each decision becomes an event in a hash chain. Withdrawing is one click, the same as agreeing.
Demo Clinic asks
Demo, nothing is recordedChoose what Demo Clinic may use your details for. Nothing is pre-ticked.
- Booking and managing appointmentsAlways on
The three buttons look the same on purpose. Saying no should be as easy as saying yes.
Your receipt appears here
Make a choice in the form. You get a receipt code and the chain hash that seals it.
What happens when someone says yes
- Step 01
The choice is captured
On your website, in your app, at a kiosk, by QR or on WhatsApp. The capture records which notice version the person saw and in which language. - Step 02
It is appended to the ledger
Inside one database transaction, the event gets the next position in your property’s chain and a hash that covers the previous event’s hash. - Step 03
A receipt is signed
OptProof signs a short receipt with an Ed25519 key. It names the event and its hash, and contains nothing that identifies the person. - Step 04
Your tools are told
Webhooks and connectors pass the change on to your CRM, store and messaging lists. - Step 05
The day is sealed
At 00:30 IST we sign the last hash of the previous day and write it to an S3 bucket with Object Lock in compliance mode. - Step 06
Anyone can check it
verify.optproof.in checks the signature, recomputes the chain to the anchor, and explains the result in plain words.
The event
Seventeen fields, serialised as canonical JSON so that anyone gets the same bytes. The ledger stores a keyed pseudonym of the person, never their phone number or email.
{ "action": "grant", "channel": "qr", "context": { "location_id": "loc_…", "staff_id": "stf_…", "ui_variant": "qr" }, "device_ref": null, "id": "evt_01JB…", "is_test": false, "language": "hi", "notice_id": "ntc_01JA…", "notice_version": 3, "occurred_at": "2026-10-25T05:12:41.000Z", "prev_hash": "3ad8e6b1c94f02a7…", "principal_ref": "k3Jd9…", // keyed pseudonym, not a phone number "property_id": "prp_01J9…", "purpose_keys": ["appointments", "whatsapp_reminders"], "recorded_at": "2026-10-25T05:12:41.214Z", "seq": "1042", "tenant_id": "ten_01J8…"}hash = SHA-256( prev_hash_bytes ‖ canonical_json(event) )The receipt
A compact JWS. The person can keep it as a PDF, a QR code or a file, and check it years later: retired signing keys stay published.
// Header{ "alg": "EdDSA", "kid": "opk_2026_10_7k3m9q2x", "typ": "optproof-receipt+jws" }// Payload: no name, phone number or email{ "rc": "OP-7K2M-9QXD", "evt": "evt_01JB…", "prp": "prp_01J9…", "seq": "1042", "h": "c71b0e9a2f4d86e3…", "act": "grant", "pur": ["appointments", "whatsapp_reminders"], "nv": 3, "lang": "hi", "ch": "qr", "ts": "2026-10-25T05:12:41.000Z"}What the checks catch
| If someone… | It shows up as |
|---|---|
| A field of a past event is edited | The event’s hash no longer matches |
| An event is edited and its hash recomputed | The next event no longer links to it |
| An event is deleted, or events are reordered | A gap or a broken link in the chain |
| A forged event is inserted | Broken links, or a mismatch with the anchor |
| History is rewritten from some point, all hashes recomputed | Anchors signed before the rewrite, and receipts people already hold |
| The newest events are removed | The chain ends before the anchored position |
| A receipt is changed or made up | The signature does not verify |
The limits, stated plainly
- The newest events. Until the nightly anchor (up to about a day), the receipt in the person’s hands is the main protection for a new event. The verifier shows these as pending, not verified.
- Our own keys. Receipts and anchors are signed with OptProof keys. What stops a silent rewrite is the write-once storage of past anchors, the receipts people already hold, and, later, a public feed of daily anchors that anyone can copy.
- What “valid” means. A valid record shows what was recorded and when, and that it has not changed. It does not judge whether the notice or the consent met a legal standard.
Compared
What a basic banner leaves out
A banner records a click. A business that may have to show its records needs more than that.
| Feature | Typical basic banner | OptProof |
|---|---|---|
| Capture | ||
| Cookie banner with Accept and Reject side by side | Included | Included |
| Consent per purpose, tied to the notice version shown | Partly | Included |
| Consent at the front desk by QR or tablet kiosk | Not included | IncludedQR on Growth, kiosk on Business |
| WhatsApp consent and imported lists with evidence | Not included | IncludedImports on Growth, WhatsApp on Business |
| Proof | ||
| A signed receipt the person can keep | Not included | Included |
| Anyone can verify a record without trusting the vendor | Not included | Included |
| Published verification method and test vectors | Not included | Included |
| Sync | ||
| Withdrawals pushed to your CRM, store and email tools | Partly | IncludedWebhooks on Starter, connectors on Growth |
| Rights | ||
| Request desk with deadlines and reminders | Partly | IncludedStarter and above |
| Setup | ||
| Where data is stored | Varies | AWS Mumbai (ap-south-1) |
| A person who sets it up with you | Not included | OptionalOne-time fee per website or app |
Start with test keys today. Go live when you’re ready.
Install the widget, record test consents and verify your first receipt in under ten minutes.