ERC: Cryptographic Amnesia Interface — Provable key destruction for the right to be forgotten on blockchain

ERCs
1

Summary

I’m proposing a new ERC that defines a standard interface for cryptographic amnesia — provable, irreversible encryption key destruction on append-only ledgers.

After a destruction ceremony completes, encrypted on-chain data becomes mathematically indistinguishable from random noise. No key exists anywhere in the universe to decrypt it. The ciphertext remains on-chain, but it’s permanent noise.

This is the first standard to enable a credible right to be forgotten on an immutable blockchain.

Repository: https://github.com/Valisthea/styx-erc-cryptographic-amnesia
Author: Valisthea
Related: ERC: Encrypted Token Standard (submitted separately)

The Problem

Blockchains never forget. This is a feature — until it becomes a liability.

  1. GDPR Article 17 — EU law requires data controllers to delete personal data upon request. On a public blockchain, deletion is architecturally impossible. No existing standard addresses this. Projects handling EU user data on-chain operate in a legal grey zone with no technical solution.

  2. Governance pollution — DAO votes create permanent political records. After a governance cycle, individual voting positions become ammunition for coercion, retaliation, and faction warfare. The result matters. How each person voted should not persist forever.

  3. Sealed-bid auctions — After the winner is determined, losing bids should become permanently inaccessible. Today, encrypted bids remain recoverable if the encryption key is ever compromised — even decades later.

  4. Medical and legal records — Temporary on-chain storage (clinical trials, legal proceedings, whistleblower reports) where retention past a defined period creates risk, not value.

  5. Key compromise limitation — When an encryption key is suspected compromised, there’s no standard way to provably destroy it and limit the damage window.

Why “Just Delete the Key” Doesn’t Work

Deleting a key from a single server proves nothing. The key could exist in backups, RAM dumps, HSM snapshots, or the administrator’s memory. There’s no cryptographic proof that deletion occurred.

This standard solves this through distributed destruction with individual proofs: the master key is split via Shamir Secret Sharing across independent custodians. Each custodian independently proves their share was destroyed via a ZK proof. The threshold property of Shamir SSS guarantees that once enough shares are destroyed, reconstruction is mathematically impossible — regardless of what any remaining party retains.

How It Works

Ceremony Lifecycle

IDLE → PENDING (VDF countdown) → ACTIVE (accepting destruction proofs) → COMPLETED (amnesia)
                                                                       → FAILED (timeout, retry possible)

Phase 1 — Initiation. An authorized party calls initiateOblivion(sessionId). This starts a VDF (Verifiable Delay Function) time-lock countdown. Minimum 24 hours, recommended 72 hours for sensitive data.

Phase 2 — VDF delay. The countdown prevents coerced or panicked destruction. Stakeholders see the OblivionInitiated event and can take action: retrieve their data, cancel the ceremony, or veto via custodian supermajority.

Phase 3 — Destruction proofs. After the VDF delay, custodians submit ZK proofs that their key share has been destroyed. Each proof attests that the custodian knew a valid Shamir share and has committed to the destruction ceremony.

Phase 4 — Completion. When the destruction threshold is reached (n-k+1 proofs for a k-of-n scheme), AmnesiaAchieved is emitted. isForgotten(sessionId) returns true — permanently and irreversibly.

If the deadline passes without enough proofs → FAILED. Keys are NOT destroyed. A new ceremony can be initiated (with cooldown and attempt limits).

Core Interface

solidity

interface IERCYYYY {
    // Lifecycle
    function initiateOblivion(bytes32 sessionId) external returns (uint256 vdfUnlockTime, uint256 deadline);
    function submitDestructionProof(bytes32 sessionId, uint256 custodianIndex, bytes calldata proof) external returns (bool ceremonyComplete);
    function cancelOblivion(bytes32 sessionId) external;
    function vetoCeremony(bytes32 sessionId, bytes calldata vetoProof) external;
    
    // Queries
    function isForgotten(bytes32 sessionId) external view returns (bool);
    function isForgoable(bytes32 sessionId) external view returns (bool);
    function ceremonyInfo(bytes32 sessionId) external view returns (CeremonyInfo memory);
    
