oConsent
Open Consent Protocol

Consent you can check later.

Most consent today is a checkbox and a promise. oConsent turns it into a record anyone can verify: signed by the person, stamped with an independent time, and anchored on a public chain. If a company says you agreed, you can prove whether you did.

v0.1.0 · Early. Pre-1.0. arXiv:2201.01326 Open source
Consent record
subjectdid:oc:9f2a…c41
processoracme-analytics
purposeproduct-analytics
valid_from2026-06-28
valid_until2027-06-28
timestampnist + btc
grantedRevocable at any time. Expires on its own.
01 The problem

Nobody can check a checkbox.

Sites, apps, and devices collect activity data through cookies, device IDs, embedded scripts, and pixels. You click "I agree" and the record of that agreement lives on the collector's servers, in a format only they control. If they change it, lose it, or read it generously in their own favor, there is no independent copy to check against. Laws like GDPR and CCPA give people rights over their data, but the proof of what was agreed, and when, is still a matter of trust.

  • The agreement and the audit log sit with the same party that benefits from them.
  • Revocation is hard to prove after the fact.
  • Regulators and auditors get screenshots, not evidence.
02 How it works

A consent record, end to end.

oConsent describes a consent agreement as structured data and gives it a life: created, signed, timestamped, anchored, checked, and ended. The steps below map to the reference code, not a wish list.

01

Record

A consent agreement names the subject, the processor, the specific purposes, and a validity window. Purposes carry their own retention period.

02

Sign

The agreement is signed with the subject's key, so a record cannot be forged or quietly edited later.

03

Timestamp

An independent time is attached from the NIST Randomness Beacon and from Bitcoin, so the date is not just the collector's word.

04

Anchor

Hashes go on a public chain through the Solidity contracts. The bulky metadata stays off-chain in IPFS, referenced by hash.

05

Verify

Anyone with the record can check that it is active, inside its window, and valid for a given purpose and processor.

06

Revoke or expire

A subject can revoke at any time, and consent can expire on its own. Both are recorded the same verifiable way.

03 Who it is for

Three sides of the same record.

People

See what you agreed to, in plain fields, and revoke it without asking permission from the company holding your data.

Processors and privacy officers

Hold evidence of valid consent that an auditor can verify independently, instead of a log only you can produce.

Developers

Wire consent checks into your stack with a Python SDK, a CLI, and contracts you can read. Small surface, no black box.

04 Where it stands

Early, and honest about it.

This is a research project with working code, not a finished product. The consent lifecycle, signatures, timestamping, IPFS storage, and the contracts are real and tested. Some pieces named in the paper, like production zero-knowledge proofs and support beyond Ethereum, are not built yet. The status page says plainly what works today and what does not.

05 Get involved

This needs people, not a waitlist.

oConsent is small and open. The most useful thing you can do is read the code, try to break the model, and tell us where it falls short. Good first moves: run the CLI, review a contract, or open an issue on the spec.

Reference implementation: bassrehab/oconsent