Skip to content
Minerva. Post-quantum, proof of work.

Security

Security model

“Breaking ECDSA/secp256k1 alone cannot move default Minerva Account funds or control protocol/admin accounts.”

This is an account-control claim, not a statement about every subsystem. It holds on the devnet and the public testnet for default account funds, where execution and key rotation require an ML-DSA-65 signature. Protocol and admin controls are a release gate: each must be a Minerva account or a stricter post-quantum policy before the claim covers it.

A marble floor under grid lines
Post-quantum signatures

Primitives

Account signatures
ML-DSA-65 (FIPS 204)
Verifier
native precompile at 0x0000000000000000000000000000000000004D00, Cloudflare CIRCL implementation
Signing context
MINERVA_PQ_TX_V1 (constant, not signer-chosen)
Key and signature size
1952 and 3309 bytes
Fallback research
SLH-DSA (FIPS 205) and SPHINCS-, research only
Ordering
Proof of Work; a separate security property from authorization

The full authorization path

The signature check is a consensus rule, not a wallet or RPC feature. It runs at pool admission and again when a block is imported, so a miner cannot include an unauthorized transaction by bypassing the pool.

  1. 1

    Wallet / SDK

    Builds a MinervaPQTxV1 envelope and signs its hash with the account's ML-DSA-65 key under the constant context.

  2. 2

    Transaction

    Type 0x4D. Carries the account, the public key, the algorithm, the policy version and the signature; about 5.4 KB.

  3. 3

    Node validation

    Signature verified, account binding checked, control record read from the registry. Admission to the pool only if all three hold.

  4. 4

    Block validation

    The same checks run when a block is imported. A block carrying an invalid native transaction is invalid itself.

  5. 5

    Account execution

    The account contract executes with the authorizing key available through MINERVA_TX_CONTEXT, so device-key scopes are enforced in-contract.

Adversarial case

  1. 1Invalid authorization
  2. 2Direct block-inclusion attempt
  3. 3Expected result: block rejected

Required behaviour

After the native-only activation, a block is invalid if it contains any transaction that is not type 0x4D, or a native transaction whose signature, account binding or control record fails. Validation is a consensus rule in chain configuration; no node setting relaxes it.

Evidence

Unit tests cover the shared precheck (rotated-out keys, wrong chain, wrong account binding, ECDSA signers) and pool admission for legacy types; live devnet and testnet nodes refuse non-native submissions. A dedicated block-import test for the invalid-authorization case is still pending, which is why block validation is listed as implemented rather than tested.

FIPS 204 specifies ML-DSA. Using a standardised algorithm does not by itself show that the transaction, recovery and block-validation integration is correct; the tests listed on the Core v1 page are the evidence, within their stated scope. NIST FIPS 204

Coverage

Covered on devnet and testnet

  • Default account funds and execution
  • Control Key rotation and rotated-out key rejection
  • Device keys with scopes and consensus-level revocation
  • Native-only transaction types, by consensus
  • Faucet, relayer and miner addresses without any EOA key
  • Release builds: reproducible, signed classically and with ML-DSA-65

Release gates and known gaps

  • Protocol and admin controls: no privileged production control exists yet; any future one must be PQ-controlled
  • Bridge guardians are classical keys; the bridge is a separate gate
  • Node identity and transport are classical; a PQ design exists, no code
  • Policy-based recovery (guardians) is planned, not shipped
  • No independent review; no multi-node verification

Documentation