ãdo.com

Say yes to one thing. Keep the record of it.

ãdo.com is the consent home for the commercial layer the DAO runs. A grant is not a signup and not a blanket agreement — it is a small, record naming exactly what was agreed to, its scope, when it ends, and how to take it back. Nothing on this page asks for a name, an email, or any material that would identify you to read it.

ãdo.com is the consent home for the commercial layer the DAO runs. A grant here is not a signup and not a blanket yes. It is a small record. It names exactly what was agreed to, its scope, when it ends, and how to take it back. This page never asks for a name, an email, or anything that would identify you just by reading the record.

this page used to be the naming gate

That flow — sign a message with a wallet to bind a subdomain — has moved and is retired from this page. ãdo.com now does one job: define, document, and preview what a consent record contains.

This page used to bind subdomain names to keys. That job has moved. ãdo.com now does one thing: define, document, and preview what a consent record contains.

What consent governs

Three readings. One is shipped.

The same record shape can stand for more than one kind of yes. We pick which reading is live rather than leave it ambiguous, because a consent record nobody can misread is the whole point of building one.

The same record shape can stand for more than one kind of yes. We pick which reading is live. We do not leave it ambiguous. A consent record nobody can misread is the whole point of building one.

Data use shipped default

The grantee may use one named, content-addressed piece of material — a corpus, a document, a dataset — in specific listed ways: read it, feed it to an engine, combine it with other material, or republish it. Nothing more.

Representation flagged, not shipped

The grantee may let a synthesized voice, persona, or likeness speak or act on the subject's behalf within a stated scope. Same fields, heavier stakes — persona drift and stale scope need their own review first.

Votes as consent flagged, not shipped

A governance vote on the DAO ledger doubles as a standing grant. Tempting to unify with proposal verdicts, but a vote and a grant lapse on different clocks and conflating them needs its own design pass.

decision, not a discovery

Default scope: data use.

Every field below works the same way for representation and votes-as-consent — purpose is the only value that changes. But only data-use records are issued in production today. The other two are documented so the schema doesn't have to be redesigned when they ship; they are not yet available from the builder's authorization step, and any page that claims otherwise is out of date.

Every field below works the same way for all three kinds. Only purpose changes. But only data-use records are actually issued today. The other two are written down so the schema does not need a redesign later. They cannot yet be signed for real. If a page says otherwise, that page is out of date.

The record

Ten fields, no identity.

A consent record is a flat, small JSON object. Every field is either a content address, a timestamp, an enum, or a short controlled list — nothing free-text is load-bearing, and nothing in the shape can hold a name, an email, a face, or a biometric.

A consent record is a small, flat JSON object. Every field is a content address, a timestamp, a fixed choice, or a short list. Nothing free-text carries any weight. Nothing in the shape can hold a name, an email, a face, or a biometric.

field	type	meaning
schema	string	Fixed to `ΑΔΩ/consent/1` — names the shape and its version so any reader, human or machine, knows how to parse what follows.
purpose	enum	`data-use` · `representation` · `votes-as-consent`. See the default above — only `data-use` is issued today.
subject_ref	sha256	Stands in for the person without naming them: the hash of a value only they know. No name, email, image, or biometric is ever a field in this schema — this is the closest it gets to "who," and it is one-way.
grantee	urn	Who receives the grant. Fixed to the commercial layer a record is made for, e.g. `ΑΔΩ/dao/commercial`.
scope.resource	sha256 / CID	The exact material or capability covered, referenced by its own hash rather than described in prose.
scope.actions	string[]	What the grantee may specifically do: `read`, `feed`, `combine`, `represent`, `republish`. Fewer is the safe default.
scope.description	string	A human-readable note beside the machine-checkable fields above. Informative, not authoritative — the fields above govern.
granted_at	timestamp	ISO-8601. When the grant was made.
expires_at	timestamp / null	When the grant lapses on its own. `null` means it does not expire on a timer and can only be ended by revocation.
terms_cid	sha256	The exact bytes of the terms text shown at the moment of granting, hashed so those terms can never be quietly reworded after the fact.
authorization	object	`{method, key}` — records that a key authorized the grant, and which key. It proves a key was used; it does not prove who held it, how old they are, or what law applies to them.
parent	sha256 / null	Set when a record amends an earlier one — links the two without erasing the earlier record.
revokes	sha256 / null	Set only on a revocation record: names the record being withdrawn. Revocation is a new record, not a deletion of the old one.
record_cid	sha256 / CID	The record's own address, filled in once it is pinned to IPFS. Empty until then — a record cannot know its own hash before it is finished.

