Skip to main content
Some applications need different transaction policies depending on which party authorizes a transaction. For example, a restricted signer should only be allowed to send small transfers, while a full-access signer can send transactions of any size. Privy supports this through additional signers with override policies. Each signer added to a wallet can have its own policy, so the constraints applied to a transaction depend on which signer authorizes it.

​
How it works

  • Each wallet can have multiple additional signers (authorization keys or key quorums)
  • Each signer can have an override policy that defines what policies that signer is subject to
  • When a signer submits a transaction, Privy evaluates only that signer’s override policy — not the policies of other signers
  • If the transaction satisfies the signer’s policy, Privy signs it. Otherwise, Privy denies the request
This gives the same wallet different levels of access depending on which signer acts, without needing separate wallets.

​
Setup

At a high level:
1

Create policies

Define a policy for each access level (e.g., a restrictive policy and a permissive policy).
2

Create authorization keys

Create an authorization key (or key quorum) for each signer that needs access to the wallet.
3

Add signers with override policies

Add each signer to the wallet with its corresponding policy.
4

Route transactions through the appropriate signer

Your server selects which authorization key to sign with based on the context of the request.

​
1. Create policies

Define a policy for each signer. In this example, the restricted signer can only send small USDC transfers, while the full-access signer can send transactions to any address. Save the id from each policy response. These are needed when adding signers to the wallet.

Create a policy

Learn more about defining policies with rules and conditions.

​
2. Create authorization keys

Create a separate authorization key for each signer. Each key corresponds to a different party or service that needs wallet access.

Create authorization keys

Generate keypairs and register them in the Privy Dashboard or via the SDK.
Store each private key securely (e.g., in a secrets manager). In the examples below, these are referenced as restrictedSignerPrivateKey and fullAccessSignerPrivateKey.

​
3. Add signers with override policies

Add each authorization key as a signer on the wallet, attaching the appropriate override policy. The override policy scopes what that specific signer can authorize.

​
4. Route transactions through the appropriate signer

Your server selects which authorization key to use based on the request context. For example, an automated service signs with the restricted signer, while an admin endpoint signs with the full-access signer. If the transaction violates the signer’s override policy, Privy denies the request. Transactions do not fall back to another signer’s policy — Privy evaluates each signer independently.

​
Learn more

Additional signers

Add signers to wallets and manage their permissions.

Policies

Define rules that constrain which transactions are allowed.

Authorization keys

Create and manage server-controlled authorization keys.