Draft for counsel. The periods below are Mirror's proposed defaults for what the operator holds. Each member bank's own record-keeping obligations govern what it keeps, and may be longer. Not legal advice.
What the operator holds, and for how long#
| Record class | Where | Proposed retention | Why | Disposal |
|---|---|---|---|---|
| Governance events (members, corridors, witnesses, revocations) | mirror_registry_events | The life of the rail | The registry is the root of trust; every verdict is judged against it | Never deleted. A retired corridor or member is its own event. |
| Signed verdicts (the ledger) | mirror_verdicts | At least 10 years | Members' AML record-keeping periods; the verification escrow (mirror-archive) is built for the ten-year record | Kept intact, so the hash-linked log stays verifiable. Made unlinkable by crypto-shredding (below). |
| Member public keys | mirror_member_keys | The life of the rail | Old verdicts must stay verifiable | Never deleted |
| pKYC triggers (entity commitments) | mirror_trigger_bus | The period the legal basis allows | Each trigger is shared under a named basis | Pruning by basis is not automated today |
| Webhook subscriptions | mirror_webhooks | While subscribed | Delivery | Deleted on unsubscribe |
| Webhook deliveries (the outbox) | mirror_webhook_deliveries | Proposed 90 days after delivered, dead or gone | Delivery evidence for the member | Pruning is not automated today |
| Delegations | Not stored | — | Presented at each sign-in | — |
The erasure conflict, resolved by design#
A data subject's right to erasure (GDPR Art. 17) and the members' duty to keep AML records pull in opposite directions. Art. 17(3)(b) exempts processing necessary for a legal obligation, which covers the members' record-keeping period.
What happens after that period is where Mirror's construction helps. A commitment is only linkable to anything through the secret that salted it:
- the corridor secret, for band commitments and locators;
- the network secret, for pKYC entity commitments;
- the receipt or certificate secret, for witness commitments;
- the document salt, for origin commitments.
Destroying that secret is crypto-shredding.
- After: no one, the members included, can open or re-link any commitment made under it. The operator's signed ledger stays byte-for-byte intact and verifiable; its content is unlinkable for everyone.
- When: the destruction is scheduled in the corridor-key rotation plan (
retain_old_until), after the retention period. - Only if nothing holds it: a litigation hold or a supervisory request stops it first.
mirror-rotation.state()reportsold_key_shred_dueand names the consequence. - Where it happens: in the members' HSMs, under their dual control. Mirror never holds the secret, so it cannot shred it, and cannot fail to.
What is not solved here#
- Automated pruning of pKYC triggers and delivery rows.
- Retention in a member's own systems: its bander run logs, its case system, its copies of verdicts. That is the member's schedule.
- Backups of the operator's store. They follow the store provider's backup regime (see sub-processors). Crypto-shredding covers them too, because what they hold is also unlinkable without the destroyed secret.