The registry today records a SHA-256 for every content address; a is added wherever the underlying material is pinned to IPFS. Not PII by construction: strip authorization.key and every remaining field is either a hash, a timestamp, or a value from a short fixed list.

The registry keeps a SHA-256 for every content address today. A is added once the underlying material is pinned to IPFS. This is not personal data by construction. Set aside authorization.key and every other field is a hash, a timestamp, or a pick from a short fixed list.

Build one

Preview a record, right here.

Everything below runs in this browser. The phrase you type is hashed on your device and never leaves it — only the hash becomes subject_ref. This builds and content-addresses the record; it does not issue or pin one, and it does not sign anything. That step is flagged at the end of this section.

Everything below runs in this browser. The phrase you type is hashed on your device. It never leaves your device. Only the hash goes into the record, as subject_ref. This builds and content-addresses a record. It does not issue or pin one, and it does not sign anything. That step is flagged at the end of this section.

This part of the page needs JavaScript. With scripts turned off you can still read the whole schema above and every term at the foot of the page, but the builder below will stay empty.

A phrase only you know — stands in for subject_ref

Nothing is stored, submitted, or logged. Clear the field and the record's subject_ref reverts to empty.

Resource covered — scope.resource

Actions granted — scope.actions

Expiry — expires_at

Scope, in words — scope.description

Type a phrase above to begin. The record is written out here as you fill in the fields.

record size—

would-be address—

supersedesnone — this is a root record

Type a phrase first

Supersede writes a new record with parent set to this one's address — an amendment, not an edit. Revoke writes a separate record with revokes set to this one's address; the original stays exactly as it was, and any reader checking the subject and grantee finds the revocation sitting after it.

The Supersede button writes a new record. It points parent back at this one — an amendment, not an edit. The Revoke button writes a different record. It sets revokes to this one's address. The original record does not change. Anyone checking later sees the revocation sitting after it.

flagged: the issuing service is not built here

What this page does not do.

Turning a preview into a real, checkable grant needs a small backend: it has to verify the authorization signature over this JSON, stamp granted_at from a trusted clock, pin the bytes to IPFS with a Pinata-backed key held in a worker binding (never in this page), return the resulting record_cid, and answer "is this still live" lookups by walking a subject's trail of supersessions and revocations. None of that is safe to run client-side, and none of it is built on this page. A commented skeleton for that worker — routes, the checks each one owes, and where the pin call goes — lives beside this file rather than on it.

Turning a preview into a real grant needs a small backend. It has to check the authorization signature. It has to stamp granted_at from a clock nobody can fake. It has to pin the bytes to IPFS using a key held in a worker binding, never in this page. It has to hand back the record_cid. And it has to answer "is this still live" by walking a subject's later records. None of that is safe to run in the browser, and none of it is built here. A commented skeleton for that backend sits beside this file, not on it.

Before you rely on this

A record is not a law. It is evidence of one moment.

A consent record proves that a key authorized a scope at a time, against terms whose exact bytes are hashed in. It does not establish who held the key, whether they were old enough to hold it, or which jurisdiction's consent law applies to them — those checks belong upstream of this schema, not inside it.

A consent record proves one thing: a key authorized a scope, at a time, against terms whose exact bytes are hashed in. It does not prove who held the key. It does not prove they were old enough to hold it. It does not prove which jurisdiction's law applies to them. Those checks happen before this schema, not inside it.

Not identity or age verification — authorization.key proves a key, not a person.
Not legal advice — pairing a record with the consent-law requirements of a subject's actual jurisdiction is a separate, necessary step.
Not a token, a share, or an economic right — a grant is a scope on material, nothing tradeable.
Not deletable — a revocation is a new record, not a delete; see the schema's revokes field above.

Not identity or age verification. A key proves a key was used, not who used it.
Not legal advice. Pairing a record with the actual consent law of a subject's jurisdiction is a separate step, and a necessary one.
Not a token, a share, or an economic right. A grant is a scope on material — nothing tradeable.
Not deletable. A revocation is a new record, not a delete. See revokes above.

Terms

consent record: A small, signed document naming who authorized what, its scope, and how long it stands. Kept as a content address, not stored as a copy of anyone's personal material.
subject_ref: A hash of something only the subject knows, standing in for their identity. One-way — it cannot be turned back into the phrase that made it.
scope: Exactly what a grant covers: which resource, and which specific actions on it. Nothing outside the listed actions is authorized.
revocation: A new record that names an earlier one as withdrawn. It does not erase the earlier record — it sits after it, and any reader has to check for one.
ledger: The record of what was granted and revoked, written down as addresses. It is only added to. Nothing in it is edited later.
CID: A name made out of the file itself. Change one byte and the name changes. So the name proves what the file is.