> ## Documentation Index
> Fetch the complete documentation index at: https://docs.useotto.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Your Safe, Your Authority

> Otto is converging onto a Safe smart account you own. Learn what sole ownership means, what Otto's unified activation delegates, and how revocation works.

Otto AI is converging onto a **user-owned smart account**: a Safe whose sole
owner is your wallet. Ownership and delegated automation are different facts,
so this page describes both.

<Note>
  **Where this stands today.** The Safe7579 account is rolling out in gated early
  access and is not yet the default for everyone. During the migration, live
  trade execution still runs on Otto's existing agent-custodial execution rail.
  The unified owner activation is available on the public arm surface for
  supported Base workflows; automatic EAL billing remains built but disabled.
</Note>

## What is a smart account?

A normal wallet (an EOA, such as MetaMask) is controlled directly by a private
key. A **smart account** is a wallet implemented as a contract. It still has an
owner, and it can also install modules and delegated permissions.

Otto's converged account uses [Safe](https://safe.global) with the ERC-7579
modular standard (internally, *Safe7579*). Your connected EOA or Dynamic
embedded wallet is the Safe's only owner.

## Ownership before activation

Before you activate Otto:

* **You are the sole owner.** There is no Otto co-owner or Otto owner key.
* **Otto has no session authority.** It cannot use the Safe until you install a
  permission.
* **The address is deterministic.** It is derived from your owner wallet.
* **Deployment relay is not account authority.** Otto can relay deployment and
  pay deployment gas without becoming an owner.

For email or social sign-ins, Dynamic holds the embedded-wallet key on your
behalf. An external wallet keeps that owner key under your direct control.

## What activation delegates

The current **ARM OTTO** action installs **two separate** Smart Sessions
permissions in one signature. They have **no runtime key in common**: each
permission has exactly one named operator, and the trading operator is the only
key with unrestricted authority.

**Permission 1 — trading (unrestricted):**

| Permission fact                | Current value                              |
| ------------------------------ | ------------------------------------------ |
| Safe owner                     | Your wallet remains the sole owner         |
| Runtime operator               | One named Otto trading signer address      |
| Threshold                      | 1 of 1 — only the trading operator may act |
| On-chain action scope          | Unrestricted generic Safe authority        |
| Spending cap                   | None in the on-chain permission            |
| Target / token / selector list | None in the on-chain permission            |
| Usage limit                    | None                                       |
| Expiry                         | None                                       |
| End condition                  | You revoke the permissions                 |

**Permission 2 — billing (bounded):**

| Permission fact       | Current value                                           |
| --------------------- | ------------------------------------------------------- |
| Runtime operator      | One named Otto billing signer address — a different key |
| Threshold             | 1 of 1 — only the billing operator may act              |
| On-chain action scope | `USDC.transfer` to Otto's billing address only          |
| Spending cap          | A per-charge cap and a cumulative total, both on-chain  |
| Usage limit           | A maximum number of collection operations               |
| Expiry                | Yes — the permission expires on its own                 |
| End condition         | Expiry, or you revoke the permissions                   |

The named Otto **trading** operator can therefore move Safe funds, approve
spenders, call contracts, or change Safe authority while the permission is
installed. The billing operator cannot: it holds no unrestricted permission on
this Safe, only bounded billing permissions.

The owner key never leaves your control, but sole ownership does not make the
armed trading authority narrow or per-action, and the billing permission's caps
are **not** a cap on what the trading permission can move.

Otto's application routes still validate authenticated intent, supported
markets, exact calldata, billing ledgers, payment destination, receipts, and
operational exposure limits. Those checks govern how Otto intends to use the
permission; they are not on-chain caps or expiry conditions on the permission
itself.

## Revocation and exit

**REVOKE AGENT ACCESS** removes both permissions, in one signature, and clears
known Otto allowances. Once finalized and reconciled, neither named runtime key
can use the permission it held.

Revocation is prospective. It does not reverse completed transfers, contract
calls, approvals outside the known cleanup set, or other durable Safe changes
that occurred while the permission was active. Review the activation text,
keep only the funds you intend the automated workflows to use in this Safe,
and revoke when you no longer want Otto to act.

Because your wallet remains the sole Safe owner, you can also perform
owner-authorized actions independently of Otto.

## How this differs from the existing execution path

|                               | **Converged Safe7579**                                                                                                                | **Existing execution Safe** |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- |
| Owner                         | Your EOA / embedded wallet                                                                                                            | An Otto-managed agent key   |
| Otto authority while disarmed | None                                                                                                                                  | Agent owner key can sign    |
| Otto authority while armed    | The named trading key has an unrestricted, non-expiring permission until revocation; the billing key has only a bounded, expiring one | Agent owner key can sign    |
| Status                        | Rolling out in gated early access                                                                                                     | Current live execution rail |

The converged model separates ownership from runtime automation and gives the
owner a direct revocation action. It does not claim that an armed Otto runtime
has only a capped trade lane.

## EAL automatic payment

The coming funded EAL path collects through the **bounded billing permission**
installed alongside the trading one — not through the unrestricted trading
permission. Otto fronts an approved service call, records the settled amount,
and the billing runtime reconciles that amount from the Safe to the pinned
payer, within the billing permission's on-chain caps and before its expiry.
Application exposure ceilings and exact ledger/receipt checks apply on top.

The trading permission is unaffected by this path and remains unrestricted and
non-expiring until revocation; the billing operator holds no unrestricted
permission on the Safe.

The funded EAL path is still disabled. Use
[BYO-x402](/account-and-settings/enterprise-agent-layer#byo-x402-live-today)
until its funded production proof and arming review are complete.

## Related

* [Empire Access Layer](/account-and-settings/enterprise-agent-layer) — live
  BYO-x402 and the disabled funded path
* [Your Wallet, Your Responsibility](/safety-and-security/wallet-security) —
  custody and delegated-authority models side by side
* [What's Live & What's Next](/introduction/roadmap) — current product status
* [Moving Funds Out](/account-and-settings/removing-funds) — current withdrawal
  and recovery paths