Embedded Wallets

03 / EMBEDDED WALLETS

Embedded Wallets let you ship crypto wallets natively inside your product — without exposing private keys to your application or your team. Each user gets an isolated sub-organization with its own key material, authentication methods, and policies.

Why embedded wallets?

Non-custodial by default — users control their own credentials; you control the authentication surface
No key exposure — private keys are generated and stored inside TEE enclaves; they never leave
Flexible authentication — passkeys, email OTP, SMS OTP, email magic-link, Google OIDC
Policy-gated signing — apply per-user CEL rules with EVM, Solana, EIP-712, and Tron transaction contexts before any transaction is signed
EVM-, Solana-, and Tron-first parsing — EVM, Solana, and Tron have in-enclave transaction parsing and policy contexts; other chains support address derivation + raw signing only

Custodial vs. non-custodial

0xkey supports both models through the same sub-organization primitive:

Model	How it works
Custodial	Your backend holds an API key that can sign on behalf of the user. User may not hold credentials at all.
Non-custodial	The user holds their own passkey or OTP credential. Your backend cannot sign without user approval.
Hybrid	User holds a passkey; your backend holds an API key. Policies determine which actions each credential can authorize.

Architecture

Each embedded wallet is backed by a sub-organization:

Parent org (your application)
 └── Sub-org (one per user)
      ├── User (end user's credential: passkey, OTP, OAuth)
      ├── User (optional: your backend API key)
      ├── Wallet → Account (0x… / sol1…)
      └── Policies

The parent org cannot modify sub-org contents — only the sub-org’s own credentialed users can take action, subject to its policies.

Current capabilities

Feature	Status
Passkey / WebAuthn authentication	Supported
Email OTP / SMS OTP	Supported / Partial (SMS API only; no provider wired)
Email magic-link (`email_auth`)	Supported
Google OAuth (OIDC)	Supported
Apple / Facebook / Discord / X OAuth	Partial (depends on `oauthProviders` and deployment)
Read-write sessions + HPKE credential bundles	Supported
Read-only sessions	Partial (API supported; TypeScript SDKs do not expose helpers — see Sessions)
EVM wallet creation, signing, in-enclave parsing, EIP-712	Supported
Solana signing + in-enclave parsing	Supported (broadcast still Coming soon)
Tron signing + in-enclave parsing + policy contexts	Partial
Address derivation for Cosmos, Sei, Sui, Aptos, BTC, Doge, Stellar, TON, XRP	Supported (raw signing only; no in-enclave parsing yet)
Policy engine (CEL) with EVM / Solana / EIP-712 / Tron contexts	Supported
Pre-built TypeScript / React components (`@0xkey-io/react-wallet-kit`)	Supported
`get_policy_evaluations` history	Partial (best-effort persistence after a Policy ruling)
Wallet import / export end-to-end product flows	Partial (HPKE primitives wired; Dashboard flows in progress)
On-chain broadcast (`eth_send_*`, `sol_send_transaction`)	Coming soon (raw is mocked, high-level send errors today)
Gas sponsorship / ERC-4337 smart accounts	Coming soon
Fiat on-ramp	Coming soon
Webhooks	Coming soon (no RPC in `public_api.proto` yet)
Non-EVM transaction parsing & policy contexts (beyond Tron)	Coming soon

See the Roadmap for the authoritative status matrix.

Get started

Embedded Wallet quickstart

Set up sub-org creation and auth in minutes

Authentication overview

Passkeys, OTP, OAuth, email, and sessions

Sub-organization auth

How sub-org authentication flows work

Wallet Kit setup

Install and configure @0xkey-io/react-wallet-kit

​Why embedded wallets?

​Custodial vs. non-custodial

​Architecture

​Current capabilities

​Get started