Delegated Access
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.
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 common transactions (e.g., staking, redemptions)
- Sign transactions to whitelisted addresses without user involvement
- Perform scheduled operations
- Respond to specific onchain events programmatically
Implementation flow
Here’s how to implement delegated access for an embedded wallet setup:
- Create a sub-organization with two root users: The end user and your “Delegated User” with an API key authenticator that you control
- Enable the Delegated Account to take particular actions by setting policies explicitly allowing those specific actions
- Update the root quorum to ensure only the end-user retains root privileges
A simple example demonstrating the delegated acess setup can be found here.
Step-by-step implementation
Step 1: Create a sub-organization with two root users
-
Create your sub-organization with the two root users being:
- The end-user
- A user you control (we’ll call it the ‘Delegated Account’)
Step 2: Limit the permissions of the Delegated Account user via policies
-
Create a custom policy granting the Delegated Account specific permissions. You might grant that user permissions to:
- Sign any transaction
- Sign only transactions to a specific address
- Create new users in the sub-org
- Or any other activity you want to be able to take using your Delegated Account
Here’s one example, granting the Delegated Account only the permission to sign ethereum transactions to a specific receiver address:
Step 3: Remove the Delegated Account from the root quorum using the Delegated Account’s credentials:
After completing these steps, the sub-organization will have two users: the end-user (the only root-user) and the Delegated Account user, which only has the permissions granted earlier via policies and no longer retains root user privileges.
Delegated Access Code Example
Below is a code example outlining the implementation of the delegated access setup flow described above