--- title: "Riesgo del propietario y la recuperación de una cuenta inteligente" description: "Audite quién puede controlar una cuenta inteligente, cómo la recuperación cambia al propietario, qué demoras y derechos de cancelación se aplican y si módulos o actualizaciones crean vías ocultas de toma de control." 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. # Riesgo del propietario y la recuperación de una cuenta inteligente > Solo con fines educativos; no constituye asesoramiento de inversión, jurídico ni de seguridad. Un error de recuperación o configuración puede transferir el control de una cuenta inteligente o bloquearla de forma permanente. ## Respuesta directa Una cuenta inteligente está controlada por la lógica de autorización desplegada para ella, no necesariamente por una sola clave privada. Un propietario o validador puede aprobar operaciones normales, mientras que un guardián, módulo de recuperación, ejecutor o administrador de actualizaciones puede tener otra vía para sustituir al propietario o ejecutar transacciones. La recuperación reduce la probabilidad de que la pérdida de una clave inutilice la cuenta, pero añade otra superficie de toma de control. Audite cada vía capaz de autorizar ejecuciones, cambiar validadores o propietarios, instalar módulos, actualizar código o cancelar y finalizar la recuperación. Las etiquetas de la interfaz como «propietario» y «guardián» no prueban la autoridad real del contrato. Registre el resultado en una tabla de permisos: dirección exacta en cadena, rol, acción invocable, umbral, demora, autoridad de cancelación, vencimiento, alcance de gasto, autoridad de actualización y dominio de control independiente. Revísela después de cada cambio de configuración y en cada cadena donde exista la cuenta. ## Cómo funciona 1. **Identifique la cuenta y el código.** Verifique el ID de cadena y la dirección de la cuenta; determine la implementación, el proxy o beacon, la fábrica y la versión. Para un proxy ERC-1967, lea los slots de implementación, beacon y administrador en lugar de confiar en una insignia de la interfaz. 2. **Enumere las vías de autorización.** Lea propietarios y umbrales, validadores ERC-4337, validadores, ejecutores, hooks y controladores fallback ERC-7579, módulos y guards tipo Safe, claves de sesión, contratos de recuperación y cualquier administrador de emergencia o actualización. Un ejecutor o módulo Safe puede ejecutar sin el umbral normal de propietarios. 3. **Descodifique la máquina de estados de recuperación.** Determine quién puede proponer un propietario sustituto, cómo se cuentan las aprobaciones de guardianes, si caducan, cuándo comienza la demora, quién puede cancelar, quién puede finalizar y qué ocurre si una recuperación se sustituye o repite. No suponga que todos los contratos de «recuperación social» siguen la misma secuencia. 4. **Pruebe independencia y disponibilidad.** Varias direcciones no son independientes si las controla el mismo dispositivo, persona, cuenta en la nube, bóveda de contraseñas, custodio o administrador. Confirme que el umbral siga siendo alcanzable tras un fallo previsto sin conceder a un dominio de control poder suficiente para tomar la cuenta. 5. **Revise la autoridad de configuración.** Determine quién puede añadir o quitar guardianes, validadores, ejecutores, hooks, módulos o controladores fallback; cambiar el umbral o la demora; suspender la cancelación; o actualizar el código de cuenta y recuperación. Un timelock solo sirve si otro rol no puede eludir su demora y su vía de cancelación. 6. **Supervise y verifique.** Suscríbase o consulte de forma independiente cambios de recuperación, propietario, módulo, umbral, implementación y administrador. Tras cualquier operación, descodifique la transacción y verifique recibos, eventos, almacenamiento y el conjunto final de propietarios en la cadena correcta; una notificación de éxito de la interfaz no basta. ## Ejemplo práctico Suponga que una cuenta tiene al propietario `O` y tres guardianes `G1`, `G2` y `G3`. Cualquier `2-of-3` guardianes puede proponer al nuevo propietario `N`; comienza entonces una demora de `24-hour`; `O` puede cancelar durante ella; y cualquiera puede finalizar al vencer. El módulo de recuperación puede llamar a la función de cambio de propietario sin que `O` apruebe esa transacción final. Las etiquetas sugieren recuperación distribuida, pero `G1` y `G2` son aplicaciones respaldadas en la misma cuenta en la nube. Comprometer esa credencial concede a un atacante el umbral efectivo `2-of-3`. Propone a `N`; si la supervisión o cancelación falla durante `24 hours`, la finalización transfiere el control aunque nunca se haya robado la clave privada de `O`. La auditoría marca por ello `G1` y `G2` como un solo dominio de control, verifica dirección y código del módulo de recuperación, prueba la cancelación desde un dispositivo no comprometido, confirma qué evento inicia la demora y comprueba si un administrador puede sustituir el módulo de inmediato. No ejecuta una recuperación real en la cuenta que guarda activos salvo que la implementación ofrezca un proceso de prueba documentado y reversible con seguridad. ## Riesgos y controles - **Guardianes correlacionados:** use dispositivos, credenciales, personas o custodios realmente independientes; pruebe contactos y recuperación sin reunir frases semilla. - **Módulo o ejecutor con poder excesivo:** inspeccione el código instalado y el alcance exacto invocable. Quite módulos sin uso por la vía documentada y verifique la eliminación en cadena. - **Umbral débil:** evalúe resistencia a la toma y disponibilidad. Un umbral nominal mayor no ayuda si los firmantes comparten dominio; uno inalcanzable puede bloquear la cuenta. - **Demora ausente o eludible:** verifique en cadena la demora, el evento que la inicia, quién puede acortarla y toda vía capaz de cambiar inmediatamente al propietario. - **Cancelación ineficaz:** ensaye detección y cancelación, conserve gas nativo y una ruta de envío independiente cuando sea necesario y compruebe si cancelar exige al propietario anterior, un cuórum u otro rol. - **Toma mediante actualización:** supervise cambios de implementación, beacon y administrador. Considere que un administrador capaz de actualizar sin demora puede cambiar todas las reglas de recuperación documentadas. - **Interfaz maliciosa o desactualizada:** verifique por separado cadena, cuenta, módulo, propietario propuesto, umbral, demora y calldata. Nunca revele una frase semilla ni clave privada a un servicio de «recuperación». - **Finalización falsa:** tras cancelar o finalizar, confirme el recibo y el estado final de almacenamiento. Compruebe que propietario y módulos previstos están activos y que la propuesta no deseada ya no puede ejecutarse. Si aparece una recuperación no autorizada, deje de firmar solicitudes ajenas y conserve el ID de propuesta, hash de transacción, calldata, bloque, dirección del módulo y estado actual. Desde un dispositivo no comprometido, verifique la alerta con un RPC independiente, utilice la vía de cancelación documentada si aún está disponible y supervise finalización, actualizaciones, cambios de módulos y transferencias. Si quizá ya perdió el control, siga un plan de incidentes redactado de antemano y contacte solo con el proyecto o custodio por canales autenticados; una transferencia improvisada puede sufrir front-running o revelar el destino. ## Errores comunes - **«El propietario es la única cuenta que puede mover activos».** Validadores, ejecutores, módulos, contratos de recuperación o código actualizado pueden proporcionar otras vías. - **«Tres guardianes significan tres partes independientes».** El contrato cuenta aprobaciones válidas de direcciones; no detecta dispositivos, copias de seguridad ni administradores compartidos. - **«Una demora de `24-hour` garantiza tiempo para reaccionar».** También hacen falta supervisión, autoridad de cancelación utilizable, gas e inclusión; otra vía privilegiada puede eludirla. - **«Quitar un guardián termina su acceso».** Confirme la configuración final en cadena y revise otros roles, módulos, claves de sesión y recuperaciones pendientes ligados a esa parte. - **«Soporte puede restaurar cualquier cuenta inteligente».** Solo la autoridad codificada o configurada previamente en cadena puede cambiar una cuenta de autocustodia. Sin propietario ni vía de recuperación válidos, el acceso puede perderse para siempre. ## Temas relacionados - [Abstracción de cuenta](/es/crypto/account-abstraction/) - [Riesgo de módulos multifirma](/es/crypto/multisig-module-risk/) - [Rotación de firmantes multifirma](/es/crypto/multisig-signer-rotation/) - [Gestión de claves privadas](/es/crypto/private-key-management/) - [Simulación de transacciones](/es/crypto/transaction-simulation/) ## Fuentes - [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) - [ERC-7579: Minimal Modular Smart Accounts](https://ercs.ethereum.org/ERCS/erc-7579) - [Safe Modules](https://docs.safe.global/advanced/smart-account-modules) - [Safe.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/Safe.sol) - [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) Source: https://wiki.fcontext.com/es/crypto/smart-account-owner-recovery-risk/index.mdx