The 0xkey Architecture

0xkey is organized around a narrow trusted path. Clients submit signed requests. The API boundary authenticates transport and routes requests, but cryptographic identity and authorization are evaluated inside the enclave boundary. Storage holds organization data and encrypted key material, but trusted components verify the integrity of that data before using it.

Publicly, this architecture can be understood without exposing every internal service. There is an API boundary, an orchestration layer, untrusted persistence, and a set of verifiable enclave applications responsible for policy, state integrity, signing, transaction parsing, and proof-producing external fetches.

Applications, embedded wallet frontends, backend systems, and agents interact with 0xkey through HTTP APIs and SDKs. Requests that mutate state or use signing resources are represented as activities. The orchestration layer gathers the relevant organization state, routes the activity through the trusted path, and persists the resulting signed state transitions.

The architecture intentionally keeps the public shape small. Details such as separate control-plane services, dashboard-specific gateways, deployment sidecars, and cluster routing are implementation choices. They are useful for operators, but the whitepaper-level security model is defined by which components can produce or verify evidence.

0xkey divides requests into read-only queries and signed activities. Queries can be answered from read models because they do not mutate organization state or use private key material. Activities represent critical operations: creating users, updating policy, creating wallets, importing or exporting key material, approving a request, or producing a signature.

An activity contains typed intent and one or more stamps from actors. A stamp is a signature over the request body from a credential known to the organization: passkey, API key, embedded authenticator, or another supported signing credential. The activity is not trusted because it arrived at the API. It becomes actionable only after the trusted path verifies identity, policy, state, and any required consensus.

The policy engine is the authorization brain of 0xkey. It verifies who signed the activity, evaluates organization policy, handles allow and deny semantics, and determines whether additional approval is required. Its output is a signed ruling that other trusted components consume.

Policies are designed to cover both human and machine workflows. They can describe ordinary access control, root quorum approvals, scoped agent permissions, transaction-specific restrictions, and higher-risk flows such as export or recovery. The same policy system can govern an administrator, a backend service, and an autonomous agent.

Organization data includes users, credentials, wallets, private key references, policies, tags, and other authorization-relevant state. Because this data is persisted outside the enclave boundary, it cannot be trusted merely because it was loaded from a database.

The notarization path converts organization state into signed evidence. A notarization binds the organization identifier, state digest, sequence, previous digest, and timestamp. Downstream components verify this evidence before accepting state as current. This protects against unauthorized edits, stale state, and rollback attacks by untrusted infrastructure.

The signer is responsible for the lifecycle of key material: generation, derivation, import, export, and producing signatures. It should not decide policy by itself. Instead, it consumes signed rulings and notarized organization state, then produces signed results that can be persisted or returned to the caller.

Transaction parsing complements signing. A raw transaction can encode more intent than a user interface or agent prompt reveals. Parser output gives the policy system structured transaction metadata: chain, target, value, method, program, account, or ABI/IDL-enriched fields. That lets 0xkey constrain what an agent or user can sign at the semantic level.

Some secure workflows need external data: OAuth token exchange, OIDC discovery, JWKS retrieval, compliance lists, price feeds, or other HTTPS endpoints. A normal server can fetch this data easily, but then trusted components must rely on the honesty of that server.

The 0xkey proof-producing fetch path moves external retrieval into the trusted boundary when the result affects security. The fetcher establishes TLS from inside the enclave, validates the remote server, and signs a digest or structured proof of the response. Other components can then consume external data without trusting the relay that transported it.