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. Mainnet anchoring is not live yet

On-chain anchoring runs today on Base Sepolia, a testnet. Base mainnet is not yet deployed, and mainnet anchoring is relayer-gated. Read anything about the "on-chain anchor" with that status in mind: the mechanism is real and running on testnet, and production mainnet anchoring is still ahead.

Next