Tokenization with receipts that outlive the cryptography

A tokenized bond matures in thirty years. A property title changes hands once a decade. A fund share must remain provable to a supervisor for as long as the fund exists. When a real-world asset moves on chain, the token inherits the lifetime of the asset, and the whole construction rests on one thing: that the record of who holds what, and the documents that say why, can still be verified at maturity, not only at issuance.

Assets live for thirty years. ECDSA does not.

For the classical elliptic-curve signatures that secure most public ledgers, NIST's post-quantum migration guidance (IR 8547, initial public draft 2024) schedules deprecation after 2030 and disallowance after 2035, sooner than the maturity of many assets being tokenized onto them. Once that cryptography falls, an adversary who recovers old validator keys could, in principle, re-sign an alternative history. At that point a registry you meant to hold for decades stops being a proof and becomes an argument. For a payment this is tomorrow's problem. For a thirty-year asset it is a design flaw, present at issuance.

What the ledger underneath provides

Chain 2800 is a public EVM Layer 1 with deterministic finality: a block is final when a quorum of seven of ten validators signs it (ten validators since 2026-09-11), and the QBFT consensus produces no reorganizations of finalized blocks by design. Blocks arrive about every 0.60 seconds (re-measured on 2026-11-03, against a 0.5-second target). For an asset registry this means a transfer is settled for the validators when it is included, and it stays settled; from block 25,080,000 (AIP-22 stage 5) a node that does not take part in consensus, such as the public RPC endpoints, admits a header between anchors on the Falcon-512 seal of its proposer alone, so until the next anchor the blocks above its finalized block, including blocks it has already shown, can be replaced by a branch that the key of a single validator builds (such a node keeps the total-difficulty fork choice of the upstream client; the rule that never leaves a decided block runs on the validators only); for settlement, read the finalized or safe block, which moves only on an anchor certificate that the key of one validator cannot produce (derived from the code; measured on the rehearsal network 28099 with a classical-only fork, AIP-22 record of 2026-09-27: such a node followed the fork up to the block before the next anchor and moved to the anchored chain once linked to an honest validator; not measured: the same with a post-quantum key from stage 5, and whether a node started from the published package, with its seal ceiling at 1, answers these tags the same way).

Consensus is hybrid in a precise and limited sense: since block 13,014,000 every 32nd header (every 128th from block 17,225,968 to block 20,746,736, 2026-09-05 to 2026-09-29) carries a certificate of validator Falcon-512 seals bound under the block hash itself, with a minimum of three seals (f+1 of the nine validators of that time) enforced since 2026-08-14, raised to six seals, then as many as the quorum of nine, at block 14,961,456 (2026-08-21); ten validators since 2026-09-11, where six was below the quorum of seven until block 20,715,632, on 2026-09-29, raised the minimum to seven, as many as the quorum of ten (below block 24,148,752 the seals proved those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01, and from that block a certificate that carries the quorum of one round proves the decision), so an anchor block without it does not finalize; QBFT finalizes every block, whose votes every validator attributes, since block 24,300,000 (AIP-22 stage 4), only through their verified post-quantum seals (corrected 2026-11-04: from block 24,300,000 until 2026-10-31 12:27Z one path of the second client took the author of a proposal that named a height below 24,300,000 from its ECDSA envelope, as the correction of 2026-11-01 to rule 3 of AIP-22 says) (since block 25,080,000, AIP-22 stage 5, headers no longer carry ECDSA commit seals and are admitted on the Falcon-512 seal of their proposer alone; a commit still carries the ECDSA commit seal of its validator as an additional check). (Correction 2026-08-19: the earlier statement that from block 14,050,000 every block required a six-of-nine post-quantum quorum to finalize is withdrawn; the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules and changed no enforcement.) The record your asset lives in is not waiting for a migration; the post-quantum evidence is already in the blocks. The full layer-by-layer picture is on the quantum stack page.

The same durability is available at the account and contract level. Five NIST post-quantum precompiles have been live since block 9,189,161: four signature verifiers, Falcon-512, Falcon-1024, ML-DSA-44 and SLH-DSA-128s, and the SHAKE256 hash, each validated against the official NIST vectors (corrected 2026-10-28: this called all five verifiers). A transfer-agent contract or an issuer workflow can require a post-quantum signature on its own operations, on chain, today. Everything else is standard EVM under Ethereum's Prague and Osaka rules (one exception: the EIP-4788 beacon-roots contract has no code), so MetaMask, ethers, and hardhat or foundry work unchanged, and the native token AERE has a fixed supply of 2.8 billion set at genesis, with no new minting.

Notarization and attestation, the other half of an asset

A real-world asset is never just a token. It is a prospectus, a valuation report, a custody attestation, an insurance certificate: a document trail that has to remain provably unaltered for as long as the asset exists. Our post-quantum notarization anchors a document's hash on chain 2800 without the file ever leaving your hands, and the timestamp inherits the durability of the ledger itself. The mechanism is not a promise: this network's own whitepaper re-anchors its content hash on a fresh block four times a day, publicly verifiable right now.

Honest boundaries

All ten validators are operated by the Foundation today (ten since 2026-09-11). The chain is not yet decentralized and we do not describe it that way; an independent-operator program is being built. No third-party security audit has been completed yet; one is on the roadmap. Our performance claim is deterministic sub-second finality on the validators, and we do not publish throughput figures. And this page describes what the chain can do and how we would engage alongside you: it is not a deployed retail product, and we do not offer card programs, banking, or custody as our product. We would rather you learn the limits from us than from a hostile reader.

Ways to work with us

The path for regulated issuers is the quantum-safe tokenization pilot, described alongside our other engagements on the regulated finance page: your asset, tokenized, with post-quantum evidence in the block record, not only at the application layer. It starts the way every engagement with us starts, with verification instead of slides. Your team runs the public toolkit against the live chain, checks our claims yourself, and receives a reproducible conformance report of the kind you can generate with the same tools. Then, and only then, we map your asset and its document trail onto the ledger together. Builders can start on the developer hub today.

curl -O https://aere.network/tools/verify-anchor.mjs -O https://aere.network/tools/mpt.mjs -O https://aere.network/tools/falcon512.mjs -O https://aere.network/tools/registry-v3.mjs -O https://aere.network/tools/package.json && npm install
node verify-anchor.mjs
# recomputes the post-quantum binding digest of recent
# anchor blocks from raw bytes, independently of us.

# the full toolkit, 35 checks against the public chain:
# precompiles vs NIST vectors, block interval, validator set.
curl -O https://aere.network/tools/verifica-lantul.tar.gz
tar -xzf verifica-lantul.tar.gz && cd verifica-lantul
node verifica.mjs