Privacy and erasure

Agreely is built so that proving consent does not require holding the data, and so that erasing consent destroys the readable claim rather than promising to. This page covers two distinct rights that are easy to conflate, and the crypto-shred that backs the erasure of Agreely's own copy.

#Withdrawal is not erasure

Two different rights sit behind "stop using my data," and Agreely keeps them apart on purpose.

• Withdrawal (section 8) ends a live consent. It flips the enforcement record to revoked, and the very next check denies. Withdrawal deliberately keeps a record: the consentRef, the receipt, and the anchored commitment all survive, because being able to prove that a consent existed and was then withdrawn is itself the accountability Law 25 asks for.
• Erasure (article 23) is a request to destroy. It is not a status flip; it crypto-shreds Agreely's own readable copy of the cell and produces a request the company must honor in its own systems. Agreely cannot reach into your database, so erasure is Agreely's part plus your obligation, not a single switch.

#Crypto-shred erasure

Agreely implements erasure of its own copy per-cell as a crypto-shred. Each consent cell is bound by a commitment:

commitment = keccak256( JCS(claim) || salt32 )

The 32-byte salt is the cell's only secret and the only thing that makes the commitment reversible to the claim. Erasing a cell destroys that salt (and the readable claim rows around it), while keeping the commitment so the surviving cells of the same consent still verify against the Merkle root. The synchronous check default-denies the instant the erase transaction commits.

#The honest boundary

It is tempting to claim erasure is instantaneous and total everywhere. It is not, and Agreely states the boundary plainly rather than overclaiming.

Concretely, the moment the erase transaction commits:

• the salt is gone from the live row, so the retained commitment is a one-way hash that is not reversible to the claim;
• the readable claim row (the plaintext category/purpose) is deleted;
• the synchronous check default-denies and the dashboard no longer lists the cell.

What still exists, until the retention window passes, is an unreadable residual that carries no category or purpose claim: the on-chain commitment is an orphan with its salt destroyed, and the remaining linkage ties a DID to an opaque random consent_ref that reveals nothing. Full physical destruction completes within the documented retention window.

#Why the residual carries no identity

Erasure can keep a consent_ref-to-DID linkage as a Merkle sibling without that residual carrying any readable identity, because the consent_ref is a fresh, opaque random value that reveals nothing about who the person is. That property is unlinkability, and it is what lets Agreely retain the cryptographic proof of a consent while destroying its readable form. The full account, including the precise boundary of what unlinkability does and does not hide, lives on its own page.

#Independent verifiability

None of this requires trusting Agreely. The artifacts a person or auditor holds, the receipt, the DID documents, and the on-chain anchor, are enough to verify a grant end to end. See the verify recipe.

#Next

• Unlinkability: the full company/citizen non-correlation model.
• Honest boundaries: why "destroyed everywhere at all times" is a claim Agreely refuses to make.