---
id: TIP-1107
title: Configurable Accounts (Meta)
description: Native accounts with weighted ownership, key rotation, recovery, and delegated spending at the same address.
authors: Tanishk Goyal (@legion2002), Jake Moxey (@jxom)
status: Draft
related: TIP-1114, TIP-1108, TIP-1109, TIP-1110, TIP-1111, TIP-1086, TIP-1112, TIP-1113, TIP-1137
protocolVersion: T14
---

# TIP-1107: Configurable Accounts (Meta)

## Abstract

Configurable accounts let users change an account's owners and approval threshold without changing its address. They support key rotation and account recovery, weighted multisig ownership, and delegated spending through access keys.

This meta TIP describes the account model, user journeys and proposed implementation phases. Component TIPs define the detailed protocol rules.

## Motivation

Users and treasuries need multisig control, key recovery, and key rotation without changing their account address. Configurable accounts let authorised owners approve transactions and replace signing keys while preserving balances, deposit addresses, and application permissions.

Access keys let users delegate spending across devices. Configurable accounts let an owner quorum manage those keys and replace lost or compromised owners without changing the account address.

## Assumptions

- Proposed Phase 1 introduces new configurable accounts with weighted ownership, key rotation, access-key support, and existing-account migration with root-key disablement. Admin access-key authority is removed in the same phase. Its component TIPs activate together.
- Phase 2 adds post-quantum signature support and reduces access-key costs.

# Specification

## Ownership and authorisation

A configurable account can have one or several owners. A single-owner account can replace its signing key without changing its address. Each owner has an assigned weight, and the account has an approval threshold. Owners sign with secp256k1, P256, or WebAuthn keys.

Owners authorise a transaction by supplying signatures and the full account configuration: owners and weights, approval threshold, salt, and version. The signatures must be valid, and the signing owners' combined weight must meet the approval threshold before any calls execute.

The owners' signatures approve the entire transaction, including every call in a batch. Transactions are sent from the configurable account's address. Each contract called directly by the transaction sees that address as its caller.

