Wallet Security + Staking AES / Kyber Lockbox

Wallet custody and staking designed for long-run network safety.

Atho wallet security uses encrypted-at-rest lockbox controls with Argon2id, AES-256-GCM payload encryption, and mandatory Kyber DEK wrap. Wallet staking remains deterministic and auditable: payouts are weighted by each address share of total active stake in the settled epoch.

Wallet Policy Snapshot

  • Encryption stack Argon2id KDF, AES-256-GCM payload encryption, AES-256-GCM DEK wrap, and mandatory Kyber DEK wrap.
  • Unlock modes default (password path) and advanced (password + Kyber unlock file import).
  • Staking weighting rule stake_payout_i = stake_pool_epoch * (active_stake_i / total_active_stake_epoch).
  • Settlement windows Deterministic 720-block epoch plus 3600-block finalization buffer.
Wallet Addressing + Fees

How Base56 addresses and fee-per-byte policy work in Atho wallets.

Wallet addresses are generated from Falcon public-key material through deterministic SHA3-384 pathways, then encoded in Base56 for human use. Fee policy is calculated by vsize with a floor of 500 atoms/vB and minimum transaction fee 200,000 atoms.

Deterministic Address Pipeline

One key source, multiple role-safe addresses. Domain-separated hashes prevent regular, bond, and stake destination mix-ups.

  • Role domains ATHO_ADDR_V1, ATHO_BOND_V1, ATHO_STAKE_V1.

Base56 Format (Human-Safe Encoding)

Base56 avoids ambiguous symbols to reduce copy/read mistakes in wallets, terminals, and printed records.

Role-Separated Base56 UX

Fee-Per-Byte Policy in Wallet Send Flow

Wallet send estimation uses virtual size (vsize) policy. Current floor is 500 atoms/vB with minimum tx fee 200,000 atoms and dust limit 20,000 atoms.

required_fee_atoms = max(500 * vsize, 200000)

Address Protection and Key Isolation

Role addresses are deterministic and domain-separated from the same Falcon pubkey source bytes, so regular, bond, and stake pathways cannot be confused or replayed across roles.

  • Role derivation domains ATHO_ADDR_V1, ATHO_BOND_V1, and ATHO_STAKE_V1 each hash to separate addresses.
  • Plaintext vs encrypted fields Display identifiers and Base56 addresses stay visible; raw keys, mnemonic material, and private components remain encrypted while locked.
  • Fail-closed lock policy Sensitive wallet operations refuse to run while lockbox is encrypted and locked.
  • Atomic + backup-safe writes Key file writes are lock-protected and backup-on-write to reduce corruption risk.

Hybrid Security Stack Visual

Kyber does not replace AES; it wraps the same DEK used by AES payload encryption. This keeps fast encrypted payload handling plus a post-quantum recovery/control plane.

1) Generate random DEK
2) Encrypt wallet payload with AES-256-GCM(DEK)
3) Wrap DEK with Argon2id-derived KEK
4) Wrap same DEK with Kyber metadata/ciphertext
5) Persist lockbox metadata + encrypted payload

Private Transaction UX in Wallet Nodes

Wallet nodes orchestrate private transaction assembly: sender authentication, note selection, deterministic witness context, recipient bundle parsing, and payload encryption before any transaction reaches mempool.

  • Public -> private funding Spend public UTXOs and produce private commitments with recipient-bound encrypted note payloads.
  • Private -> private transfer Consume private notes via nullifiers and create fresh commitments while preserving spend privacy.
  • Private -> public release Spend private notes and emit public UTXO outputs when transparent settlement is needed.

Recipient Bundles, QR, and Address Binding

  • Reusable receive bundles Wallets can expose reusable bundle data for receive UX while private-note derivation remains unlinkable through deterministic counters.
  • QR and copy workflows Receive views support QR payload sharing and direct address/bundle copy for low-friction transaction initiation.
  • X-address integrity checks Validation logic enforces x-address hash consistency with bundle material before accepting private payloads.
  • Password-gated private sends Sensitive private send operations require unlocked wallet auth policy on each send path.
Bundle Reuse UX Deterministic Note Keys Encrypted Payload X-Address Hash Match
Wallet Staking Mechanics

Staking rewards are weighted by active stake share, not fixed equally.

Wallet staking is separate from mining rights. Rewards are settled from the stake-side bucket and distributed by proportional active share in each settled epoch.

Staking Lifecycle

Stake transitions follow deterministic state rules: pending -> active -> exiting -> unlockable -> withdrawn.

  • Epoch accounting 720-block epoch with 3600-block finalization buffer.
  • Role separation Staking accrues economic rewards only; block production still requires PoW + active bond.

Stake Pool Weighting Visual

Example from reward docs: if epoch stake pool is 900 ATHO, payout follows each staker's active share.

stake_payout_i_epoch
  = stake_pool_epoch * (active_stake_i / total_active_stake_epoch)

What This Means for Wallet Users

  • Bigger active share = bigger payout Rewards scale linearly with your active stake percentage in the settled epoch.
  • No hidden manual overrides Pool split and weighting rules are deterministic consensus/accounting pathways.
  • Auditability Reward constants, split math, and epoch windows are documented across Whitepaper, Consensus, and Rewards docs.
  • Current staking bounds 20 ATHO minimum, 500 ATHO max per address, 25,000 ATHO max new stake per rolling 30 days, and 25,000,000 ATHO max total staked network-wide.

Mnemonic Recovery Options at Wallet Creation

Wallet creation defaults to mnemonic-backed deterministic keys with 24 words. Creation flow supports 12, 24, or 48 words, and recovery can import the same mnemonic path later.

  • Creation options Generate new mnemonic wallet, recover from existing mnemonic, or import an existing Falcon key export.
  • Passphrase handling Mnemonic passphrases are never stored in key JSON or export files; keep passphrases separately.

Recovery + Lockbox Flow

After import or recovery, lockbox controls apply the same encrypted-at-rest policy and unlock controls used for daily wallet operations.

Mobile Wallet (App Store + Google Play) is in progress.

Mobile clients are being prepared with the same custody posture: encrypted lockbox pathways, deterministic role-address handling, and transparent staking controls. Release will prioritize security review, predictable backup flows, and clear recovery UX before public launch.

AES-256-GCM wallet lockbox Kyber-based DEK wrap path Base56 role-safe addresses Wallet staking visibility Recovery + export controls

Coming Soon

iOS and Android releases are planned after wallet security QA, recovery-flow testing, and operator rollout validation.

Coming Soon on App Store
Coming Soon on Google Play