ERC-8199: Sandboxed Smart Wallet

Abstract

---

Automation through Agents in a wallet is a widely being adopted, and many approaches have been discussed and proposed for secure delegation of access/assets to agents. Including session keys, Trusted Execution Environment (TEE) based policy engine, shared account key, in which some degree of trust and trade-offs exist.

This standard outlines the smart wallet specifically for agents of high frequency trading entities to operate in a completely sandboxed(detached) environment, while still enabling the owner to have granular control over the sandboxed smart wallet.

The sandbox is achieved through the complete detach of agent smart wallet from the owner wallet and only having the owner wallet persistently access to the agent smart wallet.

Motivation

---

Automation through an agentic infrastructure as a wallet is an inevitable flow of the industry. Although agents bring in a highly autonomous system with convenience, it is important that these adoptions should incorporate security mechanisms together.

Session key like architecture, although having the advantage of shared owner wallet, has limitations on the security postures unless imposed with an enforced whitelist mechanism that limits the access of the session key, which potentially limits the capability of what agent can perform.

A TEE based policy engine, although it comes with high convenience, relies fully on central trust.

Shared account key, despite the most intuitive and convenient solution, gives unlimited access to the wallet unless the user explicitly approves each operation, which then conflicts with the goal of autonomous automation through agents.

This standard proposes an interface for agents that operates in a sandboxed, detached environment from the owner account, while the owner maintains access to the sandbox smart wallet.

Key factors taken into consideration for the standard:

1. Complete sandboxed account for agents.

2. Owner account persistently having access to sandboxed wallet.

3. Time-gated & optional permission checks, enforceable.

4. Multi-agent sharing a sandboxed wallet.

5. Benefits exist when Agents also use smart wallet.

6. Complete sandboxed account for agents: The standard separates the execution environment of agents from the owner account. This removes the possibility of security breach or hallucination of AI agents from impacting the owner account, unintendedly. Also, session key, granular permission driven approach that shares the owner wallet inherently brings in permission evasion issues unless imposing whitelist driven approach. This sandboxed approach makes this standard free of these concerns.

7. Owner account persistently having access to sandboxed wallet: The relationship between owner account and sandboxed wallet is one-directional. The owner account has permission to withdraw assets, or remove the agent key from accessing the sandboxed wallet. While the sandboxed wallet does not possess any rights against the owner account.

8. Time-gated & optional permission checks, enforceable: Although the sandboxed account environment itself already gives limited boundary in execution, the standard imposes time-gated & optional permission checks, enforceable in each agentic execution, for policy or additional security measures.

9. Multi-agent sharing a sandboxed wallet: Multiple agents can share a single sandboxed wallet. Sharing the same asset, on-chain address reputation, transaction history. Based on the want of the user.

10. Benefits exist when Agents also use smart wallet:

    1. Gas Abstraction

       i. Agents also confronts the native gas requirement. Gas Abstraction by smart wallet will benefit agents in execution and portfolio management.

    2. On-Chain Conditional Execution & Sophisticated trade operations

       i. Conditional executions on-chain through checks and multi-layered sophisticated trade requires smart contract to batch, layer conditions of pre/post state. Smart Wallet can sufficiently assist in fulfilling these requirements.

    3. Parallel execution

       i. In high frequency trading environment, agents need to be able to execute multiple transactions in parallel. But managing a 1 dimension, linear nonce across multi-agent sharing a wallet, or for a single wallet as well for high frequency trading can be complex. This can be simplified with 2d nonce of smart wallet, or other custom mechanisms imposed by the smart wallet.

Specification

---

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

A Sandboxed Smart Wallet MUST implement the following interface:

Contracts MAY implement ERC-165.

The Checker smart contract MUST implement the following interface.

Rationale

---

1. The interface of SandboxedSmartWallet is kept with only the essentials for agentic operations. The additional capability, e.g., ERC-4337 based gas abstraction, etc is left untouched for the wallet developers to decide on their preference of the stack.
2. The initial bootstrapping process is to transfer the initial funds from Owner wallet to the SandboxedSmartWallet. Token approval model is not a recommended process to ensure that there is no logical or account level correlation that SandboxedSmartWallet can interfere or impact the Owner Wallet.
3. Time based validity window is introduced so Agents can have a limited time boundary that can access the user’s asset within the SandboxedSmartWallet.
4. Standard interface referencing ERC-173’s owner() is imposed for better compatibility with ownership based tooling/sdks.
5. Through the interface of executeFromOwner(), Owner Wallet, at any point in time can withdraw assets or perform arbitrary execution. Creating a one-directional relationship where only Owner Wallet can impact SandboxedSmartWallet and not vice versa.

Backwards Compatibility

---

TBD

Security Considerations

---

1. SandboxedSmartWallet should impose signature replay attack protection for the invoke of invokeAgentExec() signature to make agentKey signature non-replayable.
2. Agents should be strictly restricted from calling the SandboxedSmartWallet outside the validity window of validityTimestamp.
3. isAgentActive() should only return true if validityTimestamp is within current block.timestamp.
4. It is highly recommended to add time-boxed signature for invokeAgentExec().
5. For Checker’s termData composition, it is recommended to perform whitelist-style enforcement compared to blacklist-style enforcement for stronger enforcement checks.
6. executeFromOwner() is recommended to be always open for Owner Wallet to perform execution. The standard however does not enforce a certain behavior on this.
7. SandboxedSmartWallet can optionally impose ERC-173 or ERC-8023 based ownership mechanism for secure ownership management.

Copyright

---

Copyright and related rights waived via CC0.