[TIP-1114](./tip-1114.md) defines authorisation and its limits. Applications can [verify that a message was approved](./tip-1114.md#on-chain-signature-verification) by owners meeting the account's current approval threshold.

## Account creation & onboarding

The user chooses the owners and approval threshold. The wallet builds the initial configuration and [derives the account address](./tip-1110.md#address-derivation). The account can receive funds before its configuration is registered.

[Registration](./tip-1114.md#initial-use) happens when the account first authorises a valid transaction that is included onchain, even if its execution fails. The supplied initial configuration must produce the account's address.

[TIP-1108](./tip-1108.md) stores a 32-byte hash of the configuration in the account leaf, avoiding a separate storage lookup. After registration, the supplied configuration is verified against this hash. Owner rotation updates the hash, allowing the owners and approval threshold to change without changing the address.

Phase 1 will also ship in-place migration of existing accounts ([TIP-1113](./tip-1113.md)).

## Key rotation and recovery

Current owners whose combined weight meets the approval threshold can call [`updateConfig`](./tip-1109.md) to replace the owners and approval threshold. The update increments the configuration version, invalidating signatures for earlier versions. The account address remains unchanged. Owner rotation does not revoke separately authorised access keys. Their permissions and spending counters remain unchanged. Removing their access requires explicit revocation.

Alice sets up her account with an approval threshold of **2** and the following owners:

| Owner | Weight |
|---|---|
| Alice's passkey | 2 |
| Wallet provider | 1 |
| Independent recovery provider | 1 |

Alice can transact independently. If she loses access, the two providers can jointly approve replacing her passkey. Neither provider can act alone. Together, the two providers can also approve spending or replace owners at any time.

1. Alice creates a new passkey.
2. The providers complete their identity checks offchain.
3. Both providers sign an `updateConfig` transaction replacing her old passkey.
4. Once the update succeeds, Alice uses her new passkey with the same account address and funds.

## Access keys

[TIP-1111](./tip-1111.md) lets configurable accounts authorise access keys and act as access keys for other accounts. For example, three owners of a three-of-five treasury jointly authorise an employee's access key with a limit of 500 pathUSD per 24-hour period. The employee can then make payments within that limit without further owner approvals.

Access keys act within their granted permissions. Only the parent account's owner quorum can manage its access keys. Delegates cannot authorise other keys, change grants or replace the parent's owners.

[TIP-1137](https://github.com/tempoxyz/tempo/pull/8204) removes admin access-key authority at T14. Its current draft retains unrestricted spending for pre-T14 admin grants until explicitly revoked, but those grants can no longer manage keys.

## Cross-chain transfer recovery

[TIP-1110](./tip-1110.md) derives addresses using CREATE2. On supported destination chains, the canonical recovery wallet at the same address can retrieve transfers when the initial secp256k1 owners can meet the original approval threshold. P256 and WebAuthn owners do not contribute to that recovery threshold. Owner rotation on Tempo does not change this recovery authority. On Tempo, the address is a native configurable account.

Phase 1 includes proxy creation code in the CREATE2 derivation: a user-controlled account proxy points to a Tempo-controlled implementation proxy. This allows the recovery implementation to be upgraded without changing account addresses. Remote control from Tempo remains future work. Existing accounts migrated in place do not gain CREATE2 recovery.

## Components and proposed phases

- **Proposed Phase 1:** new configurable accounts, multisig ownership, key rotation and recovery, access-key support, existing-account migration with root-key disablement, and removal of admin access-key authority.
- **Proposed Phase 2:** post-quantum signature support and lower access-key costs.

| TIP | What it adds and why | Proposed Phase |
|---|---|---|
| [TIP-1114: Native multisig account type](./tip-1114.md) | Defines native accounts with weighted owners and an approval threshold, from a single signer to a shared treasury. | 1 |
| [TIP-1109: Configurable ownership and key rotation](./tip-1109.md) | Lets current owners meeting the approval threshold replace owners and change the threshold without changing the address. | 1 |
| [TIP-1110: CREATE2 addresses and cross-chain recovery](./tip-1110.md) | Includes proxy creation code in the address derivation and lets initial secp256k1 owners meeting the original threshold retrieve transfers at the same address on another supported chain. | 1 |
| [TIP-1108: Account leaf](./tip-1108.md) | Stores the account configuration hash in the account leaf for efficient access during validation. | 1 |
| [TIP-1111: Access keys for treasuries](./tip-1111.md) | Lets the account's owner quorum authorise access keys for spending without further owner approvals for each payment. | 1 |
| [TIP-1112: Root-key disablement](./tip-1112.md) | Prevents the original EOA key from bypassing configured ownership. | 1 |
| [TIP-1113: Existing-account migration](./tip-1113.md) | Upgrades existing accounts without changing their address. Requires TIP-1112. | 1 |
| [TIP-1137: Remove admin access keys](https://github.com/tempoxyz/tempo/pull/8204) | Removes admin access-key authority so only the root key or configurable account's owner quorum can manage access keys. | 1 |
| [TIP-1086: Account root](https://github.com/tempoxyz/tempo/pull/7506) | Reduces access-key costs through a shared account commitment. | 2 |

## Scope boundaries

- Configurable accounts cannot have deployed EVM code or EIP-7702 delegation.
- The approval threshold is 1–255 and must be reachable with at most eight owner signatures. An account can have up to 48 owners.
- The same approval threshold applies to spending and ownership changes. Recovery providers configured as owners can therefore also approve spending when their combined weight meets the threshold; their authority cannot be limited to recovery.
- Nested multisig owners are excluded to bound signature-verification work and prevent denial-of-service attacks through recursive validation.
- Access-key signatures cannot count towards the owner threshold. Configurable delegates under TIP-1111 use a separate, bounded validation path.
- Timelocks and arbitrary programmable authorisation policies are outside the current component set.

# Tooling

Wallets and SDKs must support account creation, independent collection of owner signatures, key rotation, recovery, and in-place migration. The component TIPs define the detailed tooling requirements.

# Observability

Component TIPs define the events and transaction data used to track account creation, ownership changes, and access-key activity.

# Threat Model

Phase 1 protects account funds and ownership against unauthorised use. It assumes correct Tempo consensus, secure signatures and hashes, and that no attacker knows a primitive private key for an unregistered derived account address. Cross-chain recovery also depends on the canonical contracts being available on the destination chain.

| Actor | Trust |
| --- | --- |
| Owners / recovery providers | Any owner quorum can spend and replace owners; recovery providers have the same authority. Quorum compromise or collusion gives account control; losing enough keys can prevent access. Eligible initial secp256k1 owners retain cross-chain recovery authority under the original threshold after removal on Tempo. |
| Original root key | Trusted until migration succeeds; a compromised root can race migration or choose different owners. After migration, it has no independent protocol authority. Applications using pure signature recovery must check root disablement separately. |
| Wallets | A compromised wallet can mislead owners into approving harmful transactions. Losing the current configuration prevents owner authorisation until it is recovered. |
| Access keys | Bound by configured spending limits, call scopes and expiry. Cannot manage keys or replace owners. Pre-T14 admin grants retain unrestricted spending under the current TIP-1137 draft, but lose key-management authority. |
| Tempo upgrade authority | Controls the shared recovery implementation. Compromise can allow theft from destination-chain proxies using it. |
| RPCs / fee payers / relayers | Submitting transactions or paying fees grants no authority to change what owners signed. |
| Users | Can submit invalid transactions that consume unpaid verification work. Configuration and signature limits bound this work; recursive signature verification is rejected. |

Migration and owner rotation preserve access-key grants. Compromised grants require explicit revocation; removing admin authority does not revoke legacy spending grants or keys previously authorised by an admin.

# Invariants

- Ownership changes preserve the account address.
- Owner rotation preserves access-key grants, permissions, and spending counters stored in AccountKeychain.
- Owner approvals must match the configuration and version at the transaction's position in the block.
- Access keys cannot manage the parent account's keys or change its owners.
- Successful migration preserves the account address and disables independent root-key authority at the protocol level.
- Every configurable signer of an included transaction retains a nonzero configuration hash, even if execution fails.
- Owner updates follow execution rollback rules without undoing initial registration.
- Owner rotation on Tempo preserves cross-chain recovery authority for eligible initial owners.