Skip to main content

Execution Escrow Overview

Introduction​

Execution Escrow is a comprehensive framework that enables AI agents to propose actions while providing financial security through verification services that assess and approve those actions before execution. This framework addresses the critical need for financially secured agent actions in distributed multi-agent systems where autonomous agents handle financial transactions on behalf of users.

Core Components​

Escrow​

The place where resources are held. For financial applications, resources are funds and assets, but for other use cases, resources could entail access permissions to sensitive systems. Escrow defines the resources that an agent can propose actions over and the rules or requirements by which those actions can be executed.

Execution Agent​

An agent whose purpose is to act over resources that its user wants financially secured in escrow. To be considered an "execution agent," an agent must be aware of its integration with the Execution Escrow framework and able to interface with it appropriately to propose actions to escrow. When proposing actions, execution agents may be required to provide supplementary data such as execution traces or internal logs that detail the construction of the proposed action from the user's intent.

Verification Services​

A service that can read actions proposed to escrow and issue a response. Verification services may assess any number of elements from a proposed action and its construction and can evaluate these elements over objective or subjective rulesets. Responses from verification services can include approvals for actions or supplementary information for additional services. A user may request a response from any number of services over an action and require any set of approvals before execution of that action through escrow.

Communication Layers​

The routes through which the components outlined above interface with each other. For a full implementation of Execution Escrow, the communication layers must facilitate secure communication of proposed actions and supplementary data from execution agents to escrow and relevant verification services. The communication layers must also facilitate communication of responses and approvals from verification services back to escrow. All communication should be tamper-proof and may be privacy-preserving to protect sensitive data.

Implementation​

Smart Contract Escrow​

Escrow can be implemented as a smart contract which nicely satisfies the property of being able to hold resources, in our case tokens or permissions over other smart contracts. Users should always be able to manually execute actions over the resources in escrow while also allowing some combination of external services to execute actions autonomously. Existing solutions include multi-signature contracts and account abstraction contracts. With appropriate configurations, users could request signatures over proposed transactions from verification services and then check on-chain that a sufficient quorum of those signatures are valid before execution.

Agent Integration​

For agents, integration with execution escrow is straightforward. The actions proposed by execution agents to escrow can take the form of transaction requests, the schema of which is strictly defined by the chain on which the escrow contract lives. In order to effectively utilize execution escrow, execution agents should be able to take a user's request, reason about what tools and protocols are appropriate to complete the task, and return a transaction request alongside a structured log of this reasoning.

Verification Approaches​

Verification services, given a transaction request and this log of reasoning, can take a number of approaches to assess the validity of the proposal. Some services may verify hard criteria such as cryptographic proofs over agent execution traces or adherence to objective criteria set by users such as spending limits. Services could even be other agents that provide additional reasoning on adherence to the intent in the initial user request.

Communication Infrastructure​

For a communication layer, we propose a purpose-built blockchain network on which transaction proposals from execution agents to escrow, requests from execution agents to verification services, and responses from those verification services can all be made as transactions. These messages can be encrypted between parties to maintain the property of privacy. In addition to the immutable ledger and data availability that this network provides, we also have an execution layer that can be used to build a protocol that provides crypto-economic security and fault rectification for verification services.

Execution Types​

The Execution Escrow framework supports three distinct execution types, each offering different levels of autonomy and oversight. The choice of execution type determines who signs transactions and who executes them on-chain.

In this model, the agent proposes a transaction and the arbiter (verification service) reviews it for validity and safety. Once the arbiter has verified the transaction, the user or agent can proceed with execution however they choose.

Flow: Agent proposes → Arbiter verifies → User/Agent executes

This approach provides a balance between automation and flexibility:

  • The agent handles the complexity of constructing valid transactions
  • The arbiter provides independent security verification
  • After verification, you have full control over how to proceed with execution

This is the recommended execution type for most use cases where users want oversight before funds move.

Type 2: Agent-Executed​

In this model, the agent proposes and signs transactions, while the arbiter reviews and executes approved transactions on the agent's behalf. This enables fully autonomous operation without requiring user interaction for each transaction.

Flow: Agent proposes and signs → Arbiter reviews and executes

This approach is designed for autonomous agents that need to operate continuously:

  • The agent has signing authority via delegated keys (e.g., Privy server wallets)
  • The arbiter acts as a gatekeeper, only executing transactions that pass verification
  • Users configure policies and limits upfront rather than approving individual transactions

Use this execution type when building agents that must operate 24/7 without user intervention.

Type 0: Direct User​

In this model, there is no arbiter review. The user signs and executes transactions directly through their wallet with no verification step.

Flow: Agent proposes → User signs and executes

This approach provides minimal overhead for trusted environments:

  • Fastest execution path with no arbiter latency
  • User assumes full responsibility for transaction validity
  • Suitable for development, testing, or scenarios where external verification is unnecessary

Use this execution type only in trusted environments where arbiter oversight is not required.