---
id: TIP-1137
title: Remove Admin Access Keys
description: Removes TIP-1049 admin access keys at T14 in favor of configurable account owners.
authors: Tanishk Goyal (@legion2002)
status: Draft
related: TIP-1049, TIP-1107, TIP-1108, TIP-1109, TIP-1111, TIP-1113, TIP-1114
protocolVersion: T14
---

# TIP-1137: Remove Admin Access Keys

## Abstract

This TIP removes admin access keys ([TIP-1049](./tip-1049.md)) at T14. From T14, no key can become an admin key and only an account's root key manages its access keys. Admin keys authorized before T14 become regular access keys without limits.

Configurable accounts ([TIP-1107](./tip-1107.md)) replace the feature: a device that would have held an admin key is added as an owner instead.

## Motivation

TIP-1049 added admin keys at T6 so a second device could manage access keys without the root key. An admin key has no spending limit, call scope or expiry. It acts alone and can authorize further admin keys.

Configurable accounts ship at T14 and cover the same use case. To give a second device full control, the user adds its key as an owner whose weight meets the approval threshold. That carries less risk than an admin key:

| Property | Admin key | Owner |
|---|---|---|
| Where it is recorded | Keychain storage, outside the account configuration | Account configuration, committed in the account leaf ([TIP-1108](./tip-1108.md)) |
| Approval | Always acts alone | Counts toward a threshold the user chooses; a 2-of-2 setup needs both devices |
| Adding more keys with the same power | Can authorize new admin keys by itself | Needs the owner quorum through `updateConfig` ([TIP-1109](./tip-1109.md)) |
| Rotation | Revoke and re-authorize per key | `updateConfig` bumps the configuration version and invalidates signatures for earlier versions |

Admin keys also bypass configurable accounts. An EOA migrated with TIP-1113 would keep its pre-T14 admin keys, which could spend without the owner quorum.

The feature is unused on mainnet. Between mainnet blocks 26,629,191 (T6 activation) and 43,226,357, there were zero `AdminKeyAuthorized` events and 4,961 regular key authorizations. Both admin-creation paths emit the event; pre-T6 keys have `is_admin = false`. Moderato had 256 admin keys across 101 accounts.

Alternatives considered:

- **Treat stored admin keys as revoked at T14.** Every keychain read path would need a fork-gated override, and the pool would need a T14 boundary eviction.
- **Make stored admin keys inert.** Unlimited regular access keys can already be created, so disabling signing for admin keys adds no protection that other keys lack.
- **Keep stored admin keys as signers and add a permissionless revoke.** Needs a new ABI function and an off-chain cleanup for the same end state.
- **Keep admin keys and exclude them from configurable accounts.** Keeps the T6 surface and needs extra rules in TIP-1111 and TIP-1113 for a feature nobody uses on mainnet.

## Assumptions

| Assumption | If violated |
|---|---|
| Configurable accounts activate at T14. | This TIP can activate alone. Multi-device key management then needs the root key until configurable accounts ship. |
| Mainnet has no admin keys at T14 activation. | Their holders lose management authority at T14; the keys keep signing as unlimited regular access keys. |
| Holders of admin keys accept them as unlimited regular access keys. | They restrict them with `updateSpendingLimit` or `setAllowedCalls`, or revoke them with `revokeKey`. |

---

# Specification

## Overview

All rules apply from T14. Before T14, TIP-1049 applies unchanged, so T6 to T13 blocks replay exactly.

1. **Creation.** No path can set `is_admin = true` on a key.
2. **Management.** Only the root key manages access keys. A configurable parent's access keys are managed by its own owner quorum ([TIP-1111](./tip-1111.md)).
3. **Existing admin keys.** Keys stored with `is_admin = true` become regular access keys without limits.

## Creation

- `authorizeAdminKey` reverts with `UnknownFunctionSelector`.
- A transaction whose `key_authorization` has `is_admin = true` is invalid.
- Only the target account's root key may sign a `key_authorization`; for an account with a configuration commitment, only its owner quorum may. A signature by an access key is invalid, whatever its stored flag.
- If `account` is present in a `key_authorization`, it must equal the target account.
- TIP-1111's admin-signed grants are removed. Only the configurable parent's own owner quorum may sign a grant.
- The transaction pool applies the same rules.

