Agreely
FR EN

Honest boundaries

Agreely's value is that it proves consent instead of merely logging it. That only holds if the proofs are described honestly, including where they stop. This page is the list of things Agreely deliberately does not claim. Every one of them is a place where an easy overclaim would be tempting and wrong.

1. Erasure is Agreely's copy plus a request the company must honor

Erasing a cell is a crypto-shred of Agreely's own readable copy, plus a request the company must honor in its own systems. It is not a single switch that destroys the data everywhere.

Never "destroyed everywhere at all times"

After a shred, a residual persists in write-ahead logs and base backups within a documented retention window, and the data the company holds in its own systems is outside Agreely's reach entirely. Agreely claims immediate anonymization of the live database and full physical destruction within the retention window. It never claims the consent is destroyed everywhere, instantly, for all copies.

A manual or offline consent produces a company-attested receipt. The company attests that it holds a hand-signed document (a PDF) whose hash matches the recorded commitment. The server trusts the client-computed PDF hash: it is a notary-style date-stamp on a document the company vouches for, not cryptographic proof that a specific human signed.

Attested is weaker than signed, and labeled as such

A citizen_signed consent carries a passkey assertion that binds a human's authenticator to the exact cells. A company_attested consent carries only the company's word plus a matching hash. Both enforce identically at check time, but the tier label always tells a reader which one they are looking at.

Agreely's consent-document drafts and its Law 25 compliance mapping are a starting point to reason from, not a legal opinion. Final validation of any consent wording, retention rule, or article mapping rests with the company's own legal counsel. Agreely does not practice law and does not certify compliance.

4. On-chain anchoring is hashes only

What Agreely writes on-chain is limited to opaque bytes32 commitments, emitted once, carrying no readable content. There is no personal information, no DID, and no customer_id on-chain. The anchor exists so a record cannot be quietly rewritten after the fact.

The chain is proof, never the read path

The synchronous check never reads the chain, and the chain never gates a decision. Enforcement is authoritative in the application database the instant a grant or withdrawal commits. If the chain were unreachable, checks would still resolve. The anchor is there for after-the-fact verification, not for enforcement.

5. The IPFS document copy is not proof anyone consented

Agreely publishes a public copy (an IPFS CID) of the article 8 disclosure document, the notice describing what is collected and why. That copy exists so the disclosure text is publicly pinned and cannot be quietly altered.

A published disclosure is not a consent

The IPFS copy is the company's disclosure notice, not any person's answer. It is explicitly not proof that any citizen consented, and it is not personal information. Consent lives in the receipt and the enforcement record, never in the public document copy.

6. Anchoring is asynchronous, and Agreely's relayer is the writer

Production anchoring is live on Base mainnet (chain id 8453). Two limits remain true, and are stated as such.

First, anchoring is asynchronous. A grant or a withdrawal is authoritative in the database the instant it commits, and the on-chain write follows. There is therefore a window in which a consent is fully enforceable but not yet anchored. That is deliberate: the chain never gates a decision.

Second, an Agreely relayer wallet submits the transactions (onlyRelayer). So what the chain guarantees is not that Agreely wrote everything it should have written; it is that what was written cannot be quietly rewritten afterwards, and that a company or an auditor can read it directly without going through Agreely.

7. Epoch signing and delegation are accountability, not non-repudiation

Each epoch root is signed with the company's registered DID key, and the company authorizes that signing key with its own root passkey, committed in its DNS. It is a real accountability improvement, described exactly as such.

Agreely-hosted: never "you alone"

The operational signing key is Agreely-hosted: it is generated server-side and its secret is wrapped under the tenant's data-encryption key, so Agreely can unwrap it and sign on the company's behalf. Agreely therefore says "signed with your company's registered DID key" and "you authorize the signing key with your own passkey, committed in your DNS, auditable and revocable." It never claims non-repudiation, "you alone," tamper-proof, or a revocation guaranteed visible independently of the relayer. For a synced passkey, the level stays ~AAL2 (no hardware isolation). A signature or delegation that is absent or invalid degrades to "not company-attested," never to an integrity failure.

Next