---
title: "Monedero con clave de sesión"
description: "Aprende cómo las claves de sesión de cuentas inteligentes delegan una autoridad limitada, qué restricciones deben aplicarse y cómo verificar, revocar y responder ante una clave filtrada."
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.

# Monedero con clave de sesión

> Solo con fines educativos; no constituye asesoramiento de inversión. Una clave de sesión filtrada o con permisos excesivos puede causar pérdidas irreversibles de activos digitales.

<a id="answer"></a>

## Respuesta directa

Una clave de sesión de un monedero suele ser una clave de firma secundaria, o una credencial delegada vinculada a ella, que una cuenta inteligente acepta únicamente conforme a reglas definidas. Esas reglas pueden limitar el tiempo, los contratos de destino, los selectores de función, los importes de tokens, el número de transacciones u otras condiciones. Su finalidad es permitir que una aplicación ejecute acciones repetidas sin pedir al titular que apruebe cada operación con el firmante principal.

La “clave de sesión” es un patrón de diseño, no un estándar universal de Ethereum. ERC-4337 ofrece validación programable de cuentas y validación temporal de `UserOperation`, mientras que sistemas modulares como ERC-7579 pueden alojar validadores, ejecutores y hooks. El código desplegado de la cuenta y sus módulos decide en última instancia qué puede hacer la clave. La caducidad por sí sola no vuelve segura una sesión, y borrar una copia del navegador no revoca necesariamente la autoridad registrada en cadena o incluida en una delegación aún vigente.

<a id="mechanism"></a>

## Cómo funciona

Un flujo habitual tiene 5 etapas:

1. El titular crea un par de claves nuevo en un dispositivo o autoriza una credencial que identifica al firmante de la sesión. La clave privada de sesión nunca debe enviarse al servidor de la aplicación, salvo que el diseño convierta expresamente a ese servidor en custodio de confianza.
2. El titular autoriza una política con el monedero principal. Algunos sistemas instalan la clave y la política en cadena; otros usan una delegación firmada que la cuenta valida cuando llega una operación.
3. La aplicación construye una operación y la firma con la clave de sesión. En un flujo ERC-4337, la lógica `validateUserOp` de la cuenta comprueba la firma y la política; la simulación de un bundler es una prueba de admisión, no una demostración de ejecución ni de seguridad.
4. La cuenta debe aplicar todas las restricciones antes de ejecutar. La autoridad efectiva puede resumirse como `A_effective = K ∩ P ∩ S`: la posesión de la clave (`K`), la política configurada (`P`) y el estado actual de la cuenta o la cadena (`S`) deben permitir la acción.
5. La sesión termina por caducidad, agotamiento del nonce o la cuota, revocación explícita, eliminación del módulo u otra vía de invalidación propia de la implementación. Confirma el estado resultante de la cuenta en la cadena correcta.

Antes de autorizar una sesión, verifica:

- el ID de cadena, la dirección de la cuenta inteligente, la implementación de la cuenta y la dirección del validador o módulo;
- la clave pública de sesión o el identificador de la credencial y dónde se almacenará su material privado;
- cada destino, selector de función, token y regla de destinatario permitidos, así como el límite de valor nativo y el tope de gasto por llamada o acumulado;
- `validAfter`, `validUntil`, las reglas de nonce, el número de usos y si el tiempo se mide mediante la marca temporal del bloque u otra fuente;
- si los lotes, las llamadas anidadas, `delegatecall`, las aprobaciones de tokens, la instalación de módulos, las actualizaciones de cuenta y las firmas de mensajes ERC-1271 están bloqueados salvo que sean imprescindibles;
- quién puede revocar la sesión, si el titular conserva una vía de recuperación independiente y si la revocación requiere Gas o un bundler o paymaster operativo.

La política debe inspeccionar la acción que realmente se ejecutará. Comprobar solo el destino externo de un lote puede dejar libres las llamadas internas; comprobar solo el destinatario ignorando la función y el valor produce el mismo problema. Un límite solo es efectivo si el código que lo aplica cubre todas las vías de ejecución.

<a id="example"></a>

## Ejemplo

Un monedero de juego crea una sesión de 24 horas. Solo permite llamadas a un contrato de juego verificado, bloquea `delegatecall` y las aprobaciones de tokens, limita el valor nativo a `0.02 ETH` por llamada y el gasto total a `20 USDC`. El juego puede enviar movimientos permitidos sin confirmaciones repetidas del titular, pero una solicitud para transferir un NFT ajeno debe fallar en la validación.

Antes de usarla, el titular registra la cuenta, la cadena, el módulo, la clave pública de sesión, la caducidad, los límites y el método de revocación. Prueba una acción de poco valor, verifica la llamada decodificada y el evento de la cuenta, y después prueba la revocación por separado. Esto confirma la vía configurada; no demuestra que el módulo carezca de vulnerabilidades ni que un dispositivo comprometido no pueda gastar hasta los límites restantes.

