Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.0xkey.io/llms.txt

Use this file to discover all available pages before exploring further.

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, and EIP-712 transaction contexts before any transaction is signed
  • EVM- and Solana-first — both chains 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:
ModelHow it works
CustodialYour backend holds an API key that can sign on behalf of the user. User may not hold credentials at all.
Non-custodialThe user holds their own passkey or OTP credential. Your backend cannot sign without user approval.
HybridUser 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

FeatureStatus
Passkey / WebAuthn authenticationSupported
Email OTP / SMS OTPSupported / Partial (SMS API only; no provider wired)
Email magic-link (email_auth)Supported
Google OAuth (OIDC)Supported
Apple / Facebook / Discord / X OAuthPartial (depends on oauthProviders and deployment)
Read-write / read-only sessions + HPKE credential bundlesSupported
EVM wallet creation, signing, in-enclave parsing, EIP-712Supported
Solana signing + in-enclave parsingSupported (broadcast still Coming soon)
Address derivation for Cosmos, Sei, Tron, Sui, Aptos, BTC, Doge, Stellar, TON, XRPSupported (raw signing only, no in-enclave parsing)
Policy engine (CEL) with EVM / Solana / EIP-712 contextsSupported
Pre-built TypeScript / React components (@0xkey-io/react-wallet-kit)Supported
get_policy_evaluations historyPartial (best-effort persistence after a Policy ruling)
Wallet import / export end-to-end product flowsPartial (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 accountsComing soon
Fiat on-rampComing soon
WebhooksComing soon (no RPC in public_api.proto yet)
Non-EVM transaction parsing & policy contextsComing 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