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

Security

One claim, stated exactly.

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

The claim is an account-control claim, not a blanket statement about every subsystem. On the devnet and the public testnet it holds for default Minerva Account funds, where execution and key rotation require an ML-DSA-65 signature. The protocol and admin part is a release gate: every privileged control must be a Minerva Account or a stricter post-quantum policy before the claim covers it. Nothing here means impossible to hack, and nothing means forever.

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

A wallet signature is necessary, not sufficient. The same authorization rule is applied when a transaction enters the pool and again when a block is imported, so a miner cannot carry an unauthorized transaction into the chain by including it directly.

  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.

Test path · labeled 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 that demonstrates it

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 the ML-DSA signature scheme. Adopting the algorithm is not, by itself, proof that Minerva's transaction, recovery and block-validation integration is correct; the tests above, within their stated scope, are that proof. NIST FIPS 204

What is covered, and where

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

Read further