<a id="risks"></a>

## Riesgos y controles

- **Política demasiado amplia:** destinos comodín, selectores sin restricciones, aprobaciones ilimitadas, lotes o `delegatecall` pueden convertir una clave “limitada” en una autoridad casi equivalente a la del titular. Usa listas de permitidos explícitas y prohíbe las acciones administrativas.
- **Robo de la clave:** el almacenamiento del navegador, los registros, las copias de seguridad, las extensiones, el malware y los dispositivos compartidos pueden exponerla. Prioriza almacenamiento aislado o protegido por hardware cuando exista, plazos cortos y topes acumulados bajos.
- **Aplicación defectuosa:** una cuenta, validador, ejecutor o hook puede decodificar mal las llamadas o no cubrir una vía alternativa. Usa despliegues verificados, código revisado, auditorías y pruebas de evasión.
- **Repetición y confusión de contexto:** un nonce débil o la falta de vínculo con la cadena, cuenta, módulo o política previstos puede permitir la reutilización. Verifica el dominio firmado exacto y la protección contra repetición en cadena.
- **Suposiciones sobre la caducidad:** `validUntil` puede limitar una operación ERC-4337 sin eliminar automáticamente una clave registrada, una asignación de tokens u otra delegación. Comprueba el estado real de cada permiso tras la caducidad.
- **Fallo de revocación:** borrar datos locales solo elimina una copia del secreto. Revoca mediante la vía documentada de la cuenta y verifica el resultado en cadena; conserva Gas suficiente y una ruta alternativa controlada por el titular.
- **Módulos actualizables o maliciosos:** pueden tener amplios poderes de ejecución y una actualización puede cambiar la política. Revisa titulares, demora de actualización, poderes de pausa, dirección de implementación y procedimiento de eliminación.
- **Abuso de Gas y patrocinio:** la sesión puede gastar fondos de la cuenta en Gas o quedar inutilizable si un paymaster la rechaza. Limita las comisiones cuando sea posible y conserva una vía de envío independiente.

Si una clave de sesión puede estar expuesta, deja de usar la aplicación afectada, conserva el identificador de sesión y los hashes de transacción relevantes, y revoca o desactiva la clave desde un dispositivo limpio controlado por el titular. Después revisa operaciones pendientes y recientes, aprobaciones de tokens, módulos instalados, actualizaciones de cuenta y saldos en todas las cadenas compatibles. Mueve los activos restantes solo si el diseño hace poco fiable la revocación; acudir con prisa a un sitio de “recuperación” no verificado puede agravar la pérdida.

<a id="misconceptions"></a>

## Errores comunes

- **“Una clave de sesión no puede mover activos.”** Puede ejecutar cualquier acción permitida por su política, incluidas transferencias, intercambios, aprobaciones o firmas.
- **“ERC-4337 define los permisos de las claves de sesión.”** ERC-4337 proporciona un marco de validación y ejecución; la política depende del monedero o módulo.
- **“Una caducidad corta limita la pérdida máxima.”** La pérdida también depende de límites por llamada y acumulados, frecuencia, Gas, aprobaciones, precios y todas las vías alcanzables.
- **“Cerrar sesión revoca la clave.”** Puede borrar una copia local, pero no demuestra que el registro en cadena o una delegación firmada sean inválidos.
- **“Una simulación correcta significa que la operación es segura.”** Puede mostrar que la validación actual acepta la operación; no prueba la intención, inclusión futura, ejecución, finalidad ni ausencia de vulnerabilidades.

<a id="related"></a>

## Temas relacionados

- [Abstracción de cuentas](/es/crypto/account-abstraction/)
- [Riesgo de Paymaster en ERC-4337](/es/crypto/erc4337-paymaster-risk/)
- [Gestión de claves privadas](/es/crypto/private-key-management/)
- [Simulación de transacciones](/es/crypto/transaction-simulation/)
- [Firma del monedero](/es/crypto/wallet-signature/)

<a id="sources"></a>

## Fuentes

- [Session Keys & Delegation](https://docs.erc4337.io/smart-accounts/session-keys-and-delegation.html) - ERC-4337 Documentation (consultado: 2026-08-21)
- [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) - Ethereum Improvement Proposals (consultado: 2026-08-21)
- [ERC-7579: Minimal Modular Smart Accounts](https://eips.ethereum.org/EIPS/eip-7579) - Ethereum Improvement Proposals (consultado: 2026-08-21)
- [Safe Modules](https://docs.safe.global/advanced/smart-account-modules) - Safe Docs (consultado: 2026-08-21)

Source: https://wiki.fcontext.com/es/crypto/session-key-wallet/index.mdx