---
id: TIP-1109
title: Account Configuration Updates
description: Lets the current owner quorum rotate owners without changing the account address.
authors: Tanishk Goyal (@legion2002), Jake Moxey (@jxom)
status: Draft
related: TIP-1114, TIP-1107, TIP-1108, TIP-1113
protocolVersion: T12
---

# TIP-1109: Account Configuration Updates

## Abstract

The current owners can replace the account's owners and threshold without changing its address.

They call a precompile that updates the configuration hash in the account leaf.

## Motivation

Key rotation must be available when configurable accounts launch. The precompile lets owners replace keys without moving funds or permissions.

## Assumptions

- [TIP-1114](./tip-1114.md) defines valid configurations and checks the transaction's signatures.
- [TIP-1108](./tip-1108.md) defines where the configuration hash is stored and what writes cost.

## Threat Model

The current owner quorum controls rotation. Delegates, including admin access keys, cannot acquire that authority through their grants.

# Specification

## Interface

The precompile is available at `0xAACC000000000000000000000000000000000000` from T12. The following types and errors define its public interface:

```solidity
interface INativeMultisig {
    struct MultisigOwner {
        address owner;
        uint8 weight;
    }
    struct MultisigConfig {
        bytes32 salt;
        uint64 version;
        uint8 threshold;
        MultisigOwner[] owners;
    }

    /// Derive the initial account from salt, threshold, and sorted owners.
    /// Reverts for an invalid configuration or reserved derived address.
    function deriveAccount(
        bytes32 salt,
        uint8 threshold,
        MultisigOwner[] calldata owners
    ) external pure returns (address account);

    /// Return account's current commitment.
    /// Zero means no persisted update.
    function getConfigCommitment(address account)
        external view returns (bytes32 commitment);

    /// Replace msg.sender's owners and threshold, proving current configuration.
    /// Requires a direct owner-quorum transaction and a top-level batch call.
    /// Reverts for unauthorized callers, stale current state, or invalid new config.
    function updateConfig(
        MultisigConfig calldata current,
        uint8 threshold,
        MultisigOwner[] calldata owners
    ) external;

    event MultisigConfigUpdated(
        address indexed account,
        bytes32 salt,
        uint64 version,
        uint8 threshold,
        MultisigOwner[] owners
    );

    error InvalidAccount();
    error InvalidConfig();
    error InvalidThreshold();
    error InvalidMultisigOwner();
    error InvalidWeight();
    error TooManyOwners();
    error DuplicateOwner();
    error InvalidOwnerOrder();
    error UnauthorizedMultisigCaller();
}
```

## Update rules

**Who can call `updateConfig`**

- The transaction must be signed directly by the owner quorum.
- The call must be a top-level call created by the protocol, with `msg.sender == tx.origin`.
- Access keys, contract callbacks, and fee payers cannot authorize rotation.
- No separate approval signature is accepted. The transaction signature already covers the update calldata.

**How an update works**

1. Check the supplied `current` configuration against the account leaf at call time. The initial hash has already been registered under TIP-1114 before calls execute.
2. Keep the current salt.
3. Increase the version by exactly one. Reject version overflow.
4. Replace the threshold and owner list with the supplied values.
5. Validate the new configuration under TIP-1114.
6. Compute its hash and reject a zero hash.
7. Store the hash and emit `MultisigConfigUpdated` with the complete new configuration.

**Versions and account state**

- First use stores version zero before any update call executes.
- The first owner update replaces that hash with version one, including an update in the first transaction.
- A migrated account already starts at version one under TIP-1113.
- Rotation does not change the account address, balances, nonce rules, or access-key permissions.

**Multiple updates in one transaction**

- Each update checks the hash left by the previous call. Versions must form a consecutive sequence.
- The original quorum approves the entire batch. Later calls do not authenticate the transaction again.
- A reverted call rolls back its write and event under ordinary batch execution rules.
- Later transactions must use the configuration left by the completed transaction.

## Validation and gas

Check caller authorization first. An unauthorized caller gets `UnauthorizedMultisigCaller`.

Check configuration errors in this order:

| Invalid input | Error |
|---|---|
| Empty owner list | `InvalidMultisigOwner` |
| Too many owners | `TooManyOwners` |
| Threshold outside 1–255 | `InvalidThreshold` |
| Invalid owner address | `InvalidMultisigOwner` |
| Zero owner weight | `InvalidWeight` |
| Duplicate owner | `DuplicateOwner` |
| Owners out of address order | `InvalidOwnerOrder` |
| Total weight above 255 | `InvalidWeight` |
| Threshold cannot be reached with at most eight owners | `InvalidThreshold` |

- A stale configuration, zero hash, or version overflow gets `InvalidConfig`.
- An invalid derived account address gets `InvalidAccount`.

Gas charges are:

- Ordinary precompile, input, and event costs.
- Account reads and writes under TIP-1108.
- Standard Keccak costs for checking the current configuration and hashing the next one.
- Both TIP-1110 derivation hashes when calling `deriveAccount`.
- Account access and normal precompile costs when calling `getConfigCommitment`.

Do not add a configuration storage-slot read or write charge.

# Tooling

- Wallets show the proposed owners and threshold, and retain the full configuration.
- Transaction pools and simulators recheck affected transactions when the commitment changes.

# Observability

`MultisigConfigUpdated` records the complete new configuration so indexers can reconstruct the commitment and current owners.

# Invariants

- Removing and later re-adding an owner never makes their old signatures valid again. The configuration version prevents this replay.
- Test consecutive updates and partial rollback within a batch.
- Rotation preserves the address and access-key permissions.