CUVEX
ARCHITECTURE
Cuvex’s architecture is designed to minimize the attack surface, eliminate external dependencies, and ensure cryptographic sovereignty.
Rather than layering security on top of a traditional model, the system is redesigned from the ground up so that entire classes of attacks are impossible by construction.
ARCHITECTURAL PRINCIPLES
Cuvex’s architecture is based on the following non-negotiable principles:
• Strict separation of responsibilities
• Elimination of backends and centralized services
• Offline signing as the only mode of operation
• Mandatory human verification
• Privacy ensured by technical impossibility, not by promises
SYSTEM COMPONENTS
1. Watch-Only App
Role: transaction monitoring and preparation
• Does not manage private keys
• Does not sign transactions
• It can operate using a self-hosted node or user-selected endpoints via TOR.
• Generates unsigned PSBT transactions
The app is not trusted and it does not need to be.
2. Cuvex Device (Personal HSM)
Role: sovereign encryption and signing
• Processes secrets exclusively in volatile memory
• Does not persist private keys
• Executes all critical operations fully offline
• Requires physical interaction and visual verification
The device has no knowledge of balances, identities, or network context.
3. External Cryptograms (NFC / USB-C)
Role: secret separation
• Seed phrases are stored encrypted (AES-256 GCM)
• The cryptogram never reveals the secret without the device
• The device never persists the secret after use
This eliminates single points of failure.
CHAIN OF TRUST
(SECURE BOOT)
Cuvex implements an explicit root of trust through a secure boot process:
-
The bootloader resides in a protected region of the device.
-
Before installing or executing any firmware, the bootloader cryptographically verifies the RSA signature of the binary.
-
Only authenticated and untampered firmware is allowed to run.
-
Any unsigned or modified firmware is rejected.
This mechanism prevents:
-
Installation of malicious firmware
-
Downgrade attacks
-
Tampering during manufacturing or distribution
DATA FLOW (HIGH LEVEL OVERVIEW)
-
The user monitors their wallet in the Watch-Only app.
-
The app generates an unsigned PSBT transaction.
-
The PSBT is transferred to the Cuvex device.
-
The encrypted cryptogram is provided via NFC or USB-C.
-
The device decrypts the secret in volatile memory and signs the transaction.
-
The signature is returned without exposing the secret.
At no point:
-
Does the secret touch a network-connected system
-
Does the device access the network
-
Are centralized metadata generated
RELATIONSHIP TO THE THREAT MODEL
Each component exists to mitigate specific threats:
• Watch-Only → malware and compromised applications
• Air gap and PSBT → remote attacks
• External cryptograms → physical attacks
• Secure Boot → supply chain attacks
The architecture is a direct materialization of the threat model.
WHY THIS ARCHITECTURE MATTERS?
Security in self-custody does not depend on exotic algorithms, but on:
-
Isolation
-
Separation
-
Verifiability
Cuvex adopts an architecture-first approach, where cryptography reinforces the design rather than replacing it.