Wallet Security & Architecture
How RelAI protects your wallet private keys using envelope encryption, Azure Key Vault, and defense-in-depth security practices.
Wallet Creation
When a user signs into RelAI for the first time using email, social login, or passkey, custodial wallets are automatically generated for both Solana and EVM networks. The entire key generation and encryption process happens server-side with multiple layers of protection.
Key Takeaway
The wallet private key is never stored in plaintext. It is encrypted with a random per-wallet Data Encryption Key (DEK), and the DEK itself is encrypted by Azure Key Vault. Even with full database access, an attacker cannot decrypt wallet keys without Key Vault access.
Security Measures
Envelope Encryption
RelAI uses envelope encryption — the same pattern used by AWS, Google Cloud, and Azure for protecting sensitive data. Instead of encrypting data directly with a master key, we use a two-layer approach:
Data Encryption Key (DEK)
- - Random 256-bit key generated per wallet
- - Used to encrypt the wallet private key (AES-256-GCM)
- - Never stored in plaintext — wrapped by KEK
- - Zeroed from memory immediately after use
Key Encryption Key (KEK)
- - RSA-2048 key stored in Azure Key Vault
- - Used to wrap/unwrap DEKs via Key Vault API
- - Never leaves Key Vault — all operations happen inside the HSM
- - Access controlled by Azure Managed Identity
Azure Key Vault Integration
Azure Key Vault provides hardware-backed key storage and cryptographic operations. The master encryption key (KEK) is stored inside the Key Vault and never exported.
HSM-backed keys — The KEK is protected by FIPS 140-2 Level 2 validated hardware security modules.
Managed Identity authentication — No API keys or credentials stored for Key Vault access. Azure App Service authenticates automatically via Managed Identity.
Audit logging — Every wrap/unwrap operation is logged in Azure Monitor for security auditing.
Key rotation — KEK can be rotated in Key Vault without re-encrypting existing wallets (new version used for new wallets).
Key Hierarchy
| Layer | Key | Storage | Purpose |
|---|---|---|---|
| L1 | KEK (RSA-2048) | Azure Key Vault (HSM) | Wraps/unwraps DEKs |
| L2 | DEK (AES-256) | Stored wrapped (encrypted by KEK) | Encrypts wallet private keys |
| L3 | Wallet Private Key | Stored encrypted (AES-256-GCM) | Signs blockchain transactions |
Wallet Types
Custodial Wallets
Custodial wallets are created for users who sign in with email, social login, or passkey. Each user gets separate Solana and EVM wallets. These wallets are scoped to the user — only the authenticated owner can access or operate their wallet.
User A
Solana Wallet 0x...001
EVM Wallet 0x...002
User B
Solana Wallet 0x...004
EVM Wallet 0x...005
User C
Solana Wallet 0x...007
EVM Wallet 0x...008
- Each user has isolated wallets — no cross-user access is possible.
- Wallet operations require authenticated user session.
- Users can export their private keys at any time (requires 2FA verification).
- Users can link multiple authentication methods to the same account.
Buyer Proxy Wallets (Metered API Access)
Buyer Proxy wallets are custodial wallets created for the Metered API Access feature. They allow developers to pay for x402 APIs using a simple API key, without managing crypto wallets directly. These wallets use the same envelope encryption as custodial wallets.
Encrypted at rest — Private keys are encrypted with AES-256-GCM + envelope encryption via Key Vault. Never stored in plaintext.
Decrypted only on demand — Keys are decrypted in memory only when signing a transaction, then immediately discarded.
Export requires 2FA — Exporting private keys requires email code or passkey verification.
Spending limits — Per-transaction and periodic (daily/weekly/monthly) spending limits can be configured.
Authentication & 2FA
All sensitive wallet operations (signing, export, withdrawal) require authenticated sessions. Additionally, high-risk operations require two-factor authentication.
Email 2FA
A one-time 6-digit code is sent to the user's registered email address. Valid for 10 minutes with a maximum of 5 attempts. Used for private key export and critical account operations.
Passkey 2FA (WebAuthn)
Hardware-backed authentication using FIDO2/WebAuthn. The strongest form of 2FA — resistant to phishing, replay attacks, and credential theft. Supported on all modern devices (Touch ID, Face ID, Windows Hello, YubiKey).
Operations requiring 2FA
| Operation | Auth Required | 2FA Required |
|---|---|---|
| View wallet balance | Session / API Key | No |
| Sign x402 payment | Session / API Key | No |
| Withdraw USDC | Session | No |
| Export private key | Session | Yes (email or passkey) |
| Delete wallet / account | Session | Yes (email or passkey) |
Recoverability
Users can export their private keys at any time. This ensures users always have full control over their assets.
Wallet recovery — Users can recover access to their wallets by signing in with any linked authentication method (email, social, passkey).
Private key export — Users can export their Solana private key (JSON array format for Phantom/Solflare) and EVM private key (hex format for MetaMask) at any time via the dashboard. Requires 2FA.
Multiple auth methods — Users can link multiple authentication providers (Google, GitHub, email, passkey) to the same account. If one method is lost, others can be used to regain access.
Important — RelAI operators do not have direct access to user private keys. Keys are encrypted with envelope encryption and can only be decrypted through the Key Vault infrastructure. There is no "admin backdoor" to access user keys.
Security & Privacy
Encryption Standards
TLS Encryption — All communications between clients and RelAI servers are encrypted with TLS. Private keys are never sent over the network in plaintext.
AES-256-GCM — Wallet private keys are encrypted at rest using AES-256-GCM with authenticated encryption (integrity verification via auth tag).
RSA-OAEP-256 — DEKs are wrapped using RSA-OAEP with SHA-256 via Azure Key Vault.
Per-wallet randomness — Each wallet has its own random IV and random DEK. Compromising one wallet's DEK does not affect any other wallet.
GDPR & CCPA
RelAI is committed to data privacy and complies with GDPR and CCPA frameworks. User data is deleted upon request within the required timeframes (30 days for GDPR, 45 days for CCPA). Wallet private keys are permanently destroyed when a user deletes their account.