1. General principles
We aim to:
- keep personal data only for as long as necessary for the relevant purpose;
- distinguish short-lived operational data from longer-lived legal, moderation, or accountability records;
- distinguish off-chain application records from public-chain references; and
- delete, prune, or anonymize records where lawful and technically feasible.
2. Main record classes
| Category | Typical contents | Typical retention posture |
|---|---|---|
| Authentication challenges | Challenge material and short-lived auth state | Typically up to 5 minutes |
| Session and abuse-prevention data | Session metadata, verification events, IP / user-agent context, rate-limit signals | Access-session state typically up to 1 hour; refresh-session state up to 30 days; related abuse-prevention signals only as long as needed for the active window or security review |
| Use-context and acknowledgement records | Business / developer / consumer self-classification, acknowledgement timestamps, terms version, IP hash | Retained with the related compliance profile while needed for legal traceability, abuse prevention, and claim defense |
| Audit and privileged-action records | Administrative actions, security-relevant events, moderation audit trail | Retained for operational accountability and claim defense; may be kept longer where incident handling, legal hold, or claims require it |
| Idempotency and failed-side-effect records | Completed idempotency keys, dead-letter traces, retry-suppression records | Short operational windows sized to duplicate suppression and failure analysis needs |
| Notices, statements of reasons, and appeals | Notice intake, decisions, redress and appeal records | Formal compliance appeals currently use a 6-year retention class after closure; related notice and statement records may be kept for matching or shorter legal/accountability windows depending on the workflow |
| Chain-event mirrors and reconciliation data | Public-chain event mirrors, reconciliation and integrity records | Retained as needed for integrity, reconciliation, and incident analysis |
| Managed-storage records | Artifact references, retention metadata, related storage events | Typically finalized 24 hours after a settled milestone and, absent legal hold or claim preservation needs, no later than 7 days from creation |
| Enhanced compliance records | Trader-verification, tax-reporting, or other compliance-specific material, if enabled | Only when enabled and only for as long as required by purpose and law |
| Support, legal, and security correspondence | Support requests, privacy requests, abuse reports, security reports | Retained as needed to resolve the matter and meet legal or accountability needs |
3. Public blockchain limitation
Public blockchain data may remain visible indefinitely from the relevant network, archives, explorers, mirrors, or other third-party infrastructure even if we delete or restrict related off-chain records under our control.
4. Changes and exceptions
Actual retention windows may vary by system, feature, incident, legal hold, dispute, appeal, or operational need.
We may keep records longer where reasonably necessary to:
- comply with law, sanctions, court orders, or regulator demands;
- detect, investigate, or defend against abuse, fraud, or security incidents;
- preserve evidence for disputes, appeals, or legal claims; or
- protect users, infrastructure, or the integrity of the Services.
5. Changelog
- 2026-04-20.2: Added concrete examples for current auth, session, appeal, and managed-storage retention windows where the runtime already exposes a defined baseline.
- 2026-04-20.1: Added explicit retention coverage for use-context and acknowledgement records and introduced document versioning.