Coordinated disclosure, safe harbor, public credit.

Coordinated security disclosure is received today at mail@sealedaion.com, which is monitored. A PGP key is forthcoming; until it is published, send your report unencrypted, or ask in your first message and the maintainer will exchange keys before you send anything sensitive. Do not transmit seed phrases, private keys, shards, or plaintext. Role addresses at aion.foundation are reserved for a future entity and are not yet deliverable.

Provide a reproducible report — steps, expected behavior, actual behavior, the version or commit hash you tested against. If you have a proof-of-concept, attach it; do not publish it before AION acknowledges the report.

• Cryptographic flaws in the AION client flows that compose the AES-256-GCM and Shamir sealing layer, the sequential-SHA-256 time-lock layer, and the Argon2id memory layer — as observable in the shipped client. The underlying crypto library is not yet published; review what the client actually runs, not internals that are not public.
• Network-side flaws that would cause plaintext, the memory answer, or a sufficient combination of shards to leave the user’s device.
• Supply-chain or build-pipeline weaknesses that would allow a malicious release of the AION client.
• Web-delivery integrity flaws on the AION site — anything that would tamper with the client served to the user (for example, a malicious or substituted build reaching the browser). The client-only v1 has no accounts, no login, and no server sessions, so there is no auth or session surface to test yet.
• Subdomain takeover, dependency-confusion attacks, or exposed secrets in public artifacts.

• Issues that require a malicious browser extension, physical device access, or root on the user’s machine. Those are not AION-defended.
• Theoretical attacks on the underlying primitives (AES-256-GCM, Shamir’s SSS, Argon2id, Ed25519, X25519) that do not describe a path executable today. Report them to the primitive’s maintainer.
• Volumetric denial-of-service. AION operators apply standard mitigations; large-scale traffic attacks are not in scope for this program.
• Issues already publicly disclosed or already in AION’s issue tracker, except where the report adds materially.
• Findings derived from social engineering of AION staff or other users.

AION will not pursue legal action against a researcher who reports a vulnerability in good faith, who does not exfiltrate user data beyond what is required to demonstrate the issue, who does not publish the issue before AION has acknowledged it, and who follows the timelines below. For such good-faith research that stays within this policy and respects user privacy, AION will not initiate or support action under the Computer Fraud and Abuse Act (CFAA) or under Section 1201 of the DMCA, and will treat this policy as authorization for that testing.

AION will acknowledge a report within five working days, provide a triage outcome within fifteen working days, and a fix or accepted-residual-risk decision within ninety days from acknowledgement. AION will credit the researcher publicly in the transparency report unless the researcher requests otherwise.

AION asks for a ninety-day embargo from the date of acknowledgement before public disclosure of an unfixed cryptographic flaw. If a fix lands earlier, the embargo shortens to the fix-plus-fourteen-days window so users have time to upgrade. If AION misses these windows, the researcher is free to publish.

AION does not buy silence. If a vulnerability is fixed, the fact of the vulnerability and the resolution are reported in the transparency report.

AION does not yet operate a paid bounty program. Once the Endowment is funded and the Charter is filed, a bounty schedule will be published here with severities and amounts. Until then, public credit and a thank-you in the transparency report are the recognition AION can offer. Researchers who want their finding kept confidential beyond the report will be honored in that preference.