Executor

Demo

About

Autonomous agents are beginning to hold assets, earn revenue, make payments, and enter into economic relationships. But when an agent stops operating, there is no standard way to resolve what it leaves behind. Executor is a programmable resolution protocol for autonomous economic agents. Before operating, an agent can commit to a resolution plan that defines what should happen if it becomes inactive or unable to continue operating. When predefined failure conditions are met, Executor transitions the agent into a deterministic resolution process. The protocol can freeze further activity, account for assets and obligations, process pending settlements, collect available receivables, and distribute assets according to predefined priority rules. Executor separates an agent's execution process from its economic state. A running agent may fail, but assets, obligations, pending transactions, and contractual relationships can still require resolution. We are exploring a missing primitive for the emerging agent economy: what happens when autonomous software can no longer fulfill its economic responsibilities? Executor makes that outcome programmable, transparent, and deterministic.

How it's made

ExecutorRegistry is a Solidity state machine on Sepolia (0x2946B46c2EB5Ec53 2093877223Ef043b13729e39), built with Foundry. Agent identity is keccak256 of the label; a plan is locked at registration and the four authorities are checked to be distinct. getPaymentDestination(bytes32) is a pure view over state — cheap enough to sit in any payment path. ENS is what makes the redirect invisible to the payer. We deployed ExecutorResolver against the ENSv2 beta PermissionedRegistry on Sepolia, using the new role model: ROLE_SET_RESOLVER and ROLE_SET_RESOLVER_ADMIN. The resolver answers addr() by calling straight into the registry, so the name resolves to the treasury or the estate depending on live on-chain state, with no record update and no key held by anyone. bindNode is one-way and deliberately so — once a name is bound to an agent, nobody can quietly point it somewhere else. ENSv2's per-role permissions are what let us hand out resolver control without handing out the name. Hedera carries the money. The agent pays for model calls over x402 v2 through the Blocky402 facilitator on Hedera testnet. Our DynamicPayTo hook resolves the 402 challenge's payTo field at request time out of the registry, so the paywall charges 0.01 HBAR (1,000,000 tinybars) and settles it to whichever address the agent's liveness currently dictates. Hedera's fixed, sub-cent fees are the reason this works: destination-switching per request is only sane when the settlement cost doesn't dominate the payment. The Graph is the dashboard's only data source — there is no RPC fallback anywhere in the app, which we consider the honest test of a subgraph. Subgraph v0.1.2 indexes registrations, heartbeats, state transitions, plan approvals and plan executions, and uses dynamic data source templates with DataSourceContext so each agent's estate contract gets indexed from the block it's created,without a hardcoded address list. PlanApproved and PlanExecuted are joined by planHash, which is how the UI shows approval and execution as one story. The frontend is Next.js 14 App Router with viem and ISR, deployed on Vercel. Registration is a real wallet transaction in the browser; the demo video signs it with MetaMask on camera rather than scripting it. The hacky bit worth admitting: making the agent flippable inside a single recording take. We register with a 30-second heartbeat interval and a 15-second grace period, which means the agent becomes eligible for administration 45 seconds later — inside the same video. Getting that reliable meant reading eligibility from the chain's own block.timestamp with a safety margin rather than from the recorder's wall clock, because the two disagree by enough to cause TooEarly() reverts.