What AION cannot collect, and what proves it.
The premise of AION is that the company running the system cannot read user vaults. That is not a privacy promise; it is a property of the cryptography. This document describes the line in plain language, with the legal framing — cryptographic incapacity — that substantially narrows what any surveillance regime can compel, because the Operator that runs AION cannot produce what it never holds. We make no claim that any system is beyond all legal process.
Plain-language privacy notice
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.
Privacy by design and by default
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 cryptographic refusal
- The plaintext of any vault.
- The 256-bit AES key that encrypts a vault.
- A combination of shards sufficient to reconstruct a key. Under the planned Phase 3 holder network, the seven sovereign holdings will each receive only one shard, and AION will never aggregate them.
- The memory answer, in any form, for any vault.
- The trustee private signing keys, once the trustee mechanism ships.
Cannot, not will not
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.
What you tell us, what we keep
Today AION has no accounts, no login, and no dashboard. The website is a set of public pages plus a local-only prototype at /seal and /unseal that runs in your browser. What AION actually collects today is limited to:
- What you choose to send when you contact AION through the private-session request page — for example an email address and what you write. Used only to reply. Do not send seed phrases, private keys, shards, passwords, or other secret material.
- Payment data for the founder-reviewed paid sessions: card data is handled solely by Stripe and AION never sees or stores card numbers. AION does retain limited billing metadata — Stripe customer, subscription, and charge identifiers and your billing email — to meet tax, accounting, and chargeback-dispute obligations, generally for up to seven (7) years. This metadata is unrelated to Vault contents, which AION never receives.
- Standard request logs kept by the hosting platform (timing, status, coarse diagnostics) without request bodies — a byproduct of serving the pages, not an AION application server. AION runs no third-party analytics, advertising pixels, or session-replay.
- Your vault never leaves your device in plaintext. Sealing and unsealing happen locally in your browser; AION receives ciphertext only if and when you choose to route it.
Future account features are not live. If AION later offers accounts, the additional data set below would apply, and this notice will be updated before any of it is collected: account email and profile (display name, jurisdiction), encrypted vault ciphertext and routing metadata, Stripe payment metadata, operational logs, and an audit chain of actions on a vault you control. None of it is collected today.
How long AION keeps what it keeps.Vault storage records, if you route ciphertext, carry a 24-hour grace window before destruction becomes irreversible; AION holds no plaintext, key, or answer to retain. Stripe billing metadata (customer, subscription, and charge identifiers and your billing email) is retained for up to seven (7) years to meet tax, accounting, and dispute obligations. Contact correspondence is kept only as long as needed to answer you and document the exchange. Hosting request logs are retained per the hosting provider’s default and carry no request bodies. When accounts later ship, account email and profile will follow a 30-day deletion grace before permanent erasure.
Why AION is allowed to process each item.For users to whom the GDPR or UK GDPR applies, AION’s lawful bases are: performance of a contract (Article 6(1)(b)) for the correspondence and payment processing needed to run a founder-reviewed session you requested; compliance with a legal obligation (Article 6(1)(c)) for the billing and tax metadata AION must retain; and legitimate interests (Article 6(1)(f)) for the minimal, request-body-free logging that keeps the service secure and available. AION processes no special-category data and runs no profiling or automated decision-making.
Strictly-necessary, by default
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. Because there are no accounts and no login today, AION sets no authentication or session cookies; any cookies are limited to the strictly-necessary category (for example CSRF protection on a form you submit) 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 or ships login, the change will be announced here, in advance, with the cookie banner enabled and the option to refuse without degrading the product.
Schrems II, made redundant by architecture
The current sub-processor list lives at /sub-processors — today: Stripe (payments), Vercel (hosting), and EForw with Google Gmail (inbound email routing). Each entry names the sub-processor, the data shared, the region, and the privacy URL; none ever receives Vault plaintext, keys, or unseal-sufficient material. Where a provider processes data outside your region, that transfer relies on the standard contractual clauses or equivalent safeguards in the provider’s own policy, with the architectural guarantee as the controlling supplementary measure.
Under the planned Phase 3 holder network, cross-border transfers of ciphertext between AION and sovereign holders will not be 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.
What happens if a government asks
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.
Export, deletion, correction, and the limits
You may request a copy of 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. Today that is limited to any contact correspondence you sent and a payment-history summary for any founder-reviewed session you paid for (the payment record itself is held by Stripe). When account features ship, the export will also include account profile and the audit log of your actions on a vault you control.
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.
Children. AION is not directed to children. It is intended only for adults arranging the inheritance of their own material, and AION does not knowingly collect personal data from anyone under 16. If you believe a minor has contacted AION, write to mail@sealedaion.comand AION will delete the correspondence.
EU and UK users. AION does not target or offer its services to individuals in the European Union or the United Kingdom, and the Operator has not appointed an Article 27 / UK GDPR representative. EU and UK residents who choose to use AION do so on their own initiative; where the GDPR or UK GDPR nonetheless applies, the rights and lawful bases above govern, and requests are received at mail@sealedaion.com.
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.
What happens if something fails
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.
Where to write
Data-subject and deletion requests under this Policy, and all other privacy correspondence, are received today at mail@sealedaion.com, which is monitored. Do not include seed phrases, keys, shards, or any secret material. The @aion.foundation role addresses below are the future routing structure and are not currently deliverable.
AION is in a pre-launch state. The aion.foundation domain is reserved, but DNS and email forwarding are not verified, and the cryptographic library is held privately by the maintainer of record pending the Phase 1 audit. Until those milestones land, the role addresses below are not verified legal/security mailboxes. AION would rather show this gap honestly than invent a channel that does not exist.
The addresses below are the future routing structure of the AION protocol. They become live only after DNS and email routing are verified. Mail sent to them today may not be received; they are published so that the routing is known in advance and cannot be invented later.
Private-session interest is routed separately through the no-payment request page; do not send seed phrases, private keys, shards, answers, or plaintext through any contact channel.
- privacy@aion.foundation — data-subject requests under this Policy.
- dpo@aion.foundation — data-protection-officer correspondence, when a DPO is designated under GDPR Article 37 by a future Foundation.
- security@aion.foundation — coordinated disclosure under the Security page.
AION is operated today, and all fees charged, by TechBantu IT Solutions, LLC (the “Operator” — see Terms §1). A successor foundation is contemplated as the future IP-holding entity (subject to the open jurisdictional question — see the Charter); until it is formed and published, the Operator is the responsible legal entity and is reachable at mail@sealedaion.com and through the private-session request page.