Report a vulnerability by email:

Please include what you found and why it matters, how to reproduce it (a minimal case and the affected commit, tag, or release artifact), and the impact you believe it has. We aim to acknowledge within 3 business days, to keep you updated as we assess and fix, and to coordinate public disclosure with you. Please don't open a public issue for a suspected vulnerability. If you'd like to encrypt your report and don't have a key from us, say so in a first non-sensitive email and we'll arrange it.

• The Sovereign Substrate codebase — the sealed core, the hand-written Ed25519 / SHA-512 cryptography, the boot-authority chain, the firmware and wire parsers, and the gate that certifies the tree.
• The public verifier (substrate-verify) and the free-tier boot / verify artifacts.
• The website phoenixforgefoundation.org.

We are especially interested in: forging a valid attestation or boot authorization without the Master Root private key; any signature-verification bypass; memory-safety defects in the boot chain or the parsers; a way to make the gate report green over a real invariant violation; and anything that falsifies a claim the documentation asserts as proven.

• The free tier is keyless by design (AUTH:NONE, custody = possession) — it claims possession, not authority. That is the design, stated on the wire.
• On writable media the boot gate is tamper-evidence, not an unforgeable root — use a hardware write-protected drive for a root of trust. Disclosed on every report.
• RDP = 0 on development hardware: the on-chip seed is physically readable. Disclosed; hardening is tracked, not hidden.
• The signer's non-constant-time timing side-channel is publicly scoped (ADR 0034).
• The verifier and the trust anchors are public by design (Kerckhoffs's principle). Publishing the public keys is the mechanism, not a leak; the security lives in private keys held in hardware custody that never enter any repository. "The code or the anchor is public" is not a finding.

But if you can show a disclosed ceiling is worse than we claim — a way to defeat hardware write-protection, to read the seed without physical access, or to break the constant-time work once it ships — that is in scope, and valuable.

We will not pursue or support legal action against research that stays within the scope above, uses only your own hardware, drives, and keys — never someone else's deployed unit or data — avoids privacy violations, service disruption, and data destruction, and gives us reasonable time to remediate before any public disclosure. If in doubt about whether an action is authorized, ask first at the address above.

We will work with you on a disclosure timeline and target a fix within 90 days of a confirmed report, sooner where we can. We are glad to credit you by name or handle — or to keep you anonymous if you prefer.

• /.well-known/security.txt — the RFC 9116 security contact.
• SECURITY.md in the public verifier. This page is the canonical copy of the full policy.