Accounts
A permanent address with evolving authority.
Every Minerva account is a smart account controlled by an ML-DSA-65 key. The address never moves; the key that may authorize it can.
Account lifecycle
- 1
Create
An account address is derived with CREATE2 from the factory, the initial ML-DSA-65 key and a salt. It can receive funds before any contract exists, and it can deploy itself with its own first transaction.
- 2
Authorize
Every native transaction carries the account, the public key, the algorithm, the policy version and a signature over a hash that binds chain id, nonce and the whole envelope. The node verifies it against the account's control record before gas is charged.
- 3
Rotate
rotatePQKey, signed by the current key, writes the new key commitment and increments the policy version in the Account Control Registry. From that block the previous key is rejected on the native path at every policy version.
- 4
Delegate
Device keys are enrolled with scopes: allowed targets or any, a value limit per window, an expiry, and protected targets no scope can include. Consensus admits a device key only for zero-value self-calls; the account contract enforces the scope.
- 5
Recover
Today recovery means restoring the encrypted ML-DSA key from the Recovery Kit and rotating. Policy-based recovery (guardians) would end in the same registry write; it is planned, not shipped.
The diagram follows the implemented model. The steps marked as planned are design targets and are labeled as such on the Core v1 page.
In one line each
Native transaction
MinervaPQTxV1 is the only transaction type a Minerva network accepts. Legacy Ethereum types are invalid by consensus, so no ECDSA path exists for any account.
- Type byte
- 0x4D
- Fields
- chainId, nonce, fees, gas, account, factorySalt, to, value, data, accessList, pqAlgorithm, pqPublicKey, policyVersion, pqSignature
- Signing context
- MINERVA_PQ_TX_V1
- Account context
- MINERVA_ACCOUNT_V1 (executePQ, rotatePQKey, isValidSignature)
- Authorizing key in-contract
- MINERVA_TX_CONTEXT precompile at 0x0000000000000000000000000000000000004D01
- Control record
- AccountControlRegistry at 0x…0204: commitment, algorithm, policyVersion
Account Security Center
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
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.
Read further
- PQ-native transaction layer
sender rule, node responsibilities, device keys
- Architecture overview
node, precompile, contracts, services
- @minerva/sdk
create accounts and send native transactions