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

Minerva · Layer 1

Proof-of-Work.Post-Quantum Security.Built for the next generation of blockchain.

Minerva is a mineable Layer 1 with EVM smart contracts. Every account is a smart account controlled by an ML-DSA-65 key. The node verifies that signature for every transaction, at pool admission and again at block validation. There are no ECDSA accounts: mining rewards, faucets, relayers and users all operate from post-quantum accounts.

Consensus
Proof of Work (Ethash)
Signatures
ML-DSA-65, FIPS 204
Execution
EVM, Shanghai rules
Testnet
chain 77138, live
The Minerva emblem: a helmeted classical figure inside a ring reading Minerva, MRV, post-quantum, proof of work.
Transaction type 0x4D · precompile 0x0000…4D00reading the testnet RPC…

Technology

What the network consists of

Mining

  • Proof of Work with the Ethash algorithm; the chain is secured by hash rate, not stake.
  • Block reward 1 MRV, halving every 10,500,000 blocks; 21,000,000 MRV scheduled issuance, no tail emission.
  • Base fee split: 30 % to the miner, 70 % burned. No uncle rewards, no difficulty bomb.
  • Rewards are paid to a Minerva account. Any CPU or GPU miner can start from the published genesis and bootnode.
Details

Post-quantum cryptography

  • ML-DSA-65 (NIST FIPS 204) is the account signature scheme. Public key 1952 bytes, signature 3309 bytes.
  • Verification runs in a native precompile at 0x…4D00, implemented with Cloudflare CIRCL; wallets sign with an independent implementation.
  • Signatures bind chain id, account, nonce, policy version and the full transaction under a constant context.
  • SLH-DSA (FIPS 205) is tracked as the hash-based fallback; it is research, not consensus code.
Details

Smart contracts

  • Standard EVM at Shanghai rules with 0x addresses; Solidity, Foundry and viem work unchanged for contract code.
  • Every caller is a contract account, so ecrecover-based signer checks do not apply; ERC-1271 verifies account signatures.
  • System contracts at fixed addresses: security modes, readiness, account factory, account control registry, migration reserve.
  • The authorizing key of the current transaction is readable in-contract through the MINERVA_TX_CONTEXT precompile.
Details

Account security

  • The address is derived once (CREATE2 from the initial key and a salt) and never changes.
  • The Control Key rotates by writing a new key commitment and policy version to the Account Control Registry; the old key is rejected by consensus from that block.
  • Device keys carry scopes (targets, value window, expiry) and are limited to zero-value self-calls at the protocol level.
  • Recovery today is an encrypted Recovery Kit; policy-based recovery is specified and not yet built.
Details

Network infrastructure

  • minerva-geth, a CoreGeth fork, with standard JSON-RPC plus the minerva_ namespace (sendRawPQTransaction, getAccountControl, getDeviceKey, networkInfo).
  • Public testnet 77138: RPC, faucet and PQ relayer behind one host; genesis and bootnode published.
  • TypeScript SDK, Minerva Wallet (mobile, extension, desktop), reproducible node builds with SSH and ML-DSA-65 signed checksums.
  • A liquidity-backed Ethereum bridge is built and tested; it is a separate security gate and is not live.
Details

Account model

Key rotation without changing the address

A Minerva account is a contract at a CREATE2-derived address. The key that may authorize it is recorded on-chain and can be replaced; consensus enforces the current record.

01 · Authorize

Transaction authorization

The node reads the account's control record (key commitment, algorithm, policy version) from the Account Control Registry and verifies the ML-DSA-65 signature against it before gas is charged. A transaction that fails this check is invalid in the pool and in a block.

Minerva account

0x7D3488118952dD7A7d087Ff7845151fd3C1A5829

Current Control Key
Key A · policy v0
Account policy
Native-only · device keys: none
Transaction nonce
8
Network
Minerva Testnet · 77138
  • Transaction #8: signature verified against policy v0

02 · Rotate

Control Key rotation

rotatePQKey is signed by the current key and writes the new key commitment and an incremented policy version to the registry. The change is effective from the block that includes it. The address does not change; the previous key is rejected from that block on.

Minerva account

0x7D3488118952dD7A7d087Ff7845151fd3C1A5829

Current Control Key
Key B · policy v1
Account policy
Native-only · device keys: none
Transaction nonce
9
Network
Minerva Testnet · 77138
  • Rotation to Key B: requested, awaiting confirmation
  • Rotation effective at block 12,418 · policy v1
  • Key A: invalid for every policy version

03 · Recover

Recovery

Recovery is a rotation performed with a key restored from the Recovery Kit: a new key commitment, a new policy version, the same address. Policy-based recovery with guardians is specified and not yet implemented.

Minerva account

0x7D3488118952dD7A7d087Ff7845151fd3C1A5829

Current Control Key
Key C · policy v2
Account policy
Native-only · device keys: none
Transaction nonce
10
Network
Minerva Testnet · 77138
  • Recovery Kit restores signing · Key C · policy v2
  • Key B: rotated out

Same address, new Control Key.

Rotation changes which key may authorize the account. Funds, contract state and the address itself are unaffected.

Sample data. The rule shown, a rotated-out key rejected once the new policy version is in force, is implemented in the node and verified on the devnet; see Core v1 for the test names and their scope.

