aere-network/aere-node
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ea4ebcda5d
aere-node/SECURITY.md
Aere Network ea4ebcda5d AIP-22 stages 1 to 3 on chain 2800 in the node package; verifier no longer prints the stage-5 sentence on chain 2800 
README, SPEC, RUN-A-NODE, SECURITY, AUDITS and anchor/README now state the live rules: at least seven of
ten seals per scheme from block 20,715,632 (stage 1), Falcon-512 at every 32nd block and SLH-DSA-SHA2-128s
at every 128th from block 20,746,736 (stage 2), post-quantum validator ids in the header and in
qbft_getValidatorsByBlockNumber from block 20,836,228 (stage 3). Stages 4 and 5 are not active on chain 2800.

tools/verify-anchor.mjs: the FINALIZED line said on every chain that a header between anchors carries only
its proposer's seal, which is true only where AIP-22 stage 5 is active (testnet 28001). It now reports what
it measured: on chain 2800 headers between anchors carry the validators' classical ECDSA commit seals.
Checked on both chains on 2026-10-01: chain 2800, 4/4 anchors verified, ECDSA branch printed; testnet 28001,
2/2 anchors and 20/20 proposer seals verified, stage-5 branch printed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-01 13:27:11 +03:00

2.5 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 (every 128th from block 17,225,968 to block 20,746,736) carries a post-quantum certificate under the block hash (Falcon-512, and from block 17,047,600 also SLH-DSA-SHA2-128s, at every 128th block since block 20,746,736), requiring at least seven valid seals of each scheme since block 20,715,632, the full quorum of the ten validators (six from block 14,961,456, six of nine validators then). 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.