Cryptography

heartwood-crypto defines keys, addresses, signatures, and the byte encodings used by the current Rust baseline. It also implements transaction and block rules against the pinned reference.

Current signing

The baseline uses BIP340 signatures. A separate feature retains the legacy Schnorr scheme needed for reference peer-status messages. Address and network behavior are checked with committed vectors.

The validator portal adapter signs the SHA-256 digest of the exact UTF-8 login message with BIP340. It uses compressed public keys and the explicit heartwood-devnet-v90 identity format. These settings describe that adapter, not a final mainnet specification.

Feature boundaries

All optional crypto features are off by default.

Feature	Purpose
legacy-schnorr	Reference-compatible peer-status signatures
genesis	Development chain-definition builder
fixed-aux	Reproducible signatures for tests only

Build release artifacts one package at a time. A workspace-wide release build can unify features requested by test tools, including test-only signing seams. The repository’s release check guards against that leakage.

Input validation

The crate forbids unsafe code and returns typed decoding errors. Choose the entry point for the operation:

• Block::receive: apply the reference’s receive behavior, including canonicalization.
• Block::decode: check the supplied bytes.

Decoding alone does not check every rule required to receive a peer’s block.

Post-quantum direction

The draft whitepaper selects ML-DSA-65 for every native protocol signature from mainnet genesis, with explicit signature-scheme identifiers. It also proposes Bech32m addresses and transaction IDs that exclude signature witnesses.

Those are proposed mainnet rules, separate from the current BIP340 compatibility baseline. In particular, do not mix the draft’s address or transaction-ID format with the running portal adapter.