Skip to main content
Phantom’s Key Management System (KMS) lets apps use KMS-backed wallets without storing wallet private keys on the client device.

​
What is KMS?

KMS allows users to securely generate, store, and access wallet keys inside trusted enclaves (TEE). When a KMS-backed wallet is selected, the client requests signatures from KMS rather than signing locally on-device. From a client’s point of view:
  • A KMS account is a local reference to a KMS-managed wallet (not a locally stored seed).
  • App-level signing APIs can stay consistent. What changes is where the signature is produced (in KMS).

​
Core components

​
Backend services

  • KMS API: Receives stamped RPC requests from clients.
  • Policy engine enclave: Authenticates requests and authorizes operations (policies, scopes, rate limits).
  • Signer enclave: Holds encrypted wallet seed material and produces signatures.
  • Certifier enclave: Issues certificates and attests to configurations.

​
Data model (what KMS manages)

  • Organization: The primary unit of access control. Contains users, authenticators, and configuration.
  • Wallet: Encrypted seed material plus derived chain addresses.
  • Policy: Rules linking organizations/users to wallets with scoped permissions and limits.
  • User: Roles and authenticators. Users may be time-limited (ephemeral), depending on the integration.

​
How signing works

When a KMS-backed wallet is selected, signing is performed by KMS. The client sends a signing request to KMS, KMS enforces policy, and KMS returns a signature.
  1. The client sends a signing request to the KMS API.
  2. The policy engine enclave authenticates and authorizes the request, enforcing policies (for example, spending limits).
  3. If allowed, the signer enclave produces a signature.
  4. KMS returns a signature to the client. The signed transaction is then submitted to the network.
Each request to KMS is cryptographically signed with an authenticator key held client-side (where it’s stored depends on the integration). KMS checks that signature and independently enforces policy before it will sign.

​
The authenticator

KMS uses an authenticator to confirm that KMS signing requests are coming from the user. The authenticator is a cryptographic identifier key that’s separate from wallet keys. The authenticator is used to stamp KMS requests so the client can request signatures without exposing wallet private keys.

​
How apps authenticate to KMS

​
Embedded wallet

Use embedded wallet mode when your app integrates directly with the SDK. What happens:
  • Your app integrates with the embedded SDK directly.
  • The SDK generates a non-extractable key (for example, via WebCrypto / an IndexedDB stamper).
  • The SDK completes OAuth via Phantom Connect. The session returns organization and wallet identifiers.
  • The embedded SDK holds a restricted authenticator and uses it to stamp KMS requests.

​
MCP server

In MCP server integrations, the user signs in through Phantom Connect. The MCP server stores the resulting session and uses a stamper key to sign requests to KMS. KMS validates each signed request, enforces policy, and then signs and submits.

​
Where you’ll see KMS in Phantom

  • Mobile: KMS accounts can appear alongside local accounts. Signatures are produced by KMS.
  • Browser extension: Adds origin validation and consent screen. KMS accounts can be created or discovered depending on the flow.
  • Use the embedded wallet flow. Signing routes through KMS using the embedded authenticator model.
  • MCP server: Agent wallets use a Connect sign-in and a stamper key to stamp KMS requests. KMS validates each request, enforces policy, and then signs and submits.

​
Glossary

  • Authenticator: A cryptographic identifier key that is separate from wallet keys and is used to stamp KMS requests.
  • Embedded wallet: A no-extension integration where the app uses the embedded SDK, creates a device-protected authenticator, and stamps KMS requests client-side.
  • Enclave/TEE: Trusted environment used to protect key operations.
  • Organization: Access-control container for users, authenticators, and policies.
  • Policy engine: Enclave that authorizes operations and enforces policies/limits.
  • Stamper key: A client-side key used to sign (stamp) requests to Phantom services, including KMS.