A native desktop cryptocurrency wallet written in C++20 and Qt 6. No Electron, no webview, no cloud key storage, no analytics.

Experimental software. Not independently audited. Do not use it as the sole protection for funds you cannot afford to lose. See SECURITY.md for what is and is not defended against.

• Overview
• Supported assets
• Architecture and security design
• Build
• Usage
• Platform support
• Verification status
• Known limitations
• Documentation
• License

Eleven assets across seven networks, with full key derivation, receive, and send support:

Swaps. A built-in swap screen routes through Trocador. It requires an API key in AURUM_TROCADOR_API_KEY. A catalog of 107 additional coins (src/catalog.cpp) can be selected as swap destinations; Aurum derives no keys or addresses for them, and the user supplies the payout address.

• Vault. The wallet file is 160 bytes: a fresh 16-byte salt and 24-byte nonce, with the key derived by Argon2id (libsodium moderate parameters: 3 passes, 256 MiB) and authenticated by XChaCha20-Poly1305. No private key is stored in plaintext.
• Isolated signer. Key creation, restore, address derivation and signing run in a separate aurum-signer process. The GUI never decrypts a private key. The password is passed over an anonymous local socket pair from locked memory, never through arguments, environment, or temporary files. The helper performs exactly one operation and exits.
• Syscall sandbox (Linux). Before reading the password, the signer installs a seccomp allowlist that denies filesystem opens, sockets, process creation and ptrace.
• Memory handling. Secrets live in libsodium guarded allocations that are locked, excluded from core dumps, zeroed on release, and made read-only after construction. Core dumps and ptrace attachment are disabled for the main process.
• Constrained signing. The signer accepts only supported transfer formats (BTC/LTC transfers, EVM native and ERC-20 transfers, native SOL/SPL transfers). Token approvals, arbitrary contract calls and unexpected Solana instructions are rejected.
• Network hygiene. TLS verification is on, cross-origin redirects are refused, and requests have size and time limits.
• Monero. Handled by the signed upstream monero-wallet-rpc rather than Aurum's own vault. The default route is a public onion node over local Tor; Aurum does not silently fall back to clearnet.

The full threat model, including what is explicitly out of scope, is in SECURITY.md.

Dependencies: Qt 6.4+ (Core, Gui, Widgets, Network, WebSockets, Svg, Test), OpenSSL, libsodium, libsecp256k1 (with the recovery module), Crypto++, libqrencode, CMake, and a C++20 compiler.

Debian / Ubuntu:

sudo apt-get install cmake ninja-build g++ qt6-base-dev qt6-websockets-dev qt6-svg-dev \
  libqt6svg6 libssl-dev libcrypto++-dev libsodium-dev libsecp256k1-dev libqrencode-dev

Configure, build, test:

cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=ON
cmake --build build
QT_QPA_PLATFORM=offscreen ctest --test-dir build --output-on-failure

Run the offline demo (no network, public test keys only):

./build/aurum --demo

1. Start Aurum and create or restore an encrypted wallet, or open an existing profile.
2. Use Receive to show an address and QR code, and Send for a reviewed, password-confirmed transfer.
3. Use All assets → Swap to quote and create a Trocador swap, then send the deposit from the wallet.
4. Optional: configure Tor and Mullvad routing under Connection settings.

See GUIDE.md for the complete walkthrough.

Releases are produced automatically: when the version in CMakeLists.txt has no matching v* tag on main, the release workflow builds, tests, tags and publishes artifacts with checksums.

• Automated: unit, integration and UI suites run in CI (signer, security controls, core transaction vectors, market data, Electrum, wallet profiles, UI). Historical results and their scope are recorded in TESTING.md.
• Manual mainnet check: sending and receiving were verified by the maintainers on Litecoin and Solana, each with a balance above US$50.
• Not verified: the Trocador integration (the endpoints were implemented without access to the provider's browser-gated documentation and have not been exercised with a live key) and the Windows build path.
• Not performed: an external security audit, a fuzzing campaign, formal verification, and hardware-wallet integration.

• Monero synchronization through public nodes over Tor can time out. XMR send/receive readiness is not established in this snapshot.
• Remote nodes and public APIs learn your addresses and IP address, and may fail or return false data.
• Process protections do not defend against root, a compromised kernel, physical memory capture, or same-user malware (keyloggers, clipboard replacement, replaced binaries).
• Windows builds have weaker isolation than Linux builds (see above).

Do not include a password, wallet file, secret key or recovery material in a bug report.

Released under the MIT License. Third-party components retain their own licenses; see THIRD_PARTY.md.