With Turnkey you can create multi-user accounts with flexible co-ownership controls. This primitive enables you to establish delegated access to a user’s wallet, reducing or removing the need for them to manually approve each action. You can provide a smoother user experience while ensuring that end-users maintain full control over their wallets.
Can I create policies on behalf of a user without their explicit approval?
When does the user 'approve' a delegated access setup?
After a limit order is filled, how can I remove/null a policy programmatically?
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?
What are best practices for storing and rotating Delegate Access API keys?
How do I scope a delegated access policy to reduce signing risk?
Can I dynamically add policies per limit order without user friction?
What are common implementation patterns among Turnkey clients using Delegated Access?
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?
eth.tx.data[...]
) and enforce conditions like: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).