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.

02 / CORE CONCEPTS
0xkey is built around a small set of composable primitives. Understanding them makes every integration decision straightforward.

​
How 0xkey works

Instead of directly managing private keys, wallets are accessed through authenticators — passkeys, API keys, or OAuth tokens. The enclave evaluates your policies before any signing operation proceeds. 
Organization
 ├── Users (with credentials: passkey, API key, OAuth)
 ├── Wallets (HD seed → multiple chain accounts)
 └── Policies (govern all activities)
      └── Sub-organizations (isolated, one per end user)
           ├── Users
           ├── Wallets
           └── Policies

​
Organizations

An organization is the top-level container for your application’s resources: users, wallets, and policies.
TypeDescription
Parent organizationCreated when you sign up. Represents your entire application. Managed by your team via the Dashboard or API.
Sub-organizationA fully isolated child organization. Typically represents one end user. The parent org has read access but cannot modify sub-org contents.
Sub-organizations are the foundation of 0xkey’s embedded wallet model — each user gets their own isolated key space.

​
Users

A user is a resource inside an organization that can submit activities using a valid credential.
TypeDescription
Root userCan bypass the policy engine and take any action in the organization. Governed by the root quorum threshold.
Normal userHas no permissions unless explicitly granted by a policy. Used for end users and backend service accounts.
Users authenticate with one or more credentials: API keys, passkeys, or OAuth tokens. Multiple credential types can be attached to a single user.

​
Wallets

A wallet in 0xkey is an HD seed phrase that can derive many chain accounts (addresses). The seed never leaves the enclave.
  • One wallet can hold accounts across multiple chains
  • Accounts are derived by addressFormat (e.g., ETHEREUM, SOLANA)
  • Signing requests reference a specific wallet account, not the seed directly

​
Policies

Policies govern all activities in an organization. Every signing operation, user creation, and resource modification is evaluated against the applicable policies before it proceeds.
  • Policies use a simple condition language (effect, consensus, condition)
  • Root users can bypass the policy engine when the root quorum threshold is met
  • Policies can target specific users, user tags, wallet accounts, or activity types
See Policy overview and the policy language reference.

​
Activities

An activity is any state-changing operation submitted to the 0xkey API — signing a transaction, creating a wallet, adding a user, etc.
  • Activities are submitted as HTTP POST requests to /public/v1/submit/*
  • Each activity goes through the policy engine before execution
  • The response includes an activity object with a status field (PENDING, COMPLETE, FAILED, etc.)
  • Some activities require additional approvals and enter a PENDING_CONSENSUS state
Read-only operations use /public/v1/query/* and do not go through the policy engine.

​
Further reading