Policy Engine

Overview

The Okto Policy Engine is a core component designed to offer robust security and risk management capabilities for all participants in the Okto ecosystem. By setting predefined rules, the engine controls how transactions are processed, protecting users while providing flexibility for clients and wallet providers.

This system revolves around three key entities:

• Wallet Provider (WP): The entity managing the underlying wallet infrastructure (e.g., Okto AA, Okto EOA, or potentially future third-party providers). (learn more about Wallet Providers)
• Client (Application): The application or dApp that integrates with Okto, onboarding users (e.g., Stan, ChainCode).
• User: The end-user interacting with the Client's application.

Policies are applied hierarchically, ensuring that the user always has the final say over the limits applied to their transactions within a specific client application. This gives the perfect balance between self-custody and delegated access.

Current Policies

Currently, the primary policy implemented and enforced by the Okto Policy Engine is:

• Per-Transaction Value Limit: Sets a maximum USD value allowed for a single transaction.

(Future Scope: Okto plans to introduce more granular policies, such as daily/weekly/monthly transaction value limits, limits based on transaction types, etc.)

Policy Hierarchy and Control

Okto employs a clear priority order for applying policy limits. The most specific setting (User) always overrides broader settings (Client, Wallet Provider).

1. User Level Settings:

• Priority: Highest.
• Control: Users can define specific policy limits for each client application they use. For example, a user might set a $5 limit for Client A and a $60 limit for Client B.
• Precedence: If a user sets a limit for a specific client, this limit always takes precedence, regardless of the limits set by the Client or the Wallet Provider.

2. Client (Application) Level Settings:

• Priority: Medium.
• Control: Clients can request specific default policy limits for their application, overriding the Wallet Provider's defaults. For example, Client A might request a $40 limit.
• Approval: These client-specific limits must be reviewed and approved by the Wallet Provider.
• Precedence: The Client's limit applies to all its users unless a specific user sets their own overriding limit for that client.

3. Wallet Provider (WP) Level Settings:

• Priority: Lowest (Default).
• Control: The Wallet Provider sets the base default policies applicable to all clients operating under it. For example, the WP might set a default $10 limit.
• Precedence: This default limit applies only if neither the Client nor the User has set a more specific overriding limit.

In summary, the enforcement hierarchy is:

User Limit > Client Limit > Wallet Provider Limit

Example:

• Wallet Provider Default Limit = $10
• Client A sets an approved limit = $40
• User 1 sets a limit for Client A = $5
• User 2 sets no specific limit for Client A.

Result:

• For User 1 interacting with Client A, the enforced limit is $5.
• For User 2 interacting with Client A, the enforced limit is $40 (the Client's limit).
• If Client A had not set a specific limit, User 2's limit would be $10 (the WP default).

Policy Enforcement Mechanism

When a user initiates a transaction via a Client application:

1. Limit Check: The Okto system determines the applicable per-transaction limit by checking the hierarchy (User > Client > WP).
2. Transaction Validation:
   • If the transaction value is within the applicable limit, it proceeds to the next steps.
   • If the transaction value exceeds the applicable limit, the transaction is initially blocked.
3. User Prompt on Exceeding Limit:
   • The user is presented with a notification screen within the client app (rendered securely by Okto) informing them that the transaction exceeds their set limit.
   • The screen displays the requested amount and the current limit.
   • The user is given options, such as:
     • Approve This Transaction: Allows the single, specific transaction to proceed, overriding the limit just for this instance.
     • Enter Lower Amount/Cancel: Allows the user to modify or cancel the transaction.
     • Update Limit: In some flows, the user might be offered the option to permanently increase their limit for that specific client.

If the user approves the transaction (e.g., via a one-time override) or modifies it to be within limits, Okto's backend may then proceed to enforce it. Else, the transaction is reverted.