height 25522 of 25522 on the network. 9 peer(s) connected, 91 in its peer directory; 2818 block(s) followed and 2298 pulled in by sync since this follower started. Caught up: this follower holds every block any peer has claimed, so every panel below is the whole chain. Genesis 1cf8655125cc1bbb…, producers genesis.
What this follower is, locally
Following 7 seed(s) — their addresses are not published here, for the reason the peer table gives. Its store is held under its own Cerberus lease — no other node’s store is opened, touched or stopped.
Cryptography
- In force on this chain 7 77.8% a record on this chain depends on it
- Carried and unused 2 22.2% compiled into this build and reached by nothing this chain does. Present is not the same as protecting anything, and this page refuses to count them together
Nothing on this page changes while it is open, so nothing on it is polled. These are properties of this build and of this chain’s genesis rather than measurements of a running network, and a page that re-requested them on a timer would be asking a validator to do work for an answer that cannot have moved.
Post-quantum parameters
- Signature suite
ml-dsa-65- Key agreement
ml-kem-768- Hybrid identity
ed25519+ml-dsa-65- Signature size
- 3309 bytes
- Public key
- 1952 bytes
- KEM public key
- 1184 bytes
- KEM ciphertext
- 1088 bytes
The sizes are here because they are the reason a hybrid signature is a decision rather than a default: a block carrying one attestation per seat pays these bytes per seat, every block, forever.
Account signatures
- Suite
ed25519- Used for
- every transfer, domain claim, identity record, wrap, delegation and contract authorization
- In force on this chain
- yes
Addresses
- Suite
sha256 over the public key, rendered zk13str_<40 hex>_<4 hex>- Used for
- deriving an address from a key, and checking that a declared key derives the address it claims
- In force on this chain
- yes
Block and record commitments
- Suite
sha256- Used for
- the transaction root, the records root, the state root and every block hash
- In force on this chain
- yes
Wallet key derivation
- Suite
BIP-39 over 2048 words, then HKDF-SHA256 to ed25519- Used for
- turning a 24-word recovery phrase into an account key and a vault key
- In force on this chain
- yes
The phrase reaches the account and the vault. A passphrase added to a wallet file does not travel with it.
Post-quantum signatures
- Suite
ml-dsa-65- Used for
- hybrid attestations and Gemini identities, beside the ed25519 signature rather than instead of it
- In force on this chain
- carried by this build and not used by this chain
Carried by this build and not used by the blocks on this chain: the head's attestations are ed25519 only. A hybrid signature costs 3309 bytes each, which is the reason it is a decision rather than a default.
Post-quantum key agreement
- Suite
ml-kem-768- Used for
- the Bifrost handshake between nodes, so a recorded session cannot be opened later
- In force on this chain
- yes
Between nodes, on the wire. It protects the transport and not the ledger: a record is signed by its holder, and that signature is the ed25519 one above.
Session encryption
- Suite
AES-256-GCM under a per-direction key, counter nonces- Used for
- every frame between two peers after the handshake
- In force on this chain
- yes
One writer per key, so two nodes cannot collide on a counter — which is what makes a counter safe as a nonce.
Keys at rest
- Suite
scrypt N=2^17, then AES-256-GCM- Used for
- the wallet file, the node identity and the seat key
- In force on this chain
- yes
Encryption at rest does not defend a compromise of the account that holds the passphrase.
Zero-knowledge proofs
- Suite
zk13-schnorr-cp-modp14-v2- Used for
- proving a statement about an identity without revealing it
- In force on this chain
- carried by this build and not used by this chain
The reference implementation. It is not on the consensus path of this chain: no block on it is accepted or refused on the strength of a ZK13 proof.
ZK13
- Version
zk13-schnorr-cp-modp14-v2- On the consensus path
- no — no block is accepted or refused on the strength of a proof
Adding a real proving system exceeds the 1-direct dependency budget; see ZK13_PRODUCTION_REQUIREMENTS and scripts/check-deps.mjs. Escalate to governance.
| Before production it must |
|---|
| An ANONYMITY SET. A proof of knowledge of the discrete log of ONE named commitment is a signature, and this tree already has ed25519 and Gemini for that - binding `y` to an identity would make ZK13 a slower, larger, redundant signature scheme, not a private one. The property that makes a nullifier worth having is "I am one of these N, and I will not say which". That needs either a linkable ring signature, whose proof grows linearly in N, or a SNARK over a Merkle-membership circuit, whose proof is constant-size. Neither is a variation on the code in this file. |
| A CLOSED, ON-CHAIN SET OF ADMISSIBLE COMMITMENTS, folded into the state root and replayed from blocks, so every node agrees on which commitments exist and none can be minted at will. That is chain state (the Idunn/Sindri/Glasir pattern), not a `src/crypto/` object. |
| A NULLIFIER LEDGER that is also chain state. Reuse is only DETECTED by something that keeps a record; a record on one node's heap is empty after a restart and shared with nobody, which is why `NullifierRegistry` was deleted rather than kept (see below). |
| A TRUSTED SETUP, if the route chosen is a SNARK: a ceremony whose output becomes a verifying key committed to genesis and thereafter consensus-critical. That is an operational event with named participants and a published transcript, not a merge. |
| A CALL SITE that consumes a proof, and a `CryptoRuntimePolicy` derived from the node's declared mode. Neither exists, and neither can be created from inside `src/crypto/`. |
5 requirements, and this is all of them — not a page of a longer list.