What AION cannot collect, and what proves it.

This is the privacy notice for AION. It applies to the AION website, the prototype application at /seal and /unseal, the memory variants at /seal/memory and /unseal/memory, and the AION protocol’s public communications. It is written to be readable by a non-lawyer and to be precise enough to verify against the source code.

Revision:v0.3 · 2026-05-03Status:Pre-launch · Phase 0/1

AION’s architecture implements privacy by design within the meaning of GDPR Article 25 in a stronger form than that article requires: not as a default that an operator can disable, but as a structural property of the protocol that no operator can disable. The five elements Article 25 lists — pseudonymization, data minimization, limitation of access, technical and organizational measures, and the integration of safeguards into processing — are each satisfied by mathematical incapacity rather than by operator policy.

In Schrems II terms (Case C-311/18, Court of Justice of the European Union, 16 July 2020), AION’s ciphertext transmitted to a non-EU sovereign holder is, on receipt by that holder, useless to the holder, useless to any surveillance authority that holder might serve, and useless to any third party. No supplementary measure is needed because the ciphertext is already protected at the highest level the framework recognizes. The supplementary measure is the architecture itself.

• The plaintext of any vault.
• The 256-bit AES key that encrypts a vault.
• A combination of shards sufficient to reconstruct a key. The seven sovereign holdings each receive one shard; AION never aggregates them.
• The memory answer, in any form, for any vault.
• Any biometric template. Biometric matches are computed on the user’s device and proved with zero-knowledge attestations.
• The trustee private signing keys.

The distinction matters legally. A privacy policy that says “we will not disclose without legal process” is a policy commitment that an order can override. AION’s position is the stronger one: AION cannot disclose the items above, because no copy exists in any AION-controlled or AION-accessible system. Compelling AION to disclose those items is compelling AION to perform an act that does not exist in its repertoire. The doctrine of impossibility is pleaded affirmatively in response to any such order.

The proof is the cryptographic library, which will be published before any paid sealing. The fixture and network-invariant tests assert at every push that no plaintext, no key, and no answer leaves the user’s device. A change that broke the invariant would fail the test before merge. The library is held privately today pending the Phase 1 audit; on publication, the assertions above become independently verifiable. See Open-Source Code for the publication schedule.

If and when AION offers accounts, the data set below is what AION stores, in the protocol operator’s database, alongside the encrypted ciphertext. This is the entirety of the personal data set.

• Email address — used for authentication and operational notices. Stored in the protocol operator’s database. Retained for account life plus a 30-day grace period after deletion. Sent to the auth provider for verification only.
• Profile data you choose to add (display name, jurisdiction). Same retention as email.
• Encrypted vault ciphertext and routing metadata (which sovereign holds which shard index). Retained for the life of the vault, not the life of the account.
• Payment metadata (when offered). Held by Stripe under their privacy policy. Tax records retained for seven years per applicable law.
• Operational logs (request timing, error rates) without request bodies. Retained 30 to 90 days then auto-expired.
• Audit chain (who did what, when, on a vault you control). Retained for at least one year and up to seven if financial.

The AION website does not run third-party trackers. No advertising pixels. No session-replay tools. No analytics that ship raw event streams to a vendor. Cookies are limited to authentication and CSRF protection — the strictly-necessary category under the EU ePrivacy Directive Article 5(3) and the analogous categories under the UK PECR, the California CPRA, and the Brazilian LGPD. If AION ever adopts a privacy-respecting analytics tool, the change will be announced here, in advance, with the cookie banner enabled and the option to refuse without degrading the product.

A current sub-processor list will live at /sub-processors when accounts ship. Each entry will name the sub-processor, the data shared, the lawful basis, the cross-border transfer mechanism (Standard Contractual Clauses, adequacy decision, or analogous), and the privacy URL.

Cross-border transfers of ciphertext between AION and the seven sovereign holders are not transfers of personal data in the sense that triggers the supplementary-measure analysis: the ciphertext is, by construction, unintelligible to the recipient, and the recipient holds insufficient shards to reconstruct the encryption key. Where the regulator’s reading nonetheless treats ciphertext as personal data, AION applies Standard Contractual Clauses or analogous instruments by default and adds the architectural guarantee as the supplementary measure. No alternative supplementary measure can be more protective than the one the architecture already supplies.

AION publishes the warrant canary at /canary and the transparency report at /transparency. When AION receives a government request, the response is governed by the type of request and the gag attached to it:

• A request for data AION does not hold (plaintext, keys, answers): AION pleads cryptographic incapacity, supplies the source code as evidence, and offers expert testimony. No disclosure occurs because no disclosure is possible.
• A request for data AION holds (encrypted ciphertext, routing metadata, account email): AION evaluates the request against the law of the receiving jurisdiction, the Charter, and the user’s rights under that user’s domicile law. Compliance, where lawful and proportionate, is reported in the transparency report unless gagged.
• A request that AION introduce a backdoor, weaken a primitive, or maintain decryption capability: AION refuses, publishes the request unless gagged, and triggers Sunset on Notice for the affected sovereign per the Charter.
• A request gagged in a way that prevents publication: the warrant canary line for that instrument is removed in the next monthly cycle, the Self-Detonation Clause activates in the receiving jurisdiction’s entity, and the Successor Entity continues the doctrine.

You may request a JSON export of all the personal data AION holds about you under GDPR Article 15 (right of access), CPRA § 1798.110 (right to know), and the analogous provisions in the UK GDPR, LGPD, PIPEDA, and the New Zealand Privacy Act. The export contains profile, login history, audit log of your actions, and a payment-history summary.

You may request correction of inaccurate personal data (GDPR Article 16, CPRA § 1798.106, equivalent provisions) and deletion (GDPR Article 17, CPRA § 1798.105, equivalent provisions). The deletion flow is described on the Data Deletion page.

AION cannot export or delete a vault on your behalf. The vault is encrypted, distributed, and gated by the convergence doctrine. Only you (or your designated heirs through the unsealing flow) can recover or destroy the plaintext. AION can only destroy the ciphertext storage record on request, which makes the vault unrecoverable. Both options are presented in plain language at the moment of decision.

If AION discovers a breach affecting personal data, AION will notify affected users within 72 hours of confirmation, consistent with GDPR Article 33 and the analogous obligations in each sovereign jurisdiction. The notification includes scope, what is known, what is unknown, and the remediation taken. A public post-mortem follows resolution. AION will not delay disclosure to make the timeline look better.

A breach that affects the cryptographic primitives (rather than the operational surface) is treated additionally as a Charter event: the cryptographic audit cadence accelerates, the affected primitive is rotated, and pre-breach vaults are flagged for re-sealing under the new primitive in the user’s next session.

AION is in a pre-launch state. The sealedaion.com domain is live, but email forwarding may still propagate after MX setup, and the cryptographic library is held privately by the maintainer of record pending the Phase 1 audit. The role addresses below are published so routing is known in advance; mail may not be received until forwarding is verified.

The addresses below are the routing structure of the AION protocol. They are published now so the routing cannot be invented later.

• privacy@sealedaion.com — data-subject requests under this Policy.
• dpo@sealedaion.com — data-protection-officer correspondence, when a DPO is designated under GDPR Article 37 by a future Foundation.
• security@sealedaion.com — coordinated disclosure under the Security page.

A future Foundation will be the registered legal entity for AION (subject to the open jurisdictional question — see the Charter). Until that filing is complete, the operating contact is the AION maintainer of record through the GitHub channel above.