---
title: "Rotación de firmantes multifirma"
description: "Un procedimiento centrado en la verificación para sustituir firmantes multifirma, conservar el cuórum, comprobar el conjunto de propietarios y el umbral exactos en cadena y responder con seguridad ante una clave comprometida."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Rotación de firmantes multifirma
> Solo con fines educativos; no constituye asesoramiento de inversión, jurídico ni de seguridad. Un error al rotar firmantes puede transferir el control, invalidar aprobaciones pendientes o bloquear permanentemente una cuenta multifirma.
## Respuesta directa
La rotación de firmantes multifirma cambia las cuentas autorizadas para aprobar transacciones. Normalmente no requiere una nueva dirección de cartera ni transferir activos: mediante una transacción privilegiada se modifica el conjunto de propietarios de la cuenta y, a veces, su umbral de aprobación. Las implementaciones difieren, por lo que hay que verificar el contrato desplegado y el estado actual en cadena en vez de asumir que las etiquetas de la interfaz describen correctamente la autoridad.
Una rotación segura demuestra primero el control de cada firmante nuevo, mantiene durante todo el cambio un cuórum ejecutable pero no concentrado, elimina al firmante anterior y verifica el estado final en cadena. Perder el cuórum requerido antes de ejecutar puede imposibilitar una rotación ordinaria de propietarios; reducir el umbral por comodidad puede crear una ventana de toma de control.
La persona, el dispositivo de firma, la clave privada y la dirección de propietario en cadena son registros distintos. Documente la dirección exacta, el custodio, el dominio de control independiente, el estado de la copia de seguridad y el motivo de la rotación. Ninguna rotación legítima exige revelar una frase semilla o una clave privada.
## Cómo funciona
1. **Inventariar la autoridad actual.** Desde una cadena y una dirección de cuenta verificadas de forma independiente, lea la implementación desplegada, la lista de propietarios, el umbral, el nonce, los módulos habilitados, los guards, el fallback handler, la ruta de recuperación y cualquier timelock. Un módulo o mecanismo de recuperación puede ejecutar fuera del umbral ordinario de propietarios, mientras que un guard restrictivo puede bloquear una rotación que de otro modo sería válida.
2. **Definir el estado objetivo antes de firmar.** Registre el conjunto de propietarios y el umbral exactos tras el cambio. Confirme que el umbral no supera el número de propietarios y que al menos esa cantidad de firmantes independientes seguirá operativa. La separación geográfica no es independencia si una sola persona, bóveda de contraseñas, cuenta en la nube o administrador controla todos los dispositivos.
3. **Incorporar y autenticar al firmante nuevo.** Genere o restaure la clave nueva en el entorno de custodia previsto, verifique la dirección en un dispositivo de confianza y demuestre el control mediante un desafío acordado o una firma de prueba. Confirme la dirección por un segundo canal autenticado; no dependa solo de texto copiado de un chat o de una interfaz de cartera.
4. **Elegir un orden con estados intermedios seguros.** Algunos contratos pueden sustituir un propietario de forma atómica. Safe, por ejemplo, expone `swapOwner`; también expone `addOwnerWithThreshold`, `removeOwner` y `changeThreshold`. Si una implementación necesita varias transacciones, analice el conjunto de propietarios y el umbral después de cada paso. Añada y verifique capacidad antes de eliminarla, salvo que un compromiso activo haga inseguro ese orden.
5. **Decodificar y simular la transacción exacta.** Compruebe de forma independiente el chain ID, la dirección de la cuenta, el target, el selector de función, las direcciones de propietario antigua y nueva, el umbral resultante, el nonce, el value y el tipo de operación. Trate `delegatecall`, el procesamiento por lotes, los cambios de módulo y los cambios de guard como efectos de alto riesgo separados. Cada firmante debe aprobar el mismo payload decodificado y el mismo hash de transacción.
6. **Ejecutar con la autoridad existente.** El cuórum válido actual autoriza la rotación, salvo que una ruta de recuperación documentada disponga otra cosa. En una emergencia, coordínese únicamente mediante contactos autenticados y use firmantes no comprometidos. Si no están disponibles ni el cuórum normal ni una autoridad de recuperación preconfigurada, una llamada estándar de gestión de propietarios no puede restablecer el acceso.
7. **Verificar y cerrar el cambio.** Tras la confirmación, consulte directamente el conjunto de propietarios y el umbral, inspeccione los eventos emitidos o las trazas según corresponda y confirme que la dirección anterior ya no está autorizada. Haga que el firmante nuevo participe en una transacción aprobada de bajo riesgo o valor cero que requiera el umbral previsto. Revise las transacciones pendientes, revoque el acceso fuera de cadena y las copias de seguridad del firmante anterior y archive la propuesta, las firmas, el hash de transacción, el bloque y el estado final.
## Ejemplo práctico
Supongamos que una cuenta `3-of-5` tiene como propietarios a `A`, `B`, `C`, `D` y `E`, y que hay que sustituir `B` por `F`. El equipo verifica primero que `F` controla la dirección exacta propuesta y sigue siendo independiente de los demás propietarios. Para un despliegue compatible de Safe, prepara `swapOwner(prevOwner, B, F)`. La llamada es en sí una transacción de Safe y, por tanto, necesita `3` confirmaciones válidas del conjunto actual de propietarios. El resultado decodificado debe conservar un total de `5` propietarios y un umbral de `3`.
Después de confirmar la transacción, el equipo lee `getOwners` y `getThreshold`, verifica que `B` está ausente y `F` presente, y hace que `F` junto con otros dos propietarios ejecuten una prueba aprobada de valor `0`. También revisa las transacciones pendientes: una firma o aprobación previa de `B` puede dejar de satisfacer las comprobaciones de propietario tras eliminarlo, por lo que las propuestas afectadas deben cancelarse o reconstruirse en vez de presuponer que son ejecutables.
Si `B` puede estar comprometido, el equipo no le pide que apruebe su eliminación. Otros tres propietarios no comprometidos ejecutan la sustitución y después inspeccionan módulos, permisos de recuperación, allowances, session keys y transacciones ya ejecutadas, porque eliminar `B` no revierte acciones anteriores ni revoca autoridad concedida por otra ruta. Si hay menos de `3` propietarios no comprometidos disponibles, solo podría ayudar una ruta de recuperación o administración configurada previamente; compartir frases semilla o confiar en un servicio de «recuperación» no solicitado no sustituye al cuórum.
## Riesgos y controles
- **Cuenta o dirección equivocada.** Verifique el chain ID, la dirección multifirma, la implementación y la dirección del propietario nuevo en dispositivos y fuentes independientes. El envenenamiento de direcciones y los errores de copia pueden dar el control a un atacante.
- **Pérdida de cuórum.** Modele cada estado intermedio. Eliminar demasiado pronto a un propietario, elevar el umbral por encima de los firmantes disponibles o rotar juntos varios dispositivos correlacionados puede inutilizar la cuenta.
- **Concentración temporal.** Un umbral menor o un firmante recién añadido puede crear un periodo en el que menos partes controlen la cuenta. Prefiera una sustitución atómica cuando sea compatible y no reduzca el umbral solo para simplificar la ceremonia.
- **Custodia correlacionada.** Distintas direcciones no son independientes si sus semillas, dispositivos, copias de seguridad, comunicaciones o administradores comparten un mismo dominio de fallo. Pruebe la recuperación sin centralizar secretos.
- **Autoridad oculta.** Los módulos, guards, fallback handlers, session keys, timelocks y contratos de recuperación pueden eludir o bloquear la ruta de los propietarios. Inventaríelos y verifíquelos antes y después de la rotación.
- **Carrera con el firmante comprometido.** Antes de que se confirme la eliminación, un firmante sospechoso puede adelantarse, retirar activos, cambiar la configuración o aprobar otra transacción. Use procedimientos de incidentes, entrega privada de transacciones cuando proceda y supervisión continua del estado; no suponga que una transacción enviada ha ganado la carrera.
- **Aprobaciones pendientes obsoletas.** Los cambios de propietarios y umbral pueden invalidar firmas recopiladas o cambiar qué aprobaciones son suficientes. Reevalúe cada transacción en cola frente al estado final y cancele las propuestas obsoletas.
- **Falsa finalización.** Una notificación de éxito de la interfaz no demuestra el estado previsto. Espere la política de confirmación exigida, lea después el estado del contrato y verifique el payload de la transacción, los eventos y el resultado de ejecución.
- **Baja incompleta.** Eliminar un propietario en cadena no borra claves copiadas, accesos organizativos, credenciales de relayer, entradas de la bóveda de contraseñas ni autoridad en otros contratos y cadenas. Revoque cada elemento por separado y conserve un registro de auditoría.
## Errores comunes
- **«Rotar significa mover todos los activos a una cartera nueva».** Muchas multifirmas de cuentas inteligentes actualizan propietarios en la misma dirección de cuenta. La migración es otra operación y quizá solo la exija una implementación o un plan de incidentes concreto.
- **«Añadir primero al firmante nuevo siempre es seguro».** Protege la disponibilidad, pero puede ampliar temporalmente el conjunto autorizado. Durante un compromiso activo, una sustitución atómica u otra secuencia de emergencia puede ser más segura.
- **«Un umbral `3-of-5` significa que tres personas nombradas cualesquiera están disponibles».** El contrato cuenta cuentas de propietario válidas, no personas, departamentos ni dispositivos. La custodia compartida y las claves inaccesibles reducen la independencia y disponibilidad efectivas.
- **«Eliminar a un propietario comprometido deshace el daño».** Tras confirmarse, la eliminación impide el uso futuro de esa ruta de propietario; no revierte transacciones ejecutadas ni revoca permisos creados en otro lugar.
- **«La interfaz de la cartera es prueba suficiente».** Las interfaces y los servicios de indexación pueden estar desactualizados, mal configurados o ser maliciosos. Decodifique la transacción y lea el estado final del contrato desde un endpoint verificado de forma independiente.
- **«Sin cuórum, el soporte puede restablecer la cartera».** Una multifirma de autocustodia solo dispone de las rutas de autoridad codificadas o configuradas previamente en cadena. Sin un cuórum válido o una ruta de recuperación, el acceso puede perderse de forma permanente.
## Temas relacionados
- [Cartera de hardware](/es/crypto/hardware-wallet/)
- [Cartera multifirma](/es/crypto/multisig-wallet/)
- [Gestión de claves privadas](/es/crypto/private-key-management/)
- [Riesgo de recuperación del propietario de una cuenta inteligente](/es/crypto/smart-account-owner-recovery-risk/)
- [Simulación de transacciones](/es/crypto/transaction-simulation/)
## Fuentes
- [¿Cómo funcionan las cuentas inteligentes de Safe?](https://docs.safe.global/advanced/smart-account-overview) - Safe Documentation (consultado: 2026-08-21)
- [addOwnerWithThreshold](https://docs.safe.global/reference-smart-account/owners/addOwnerWithThreshold) - Safe Documentation (consultado: 2026-08-21)
- [removeOwner](https://docs.safe.global/reference-smart-account/owners/removeOwner) - Safe Documentation (consultado: 2026-08-21)
- [swapOwner](https://docs.safe.global/reference-smart-account/owners/swapOwner) - Safe Documentation (consultado: 2026-08-21)
- [changeThreshold](https://docs.safe.global/reference-smart-account/owners/changeThreshold) - Safe Documentation (consultado: 2026-08-21)
- [OwnerManager.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/base/OwnerManager.sol) - Safe Ecosystem Foundation (consultado: 2026-08-21)
- [Recomendación para la gestión de claves: Parte 1 - General](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) - NIST (consultado: 2026-08-21)
Source: https://wiki.fcontext.com/es/crypto/multisig-signer-rotation/index.mdx