Run Minerva
Node setup, synchronisation, release verification and network participation.
Post-quantum account security
Ownership,Reinforced.
Minerva is a mineable Layer 1 being developed around post-quantum account authorization.
Its core account design brings transactions, Control Key rotation and recovery under a consistent security policy, with address continuity as a central goal.
Current engineering milestoneMinerva Core v1: Post-Quantum Account Hardening
Testnet 77138 live · Minerva Wallet 0.1.2reading the testnet RPC…
One account, evolving authority
The account remains. Its Control Key can change.
01 · Authorize
A transaction reaches the account.
Before gas is charged, the node reads the account's control record and checks the ML-DSA-65 signature against it: key commitment, algorithm and policy version. Anything else is invalid, in the transaction 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
A replacement Control Key is introduced.
The rotation is signed by the current key and written to the Account Control Registry. It becomes effective with its block. The address does not change, and the previous key is rejected only once the new policy version is in force.
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
A recovery path restores control.
Recovery ends in the same registry write as a rotation: a new key, a new policy version, the same address. It is bound to the configured recovery policy; it is not an unrestricted reset.
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 who can authorize the account. It should not require the account itself to disappear.
Illustrative sequence with sample data. The rule it shows, 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.
Authorization across the full path
The check happens where it cannot be skipped.
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.
1Wallet / SDK
Builds a MinervaPQTxV1 envelope and signs its hash with the account's ML-DSA-65 key under the constant context.
2Transaction
Type 0x4D. Carries the account, the public key, the algorithm, the policy version and the signature; about 5.4 KB.
3Node validation
Signature verified, account binding checked, control record read from the registry. Admission to the pool only if all three hold.
4Block validation
The same checks run when a block is imported. A block carrying an invalid native transaction is invalid itself.
- 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
- 1Invalid authorization
- 2Direct block-inclusion attempt
- 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
Explore Minerva
Nine doors into the system.
Each card opens the part of the site that explains, in sourced detail, what the headline promises.
AccountsFamiliar addresses, post-quantum control
Key rotationThe address stays; the Control Key moves
RecoveryAn encrypted backup of the signing key
SignaturesML-DSA-65, verified by the node
MiningOrdering by work, rewards to accounts
SDKTypeScript, native transactions built in
WalletMobile, extension and desktop
BridgeA separate gate, documented as such
Supply21,000,000 MRV scheduled, nothing hidden
Minerva Core v1
A public account of what has been demonstrated.
Core v1 is an engineering milestone, not a certification. Each verification area carries an explicit status and the scope of its evidence: tested version, commit, date, reproduction steps and what remains.
- Version
- minerva-geth 1.12.22 (CoreGeth fork)
- Commit
- e561109 · 2026-10-23
| Verification area | Status |
|---|---|
| Authorization coverage Devnet unit tests and live smokes; public testnet by wallet acceptance from one operator machine. | LOCALLY TESTED |
| Block validation The rule lives in the state processor and block validator; its precheck is unit-tested; block-import tests are pending. | IMPLEMENTED |
| Control Key rotation Devnet unit tests and a live rotation smoke; wallet rotation acceptance on devnet. | LOCALLY TESTED |
| Recovery and permissions Device keys: unit, Foundry and live smoke. Recovery: encrypted Recovery Kit tested; policy-based recovery not built. | LOCALLY TESTED |
| ML-DSA integration Precompile unit tests; cross-implementation agreement in every smoke (wallet signs with @noble/post-quantum, the node verifies with Cloudflare CIRCL). | LOCALLY TESTED |
| Multi-node behaviour Two-node devnet smoke (peering and block sync) only; the public testnet runs one operator node plus its bootnode identity. | LOCALLY TESTED |
Possible statuses: PLANNED · IMPLEMENTED · LOCALLY TESTED · MULTI-NODE VERIFIED · INDEPENDENTLY REVIEWED. No area is independently reviewed or multi-node verified yet.
Your account, under your control
Not a balance card. A Security Center.
Minerva Wallet reads the account's current authority from the chain and keeps requested and confirmed changes apart. Sensitive actions stay quiet: no moving targets, no scrambling addresses, no cinema during signing.
Minerva accountIllustration · sample data · not connected
Identity and activity
- Address
- 0x7D3488118952dD7A7d087Ff7845151fd3C1A5829
- Network
- Minerva Testnet · chain 77138
- Control Key
- current on-chain version · policy v1
- Key commitment
- 0xdff7…90b9
- Authorization policy
- View policy
- Recovery configuration
- View configuration
- Last confirmed update
- 0x9c4e…a1d7 · block 12,418
ReceiveSend
Account control
- Review Control Key rotationConfirmed · v1
Shows the key that is authoritative now, not the one 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.
- Review recovery policyRecovery Kit
Today: an encrypted backup of the ML-DSA key, rehearsed in the wallet. Policy-based recovery is planned, not shipped.
- Device keys0 enrolled
Scoped keys for zero-value self-calls only; revocation takes effect at consensus.
This page never asks for a Control Key or a Recovery Kit. Real signing and recovery happen in Minerva Wallet 0.1.2, whose fields follow the implemented account model; see Accounts.
Minerva Wallet 0.1.2
One wallet. Mobile, extension, desktop.
Creates and controls Minerva accounts with an ML-DSA-65 key, signs native transactions, rotates Control Keys, enrols device keys and rehearses recovery. Release checksums are signed classically and with ML-DSA-65; the verification key ships next to the files.
- Androidsigned APK
- LinuxAppImage
- Linux (Debian).deb package
- Chrome extensionManifest V3
- Firefox extensionManifest V3
- Web exportstatic build
SHA256SUMS · ML-DSA-65 signature · public key · macOS, Windows and iOS builds need a hosted runner and are not published yet · privacy policy
Minerva, in 45 seconds
The idea, before the detail.
The brand film states the position; the rest of this site states the evidence. Videos play only when you press play.
All films and brand assetsRun. Mine. Build.
Three ways in, each with its documentation.
Mine Minerva
Mining documentation, reward-address setup, operational requirements and verified network information.
Build on Minerva
SDK, account integration, the transaction format, compatibility notes and examples tied to supported behaviour.
Testnet 77138 · live reads
reading…- Block height
- —
- Block interval
- —
- Reporting nodes
- —
- Source
- testnet RPC
- eth_blockNumber, eth_getBlockByNumber, net_peerCount; refreshed every 30 s
Inspect the foundations
Examine the work. Then take part in it.
The documents, release artifacts and network files below are the same ones the team works from. The source repository is not public yet; releases ship with signed checksums and a published verification key in the meantime.