Tempo propõe TIP-1061 para introduzir uma conta multiassinatura nativa na camada de protocolo, sem necessidade de implantar contratos como o Safe

A blockchain Layer 1 Tempo, desenvolvida em conjunto pela Stripe e pela Paradigm, apresentou em 31 de maio a proposta TIP-1061 de contas nativas de multisig, com a intenção de introduzir o multisig como o principal tipo de conta na camada de protocolo da rede, permitindo controlar o multisig sem precisar fazer deploy de carteiras de contratos inteligentes como o Safe. A TIP-1061 tem como foco principal casos de uso como DAOs, instituições e nós validadores, e ainda está na fase de rascunho.

Especificações técnicas confirmadas

O design central da TIP-1061 inclui os seguintes detalhes técnicos já confirmados. O endereço da conta de multisig é derivado de um hash da configuração inicial (config_id); ao ajustar posteriormente a lista de membros, os pesos de assinatura ou o limiar (threshold), o endereço da conta permanece o mesmo.

Há suporte a três tipos de assinatura: Secp256k1, P256 e WebAuthn. O suporte inclui multisig em plano M-of-N (com cada owner com weight=1) e multisig ponderado (autorização assimétrica), por exemplo, um owner de alto peso (weight=100) pode autorizar sozinho, ou dois owners de peso médio (cada um com weight=50) podem autorizar em conjunto. Cada conta de multisig permite no máximo 10 owners (MAX_MULTISIG_OWNERS=10).

Limitações de design: não há suporte a AccountKeychain e EIP-7702

A TIP-1061 define explicitamente que contas nativas de multisig não suportam acesso a chaves via AccountKeychain; se msg.sender for uma conta nativa de multisig, modificadores de chamada do AccountKeychain devem ser recusados. O motivo do desenho da proposta é: permitir que uma única chave de autorização faça chamadas como pai da conta transformaria uma chave privada original em uma capacidade permanente de atuar como endereço de multisig dentro de qualquer escopo de autorização, o que não atende ao princípio do design de “identidade com controle por número legal de participantes”.

Além disso, contas nativas de multisig não podem instalar bytecode EVM ou código delegado do EIP-7702 após a inicialização (Bootstrap).

Estado do rascunho: pontos ainda a confirmar

A proposta ainda está como rascunho; o plano de contagem de gas (o documento marca como “pendente”) e os endereços dos contratos pré-compilados de multisig (que serão atribuídos antes da proposta sair da fase de rascunho) ainda não foram finalizados. A proposta determina que, antes do TIP-1061 entrar em vigor, todas as transações que contenham TempoSignature::Multisig devem ser rejeitadas; e todas as transações com o campo multisig_init também devem ser rejeitadas antes da ativação da proposta.

Perguntas frequentes

Qual é a diferença fundamental entre o multisig nativo do TIP-1061 e carteiras de contrato como o Safe?

O TIP-1061 eleva a validação do multisig para a camada de protocolo, eliminando a necessidade de implantar carteiras de contrato como o Safe na cadeia para obter a mesma capacidade de controle por limiar (threshold), o que elimina os custos de deploy de contratos. Além disso, após derivar o endereço a partir da configuração inicial, ele permanece estável e não muda com atualizações de membros.

Por que o endereço da conta de multisig consegue manter-se inalterado após atualização dos membros?

O endereço da conta de multisig é derivado do hash de config_id, e o config_id é calculado com base no conjunto inicial de owners (incluindo endereço, tipo de assinatura e peso) e no limiar. Durante a existência da conta, isso não muda. Chamadas posteriores a updateMultisigConfig atualizam apenas a configuração corrente armazenada, sem alterar o config_id em si nem os endereços de contas derivados dele.

Quais são os principais cenários de uso do TIP-1061?

A seção de motivação da proposta indica de forma clara que o objetivo são usuários que precisam que “nenhuma chave privada individual possa transferir fundos ou alterar configurações de operação unilateralmente”. Isso inclui equipes (Teams), departamentos financeiros (Treasury), nós validadores (Validators) e operadores institucionais (Institutional Operators).