Overview
Delegated access works by creating a specialized business-controlled user within each end-user’s sub-organization that has carefully scoped permissions to perform only specific actions, such as signing transactions to designated addresses. This can enable your backend to do things like:- Automate onchain actions such as staking, redemptions, or limit orders
- Sign transactions to whitelisted addresses without user involvement
- Perform scheduled operations (e.g. payouts, rebalances)
- Respond to specific onchain events programmatically
Implementation flow
You can implement Delegated Access for an embedded wallet in two ways, depending on whether the setup runs from the frontend (recommended) or the backend.1. Frontend (recommended)
This approach uses the end-user’s authenticated session to configure delegated access directly within their sub-organization. The flow is:- Create an API-only user (Delegated User) with a P-256 API key authenticator that you control. This key can then be used server-side to sign transactions on the user’s behalf.
- Define policies for the Delegated User that strictly limit which transactions they are allowed to sign.
- There’s no possibility of elevated (root-level) access for the delegated user.
- You can’t assume the delegated user or its policies already exist. Before referencing it, you’ll need to call
fetchOrCreateP256ApiKeyUser
andfetchOrCreatePolicies
to ensure the user and permissions are properly set up.
2. Backend
If you prefer to configure delegated access entirely server-side, the flow differs because the end-user in the embedded wallet model does not hold an API key. In this case, you must:- Create the sub-organization with two root users: the end-user and your Delegated User (API key authenticator).
- Use the delegated access API key to add policies explicitly granting the DA user the limited actions you want them to perform.
- Update the root quorum so that only the end-user remains a root user.
Caution ⚠️
When the delegated access setup is performed from the backend, your service (not the end-user) initiates and approves the sub-organization creation, delegated user addition, and root quorum updates. This means the delegated user is temporarily added to the root quorum without direct end-user consent. If any of these operations fail — particularly the quorum update — the delegated user may unintentionally retain root privileges, effectively gaining unrestricted access to the user’s wallet. If you adopt this approach, implement strict validation to confirm that:- The root quorum was successfully updated; and
- The delegated user no longer retains unintended permissions once setup completes.
- Guarantees that the delegated user exists and can perform the required actions without additional setup.
- Risk of elevated access if the delegated user isn’t successfully removed as a root user, it may retain unintended control.
- Since all actions are service-initiated, there’s no explicit end-user approval in this flow.
Frequently Asked Questions
Policy Design and Creation
Can I create policies on behalf of a user without their explicit approval?
Can I create policies on behalf of a user without their explicit approval?
When does the user 'approve' a delegated access setup?
When does the user 'approve' a delegated access setup?
When performed server-side, the setup happens without direct user involvement. This approach is generally used only in enterprise or custodial environments, where your backend manages sub-organizations and delegated users on behalf of end-users.
For typical end-user applications, the client-side setup is the recommended and more secure approach.
After a limit order is filled, how can I remove/null a policy programmatically?
After a limit order is filled, how can I remove/null a policy programmatically?
Security & Risk Management
If a delegated API key is leaked, does that allow someone to act on behalf of the user?
If a delegated API key is leaked, does that allow someone to act on behalf of the user?
Is this the same risk as having a master delegate account?
Is this the same risk as having a master delegate account?
What are best practices for storing and rotating Delegate Access API keys?
What are best practices for storing and rotating Delegate Access API keys?
- Using short-lived keys whenever viable
- Rotating API keys regurarly
- Monitoring the usage
- Secure storage (e.g. in HSMs or vaults)
Best Practices
How do I scope a delegated access policy to reduce signing risk?
How do I scope a delegated access policy to reduce signing risk?
- Recipient address restrictions (ie allowlisting addresses)
- Contract method selectors
- Transaction structure invariants
- Blockhash constraints (on Solana)
Can I dynamically add policies per limit order without user friction?
Can I dynamically add policies per limit order without user friction?
What are common implementation patterns among Turnkey clients using Delegated Access?
What are common implementation patterns among Turnkey clients using Delegated Access?
- Using broad policies with business-controlled API keys
- Using **fine-grained policies, **scoped to predictable transaction shapes
- Using delegated access to implement limit orders, automation flows, or advanced trading logic (e.g. perps, TWAPs)
- Ensuring strong operational security (e.g. tight scoping & expiring keys) is increasingly common
EVM and SVM-Specific Strategies
Are time-bound transactions supported?
Are time-bound transactions supported?
solana.tx.recent_blockhash
, which restricts a transaction’s validity to a ~60–90 second window. Not ideal for delayed executions (e.g. limit orders), but useful for immediate, single-use actions.For EVM transactions, can I enforce token-specific or contract-specific limits?
For EVM transactions, can I enforce token-specific or contract-specific limits?
eth.tx.data[...]
) and enforce conditions like:Is it safe to whitelist routers (e.g. Jupiter) in delegated access policies?
Is it safe to whitelist routers (e.g. Jupiter) in delegated access policies?
Suggestion: Only allow DA keys to interact with contracts you fully trust or control. Limit scope as much as possible (e.g., to specific instructions, amounts, or recipients).