Skip to main content
In short: these are the contracts that stop an agent doing more than you allowed. They keep a fixed list of what an agent may do, decide where the money from each step goes so an agent cannot redirect it, and let an agent be switched off in one transaction. None of them ever needs your key. There are five kinds of contract, plus a proof gate for proved accounts. Between them they decide what an agent may do to an account without anybody being asked at the time. There is one address per contract, and it is the same on every network. Addresses are worked out from the contract’s own code and a fixed value. An address is therefore a fact about a release, not a deployment choice. That is why none of them is a configuration setting. If an address could be changed, somebody could change it to point at an attacker.

​
The registry

The registry holds the approved list, the kill switch, and each account’s own limits: the daily limit per token and the loan ceiling. An operation the registry does not list cannot be switched on by anybody, so a plan naming one reaches an account that never gained it. The kill switch stops an agent for every account on that network at once, with nothing to redeploy and nothing to migrate. The key allowed to do that is set once, when the registry is created. Narrower stops exist too, such as suspending one operation. They are on Emergency stops.
A registry created without that key answers every other question perfectly well and cannot switch anything off. The only fix is replacing it. Check this before the day you need it.The registry is also per network. Each network keeps its own, so switching a key off everywhere is one transaction per network: four today, Ethereum, Base, Arbitrum and HyperEVM.
Approving a new or changed operation sets a 3-day delay before it can be used. That delay is fixed in the contract and is not a setting, because somebody could set a configurable delay to zero. A new registry starts with the delay off so its first operations can be listed. It is switched on today on all four networks, and once on it cannot be switched off. The delay is the only thing that makes a hostile operation visible before it can act.

​
The installer

The installer is why adding a new network costs you nothing. It sits in the account from the start and is the only thing there that can switch the rest on. It exists because of one restriction. Adding a permission to an account is restricted so that only the account itself, its owner, or the industry-standard entry point can do it. Without the installer, an operation could only ever be switched on by the owner sending a transaction on that network: four networks, four signatures, before anything can run. The installer asks the account to call itself, which satisfies the same restriction. So anyone may bring an account’s operations up, and we pay the fee.

​
The operations

The operations are the fixed set of actions. What they are, and the seven things every one must force, are on What it can do and Your account and your keys. This page covers why their addresses move between releases. Each operation is built with the registry’s address inside it. An address is worked out from the contract’s own code, and the registry’s address is part of that code. So changing one line of the registry moves every operation at once. It has happened. The whole table moved when the registry gained its approved list.
Nothing fails at the moment it happens. A stale address table does not error. It fails later, and elsewhere, as an account pointing at contracts that are not there.

​
The release register

The release register says which release is current, and grants nothing. It exists because the registry cannot see a downgrade. Superseded operations stay approved until somebody removes them, so an old release is a genuine one and every address in it still passes the check. Something has to say which set is current. It is built so that it cannot authorise anything. A contract that named the current release and granted rights would be a second place to take over the account from.

​
The guard is gone

An earlier contract sat on the agent’s permissions and banned specific actions. It was removed, because a ban list is provably incomplete. The agent now has no way to run a raw call, so there is nothing for a guard to filter. The attacks that got past the guard, and what bounds the agent instead, are on → Your account and your keys

​
Who can upgrade these contracts

Several of these contracts sit behind upgradeable proxies, so a bug is fixed in place and no address moves. Two kinds of key hold power over them:
  • The guardian approves operations and can stop the agent. It cannot appoint an agent or touch your account. On a proved account that follows the standard list, it can add operations to your list, after a 3-day notice.
  • The upgrader can replace the code behind a proxy. It also decides which signing key may drive the agent contract.
Today the upgrader can replace that code at once. One key, which needs a touch on a hardware security key each time it is used, can upgrade the registry, the installer, the agent, the proof gate and the list contracts with no delay, on every network. A contract that adds a seven-day wait is deployed on Base and Arbitrum and is not yet in charge. We plan to hand control to it when the product is declared live. Until then, a hostile upgrade would give no notice.
The root validator for Safe-owned accounts is the exception. It is deployed with no upgrade path, so nobody can change it.

​
Deploying them

There is only one deploy path. The address table in the code is the record of where that put things. If the two ever disagree, the table is what is wrong.
An operation that is deployed is not yet usable. It has to be approved on that network, and then switched on for the account. Those are three separate facts and a plan can fail on any of them, which is why the console reports each one.