THE PROGRAMMABLE KEY PROTOCOL

Your keys.
Your rules.
Across chains.

PairKey turns a Solana program, Solana account, passkey or OIDC identity into programmable signing authority. 2 independent TEE signers enforce each exact approval and produce signatures across chains.

Explore the protocol Try it yourself

Developer preview · Explore the architecture & availability →

AUTHORITY / FOUR SOURCES 01

◇ Your authorityProgram · account · passkey · OIDC →

INDEPENDENT TEE / A Share A Checks authorization

INDEPENDENT TEE / B Share B Checks authorization

✓ One valid signatureNo complete key assembled. 2 OF 2

MULTICHAIN BY DESIGN.
FIVE CHAINS. ONE AUTHORITY.

Solana FROST Ed25519

EVM DKLS23 ECDSA

Zcash FROST RedPallas

NEAR FROST Ed25519

Bitcoin FROST secp256k1 · BIP-340

01 / HOW PAIRKEY WORKS

One authority.
Many addresses.

Start with who can authorize. Derive keys for where you want to go. Call PairKey when you need a signature.

01
SOURCE
Choose the authority.
Each request proves that its source approved the exact message and key.
- Solana program
- Solana account
- Passkey
- OAuth / OIDC
One authorization model →
02
DERIVE
Create many addresses.
Use a different path for each account. Derive distinct public keys for chain-specific addresses.
Your authority + derivation path
- Solana01 · 02 · …
- EVM01 · 02 · …
- Bitcoin01 · 02 · …
- NEAR01 · 02 · …
- Zcash01 · 02 · …
03
SIGN
Request a signature.
Call PairKey. Two independent TEE signers check the exact approval and current rules, then sign together.

TEE signer A
TEE signer B
One verifiable signature

The full private key never exists.
Follow a live signature →

02 / THE PROTOCOL

Put the rules
next to the key.

Your chosen source proves each request. Optional Solana policy and program logic add rules. Both signers check permission before your application receives a verifiable signature.

Make permission programmable.

Approve exact requests from an account, passkey or OIDC identity. Add persistent rules, or let a Solana program evaluate logic and commit decisions that consume state.

2 independent TEE signers.

Two separate shares. Two independent authorization checks. PairKey’s architecture requires both signers to participate in every signature.

Use the signature where you need it.

FROST Ed25519, DKLS23 ECDSA, FROST RedPallas, and FROST secp256k1 connect one authorization model to multiple signing schemes.

THE DESIGN PRINCIPLE

The full private key
never exists.

JOINT OUTPUTOne valid signature.

Created separately. Held independently. Used together. Each signer checks your rules and signs with its own share. Only the signing contributions combine.

The shares stay with the signers.
The signature goes to your application.
Explore the security model →

03 / TWO WAYS TO AUTHORIZE

Your rules.
Two approval paths.

OFF-CHAIN SIGNING PATH

No per-message
approval transaction.

A wallet, passkey or OIDC proof authorizes exact bytes. For immutable programs, each signer can evaluate pairkey_approve through read-only Solana simulation. Both signers check current permission without broadcasting an approval transaction.

ILLUSTRATIVE PROGRAM LOGIC · READ-ONLY

pairkey_approve(input):
  authenticate caller + exact request
  return policy.allows(input), input.digest

Keep signing within your rules. Policy and fee details →

01
Authorize the requestIdentity · key · exact message · expiry
02
Check and sign off-chainBoth signers verify current permission
03
Receive a signatureVerify it and use it in your application

EXACT-OPERATION APPROVAL

Commit a program
decision on-chain.

Use pairkey_approve_commit when your Solana program must consume an allowance or update state. It records the exact approval in the same transaction; both signers check the finalized decision before signing.

ILLUSTRATIVE PROGRAM LOGIC · STATE-CHANGING

pairkey_approve_commit(call):
  authenticate caller + exact request
  require policy.allows(call)
  require allowance > 0
  decrement allowance
  record approval via gateway CPI

Make signing authority part of your application’s on-chain logic. Explore program integration →

01
Approve exact bytesYour program commits its decision through CPI
02
Verify finalized authorityBoth signers independently check Solana
03
Receive a verified signatureDestination execution is a separate step

