Wallet Access Layer

Wallets & Signing

This page documents the current Aethelred wallet surface as it exists in the codebase today: CLI wallet provisioning, Python dual-key signing, and offline manifests that can be signed by your preferred wallet or HSM. It deliberately replaces the older placeholder wallet directory with source-backed guidance that fits the developer toolchain, the documentation path, and the testnet rollout.

CLI Wallet Ops Dual-Key Signing Offline Manifests HSM Handoff

Explore Access Models Review Security Posture

CURRENT CODEBASE ONLY

Source-backed custody surface

The current public guidance is centered on CLI bootstrap, Python dual-key signing, and offline signing flows, not speculative consumer wallet listings.

Post-quantum aware by design

Aethelred keeps ECDSA for wallet compatibility while introducing Dilithium-backed signing paths in the dual-key wallet implementation.

Cold boundary available now

Unsigned transfer manifests can be produced ahead of time and handed to a preferred wallet or HSM before broadcast.

aeth1... Current Bech32 address family

480K PBKDF2 Encrypted export hardening in Python

12+ Chars Minimum export passphrase length

Overview

What a wallet means on Aethelred right now

A wallet on Aethelred is currently an operational signing surface, not a generic browser-extension marketing object. The codebase supports key provisioning, signing, encrypted backup, and offline transaction handoff. Digital Seal verification and broader read-only protocol inspection can still happen without loading hot keys into the same environment.

CORE

Current Role

Wallets authorize value transfer and signed protocol actions

Use wallets to provision addresses, sign protocol payloads, move tokens, and maintain a clean custody boundary between application logic and privileged signing material. In the current public stack, the strongest documented paths are CLI wallet operations, Python dual-key signing, and offline handoff for external custody systems.

What Requires Keys

Wallet creation, mnemonic import, signed transfers, and any workflow that needs account-level authorization.

What Does Not

Seal inspection, explorer checks, diagnostics, and other read-only protocol queries can be run without placing signing keys on the same host.

Addressing Current Python tests assert Bech32 addresses in the aeth1... family.

Read Path Use the verifier and protocol clients for audit and inspection workflows that do not need custody material.

Write Path Keep transfer and signing boundaries explicit so wallet material is not embedded into application servers by default.

PQC

Compatibility Model

Classical compatibility with a post-quantum migration path

The current cryptography guidance keeps ECDSA for wallet compatibility while the Python wallet implements a dual-key model that adds Dilithium-backed signatures. That matters operationally: a mnemonic-derived classical key is not the whole recovery surface once you adopt dual-key signing.

Compatibility Boundary

ECDSA remains available specifically to preserve interoperability with the broader wallet ecosystem while Dilithium provides the stronger post-quantum signature path.

Recovery Boundary

In the current Python implementation, the mnemonic derives the classical key while the Dilithium key is generated separately. Full recovery therefore depends on an encrypted export, not the mnemonic alone.

Export Policy Plaintext key export has been removed. Exports are encrypted with AES-256 via Fernet and PBKDF2-HMAC-SHA256.

Operational Takeaway Back up the full encrypted wallet export whenever you move beyond compatibility-only signing.

Best Fit Production teams that need compatibility now without blocking the path to stronger signing requirements later.

Access Models

The wallet surfaces that are actually documented today

Instead of listing speculative browser and mobile brands, this page tracks the concrete wallet and signing models the current repo and documentation expose.

CLI

Provisioning

CLI wallet bootstrap for local, devnet, and testnet workflows

The current CLI docs cover wallet creation and mnemonic import alongside network selection. This is the fastest path to getting a signing identity into a controlled developer workflow without building custom custody code first.

Documented Commands

aeth wallet create and aeth wallet import --mnemonic are part of the current CLI quick start.

Best Fit

Developer onboarding, local test rehearsals, and operators who need a fast bootstrap path before moving into stricter custody.

Open CLI Section Testnet Planning

Programmatic Signing

DualKeyWallet for application-side signing and backup

The Python SDK exposes a real dual-key wallet object with signing, verification, encrypted export, restore, fingerprint inspection, and explicit zeroization on close. This is the most complete source-backed wallet implementation in the current repo.

Current Methods

from_mnemonic, sign_transaction, verify_signature, export_keys, and close.

Best Fit

Service backends, test harnesses, controlled signing environments, and teams that need encrypted backup and PQ-aware key handling.

View Python Example Open Docs

OFF

Cold Boundary

Unsigned manifests for preferred wallet or HSM signing

The developer CLI can emit unsigned transfer manifests and explicitly instruct operators to sign them with a preferred wallet or HSM. That is the cleanest current path for keeping transaction assembly and private-key usage on different trust boundaries.

Current Command

aeth wallet send --out tx-send.json produces the transfer manifest for offline signing.

Best Fit

Production operations, regulated token movement, and teams that require HSM or external signer participation before broadcast.

Review Workflow Developer Tools

OPS

Separation of Duties

Keep verification, diagnostics, and custody on the right hosts

Not every protocol action should happen where keys live. The current stack already supports read-only diagnostics, seal verification, and testnet inspection without forcing hot-wallet placement into the same runtime as your observability or compliance tooling.

Read-Only Surfaces

Seal verification, validator inspection, explorer review, and launch-readiness checks remain useful even when signing keys stay offline.

Best Fit

Teams that want clean production boundaries between monitoring, compliance review, and transaction authorization.

ZK Proofs TEE Attestation

Examples

Source-backed examples you can actually build from

