Both are prerequisites for any external review programme, and one of them was already
promised by our live security.txt to a file that did not exist.
SECURITY.md states the scope, the response times we hold ourselves to, and three things
we would rather a reviewer heard from us than discovered: there has been no third-party
audit, every validator is operated by the Foundation, and the post-quantum guarantee is
at anchor heights rather than on every block.
AUDITS.md opens by saying we have had no third-party audit, and keeps that first line
until it stops being true.
The network layer authenticates peers by their secp256k1 node key, and consensus
messages are routed by the address derived from it. An adversary who recovers a
validator's ECDSA key therefore gets everything the transport can give: it completes
the handshake as that validator and signs syntactically perfect messages that recover
to its address. This test models exactly that adversary - full ECDSA compromise, no
Falcon key - and requires all four hot-path messages to be refused while the
post-quantum enforcement is armed, with a harvested seal replayed across message
kinds, blocks, heights, rounds, chains, and from another validator entirely.
The honest form of the claim: the transport is not post-quantum, and breaking it
does not buy a break of safety. It says nothing about liveness.
One shared harness for both surfaces (the twin-class lesson applied in advance):
a seal made with SLH-DSA passes through the same untouched consensus code, and a
Falcon seal against an SLH-DSA registry is refused on both surfaces. The Falcon
nail sits only in the production wiring, for all three message enforcements.
Twelve test classes existed twice, under a neutral name and under an internal
inventory name, ~4,600 duplicated lines. Two copies of the same proof diverge
silently: one receives a repair and the other does not - which is exactly what
happened once, and what the cache-hygiene test below documents. The neutral
names survive; per pair the test counts are identical, and the only code
difference (a warm-up window constant) exercises the same path and the same
assertion. The cache-hygiene reproduction now runs the surviving class's
lifecycle, unchanged in what it asserts.
The last hot-path QBFT message under the same pattern as prepare and proposal:
its own domain AERE-PQ-ROUNDCHANGE-1 over (chainId, height, targetRound, prepared
metadata - so a bare 'move on' seal cannot be replayed as 'move on and re-propose
THIS block'), a separate emission gate (aere.pq.roundChangePq.attachBlock), a
separate enforcement height (aere.pq.roundChangePq.forkBlock) self-wired into the
payload validator so it also judges round-changes inside proposal justifications,
and byte-for-byte upstream encoding when no seal is present. The seal is signed
once and the same object goes on the wire; Falcon signatures are randomised, so
a re-signing would put a different message on the wire than the one handled
locally.
The first witness run caught a real gap: the proposal was signed twice - once for the
local copy, once for the wire - and only the local copy carried the proposer's Falcon
seal. Locally sealed, unsealed on the wire: with enforcement armed, the fleet stopped at
the enforcement height even though every node was emitting. Falcon signatures are
randomised, so the fix is structural rather than cosmetic: the proposal is built once,
seal included, and the transmitter sends that same object - two signings would produce
two valid and different proposals from the same proposer.
A new plumbing test refuses the defect's return: it fails if the transmitter's wire path
ever builds its own payload again. On the test network after the fix: emission covered
seven of seven proposers, each sealing exactly its first proposal past the gate; with
enforcement armed and emission on, the chain crossed the enforcement height with zero
refusals; with emission off it stopped exactly one block short of the height, every
refusal logged; and one unarmed node could not keep the chain alive.
Still armed nowhere: the properties are unset, and unset means never.
The remaining hot-path gap, stated precisely because the imprecise version oversells: with
PREPARE enforcement armed, an ECDSA-breaking adversary cannot finalize anything, since
"prepared" needs a full quorum of PREPAREs. What forged proposals could still do is OPEN
rounds and waste them. With proposal enforcement armed, a proposal without a valid Falcon
seal from its own proposer does not open a round.
Same pattern as the PREPARE layer, deliberately: an optional fifth payload element that
leaves the unsealed encoding byte-identical to upstream; a third, separate emission gate;
enforcement self-wired in the payload validator so no refactor can drop it silently; its
own domain over (chainId, height, round, digest), tested in both directions so an honest
offer seal cannot be replayed as a vote nor a vote seal as an offer.
Nothing is armed anywhere: the properties are unset, and unset means never. The armed-
layers table in the README says so, and says what stays classical: the ROUND-CHANGE
message itself and node-level devp2p authentication.
1,042 tests, 0 failures, counted from the XML. The enforcement's negative control ran at
5 of 5: four planted defects each turned the suite red, the untouched source stayed green.
D140FleetRestartArmingTest did not clear the aere.pq.* properties and the per-JVM anchor
config cache in setUp, while its twin PqFleetRestartArmingTest has done so since 20 August
2026. Without it the class is green on its own and red inside the full suite, on identical
sources, because a neighbouring class leaves an armed anchor config cached.
That is the concrete cost of keeping two copies of a test: a repair lands in one and not
the other, and nothing fails to say so.
1,012 tests, 0 failures.
The first publication of this directory, on 11 August 2026, was staged by hand and was
never refreshed. Measured on 29 August: of the 78 files published here, only 14 were still
identical to the tree we run, 63 had changed, and 50 files had never been published at all.
Nobody was hiding anything; there was simply no tool that could redo the selection, so
nobody redid it. There is one now, and it derives this directory from the authoritative
overlay rather than from anyone's memory.
Two things in here contradicted themselves, and both are fixed rather than trimmed.
The README withdrew, in one section, a claim that the source next to it still made: that
from block 14,050,000 a per-block 2f+1 Falcon quorum was required for a block to finalize.
The rule that property arms is retired at the anchor block, so it was inert on arrival.
Three places in the code said otherwise and now carry the correction with its date. The
old text is kept, not deleted: the rule is real code and can be armed on a chain that never
reached an anchor block. What was missing was that on chain 2800 it does not apply.
The terminology section said the certificate is signed by f+1 validators and "not by a
quorum", and invited the reader to count. Since 14,961,456 the enforced minimum is six of
nine, which is a quorum, and the paragraph had not been revised. It now says so, with the
date it changed, and adds the two things that make the claim defensible: the word applies
only at anchor heights, and the higher threshold costs liveness margin.
New in this directory: the post-quantum seal on PREPARE, the hybrid Falcon + SLH-DSA scheme
layer, and the test suites for both. Neither is armed on any network, and the README now
carries a table saying which layers are armed on chain 2800 and which are only present.
They are disarmed by absence rather than by a flag: the properties that arm them are unset,
and unset means never.
Not published, and it is the same three files every time: the negative-control harnesses.
They plant a defect on purpose to prove a guard can fail, which makes them a recipe for
disabling a guard rather than a description of one. What they prove is stated in the README.
Per-file SHA-256 in MANIFEST-sha256.txt. 1,012 tests, 0 failures, counted from the XML.
Line 23 stated the enforced minimum is six of nine, a full 2f+1 quorum. Line 192 stated
the certificate is signed by f+1 validators, not by a quorum, and that we do not call it
one - inviting the reader to count. The terminology paragraph was written when the
threshold was three, where it was true, and was not revised when the threshold was raised
on 21 August 2026. A document that asks to be counted and does not survive the count loses
more than the paragraph.
Corrected without deleting the distinction, and with the two things that were missing and
without which the claim is not defensible: the word quorum applies only at anchor heights,
about every 32nd block, and the blocks between them carry no Falcon seals at all; and the
higher threshold costs liveness margin, since at six of nine three late validators stall an
anchor block where three of nine tolerated six.
Not pushed. Publishing is the founder's decision.
Founder approved publishing the network entry points. Both are public read hosts
outside the validator set, so their downtime cannot cost consensus, and their
addresses were already public through the services they serve. One runs Besu and
one runs Nethermind, so a new node's first two peers are two independent
implementations. run-node.sh uses both by default; --bootnode still overrides.
The mail path stays as fallback for the day both are down.
This closes the last gap between "one command plus an email" and one command.
One document from which a third party can implement a client that follows chain
2800 without reading our code: chain parameters, QBFT with the full extraData
layout and what the block hash does and does not cover, the post-quantum anchor
rules with exact pre-images and the follower configuration, precompile formats
with the message in the middle and variable signature lengths, fee rules with
their historical windows, sync requirements including the genesis-set ceiling,
and the formal models with their honest boundaries.
Every normative statement carries a file citation, a [MEASURED <date>] marker
with the command, or [NOT MEASURED]. Section 8 documents twelve dated
divergences a syncing client will meet on the real chain (the 2138451 transition
value that must not be corrected, the base-fee lapse window, the anchor disarmed
window, the threshold window, the retired falcon.forkBlock rule), because a spec
that hides history cannot sync anyone. Section 9 lists ten things this spec
cannot state from published sources, by name, rather than papering over them.
run-node.sh folds the four manual steps (apply patches, build the fork, load the
registries, set BESU_OPTS) into a single deterministic, idempotent command. It
verifies the genesis sha256 and every registry against SHA256SUMS and refuses on
mismatch; applies patches 0001,0003,0004,0005 on a pristine upstream checkout
(0002 testnet excluded) with a reverse-apply idempotence check; builds with
installDist; starts a follower with the correct BESU_OPTS. It holds no key.
The registries a from-genesis follower needs were missing from this package, only
the code that reads them was here, so nobody outside could cross block 13,014,000.
Added them as public data (Falcon public keys, validator addresses, possession
proofs; no private material), byte-identical across three independent validators,
with SHA256SUMS and a provenance README. Secret gate passes.
Proven from a fresh git clone in WSL, as a stranger: built (BUILD SUCCESSFUL),
idempotent on re-run, started, loaded all three registries with verified
possession proofs, block-0 hash equals the network genesis, and synced from block
0 with zero anchor rejections and zero stateroot mismatches.
A real finding this test surfaced, fixed and documented: a from-genesis node
starts into the genesis validator set N=3, where the published seal schedule
(K=3 at 13,034,000, K=6 at 14,961,456) is unreachable, so PqAnchorThresholdGuard
refuses to start. The fix baked in is the guard's own documented remedy,
minSealsCeiling=1, which relaxes only the seal-count floor (a proposer-liveness
property) without weakening the PQ binding: every anchor still needs a valid
registry-verified Falcon seal. A validator does not set this.
Honest limit: crossing 13,014,000 was not reached in-session because the two
public bootnodes serve historical block bodies at only ~7 blk/s sustained (ETA
~19 days), and syncing bodies from validators would breach the read-only fleet
rule. The crossing rests on these registries being byte-identical to those in the
Aug 15 import proof that reached the live tip.
Reaching the tip needed two historical facts encoded, and the second one was
not in the original hypothesis.
First, the disarmed window: 36 anchor heights (13,267,824 to 13,268,944) whose
blocks carry an attached certificate but no digest, and whose signer indices are
not strictly increasing, produced while anchoring was disarmed fleet-wide to
unblock the chain after an incident. Encoded as a named list of historical
windows with fixed bounds in code, after the precedent of the base-fee lapse
windows: inside, the header is accepted as written; outside, nothing changes.
Second, the recovery, found by measuring rather than guessing. After the
emergency re-arm the fleet ran for a stretch with a lowered seal threshold, so
proposers legitimately wrote shorter certificates. Its extent was measured by
reading 25,252 anchor heights one at a time, with NO binary search, because the
property is not monotone: only about 15 percent of heights are affected and the
largest gap between two affected heights is 44, so a binary search would have
returned an answer that looks exactly like a good one. Result: 13,268,976 to
13,890,544, thresholds measured at 1 or 2, never 0.
The second window relaxes the seal COUNT only. Digest binding and index
ordering stay enforced and every seal is still verified. Widening the disarmed
window to cover both would have been easier and would have thrown away
certificate binding on 19,425 anchor heights, which is the one property the
anchor exists for.
Negative control in four directions, because an exception can fail both ways:
the window predicate forced always-false turns 10 tests red; forced always-true
turns 39 red, of which 22 are pre-existing strictness tests, making the
exception swallowing the chain visible; the historical threshold emptied turns 7
red; pinned at 1 turns 8 red. Restored: 641 tests, 0 failures, counted from XML.
Patch verified on a pristine upstream checkout, alone and in series, and the
resulting tree compiles.
Measured on the live chain by reading vanityData block by block: the last
anchor carrying a digest before the window is 13,267,792; heights 13,267,824
through 13,268,944 (37 anchor heights) carry the ordinary client string instead
of a digest; the digest resumes at 13,268,976. All 37 still carry an attached
seal certificate (2,620 to 3,282 byte headers), which is direct on-chain proof
that seal attachment and digest anchoring are two independent switches and were
in different states here.
What happened: several validators restarted inside a short window and were all
left holding no heard seals at the same time, while the next height was an
anchor height with a seal threshold, so no node could propose. Unblocking meant
disarming the anchor fleet-wide, which restarted block production immediately.
Blocks produced while disarmed also carry signer indices that are not strictly
increasing, because canonical ordering is applied on the anchoring path.
Why it matters to anyone running a node: those 37 heights are real, immutable
chain history. A node syncing from genesis meets them and correctly refuses
them if it carries a single anchoring configuration; nodes that were already
running do not stumble because the blocks are already in their database and are
not revalidated. So the package needs the historical disarmed windows, named
with exact bounds, in which the anchoring rules accept the header as given,
exactly like the base-fee lapse windows the second client already carries. The
fix is in progress; until it is proven by import past the window, this section
states the limit rather than hiding it.
The published patch carried a one-block boundary defect: the seal rule asks the
index-to-address map at the parent height (H-1) while the registry schedule
binds inclusively from H, so at the very first anchor the schedule was empty and
the lookup fell back to a head map that is empty on a node synced from genesis.
A valid certificate was rejected. Fixed in both lookup paths: when the schedule
has an entry at exactly blockNumber+1, answer from that entry's verified bound
registry. The boundary stays exactly one block.
Proven by import, not by assertion: the package-built node was stuck at
13,013,999 with 6,646 rejections; with the fix it crossed 13,014,000 in 42
seconds and imported 253,729 further blocks through the anchor era with zero
rejections. Tests: new PqParentHeightAlignmentTest 3/3, consensus:common 391/0,
consensus:qbft 217/0. Negative control measured: disarm the condition and the
measuring test goes red; restore it and it is green.
Patch verified to apply cleanly on a pristine upstream checkout, alone and in
series with 0001/0004/0005; file list is the previous 75 plus the new test, and
every untouched section is byte-identical to the old patch. The anchor/ source
copy in this package was brought to the same state so the two cannot diverge.
Honest limit, recorded in IMPORT-PROOF-STARE: further along, at 13,267,729, the
node stops again for a DIFFERENT reason. Blocks in a band there carry an
attached certificate whose vanityData is the ordinary client string rather than
the digest, at heights a single static interval treats as anchor heights. The
best-supported reading is that the fleet ran a different anchoring configuration
in that window (these values are not consensus-bound), so the package needs a
HISTORICAL anchoring schedule, not one value. Stated rather than implied.
A from-genesis sync of the patches-only build reached the first real anchor
(13,014,000, certificate index 0) and was rejected there: PqAnchorSealsRule
says index 0 is unbound, though the registry the node itself bound contains
key 0 and production validates the same block. Two paths over one registry
that disagree. Fix (align the index->address mapping in 0003 with production
source) needs a dedicated binary session with a negative control. Written
honestly; RUN-A-NODE already flags the build as a follower until a full
import proof. Trying the proof for real found the missing link in one evening.
A from-genesis sync of a patches-only build stopped at block 9,189,161, the
futureEipsTime activation, with a stateroot mismatch. Two causes, one patch:
upstream bases futureEips on the unreleased amsterdam definition while chain
2800 isolates it on Osaka, and the fleet activates EIP-2935 history storage in
the same fork, one system state write per block that a build without this
patch never performs. With 0005 applied the same node, same data directory,
crossed the activation and keeps importing. The fleet's optional Block-STM
wiring is deliberately omitted and the omission is stated in the patch header.
Pristine d2032017, plain git apply of 0001+0003+0004, installDist exit 0 on
JDK 21, besu/v26.8-develop-d203201. Stated next to what it does not prove:
the import proof against the live chain is still owed.
The licence-note edits had normalized whitespace inside hunks, so the recipe
this repository tells its reader to run failed at step one with 'patch does
not apply'; only --ignore-whitespace passed, and the README nowhere says to
use it. Each patch was re-applied to pristine d2032017 with whitespace
tolerance, then regenerated from the resulting tree with its prose header
kept, and the full sequence 0001, 0003, 0004 was applied with PLAIN git
apply on a fresh pristine checkout before this commit was made.
A Windows checkout was silently rewriting genesis.json to CRLF, so the
working-copy hash stopped matching the published and fleet hash, and the
package gate went red on a file whose bytes in git were correct. bd4f8b4
fixed this once by re-adding the file; this pins the rule so no checkout
can undo it again.
The table carried the hash of an earlier derived export; the published file
has been the fleet's byte-for-byte genesis since the registry-binding commit.
The line-ending caveat is written next to it because that is exactly how the
wrong hash survives review on a Windows checkout.
The published line delivered the anchor (source and patch 0003) but had lost
the chain configuration: no genesis, no run recipe. The unpublished local line
had genesis.json, RUN-A-NODE.md and the measured claims, but predated the
anchor. This commit carries the package files onto the anchor line:
- genesis.json restored, byte for byte as the running nodes hold it
- RUN-A-NODE.md restored; the basefee-floor patch returns as 0004; the anchor
section states plainly that a build without patch 0003 has not been shown to
import headers past block 13,014,000, and that an import proof for a
patches-only build is the next thing this repository owes its reader
- bootnodes are deliberately NOT published: today's entry points are consensus
or origin hosts, and this project does not print its machines' addresses; a
dedicated bootnode host is the planned replacement, an enode is available by
mail until then
We went and read the field instead of asserting into it, and two things in the
README were saying more than the literature supports.
The attack has a name we were not using. It is posterior corruption, also called
the founders' attack, long-range attack, history revision or costless simulation.
Tas, Tse, Gai, Kannan, Maddah-Ali and Yu (arXiv 2207.08392) survey the four known
mitigations: social consensus, key-evolving signatures, verifiable delay
functions, and timestamping onto a proof-of-work chain.
That paper proves an impossibility, and the previous wording here would have read
as if we had stepped around it. We had not, because it says something narrower
than it first appears: slashable safety, which is safety plus the ability to
punish the attacker, needs an external trusted source. Plain safety against
posterior corruption does not, and key-evolving signatures are shown to give it
under an honest majority. This anchor does not claim slashable safety and the
README now says so.
What it does claim is now stated where it is actually strong. Key-evolving
signatures rest on an old key being gone once deleted. A quantum adversary does
not need it to have been kept: QBFT headers carry addresses, but every seal is an
ECDSA signature from which the public key is recoverable, and from that the
private one. Deleting the key buys nothing when the chain reconstructs it. The
certificate under the block hash still has to be forged, and that needs a secret
no amount of computation derives from the chain.
So this is the post-quantum analogue of what key-evolving signatures give
classically, in the setting where their central assumption is void. Narrower than
checkpointing, and borrowing nothing from another chain. Both true at once.
Sources opened and checked, not recalled: arXiv 2207.08392, eprint 2019/1440,
arXiv 2208.05408.
We cite Azouvi, Danezis and Nikolaenko's "Winkle" for the threat this anchor
addresses. Today we opened the paper instead of repeating the citation, and two
things need saying, because a reader who opens it will notice both.
Winkle does not mention quantum adversaries anywhere. It treats old validator
keys becoming compromised, by any means. The quantum framing is ours.
And Winkle's defence is not this one. It adds a secondary layer of client-based
validation in which clients sign a hash of the previously sequenced block. The
same authors' later work, Pikachu, checkpoints into Bitcoin instead. Both are
established answers to this threat, and a reader weighing our design deserves to
be pointed at them rather than left to find them.
So the README now says it plainly: the threat has peer-reviewed grounding, the
defence in this repository is ours, and the honest difference from checkpointing
is that checkpointing borrows security from another chain while this borrows
nothing.
Citations verified at source, not from memory: eprint.iacr.org/2019/1440, AFT
2020 pp. 189-201; arXiv 2208.05408, 2022.
Caught by our own licence gate the minute the anchor went up, which is the only
reason this is a same-day correction rather than something a reader finds first.
Two separate requirements, both real:
- section 4(b): the twenty upstream files this overlay modifies must carry a
prominent notice that we changed them. They did not. They do now, placed after
the upstream copyright header rather than over it, because 4(c) requires that
header to survive untouched. It does: eighteen still read "Copyright ConsenSys
AG.", two "Copyright contributors to Besu."
- section 4(d): NOTICE must carry the attribution notices of the work this
derives from. It named Hyperledger Besu only, while the files themselves carry
three distinct notices. All three are now reproduced. Naming one of three was a
smaller truth than the files tell.
The patch is regenerated from the corrected files and re-verified end to end, not
assumed: git apply --check and git apply both 0 on a pristine d2032017 checkout,
the resulting tree byte-identical to anchor/ (75 files compared, 0 differences),
and 605 tests with 0 failures across consensus:common and consensus:qbft.
This repository argues, in its own README, that a patch against a named upstream
commit is the honest way to publish a contribution to a million-line project: the
diff is the contribution, the reader fetches the rest from upstream, and a patch
fails loudly when upstream moves while a whole file overwrites in silence.
The anchor was published as whole files only, which contradicted that argument.
It is now both: patches/0003 to apply, anchor/ to read.
Verified on a pristine d2032017 checkout rather than assumed:
- git apply --check and git apply both returned 0
- the resulting tree is byte-identical to anchor/: 75 files compared, 0 differences
- :consensus:common:test and :consensus:qbft:test returned 605 tests, 0 failures,
the same count class by class as the same tree built from the files
The README also said "no build file changes are required" in a place that now
reads as if it covered all three patches. It covered the first two. Patch 0003
changes one build file by one line, and that line is named.
This is the code that puts a post-quantum validator certificate under the block
hash. It is the thing this project exists to do, and it is published so that the
claim can be checked rather than believed.
What it is. In QBFT the block hash is computed over a re-encoding of the decoded
extraData with the seals removed, so anything the decoder does not know about is
dropped before hashing. Appending a certificate as a new element gives you a
certificate that is stored, gossiped, and entirely absent from the hash. The
design that works instead puts a 32-byte digest of the certificate into
vanityData, which is already under keccak. anchor/README.md sets out the four
designs that died before this one and why.
Scope, stated in the README and repeated here because it matters: consensus on
chain 2800 is classical secp256k1 ECDSA. This binds a post-quantum certificate to
the block hash. It does not make consensus post-quantum and is never described as
such.
What is here: the anchor, the validation rules, the wiring, and the tests,
including the negative controls. Applied to upstream d2032017bb, the pinned base
named in anchor/BASE.txt. One build file changes, by one line, and the README says
which and why. No cryptography is implemented here; Falcon verification calls
Bouncy Castle.
What is not here: no keys, no fleet configuration, and nothing about what is armed
on any running network.
Measured before publishing, on upstream d2032017bb with this overlay applied:
consensus:common and consensus:qbft, 605 tests, 0 failures, identical to the same
tree before this work, class by class.
Three things were found while preparing it, and all three are fixed here:
- the code spoke Romanian in 134 comment lines and 43 strings, 37 of them on
production paths, which is to say in the messages a node prints when it refuses
to start. An auditor given the code to check the guards could not read the
guards.
- ten test classes carried internal issue numbers in their names. They now say
what they test.
- the suite was green partly by ordering luck. One class cleared its system
properties but not the configuration PqAnchorProducer remembers, so it left the
anchor armed for whichever class ran next. Renaming the classes changed the
order and four tests began failing on a guard that was firing correctly. Fixed
where it leaks, with the negative control measured: remove the line and the
pair goes red, restore it and it goes green.
- Apache 2.0 section 4(b): the patches modify files that are the work of
Hyperledger Besu and now say so, with the notice inside the modified files,
which is what the licence asks for and what applying the patch produces.
- patches/ and precompiles/ now carry the staged versions rather than an older
export. The two had drifted in both directions; the only thing the published
copy had that the staged one lacked was the word "audited" in front of Bouncy
Castle, which we cannot evidence and which the staged version had dropped.
- the brand was spelled two ways in the same repository, 62 times one way and 23
the other. It is Aere Network; AERE is the ticker. The 96 AERE_* code
identifiers are untouched.
Every source file in this repository carries SPDX-License-Identifier: Apache-2.0,
and the README has always said Apache 2.0. The LICENSE file said MIT. It was the
only thing in the repository that disagreed, and it was wrong.
This code derives from Hyperledger Besu, which is Apache 2.0. Several files sit in
Besu's own packages because that is where the client loads them from. Publishing
that under MIT was not a choice we were free to make, and it is not one we made
knowingly.
The LICENSE file now contains the Apache 2.0 text as published by the Apache
Software Foundation, byte for byte (sha256 cfc7749b96f63bd31c3c42b5c471bf756814053e847c10f3eb003417bc523d30).
NOTICE records the derivation from Besu.
Nothing about the terms these files were offered under has changed: the file
headers governed before this commit and govern after it. The correction is
recorded in the README rather than made silently, because a licence is the one
thing in a repository a reader should not have to verify.
Aere Network public source. Everything here can be checked against the live
chain (chain id 2800, https://rpc.aere.network).
Scope note, stated up front rather than buried: consensus on chain 2800 is
classical secp256k1 ECDSA QBFT. The post-quantum work in this repository is at
the signature, precompile, account and transport layers. Nothing here makes the
consensus post-quantum, and no document in it should be read as claiming so.
