aere-node/AUDITS.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

63 lines
3.3 KiB
Markdown

# Security audits and reviews
**AERE Network has had no third-party security audit.** That is the first line of this page on
purpose, and it stays here until it is no longer true. Everything below describes what we have
verified ourselves, which is a weaker thing, and we do not want the difference blurred.
Last updated: 2026-09-01.
---
## External audits
| scope | auditor | date | report |
|---|---|---|---|
| — | none | — | — |
There is nothing to put in this table yet. When there is, the full report goes here, including any
findings we chose not to fix and why.
## What we have done instead, and what it is worth
- **Continuous self-verification.** The chain's live properties are re-measured automatically rather
than asserted in prose: validator set size, quorum, the post-quantum anchor threshold, the base-fee
floor, backup coverage, and the public verifier. A claim that stops being true shows up as a failed
check, not as stale documentation. This is real, and it is still *us checking us*.
- **Negative controls on every gate.** A check that has never been shown to fail is not evidence. For
each safety-relevant check we plant the defect it is supposed to catch and require it to go red,
then restore the source and require it to go green. A check that cannot fail is treated as broken.
- **A reproducibility package prepared for an external reviewer.** The consensus code under review,
a threat model naming the attack surfaces we consider realistic, a pinned reproduce guide, and a
manifest of file hashes. It is ready to hand over.
- **Independent verification by a second implementation.** The post-quantum anchor certificates on
the live chain are validated by a second client, written in a different language on a different
codebase, which reaches its own verdict on every anchor.
**None of that is an audit.** Self-verification finds the mistakes you thought to look for.
## Verify the chain yourself, without trusting us
The post-quantum anchor is designed so you do not have to take our word for it: 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 (Falcon-512, and from block 17,047,600 also SLH-DSA-SHA2-128s, at every
128th block since block 20,746,736), and the block hash covers it. Since block 20,715,632 that
certificate requires at least seven valid seals of each scheme, the full quorum of the ten
validators (six from block 14,961,456, six of nine validators then). The verifier is
public, the signatures are in the headers, and the check runs against any node — ours or your own.
## Reporting a vulnerability
Report to **security@aere.network**, or see <https://aere.network/security> for the full policy.
- We aim to acknowledge within 72 hours.
- Public credit on this page unless you ask to remain anonymous.
- We will not pursue legal action against good-faith research conducted under the published policy.
- If a report leads to a fix, the fix and the finding are published here together, including the
window during which the issue was live.
## What this page will never do
It will not describe a self-review as an audit, and it will not report a fix as complete before it
has been verified on the live chain. If you find a claim on this page that you can measure and
disprove, that itself is a valid security report, and we would like to receive it.