## Management

- `ensure_admin_caller` accepts only the root key or, for an account with a configuration commitment, its owner quorum. `authorizeKey`, `revokeKey`, `updateSpendingLimit`, `setAllowedCalls`, `removeAllowedCalls` and `burnKeyAuthorizationWitness` revert with `UnauthorizedCaller` when the transaction is signed by an access key.
- `isAdminKey(account, keyId)` returns true only when `keyId == account` and `account` has no configuration commitment. A configurable account's root key, including an EOA migrated with TIP-1113, is retired and gets false; its owner quorum manages keys instead.
- `verifyKeychainAdmin(account, hash, signature)` returns true only when the recovered signer is `account` and `account` has no configuration commitment. Its results are unchanged on mainnet, where no admin keys exist.

## Existing admin keys

Keys authorized before T14 with `is_admin = true` stay in storage without migration. From T14, the keychain ignores their `is_admin` flag, so each one acts as a regular access key with no expiry, spending limit or call scope:

- It signs transactions and passes `verifyKeychain`, as before T14.
- It has no management authority: `isAdminKey` returns false for it.
- The root key can restrict it with `updateSpendingLimit` and `setAllowedCalls`, or revoke it with `revokeKey`.

Keychain views report it as an active, unlimited and unscoped key, which is what it is.

## Interfaces

- `authorizeAdminKey(keyId, signatureType, witness)` is removed from dispatch. No functions are added.
- `KeyAuthorization` keeps its optional `is_admin` and `account` RLP fields. Encodings are unchanged.
- `AuthorizedKey` keeps its `is_admin` byte. `AdminKeyAuthorized` stays in the ABI for historical logs. Indexers and decoders need no change.
- `isAdminKey` and `verifyKeychainAdmin` keep their selectors, so existing callers do not revert.

# Tooling

- SDKs (viem, tempo-go, pytempo, tempo-std) remove `authorizeAdminKey`, `is_admin` and admin-signed key authorizations for T14 chains.
- Wallets that offered admin keys add the device key as a configurable account owner instead, through account creation, `updateConfig` or TIP-1113 migration.
- Before T14 reaches a network, dataland's `stg_t6_admin_key_authorized` model lists the accounts holding admin keys, so they can be asked to revoke them and authorize replacements.
- The T6 upgrade docs and the AccountKeychain reference note the removal.

# Observability

No events are added. From T14, `AdminKeyAuthorized` must not appear on any network; `stg_t6_admin_key_authorized` confirms it. Stored admin keys show up as regular access keys in transactions and views.

# Threat Model

| Actor | Trust |
|---|---|
| Root key of an EOA | The only key that manages the account's access keys, as before T6. A compromised root key controls the account. |
| Owner quorum of a configurable account | Manages owners and access keys. A compromised quorum can replace the other owners. |
| Access keys | Sign within their spending limits and call scopes. They cannot manage keys. |
| Keys stored as admin before T14 | Same as any access key without limits: sign anything, manage nothing. |

An owner whose weight meets the threshold alone has the same unrestricted authority an admin key had, plus owner rotation. Users who add a device that way accept that risk; the difference is that it is recorded in the account configuration and chosen through the threshold.

# Invariants

- Before T14, behavior matches TIP-1049, and T6 to T13 blocks replay unchanged.
- From T14, no transaction or call sets `is_admin = true` on any key.
- From T14, a key stored with `is_admin = true` behaves exactly like a regular access key with the same restrictions.
- From T14, `isAdminKey(account, keyId)` is true if and only if `keyId == account` and `account` has no configuration commitment.
- From T14, every keychain mutator rejects transactions signed by an access key.
- From T14, `verifyKeychainAdmin` returns false for every non-root signer and for the retired root key of a configurable account.

Tests must cover each rule at T13 and T14, including admin keys created before T14 through both creation paths (`authorizeAdminKey` and `key_authorization` with `is_admin`), an admin-signed `key_authorization`, a stored admin key signing and being restricted after T14, a stored admin key calling `burnKeyAuthorizationWitness`, a configurable parent, and an EOA migrated with TIP-1113 that holds an admin key, where `isAdminKey(account, account)` and `verifyKeychainAdmin` with a root signature both return false.