Consensus

Authorization is enforced at block validation

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

Verification status

Core v1: post-quantum account hardening

Each verification area carries a status, the tests behind it and the scope those tests cover. Tested version minerva-geth 1.12.22 (CoreGeth fork), commit e561109, 2026-10-23.

Full evidence page
AreaStatus
Authorization coverageLOCALLY TESTED
Block validationIMPLEMENTED
Control Key rotationLOCALLY TESTED
Recovery and permissionsLOCALLY TESTED
Replay protectionLOCALLY TESTED
ML-DSA integrationLOCALLY TESTED
CompatibilityIMPLEMENTED
Multi-node behaviourLOCALLY TESTED
Release integrityLOCALLY TESTED

Statuses: PLANNED · IMPLEMENTED · LOCALLY TESTED · MULTI-NODE VERIFIED · INDEPENDENTLY REVIEWED. No area is independently reviewed or multi-node verified yet.

Specification

Network parameters

Values as configured in the genesis files and chain configuration at commit e561109. Protocol changes ship as named forks with a block number, never as silent edits.

Chain ids
77137 devnet · 77138 testnet · 77139 mainnet (reserved)
Consensus
Proof of Work, Ethash; genesis difficulty 0x600000 on the testnet
Block reward
1 MRV, halving every 10,500,000 blocks; 21,000,000 MRV total scheduled issuance
Fee market
EIP-1559; 30 % of the base fee to the miner, 70 % burned
Transaction type
0x4D (MinervaPQTxV1), the only valid type; about 5.4 KB per transaction
Signature scheme
ML-DSA-65 (FIPS 204); public key 1952 B, signature 3309 B
Signing context
MINERVA_PQ_TX_V1 (transactions) · MINERVA_ACCOUNT_V1 (account calls)
Precompiles
0x0000000000000000000000000000000000004D00 ML-DSA-65 verify · 0x0000000000000000000000000000000000004D01 MINERVA_TX_CONTEXT
System contracts
0x…0201 SecurityModeRegistry · 0x…0202 AccountReadinessRegistry · 0x…0203 MinervaAccountFactory · 0x…0204 AccountControlRegistry · 0x…0205 MinervaMigrationReserve
EVM
Shanghai-level opcodes; no blob transactions; no EIP-7702; legacy transaction types rejected by consensus
Node
minerva-geth 1.12.22 (CoreGeth fork); JSON-RPC eth_, net_, web3_, txpool_ and minerva_ namespaces
Testnet genesis
0x364c9c46ce91…4a9799af38
Public endpoints
https://testnet.minervachain.org/rpc · https://testnet.minervachain.org/faucet · https://testnet.minervachain.org/pq-dev/send-raw · https://testnet.minervachain.org/api/indexer
Client software
Minerva Wallet 0.1.2 (Android, Linux, Chrome, Firefox, web) · @minerva/sdk · @minerva/pq-native-tx

Testnet 77138 · live reads

reading…
Block height
—
Block interval
—
Reporting nodes
—
Source
testnet RPC
eth_blockNumber, eth_getBlockByNumber, net_peerCount; refreshed every 30 s
A niche carved into a stone wall
Minerva Wallet

Minerva Wallet 0.1.2

Mobile, browser extension and desktop

Creates Minerva accounts, signs MinervaPQTxV1 transactions with ML-DSA-65, rotates Control Keys, enrols device keys and produces the Recovery Kit. The extension exposes an EIP-1193 provider for the Minerva chain. Checksums are signed with SSH and ML-DSA-65; the verification key is published next to the files.

SHA256SUMS · ML-DSA-65 signature · public key · macOS, Windows and iOS builds are not published yet · privacy policy

Wallet

Account control in Minerva Wallet

The wallet reads the account's current control record from the chain and shows it next to the account's state. Requested and confirmed changes are listed separately. The fields below follow the implemented account model.

A stone chest, lid ajar
Recovery Kit
AccountSample data · not connected

Identity

Address
0x7D3488118952dD7A7d087Ff7845151fd3C1A5829
Network
Minerva Testnet · chain 77138
Control Key
on-chain record · policy v1
Key commitment
0xdff7…90b9
Authorization policy
native-only · 0 device keys
Recovery configuration
Recovery Kit (encrypted key backup)
Last confirmed update
0x9c4e…a1d7 · block 12,418
ReceiveSend

Control actions

  • Control Key rotationConfirmed · v1

    Shows the key that is authoritative now, read from the Account Control Registry, not the key the account was created with.

  • Pending rotationRequested · not effective

    A requested rotation is listed separately until its block confirms. The previous key stays valid until then.

  • Recovery policyRecovery Kit

    An encrypted backup of the ML-DSA key with a rehearsal flow. Guardian-based recovery is specified, not shipped.

  • Device keys0 enrolled

    Scoped keys limited to zero-value self-calls; revocation takes effect at consensus.

This page never asks for a key or a Recovery Kit. Signing and recovery happen in Minerva Wallet 0.1.2; the account model is described under Accounts.

Participate

Run, mine, build

Decentralization that endures. A stone wall rendered in navy wireframe.

Reference

Documentation and network files

The documents are rendered from the repository at build time. Releases carry signed checksums and a published verification key. The source repository is not public yet.