ea4ebcda5d
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>
49 lines
2.5 KiB
Markdown
49 lines
2.5 KiB
Markdown
# 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](https://aere.network/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](https://aere.network/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.
|