> ## 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.

# Concepts overview

> Core building blocks of 0xkey: organizations, users, wallets, policies, and activities.

<div className="eyebrow">02 / CORE CONCEPTS</div>

0xkey is built around a small set of composable <em className="accent">primitives</em>. 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](/concepts/policies/overview) and the [policy language reference](/concepts/policies/language).

***

## 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

* [Organizations in depth](/concepts/organizations)
* [Sub-organizations](/concepts/sub-organizations)
* [Users and credentials](/concepts/users/introduction)
* [Wallets](/concepts/wallets)
* [Policies](/concepts/policies/overview)
* [API overview](/developer-reference/api-overview/intro)