These snippets are based on the current docs and source surface, not the older placeholder page. They focus on wallet creation, dual-key signing, and offline handoff.

bash wallet bootstrap

# Configure testnet access
aeth config set --network testnet
aeth config set --rpc https://rpc.testnet.aethelred.io

# Create a new wallet
aeth wallet create --name mykey

# Or import an existing mnemonic
AETH_MNEMONIC="${AETH_MNEMONIC:?set AETH_MNEMONIC}"
aeth wallet import --mnemonic "$AETH_MNEMONIC"

python dual-key wallet

import os

from aethelred import DualKeyWallet

mnemonic = os.environ["AETH_MNEMONIC"]
export_password = os.environ["AETH_EXPORT_PASSWORD"]

wallet = DualKeyWallet.from_mnemonic(mnemonic)
payload = b'{"kind":"wallet-handshake"}'

signature = wallet.sign_transaction(payload)
assert wallet.verify_signature(payload, signature)

backup = wallet.export_keys(export_password)
print(wallet.address)
print(signature.signer_address)
print(backup["encrypted"])

wallet.close()

bash offline manifest

# Build an unsigned transfer manifest
AETH_FROM_ADDRESS="${AETH_FROM_ADDRESS:?set AETH_FROM_ADDRESS}"
AETH_TO_ADDRESS="${AETH_TO_ADDRESS:?set AETH_TO_ADDRESS}"

aeth wallet send \
  --from "$AETH_FROM_ADDRESS" \
  --to "$AETH_TO_ADDRESS" \
  --amount 1000000uaethel \
  --out tx-send.json

# Sign tx-send.json with your preferred wallet or HSM
# Then submit the signed transaction with your broadcast flow

RULES

Current Guardrails

Operational details that matter before you ship custody code

The most important wallet details in the current codebase are easy to miss if you look only at the old marketing page. These are the implementation-level rules that should shape deployment decisions.

Address Family

aeth1...

Encrypted Export

AES-256 via Fernet + PBKDF2-HMAC-SHA256 (480000 iterations)

Export Passphrase Floor

12 characters minimum

Full Recovery Rule

Back up the encrypted wallet export, not only the mnemonic.

Workflow

A professional wallet flow keeps custody separate from app logic

The production-grade pattern is straightforward: provision the wallet, assemble unsigned intent, sign outside the app boundary when necessary, and validate results on read-only surfaces.

STEP 01

Provision the account surface

Create or import a wallet through the CLI, or initialize a controlled Python dual-key wallet when the workflow needs programmatic signing.

STEP 02

Assemble unsigned intent

Generate the transfer manifest before touching custody material. This gives operations teams an inspectable artifact rather than an opaque signing event inside application code.

STEP 03

Sign with the right trust boundary

Route the manifest to the preferred wallet or HSM instead of assuming that every application runtime should own private keys.

STEP 04

Broadcast and verify separately

Once the signed transaction is submitted, keep follow-on verification on read-only surfaces such as explorer, seal verification, and diagnostics.

Wallets should fit the trust model of the workload

If the workload needs purely local rehearsal first, use Infinite Sandbox. If it needs public endpoint planning next, move into the testnet dashboard. If it needs stricter signing controls, keep using unsigned manifests and external custody instead of collapsing everything into one runtime.

Open Infinite Sandbox

Security

Security expectations that match the current implementation

The older wallet mock focused on UX. The real constraints in the current codebase are key recovery, encryption, and host separation. Those are the details that determine whether a wallet flow is credible in production.

Encrypted Exports Only

The Python wallet no longer permits plaintext key export. Backups are encrypted and wrapped with a deliberate KDF policy before they leave memory.

Use Strong Export Passphrases

The current export path enforces a minimum 12-character password. Treat that as a floor, not a target, for backup hygiene.

Mnemonic Is Not Full Recovery

In the current Python dual-key implementation, the mnemonic does not deterministically recreate the Dilithium key. Teams need the encrypted export for full wallet recovery.

Prefer Cold or External Signing

For regulated or higher-value flows, use the manifest handoff path so application infrastructure can stay separate from wallets and HSMs.

Current Matrix

A quick map of the wallet surface by function

This matrix is intentionally narrow. It captures the current surfaces that are directly grounded in documentation or implementation, rather than listing future-facing integrations as if they were already live.

Surface	What It Does	Best Fit	Current Basis
aeth wallet create/import	Bootstraps a wallet identity for local, devnet, and testnet workflows.	Developer setup, test environments, early operator bootstrap.	Current CLI README quick start.
DualKeyWallet.from_mnemonic	Creates a programmatic dual-key wallet with signing and verification support.	Python services, test harnesses, controlled signing workflows.	Current Python SDK source.
DualKeyWallet.export_keys	Produces encrypted wallet backups with hardened KDF settings.	Backup, recovery, migration planning.	Current Python SDK source.
aeth wallet send --out	Builds an unsigned token transfer manifest for offline signing.	Operations, HSM participation, strict custody boundaries.	Current developer CLI source.
Seal verification and diagnostics	Audits protocol outputs and runtime health without colocating signing keys.	Compliance review, monitoring, operational inspection.	Current tools and verifier documentation.

Move from wallet setup into the rest of the protocol stack

Once custody and signing are handled correctly, continue into the developer docs, the toolchain stack, and the foundation research pages that describe how wallets fit inside Proof-of-Useful-Work, Digital Seals, and verifiable AI operations.

Open Developer Docs