04 / WHAT YOU CAN BUILD

One PairKey.
Many use cases.

Choose who can authorize, define what they can sign, and derive the addresses your application needs. The same PairKey signing flow serves different products.

01 / PROGRAM-CONTROLLED

Keys for your program.

Put application rules in a Solana program. Authorize an exact request by evaluating current state, or commit a decision that consumes an allowance.

SOURCE · SOLANA PROGRAM

02 / MULTICHAIN ACCOUNTS

One wallet. Many chains.

Use a Solana wallet to approve a message, then derive signing keys for Solana, EVM, Bitcoin, NEAR and Zcash from that authority.

SOURCE · SOLANA ACCOUNT

03 / KEYLESS ACCESS

Sign in. Then sign.

Start with a passkey or OAuth / OIDC identity. A bound, short-lived request key turns familiar sign-in into exact-message authorization.

SOURCE · PASSKEY OR OAUTH / OIDC

04 / AGENTIC WALLETS

Let agents propose. Rules decide.

Agentic wallets can request signatures while your program checks the caller, scope and current state for every action.

SOURCE · PROGRAM-GOVERNED

05 / COMPARE THE MODELS

Same destination.
Different control.

Compare who sets the rules, who holds signing power, and what each request waits for.

PairKey protocol architecture compared with the documented authorization and signing models of NEAR Chain Signatures and Turnkey.
Control & signing	PairKey Programmable key protocol	NEAR Chain Signatures	Turnkey
Authority	Programs, accounts, passkeys & OIDC Exact proof + optional Solana rules	NEAR accounts & contracts	API credentials & policy engine
Signing model	2 independent TEE signers Separate shares. No full private key.	Threshold MPC node network	Key inside a Signer enclave Separate policy enclaves
Request path	Off-chain exact approval Or state-consuming program commit	NEAR contract → MPC → response	Off-chain API + policy checks
Latency	Off-chain Checks + signingOn-chain Solana finality + checks + signing	NEAR inclusion + MPC + contract response	50–100 ms signing* Vendor-reported
Authorization fees	No Solana approval tx for off-chain requests Policy edits and program commits pay fees	NEAR gas for contract requests	Service pricing No control-chain gas

Latency describes the request path; *Turnkey’s figure is vendor-reported →, not a head-to-head benchmark. Destination-chain fees are separate. Sources, scope & measurement notes →

06 / BUILD WITH PAIRKEY

Your authority.
A wider reach.

Choose a source, derive a key and authorize one exact message. PairKey returns a signature and signer receipts your application can verify. No namespace registration transaction is needed.

Choose a quickstart

HOSTED V2 FLOW 01—04


// Conceptual flow · see runnable Rust example
01  Choose source + obtain namespace metadata
02  Derive key + prepare exact message
03  Approve + submit one signing job
04  Verify signature + recover if interrupted

Rust SDK Polling + SSE Verified receipts

Programmable
from the start.

What makes a key programmable?

The source proves each exact request. Optional Solana policy restricts destinations, paths and payloads; a program can add application logic or consume state through an on-chain commit. Both signers independently enforce the current decision.

Why two independent signers?

PairKey distributes signing power across two parties. Each holds a separate key share and independently checks authorization. The protocol produces a signature without assembling the full private key. Read the security model →

How does multichain signing work?

One authorization model connects to FROST Ed25519, DKLS23 ECDSA, FROST RedPallas, and FROST secp256k1. Your application uses the resulting signature with its destination network. Explore chain integrations →

What can I build with PairKey?

Start with a Solana account or program. Integrate passkeys or OIDC identities with bound ephemeral keys. Add persistent rules or state-consuming program approvals when your workflow needs them. Choose your source →

START WITH THE PROTOCOL

Make signing
part of your application.

Start building

Your keys.Your rules. Across chains.

One authority.Many addresses.

Choose the authority.

Create many addresses.

Request a signature.

Put the rulesnext to the key.

Make permission programmable.

2 independent TEE signers.

Use the signature where you need it.

The full private key never exists.

Your rules.Two approval paths.

No per-messageapproval transaction.

Commit a programdecision on-chain.

One PairKey.Many use cases.