DOCS / OVERVIEW

Build with programmable keys.

Programmable keys on multiple chains. Choose an authority, define its rules, and request a signature from two independent signers.

Start with your Solana account or your program. PairKey runs the signing infrastructure. The passkey guide and Google preview cover bound-identity approvals.

Source → derive → sign

A source identifies who controls a namespace. A Solana account authorizes an exact request with a wallet message signature. A program authenticates its caller and applies application rules. Passkey and OIDC identities authenticate a bound, short-lived Ed25519 key that signs the request. Solana stores optional persistent policy and program state.

Choose a destination and derivation path to obtain a public key. Both signers independently authenticate the request and enforce current rules before participating in threshold signing. The protocol uses separate key shares; it never assembles the full private key. The target deployment uses two independent TEEs; current development workers report their hardware status explicitly.

Four sources, two approval paths

Source	Exact request proof	Program or policy rules	Current availability
Solana account	Wallet `signMessage`	Optional Solana policy; wallet-authorized edits	Live devnet message signing
Solana program	Authenticated caller plus program decision	`pairkey_approve` read-only evaluation, or `pairkey_approve_commit` for state changes	On-chain example live; read-only evaluation locally tested
Passkey	WebAuthn assertion binds an ephemeral Ed25519 request signer	Optional Solana policy; native P-256 authorized edits	Browser demo and SDK; live signing acceptance pending
OIDC	Issuer ID token binds an ephemeral Ed25519 request signer	Optional Solana policy; dual-signer attested edits	SDK and local tests; Google browser preview

Every request needs its source proof even when no saved policy exists. Ordinary off-chain approval does not broadcast a Solana approval transaction. Only the program commit path consumes application state; policy edits remain separate transactions. See Policy & rules for costs and update authority.

The concepts you need

Namespace: Public derivation context binding the authority, deployment and signer set. The v2 flow establishes metadata without a registration transaction.
Derivation path: A numeric path selecting a key inside the namespace and destination context. Paths are not independent compromise domains.
Exact approval: Authentication bound to the namespace, exact payload, destination/path, request ID, policy revision and expiry.
Policy: Optional, versioned rules stored in a reusable Solana account and enforced by both signers.
Off-chain approval: Request authentication and rule checks without broadcasting an authorization transaction. Programs use authenticated RPC simulation.
On-chain approval: A program transaction that changes application state and records its exact approval atomically through gateway CPI.
Job: A durable signing attempt with a stable ID and recoverable public results. It is not a destination transaction.

Choose your next step

Choose an authority →Start with an account or program, then explore bound identities.Explore the demo →Follow authority, two signers and a verifiable signature.Define policy →Manage account, passkey, OIDC and program rules.Choose a destination →Understand each message format and signing scheme.

Development status

V2 supports message signing for Solana, EVM, Zcash, NEAR and Bitcoin. Sessions are deferred for this flow. These guides require the coordinated v2 deployment; the client refuses incompatible endpoints. Read Security & status for hardware, identity-provider, recovery and transaction-integration boundaries.