PairKey Get started →

DOCS / QUICKSTART

Build with hosted signers.

Choose your authority, derive a key, approve an exact message and receive a verifiable signature from our hosted signers.

Choose your authority

Solana account →Live devnet · Connect a wallet and approve messages off-chain. No registration transaction.Solana program →Live on-chain example · Evaluate read-only rules or commit a state-consuming decision.Quickstart: Passkey →Browser demo and SDK · Bind a WebAuthn assertion to each exact request.Quickstart: OAuth/OIDC →Google browser preview · Approve each message with a bound ID token.

PairKey runs the signers

The new flow uses https://pairkey.com/api/v2. You do not run workers, a coordinator or a validator. Account approvals need wallet message signing, with no registration rent or per-request Solana transaction. Policy changes and program on-chain approvals are explicit Solana transactions.

One approval, one signing job

  1. Connect: obtain public namespace metadata for your authority; no namespace registration transaction.
  2. Derive: choose Solana, EVM, Zcash, NEAR or Bitcoin and a path.
  3. Approve: authenticate the exact request; apply any saved rules or program decision.
  4. Sign: both hosted signers independently authorize and participate.
  5. Verify: check the signature and both signer receipts.

Signing is asynchronous. These guides return message signatures; they do not broadcast destination transactions. Save the public recovery record before submission, and recover that same job after a timeout.

Optional rules, explicit updates

Per-message authentication is required even without a saved policy. Optional rules live in a reusable Solana account; each signer reads the current revision. Programs can also evaluate custom application logic. See Policy & rules. Sessions are deferred for v2.

Deployment and availability

The API configuration identifies the gateway, signer identities and example program. These v2 guides require the coordinated gateway, worker and hosted API release; the client stops if v2 is unavailable. The development deployment uses Solana devnet, Base Sepolia for EVM messages and Bitcoin testnet for Bitcoin messages. Hardware TEE attestation is not provided by the development workers. See service status.

For operating infrastructure, see local development and operator testnet setup.