Sub-accounts, Controllers and Agents

One identity, many pockets: sub-accounts with their own budgets, protocol controllers bounded to one route, bounded allowances for bots and agents — never your keys.

Last updated 2026-09-04 · maintained in the Final Wiki

Live on all five mainnets and both test networks.

#Sub-accounts

A sub-account is a separate pocket under your Final Identity: its own address, owned by exactly one wallet, for a protocol, a purpose or a person. It is a custody route, not a second wallet — the wallet executes through it, your recovery covers it, and it is created, funded and closed by intents you sign like any other.

Isolation is the point. What a sub-account holds is all it can lose. Its own scope — a time window, a native spend cap on a rolling window, an optional allowlist of targets and functions, and per-token budgets — is set by you and applies to every path into it.
A sub-account can pay its own fees. An intent may name a sub-account as its fee source; the fee then comes out of that pocket's budget, so a trading pocket funded in one token settles its own gas from that token and nothing leaks into the wallet root.
Two kinds. Unbound: general-purpose isolation. Controller-bound: the sub-account is bound to a controller contract, a protocol's policy, and execution through it is checked against that policy as well.

#Controllers

A controller is a protocol's policy contract, bound to one sub-account. The wallet knows no protocol and treats every controller as untrusted, generic and bounded:

Blast radius is one metered route. The wallet root is never controller-bound. A buggy or malicious controller can spend at most what you budgeted into that one sub-account — never the wallet, never another sub-account, never a token outside the budget.
The lane fails closed. A freshly created sub-account has an unbounded scope; a controller cannot act through it until you have set budgets. No budget, no controller action.
Scope sits above policy. Your scope binds the controller lane exactly as it binds your own; a controller neither replaces nor bypasses it.
Policy changes need your acceptance. A controller cannot change what a sub-account will do unilaterally; a one-way policy lock exists for protocols that need an irrevocable binding.
Exit is yours. An escape — queue, wait the policy's delay, finalise — unbinds a controller with no cooperation from it, under every scope state. Using the sub-account again while an escape is queued cancels the escape, so wind a position down first.

Integrators: the recognition views, the interfaces and the shape of a controller that deserves a budget are on Protocol integration.

#Agents: a bounded allowance for a program

An agent is any program that acts for you — a trading bot, an automation, an AI agent — under a grant you sign. The grant is enforced by a chain-global module of the wallet, and it never gives the agent your keys or your authority:

What it may call. An allowlist of targets and functions, with per-token caps on a tumbling window (or for the grant's lifetime), a limit on how many dispatches per window, and an expiry.
Which pockets. Either the wallet root or a named set of sub-accounts (up to sixteen). An agent may be allowed to create its own sub-accounts, which join its allowlist automatically; or not.
All or nothing. A grant may require that the agent's intents execute only inside atomic bundles, so a multi-step plan never settles halfway.
Approvals denied by default. Token approvals grant a claim that outlives the grant and cannot be metered at dispatch, so an agent may not grant them unless you allow it — and then the approved amount counts against its cap.
Authority is structurally out of reach. Ownership, recovery configuration, post-quantum keys and module administration are denied to every agent, allowlist or not; an agent can never widen, extend or revoke a grant, its own or anyone else's.
One signature, three checks. Every agent intent passes the agent grant, then the account's scope, then — on a controller-bound sub-account — the controller's policy. Each can refuse on its own; a mistake in one layer never escalates past the others.
You end it. Revoke one agent, revoke all in one action, or uninstall the module — the hardest stop. Remaining budget per token is readable at any time, so a wallet or a dashboard can show "so much left in this agent's allowance".

#What this is for

A trading agent on a sub-account funded in one stablecoin, paying its own fees from the same budget, allowed exactly the venues and functions you listed, capped per day, expiring in thirty days.
A protocol with a dedicated, policy-bound sub-account per user, whose rules the user accepted and can leave.
A person or a team with separate pockets for separate purposes under one identity, each with its own budget and window.

#Status

Live on Ethereum, Optimism, Base, Arbitrum and Polygon and on the test networks since the September rotation. The wallet's module surface follows the ERC-7579 module-management dialect; execution runs only through the Final Gateway's intent rail, never through account-abstraction user operations.