    // Events
    event OblivionInitiated(bytes32 indexed sessionId, address indexed initiator, uint256 vdfUnlockTime, uint256 deadline);
    event ShareDestroyed(bytes32 indexed sessionId, uint256 indexed custodianIndex, bytes32 proofHash, uint256 proofsTotal, uint256 thresholdNeeded);
    event AmnesiaAchieved(bytes32 indexed sessionId, uint256 completedAt);
}

Extensions

Compliance — complianceReceipt(sessionId) returns an ABI-encoded audit trail (timestamps, custodian proof hashes, VDF parameters). retentionPeriod(sessionId) blocks amnesia before legal retention requirements expire. Built for regulated environments.

Hooks — onAmnesiaAchieved(sessionId) callback for dependent contracts. Called after state transition is complete. Reverts don’t block amnesia (irreversibility is sacred).

Key Design Decisions

Shamir SSS over MPC — MPC requires all custodians online simultaneously. Shamir allows asynchronous, independent share destruction. Critical for geographically distributed custodians across jurisdictions.

VDF over simple timelock — Block-number timelocks can be manipulated by validators (±15s). A VDF provides a cryptographic guarantee of elapsed real time, independent of block production.

FAILED preserves keys — A partially completed ceremony that destroyed some shares but not enough would leave an ambiguous state. FAILED means nothing changed — retry safely.

Irreversibility is non-negotiable — Once isForgotten() returns true, it MUST never return false. This is the entire legal and cryptographic guarantee. Reversible amnesia is not amnesia.

Trust Model (Honest Disclosure)

A ZK destruction proof proves that a custodian participated in the ceremony and knew a valid Shamir share. It does NOT prove physical deletion of the share from all possible storage locations — this is fundamentally unprovable in software.

The security guarantee relies on:

  • ≥ (n-k+1) custodians honestly destroying their shares

  • HSMs performing secure deletion (hardware trust)

  • Institutional diversity of custodians (different orgs, jurisdictions, hardware vendors)

We document this explicitly in the Security Considerations. This is not a weakness — it’s a trust boundary that must be understood.

Interaction with Other Standards

This standard is designed to complement the Encrypted Token Standard (submitted separately):

  1. Encrypted token stores balances under FHE key K

  2. Key K is split into Shamir shares across custodians

  3. Governance cycle completes, votes tallied

  4. initiateOblivion(sessionId) → VDF countdown

  5. Custodians submit destruction proofs

  6. Threshold reached → AmnesiaAchieved

  7. All data encrypted under K is now permanent noise

  8. The tally result persists. Individual votes are forgotten. Zero political debt.

Prior Art

I’m not aware of any existing ERC or EIP that addresses provable key destruction or the right to be forgotten on blockchain. The closest related work:

  • EIP-2135 (Consumable Interface) — tokens that can be “consumed”, but the data persists

  • GDPR on blockchain literature — academic papers proposing off-chain storage with on-chain hashes, but no standard interface for key destruction

  • Aztec’s note-spending model — nullifiers mark notes as spent, but the encrypted data is still decryptable if keys exist

If anyone is aware of prior work in this space, I would appreciate the reference.

Questions for the Community

  1. Minimum custodian count — the draft recommends 5 minimum, 7+ for production. Is this sufficient, or should the standard enforce a higher minimum?

  2. VDF construction — should the standard mandate a specific VDF (Wesolowski vs Pietrzak), or remain construction-agnostic?

  3. Ceremony attempt limits — the draft includes maxCeremonyAttempts() (recommended: 3). After max attempts, governance override is required. Is this the right safety valve?

  4. Cancel vs veto — the draft includes both cancelOblivion() (by initiator/governance) and vetoCeremony() (by custodian supermajority). Is the veto mechanism necessary, or is cancel sufficient?

  5. Post-amnesia token behavior — after key destruction, what should encryptedBalanceOf() return? The ciphertext (now noise)? Should the token contract enter a “frozen” state? This interaction with the Encrypted Token Standard needs community input.

  6. Legal sufficiency — has anyone consulted with EU data protection lawyers on whether “encrypted data with provably destroyed keys” satisfies GDPR Article 17? I believe it does based on current regulatory interpretation, but formal legal analysis would strengthen the standard.

Feedback welcome. This is uncharted territory — no existing standard addresses this problem.

— Valisthea