ERC-8199: Sandboxed Smart Wallet

ERCs
1

Sandboxed Smart Wallet for secure Agentic automation.

Abstract

Automation through Agents in a wallet is an industry path, and many approaches have been discussed and proposed for secure delegation of access/assets to agents. Including session keys, TEE based policy engine, shared account key. Which all exists some degree of trust and tradeoff.

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.

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.

TEE based policy engine, although 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 owner being able to maintain 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.

  1. 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 for these concerns.
  1. 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.
  2. 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.
  3. 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.
  4. 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.

image
image3124Ă—1956 293 KB

image 1
image 13674Ă—2162 361 KB

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:

/// @title Sandboxed Smart Wallet Standard
interface SandboxedSmartWallet {

		struct Agent {
				address agentKey;
				uint256 validityTimestamp; // pack( uint128 validAfter + uint128 validUntil )
				Check[] checkers;
		}
		
		struct Check {
				address to;
				bytes termsData;
		}

		event AgentRegistered(Agent calldata);
		event AgentRemoved(Agent calldata);
		
		/// @dev registers an agent to the smart wallet.
		/// only callable by the owner.
		/// The function should emit the AgentRegistered() event upon successful registration of agent.
		/// If same agentKey Agent that is active, is being registered, the function should revert.
		///
		/// @param agents the Agents to be registered.
		function registerAgents(Agent[] calldata agents) external;
		
		/// @dev removes an agent from the smart wallet.
		/// only callable by the owner.
		/// The function should emit the AgentRemoved() event upon successful removal of agent.
		/// Even if the agentKey's time validity has expired or is not valid yet,
		/// if the agentKey exists, the function should not revert.
		///
		/// @param agents the Agents to be removed.
		function removeAgents(Agent[] calldata agents) external;
		
		/// @dev returns the list of agents.
		/// It returns the full list of agents, regardless of its time validity.
		///
		/// @return agents the Agent registered to this smart wallet.
		function getAgents() external view returns (Agent[] memory);
		
		/// @dev returns if the given agentKey is active. (registered + within validity time window)
		/// @return bool the value indicating if the agent is active.
		function isAgentActive(address agentKey) external view returns (bool);
		
		struct Execution {
				address target;
				uint256 value;
				bytes data;
		}
		
		/// @dev invokes agentic execution. relayable by any entity.
		/// The time validity of execution signature, if any, can be encoded together with the signature parameter.
		/// The signature parameter includes the signature from the agentKey.
		///
		/// @param execs the struct array of executions to be performed.
		/// @param signature the signature of signed executions
		function invokeAgentExec(Execution[] calldata execs, bytes calldata signature) external;
		
		/// @dev returns the owner of the sandboxed smart wallet.
		/// The owner has access to perform arbitrary execution,
		/// including the complete asset withdrawal from the wallet.
		///
		/// @return address of the owner.
		function owner() external view returns (address);
		
		/// @notice only the address returned by the owner() can call this function.
		/// @dev The execution path for owner. The owner can withdraw assets,
		/// or perform arbitrary execution from this wallet.
		///
		/// @param execs the struct array of executions to be performed.
		function executeFromOwner(Execution[] calldata execs) external;
		
}

Contract MAY implement ERC-165.

The Checker smart contract MUST implement the following interface.

/// @title Checker. Pre/Post execution checker of SandboxedSmartWallet
interface Checker {

		/// @dev called before the execution. validates the execs based on the termsData.
		/// 
		/// @param execs the struct array of executions to be performed.
		/// @params termsData the calldata outlining the terms of validity.
		/// @return bool value indicating the success/failure of check.
		function preCheck(Execution[] calldata execs, bytes calldata termsData) external returns (bool);
		
		/// @dev called after the execution. validates the execs based on the termsData.
		///
		/// @param execs the struct array of executions to be performed.
		/// @params termsData the calldata outlining the terms of validity.
		/// @return bool value indicating the success/failure of check.
		function postCheck(Execution[] calldata execs, bytes calldata termsData) external returns (bool);
}

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 not make agentKey signature not 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

1 Like