Why Wallet Security Matters
When you use RelAI's custodial wallets or Metered API Access, we generate and store wallet private keys on your behalf. This is a huge responsibility — and we take it seriously.
This post explains exactly how we protect your keys, what technologies we use, and why we believe our approach is robust against modern threats.
Envelope Encryption: The Industry Standard
RelAI uses envelope encryption — the same pattern used by AWS, Google Cloud, and Microsoft Azure to protect sensitive data at scale.
Instead of encrypting your private key directly with a single master key, we use a two-layer approach:
- A random Data Encryption Key (DEK) is generated for each wallet — 256 bits of cryptographic randomness
- Your private key is encrypted with this DEK using AES-256-GCM (authenticated encryption with integrity verification)
- The DEK itself is encrypted (wrapped) by a Key Encryption Key (KEK) stored in Azure Key Vault
- Only the encrypted DEK and encrypted private key are stored in the database — the plaintext DEK is zeroed from memory immediately
Azure Key Vault: Hardware-Backed Key Protection
The master key (KEK) that wraps all DEKs lives inside Azure Key Vault — a cloud HSM (Hardware Security Module) service validated to FIPS 140-2 Level 2.
Key facts about our Key Vault setup:
- The KEK never leaves Key Vault — all wrap/unwrap operations happen inside the HSM
- Managed Identity authentication — no API keys or credentials are stored for Key Vault access. Our App Service authenticates automatically
- Audit logging — every key operation is logged in Azure Monitor
- Key rotation — the KEK can be rotated without re-encrypting existing wallets
Per-Wallet Isolation
Every wallet gets its own:
- Random DEK — compromising one wallet's key doesn't affect any other wallet
- Random IV (Initialization Vector) — prevents pattern analysis across encrypted keys
- Authenticated encryption (GCM auth tag) — any tampering with the ciphertext is detected
Key Hierarchy
| Layer | Key | Where It Lives | 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 |
Two-Factor Authentication for Sensitive Operations
Exporting your private key requires 2FA verification — either:
- Email code — a one-time 6-digit code sent to your registered email
- Passkey (WebAuthn) — hardware-backed FIDO2 authentication (Touch ID, Face ID, YubiKey)
What About Metered API Access Wallets?
Buyer Proxy wallets (used for Metered API Access) use the exact same envelope encryption as custodial wallets. Your API key's wallet private keys are:
- Encrypted with a per-wallet random DEK
- DEK wrapped by Azure Key Vault
- Decrypted only in memory when signing a payment, then immediately discarded
- Exportable only with 2FA verification
Summary
- AES-256-GCM encryption for all wallet private keys
- Envelope encryption with per-wallet random DEKs
- Azure Key Vault (HSM) protects the master key — it never leaves the hardware
- Per-wallet isolation — no shared secrets
- 2FA required for private key export
- Zero plaintext storage — keys exist in plaintext only briefly in memory during signing
Have questions about our security architecture? Reach out to us on X/Twitter.
