Coordinated disclosure, safe harbor, public credit.

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.

• security@sealedaion.com — coordinated security disclosure; forwarding may still propagate after MX setup.

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 four AION primitives (the AES-256-GCM and Shamir sealing primitive, the sequential-SHA-256 time-lock primitive, the Argon2id memory-layer primitive, and the convergence composition) and the client flows that compose them.
• 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.
• Authentication, session, and CSRF flaws on the AION website and application.
• 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.

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.