--- title: "Cartera multifirma" description: "Aprenda cómo una cartera multifirma M-of-N distribuye la autoridad sobre transacciones, en qué difieren las multifirmas de script y de contrato inteligente, y qué riesgos de firmantes, ejecución, módulos y recuperación persisten." 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. # Cartera multifirma > Solo con fines educativos; no constituye asesoramiento de inversión, custodia, jurídico ni de seguridad. Una multifirma aún puede perder fondos o quedar inutilizable por firmantes comprometidos, transacciones maliciosas, módulos inseguros, defectos del contrato o pérdida del cuórum. Las transacciones de activos digitales pueden ser irreversibles. ## Respuesta directa Una cartera multifirma controla una cuenta o una salida gastable mediante una regla que exige al menos M aprobaciones de N claves públicas o cuentas propietarias autorizadas. Una regla 2-of-3, por ejemplo, acepta dos autoridades válidas cualesquiera de un conjunto de tres. Así se evita que una clave privada sea el único punto de control, pero no se vuelve segura toda transacción aprobada. La multifirma convencional no divide una clave privada entre firmantes. Cada firmante suele controlar una clave o cuenta distinta, y el script o contrato comprueba varias aprobaciones. Los sistemas de firma umbral o MPC pueden, en cambio, producir una firma a partir de participaciones distribuidas de una clave; su apariencia en cadena y modelo de confianza son diferentes. La implementación importa. Bitcoin puede imponer condiciones de gasto multifirma en scripts de transacción. En Ethereum y redes programables similares, una multifirma común es una cuenta de contrato cuyo código define propietarios, umbral, reglas de ejecución y extensiones opcionales. A diferencia de una cuenta de propiedad externa, una cuenta de contrato está controlada por su código y no por una sola clave privada. El umbral M-of-N expresa límites de compromiso y disponibilidad. Una configuración 3-of-5 puede seguir funcionando si dos autoridades no están disponibles, pero tres autoridades válidas cualesquiera pueden aprobar gastos. Direcciones diferentes no son independientes si una persona, administrador de dispositivos, cuenta en la nube, ubicación de respaldo o custodio controla suficientes de ellas. ## Cómo funciona 1. **Verifique la autoridad antes de proponer.** Confirme la red y la cuenta o salida; inspeccione el script o contrato desplegado, el conjunto de propietarios, el umbral, las reglas de nonce o secuencia y todo módulo, guard, fallback handler, vía de recuperación y autoridad de actualización que pueda ejecutar o bloquear transacciones. 2. **Construya y decodifique la solicitud exacta.** Compruebe destino, activo, valor, calldata o script, tipo de operación, nonce, comisiones y contenido de lotes. Simule llamadas complejas cuando haya herramientas fiables y haga que cada firmante revise lo que autoriza realmente la firma, no una etiqueta de la interfaz. 3. **Recoja aprobaciones en dominios de control independientes.** Los firmantes verifican el mismo resumen de transacción en dispositivos de confianza y se comunican por canales autenticados. Ningún proceso legítimo exige revelar una frase semilla o clave privada. 4. **Ejecute la solicitud aprobada.** Alcanzar el umbral quizá solo vuelva ejecutable la propuesta. Un ejecutor aún debe difundirla o enviarla y puede tener que pagar una comisión de red. Un nonce obsoleto, una propuesta rival, un cambio de estado, una comisión insuficiente o una llamada fallida pueden impedir la ejecución. 5. **Verifique la finalización desde el estado de la cadena.** Espere la política de confirmación requerida, inspeccione el payload ejecutado y su resultado, y confirme saldos, configuración de propietarios y eventos según proceda. Reevalúe propuestas pendientes después de cambiar propietarios, umbral, módulos o políticas. ## Ejemplo Una tesorería usa una multifirma de cuenta inteligente 3-of-5 con propietarios A, B, C, D y E en dominios de control separados. Para un pago de 10,000 USDC, la propuesta registra red, cuenta, destinatario, contrato del token, importe, calldata, nonce y política de comisiones correctos. A, C y E decodifican de forma independiente la misma solicitud antes de aprobarla. Las aprobaciones por sí solas no mueven fondos. Un ejecutor envía la transacción; tras confirmarse, el equipo comprueba su resultado y el saldo de la tesorería en vez de confiar en una notificación de la interfaz. La propuesta, las aprobaciones, el hash y las pruebas de revisión se conservan como pista de auditoría. Si después se sospecha que la clave de B está comprometida, el cuórum no comprometido restante sigue el procedimiento de rotación de propietarios de la cuenta desplegada y verifica en cadena el conjunto final. También revisa propuestas pendientes, módulos, asignaciones, permisos de recuperación y otras cadenas, pues eliminar a B no revierte transacciones anteriores ni revoca autoridad concedida por otra vía. ## Riesgos y controles - **Custodia correlacionada.** Varias claves pueden fallar juntas si comparten persona, dispositivo, bóveda de contraseñas, administrador, ubicación, proveedor o secreto de recuperación. Mapee dominios de control y pruebe la recuperación sin centralizar autoridad suficiente para el umbral. - **Payload malicioso o mal entendido.** Un cuórum válido puede aprobar fielmente una dirección atacante, una autorización ilimitada de tokens, una delegate call o un lote dañino. Decodifique y verifique independientemente toda la solicitud; use la simulación como evidencia auxiliar, no como garantía. - **Pérdida y demora del cuórum.** Claves perdidas, personas no disponibles, disputas, cortes de red o un umbral demasiado alto pueden bloquear acciones urgentes o inmovilizar activos para siempre. Mantenga contactos autenticados, sucesión documentada, respaldos probados y un diseño explícito de recuperación. - **Autoridad oculta o de elusión.** Módulos, guards, fallback handlers, session keys, relayers, contratos de recuperación y administradores de actualización pueden eludir el umbral ordinario o impedir su ejecución. Inventaríe estas vías y trate todo cambio de permisos como una transacción de alto riesgo. - **Riesgo de contrato y despliegue.** Errores, inicialización insegura, fallos de proxy o actualización y despliegues en la red equivocada pueden anular la política prevista. Verifique direcciones y código, evalúe auditorías en contexto, reduzca extensiones y vigile cambios de configuración. - **Carrera tras un compromiso y baja incompleta.** Un firmante comprometido puede actuar antes de confirmarse su eliminación, y quitar un propietario no deshace acciones ni permisos externos. Aplique un plan de incidentes, supervise continuamente y revoque por separado accesos organizativos y en cadena. ## Errores comunes - **«Más firmantes siempre significa más seguridad».** Un conjunto mayor puede reducir la concentración, pero aumenta riesgos de coordinación, phishing y disponibilidad. Elija propietarios y umbral según el modelo de amenazas y la capacidad operativa. - **«Una cartera 3-of-5 está controlada por cinco personas independientes».** La cadena cuenta claves o cuentas propietarias válidas, no personas. Dispositivos, respaldos, administradores o custodios compartidos pueden convertir propietarios nominalmente separados en un solo dominio. - **«Multifirma equivale a autenticación de dos factores o MPC».** Todos pueden distribuir control, pero difieren en credenciales, rutas de verificación, pruebas en cadena y supuestos de recuperación. - **«Cuando aprueba el umbral, la transferencia terminó».** Aprobación, ejecutabilidad, envío, inclusión y confirmación son estados distintos. La solicitud puede quedar pendiente o fallar. - **«La multifirma impide robos y exploits de contratos».** Solo limita las rutas de autoridad codificadas en su implementación. Un cuórum válido, módulo privilegiado, contrato vulnerable o recuperación insegura aún puede causar pérdidas irreversibles. ## Temas relacionados - [Gestión de claves privadas](/es/crypto/private-key-management/) - [Cartera MPC](/es/crypto/mpc-wallet/) - [Rotación de firmantes multifirma](/es/crypto/multisig-signer-rotation/) - [Riesgo de módulos multifirma](/es/crypto/multisig-module-risk/) - [Simulación de transacciones](/es/crypto/transaction-simulation/) ## Fuentes - [BIP 11: transacciones estándar M-of-N](https://bips.dev/11/) - Bitcoin Improvement Proposals (consultado: 2026-08-21) - [Descripción general de la tecnología blockchain](https://doi.org/10.6028/NIST.IR.8202) - NIST (consultado: 2026-08-21) - [Cuentas de Ethereum](https://ethereum.org/developers/docs/accounts/) - Ethereum.org (consultado: 2026-08-21) - [¿Cómo funcionan las cuentas inteligentes Safe?](https://docs.safe.global/advanced/smart-account-overview) - Safe Documentation (consultado: 2026-08-21) - [Módulos Safe](https://docs.safe.global/advanced/smart-account-modules) - Safe Documentation (consultado: 2026-08-21) - [Guards de Safe](https://docs.safe.global/advanced/smart-account-guards) - Safe Documentation (consultado: 2026-08-21) Source: https://wiki.fcontext.com/es/crypto/multisig-wallet/index.mdx