Security Best Practices

Key management

Asentum accounts are secured by ML-DSA-65 (Dilithium3) keypairs. The post-quantum cryptography itself is invisible to the end user — the keys behave like any other modern wallet keys. Everything you know about safe key custody on Ethereum or Solana applies directly.

• Never share your private key or recovery phrase. Anyone with your private key controls your wallet and all assets in it.
• Store recovery phrases offline. Write them on paper. Keep them in a fireproof safe. Don't store them in cloud storage, photos, password managers synced to the cloud, or anywhere a remote attacker can reach.
• Use a hardware wallet for high-value addresses. When hardware wallet support ships, use it for any account holding meaningful value or running a validator.
• Use separate addresses for separate purposes. Validator signing key, delegator wallet, contract owner, day-to-day spending — keep them isolated.

Wallet security

• Verify the URL before signing. Phishing sites mimic real dApps. Bookmark the canonical URL and use the bookmark, not search results.
• Read every signing prompt. The wallet shows you what you're signing. Don't habitually click through.
• Check the immutability badge. Asentum wallets surface whether a contract is immutable or upgradeable on every signing prompt. If it's upgradeable, check the upgrade authority.
• Watch for unlimited token approvals. Approve only the amount the dApp actually needs, not "unlimited". Revoke unused approvals periodically.
• Be skeptical of "support" DMs. Asentum support will never DM you first, never ask for your seed phrase, and never ask you to import a wallet to a new site.

Smart contract safety

Asentum's contract model removes several major bug classes structurally — but contracts can still have ordinary bugs and ordinary economic exploits. The security guarantees you get for free, and the ones you still have to engineer for:

What you get for free

• Reentrancy is structurally impossible. Cross-contract calls are async message-passing. The DAO hack and its descendants cannot happen on Asentum.
• No hidden upgrade keys. Contracts are immutable by default. If a contract is upgradeable, the wallet labels it and shows the upgrade authority.
• Source verification is automatic. Plain-JS source on-chain means hash-compare verification is free.
• No floating-point determinism bugs. Math is BigInt. Floats are linted out at the contract layer.
• No ambient authority. The Hardened JavaScript sandbox denies access to the network, filesystem, clock, and random sources by default.

What you still have to engineer

• Authorization checks. Contracts must explicitly verify caller identity for privileged operations. The protocol doesn't do this for you.
• Integer overflow / underflow. BigInt doesn't overflow, but logic bugs around signed vs unsigned semantics still bite.
• Economic exploits. Oracle manipulation, sandwich attacks, MEV — these are protocol-design problems, not code bugs.
• Audits still matter. Smaller, immutable contracts are easier to audit, not audit-free.

Validator operations

If you run a validator, your bonded stake is the collateral securing the network. Operational mistakes get slashed:

• Never run two validator instances with the same key. Double-signing is the most severely slashed offense and triggers immediate ejection. If you migrate hardware, the old node must be fully shut down before the new one starts signing.
• Use a separate signing key. The Asentum CLI supports external signers via the --signer flag. For production validators, the signing key should live on dedicated hardware, not on the main node.
• Monitor uptime aggressively. Prolonged downtime is mildly slashed. Set up alerts on the local Prometheus metrics endpoint.
• Test upgrades on the testnet. When the Asentum protocol ships an upgrade, run it on a testnet validator first before applying to mainnet.
• Rotate operational keys, never validator keys. The validator signing key is your identity in the consensus committee — rotating it is a hard fork-style operation. Operational SSH/admin keys can and should be rotated regularly.

Reporting vulnerabilities

If you find a vulnerability in the Asentum protocol, the reference node, the cryptography integration, the contract VM, the SDK, or any official tooling, please report it privately:

• Email: security@asentum.com — PGP key published in the repository
• Bug bounty: A formal bug bounty program opens with the public testnet (Phase 2). Severity tiers and payouts will be published then.
• Responsible disclosure window: 90 days from initial report, or until a fix ships, whichever comes first.

Do not file vulnerabilities as public GitHub issues. Email first, always.