aere-network/aere-node
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
9fd694b888
aere-node/SECURITY.md

2.4 KiB
Raw Blame History

Security policy

Reporting a vulnerability

Report privately to security@aere.network. Do not open a public issue for a security problem.

  • We aim to acknowledge within 72 hours.
  • We will tell you whether we consider the report in scope, and why, within 7 days.
  • We will not pursue legal action against good-faith research conducted under this policy.
  • Public credit on AUDITS.md unless you ask to stay anonymous.

The canonical, always-current policy is https://aere.network/security, and the machine-readable pointer is https://aere.network/.well-known/security.txt.

In scope

  • Consensus for AERE chain 2800: the QBFT implementation, the post-quantum anchor certificate, and the post-quantum layers on consensus messages.
  • The post-quantum precompiles (0x0AE1–0x0AE5) and the code that dispatches to them.
  • Node RPC surfaces exposed publicly.
  • Solidity contracts deployed by the Foundation.

Out of scope

  • Denial of service by traffic volume against public endpoints.
  • Findings that require physical access to Foundation hardware or a Foundation private key.
  • Reports generated by automated scanners with no demonstrated impact on this chain.

What we will tell you honestly

  • There has been no third-party security audit of this project. See AUDITS.md. Everything verified so far is us checking ourselves, which is weaker, and we do not describe it as an audit.
  • All validators are operated by the Foundation. The number of independent parties who would have to agree to halt this chain is one. No amount of cryptography changes that number, and a report pointing at the consequences of that fact is in scope and welcome.
  • The post-quantum guarantee is at anchor heights, not on every block: from block 13,014,000, every 32nd block, and from block 17,225,968 every 128th, carries a post-quantum certificate under the block hash (Falcon-512, and from block 17,047,600 also SLH-DSA-SHA2-128s), requiring at least six valid seals of each scheme from block 14,961,456 (six of nine validators then, of ten since 2026-09-11). Blocks between anchors rest on ECDSA. We correct over-claims publicly when we find them, and we have done so before.

Fixes

When a report leads to a fix, we publish the finding, the fix, and the window during which the issue was live — including anything we chose not to fix, and why.