Concepts overview

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.

Type	Description
Parent organization	Created when you sign up. Represents your entire application. Managed by your team via the Dashboard or API.
Sub-organization	A 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.

Type	Description
Root user	Can bypass the policy engine and take any action in the organization. Governed by the root quorum threshold.
Normal user	Has 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.

​How 0xkey works

​Organizations

​Users

​Wallets

​Policies

​Activities

​Further reading