Key management with Privy

Every HEVN account is rooted in a self-custodial Privy embedded wallet that only the user’s email identity can unlock.

HEVN uses Privy as the key-management layer. When a user signs in with their email (or the Google account behind it), Privy provisions a self-custodial embedded wallet — a standard Ethereum EOA whose private key belongs to the user and to nobody else.

This wallet is the root of ownership for everything in HEVN: it is the initial owner — and the only one, until the user adds others — of the user’s Base Smart Wallet, where the actual balance lives.

How the key is protected

Privy never stores a complete private key anywhere. Keys are protected with a combination of Shamir’s Secret Sharing and trusted execution environments (TEEs):

1. The key is sharded

   The private key is split into multiple shares using Shamir’s Secret Sharing. Individual shares are useless on their own — no single share (and no single party) can reconstruct the key.

2. Shares are distributed across isolated systems

   Shares are end-to-end encrypted and stored across fully segregated services: the user’s authenticated session/device and Privy’s infrastructure.

3. The key is reassembled only inside a TEE

   Signing happens inside a hardware-isolated trusted execution environment. The reconstituted key exists only transiently, in an environment with built-in attestation, and only after the user has authenticated.

Under this model, neither Privy nor HEVN ever sees the user’s key: HEVN cannot sign on the user’s behalf, and a compromise of HEVN’s servers would expose no key material at all. The key-layer guarantees rest on Privy’s TEE infrastructure and attestations — this is a deliberate, explicit trust assumption on Privy as a specialized key-management provider (see their security page), not on HEVN.

Read more in Privy’s own materials:

• Embedded wallets overview
• How Privy embedded wallets work
• Privy security

Exit hatch: key export

The wallet is not locked into HEVN or Privy. At any time, the user can export the private key through Privy’s export flow — the key is assembled on a separate origin, so neither HEVN nor Privy sees it during export — and load it into any standard wallet (MetaMask, Rabby, etc.). Since that key is the owner of the Base smart wallet, the exported key controls the funds with ordinary Ethereum tooling, with no dependency on HEVN or Privy being online or in business.

Export is an emergency exit, not a security practice. An exported key forfeits every protection this page describes — sharding, TEE isolation, MFA — and becomes a plaintext secret you must guard yourself. For day-to-day resilience, use MFA with multiple factors and a trusted full-access co-owner instead.

Deterministic: one email, one wallet

The Privy wallet is bound to the user’s email identity, and the mapping is stable and deterministic — the same email always resolves to the same wallet. Wallet activation and email → address resolution run through a dedicated, change-frozen microservice that signs its responses, so the resolution logic cannot be silently altered by a backend deploy. Combined with the deterministic smart-wallet address derived from it, this means HEVN can know the final wallet address of any email in advance, which is what makes sending money by email non-custodial and safe.

Access = email access

The only way to unlock the wallet is to complete Privy authentication as the owner of the email:

• Email OTP — prove you can read the inbox.
• Google OAuth — prove you control the Google account, if that’s how you signed up.

There is no password stored by HEVN that could be leaked, and no seed phrase that could be phished. The flip side is that account recovery is deliberately impossible for anyone but you: Privy cannot restore access or change login methods on request. Link a second login method and, if you trust someone with the account, add them as a full-access co-owner — see the loss scenarios. Conversely, this makes the email account the crown jewel — see Security model for recommended protections (2FA, hardware keys).

Wallet MFA: passkeys and OTP

On top of email authentication, Privy supports multi-factor authentication for the wallet itself. Once a user enrolls, every action that touches the wallet’s private key requires a second factor — signing messages, sending transactions, exporting the key, and recovering the wallet on a new device.

Every key operation prompts for the second factor — here, a passkey verified with Face ID / Touch ID

Supported factors:

Factor	How it works	Notes
Passkeys (recommended)	Biometric / device-bound verification (Face ID, Touch ID, hardware security key) via WebAuthn	Phishing-resistant, bound to your device, independent of carriers and third-party apps
Authenticator app (TOTP)	6-digit time-based code from Google Authenticator, Authy, 1Password, etc.	Works offline; secret never travels over a network
SMS	6-digit code sent to a registered phone number	Weakest of the three — vulnerable to SIM swapping; prefer passkeys or TOTP

Factors are enrolled and managed in the app’s Security settings — passkeys, 2FA methods, and the list of signed-in devices:

Security settings: enrolled passkeys, additional 2FA methods, and active devices

Why enable it

MFA directly addresses the main residual risk in the security model: a compromised email account. Without MFA, whoever controls your inbox can unlock the wallet. With MFA enrolled, email access alone is not enough — the attacker would also need your passkey device or authenticator secret to produce a single signature.

MFA is enforced by Privy’s key layer, inside the same TEE flow that reassembles key shares — not by HEVN. HEVN cannot bypass, disable, or intercept the second factor.

HEVN authentication (getting a platform JWT) and wallet access are separate things. A leaked HEVN JWT lets an attacker read and edit platform metadata, but it can never produce a wallet signature and therefore can never move funds. See Authentication.