Delegated actions

Okto lets you securely request "on-behalf-of" permissions from users for their embedded wallets. This is known as delegated actions. It allows your application or backend to perform certain wallet operations without requiring a user signature prompt each time, so long as it adheres to user-approved policies.

What are delegated actions?

Delegated actions empower your application to take pre-defined actions using a user's embedded wallet, with the user's explicit consent. This means your application can, for example, initiate transactions or sign messages on behalf of the user, within clearly defined boundaries and under secure conditions.

Understanding Delegated Intent Flow

The diagram below shows how delegated actions work within the Okto ecosystem:

Notice that in this flow, the user isn't directly involved in the transaction approval. Once the session is established and valid, the client app can make requests directly to the Okto chain without additional user input.

How to implement delegated actions

The implementation of delegated actions via API is identical to the regular API setup flow. When you authenticate a user via the API, you create a session that can be used for delegated actions.

Key Points:

• Authentication Process: Create session keys → Generate paymaster data → Build authentication payload → Call authenticate API to create a session.
• Store Session and Generate Auth Tokens: Save the session configuration (session private key, session public key, and userSWA) securely and use it to generate auth tokens for API calls
• Make API Calls: Use the auth tokens to perform operations on behalf of the user

How It Works

1. User Consent: The user delegates their embedded wallet to your application when they login and this consent can be revoked at any time by logging out.
2. Limited Scope: Delegation is governed by a policy engine that enforces limits (e.g., transaction count, spend limits) to protect the user.
3. Session-Based Security: The delegated actions are bound to the session keys, which have a limited lifetime (10 days by default).

Policy Enforcement

Okto's policy engine may enforce transaction thresholds—such as daily or total spend—beyond which users need to re-confirm.

Security Considerations

When implementing delegated actions, keep these security best practices in mind:

• Secure Storage: Store session keys securely. Never expose them in client-side code that could be accessed by malicious actors.
• Transparent Communication: Clearly inform users when your application will use delegated actions and what those actions entail.
• Regular Verification: Periodically check session validity before attempting delegated operations.

Example Usecases