Tempo, a Layer 1 blockchain jointly developed by Stripe and Paradigm, submitted the TIP-1061 native multisig account proposal on May 31. It plans to introduce multisig as the primary account type at the protocol layer, enabling multisig control without deploying smart contract wallets such as Safe. TIP-1061 mainly targets use cases such as DAOs, institutions, and validator nodes, and is still in draft stage.
Confirmed technical specifications
The core design of TIP-1061 includes the following confirmed technical details. The multisig account address is derived from a hash of the initial configuration (config_id); when later adjusting the member list, signature weights, or threshold, the account address remains unchanged.
It supports three signature types: Secp256k1, P256, and WebAuthn. It supports M-of-N flat multisig (each owner weight=1) and weighted multisig (asymmetric authorization). For example, a high-weight owner (weight=100) can authorize alone, or two medium-weight owners (each weight=50) can authorize jointly. Each multisig account allows up to 10 owners (MAX_MULTISIG_OWNERS=10).
Design limitations: does not support AccountKeychain and EIP-7702
TIP-1061 explicitly states that native multisig accounts do not support AccountKeychain access to keys; if msg.sender is a native multisig account, any AccountKeychain modifier call must be rejected. The proposal’s design rationale is that allowing a single authorization key to make calls as a parent account would turn an original private key into a permanent capability to act as the multisig address within any authorization scope, which does not align with the design principle of “identity under legal-person count control.”
In addition, after Bootstrap, native multisig accounts must not install EVM bytecode or EIP-7702 delegation code.
Draft status: items still to be determined
The proposal is still a draft. The gas metering方案 (the document labels it as “to be done”) and the multisig precompiled contract addresses (to be assigned before the proposal leaves draft) have not yet been finalized. The proposal stipulates that before TIP-1061 goes live, all transactions containing TempoSignature::Multisig must be rejected; all transactions carrying the multisig_init field must also be rejected before the proposal goes live.
FAQ
What is the fundamental difference between TIP-1061 native multisig and contract wallets like Safe?
TIP-1061 elevates multisig verification to the protocol layer, achieving the same threshold control capabilities without deploying a Safe-like smart contract wallet on-chain. This removes contract deployment costs, and the account address remains stable after being derived from the initial configuration, without changing as members are updated.
Why can the multisig account address remain unchanged after member updates?
The multisig account address is derived from the hash of config_id. config_id is calculated from the initial owners set (including addresses, signature types, and weights) and the threshold. It does not change throughout the account’s lifetime. Subsequent updateMultisigConfig calls only update the currently stored configuration, without changing config_id itself or the derived account address.
What are the main target use cases of TIP-1061?
In the motivation section, the proposal explicitly states that the target use cases are for users who need that “no single private key can unilaterally transfer funds or change operational configuration.” This specifically includes teams (Teams), finance departments (Treasury), validator nodes (Validators), and institutional operators.
