La propuesta Tempo TIP-1061 introduce cuentas multifirma nativas a nivel de capa de acuerdo, sin necesidad de desplegar contratos como Safe

La blockchain Layer 1 Tempo, desarrollada conjuntamente por Stripe y Paradigm, presentó el 31 de mayo la propuesta TIP-1061 para cuentas nativas de multisig, con la intención de introducir el multisig como el principal tipo de cuenta de la capa de protocolo en la red, sin necesidad de desplegar carteras de contratos inteligentes como Safe para lograr el control del multisig. La TIP-1061 está dirigida principalmente a casos de uso como DAO, entidades institucionales y nodos validadores, y aún se encuentra en fase de borrador.

Especificaciones técnicas confirmadas

El diseño central de TIP-1061 incluye los siguientes detalles técnicos ya confirmados. La dirección de la cuenta multisig se deriva del hash de la configuración inicial (config_id); cuando se ajusta posteriormente la lista de miembros, el peso de las firmas o el umbral, la dirección de la cuenta permanece invariable.

Se admiten tres tipos de firma: Secp256k1, P256 y WebAuthn. Se admite el multisig en plano M-of-N (cada propietario tiene weight=1) y el multisig con ponderación (autorización asimétrica), por ejemplo, un propietario de alto peso (weight=100) puede autorizar en solitario, o dos propietarios de peso medio (cada uno weight=50) pueden autorizar conjuntamente. Cada cuenta multisig permite como máximo 10 propietarios (MAX_MULTISIG_OWNERS=10).

Limitaciones de diseño: no admite AccountKeychain ni EIP-7702

TIP-1061 establece explícitamente que la cuenta multisig nativa no admite el acceso a claves mediante AccountKeychain; si msg.sender es una cuenta multisig nativa, se debe rechazar cualquier llamada al modificador AccountKeychain. El motivo del diseño propuesto es que permitir que una sola clave de autorización haga llamadas como identidad de cuenta padre convertiría una clave privada original en una capacidad permanente para actuar como dirección multisig dentro de cualquier ámbito de autorización, lo cual no cumple el principio de diseño de “control de identidad mediante un número legal de participantes”.

Además, después del Bootstrap, la cuenta multisig nativa no puede instalar bytecode EVM ni código de delegación EIP-7702.

Estado del borrador: asuntos aún por confirmar

La propuesta sigue siendo un borrador; tanto el esquema de medición de gas (el documento lo marca como “pendiente de tareas”) como la dirección de contrato precompilado del multisig (se asignará antes de que la propuesta salga del estado de borrador) aún no se han finalizado. La propuesta establece que, antes de que TIP-1061 entre en vigor, todas las transacciones que incluyan TempoSignature::Multisig deben ser rechazadas; todas las transacciones que incluyan el campo multisig_init también deben ser rechazadas antes del inicio de la propuesta.

Preguntas frecuentes

¿Cuál es la diferencia fundamental entre el multisig nativo de TIP-1061 y carteras de contrato como Safe?

TIP-1061 eleva la verificación de multisig a la capa de protocolo, permitiendo capacidades equivalentes de control por umbral sin necesidad de desplegar carteras de contratos como Safe en la cadena, eliminando los costos de despliegue del contrato; además, la dirección de la cuenta se deriva de la configuración inicial y se mantiene estable, sin cambiar con las actualizaciones de miembros.

¿Por qué la dirección de la cuenta multisig puede mantenerse sin cambios después de la actualización de miembros?

La dirección de la cuenta multisig se deriva del hash de config_id, y config_id se calcula a partir del conjunto inicial de propietarios (incluidas direcciones, tipos de firma y pesos) y del umbral; por tanto, no cambia durante la vida de la cuenta. Llamadas posteriores a updateMultisigConfig solo actualizan la configuración actual almacenada, sin modificar el propio config_id ni la dirección de cuenta derivada.

¿Cuáles son los principales casos de uso objetivo de TIP-1061?

La sección de motivación de la propuesta indica con claridad que los casos objetivo son aquellos en los que los usuarios necesitan que “ninguna clave privada individual pueda transferir fondos o cambiar configuraciones operativas por su cuenta”, incluyendo equipos (Teams), departamentos de tesorería (Treasury), nodos validadores (Validators) y operadores institucionales (Institutional Operators).