Smart Sessions explicadas: cómo ERC-7579 deja a los bots operar sin tus claves

El problema que resuelven Smart Sessions

El trading automatizado necesita una clave que pueda firmar transacciones sin input humano. La auto-custodia necesita que cada clave esté controlada por el usuario. Estos objetivos parecen incompatibles — y lo fueron durante años. El compromiso al que los usuarios se conformaron era malo: dar a un CEX una clave API, dar a una plataforma de bots una clave privada, dar a una wallet custodial una seed phrase.

Las Smart Sessions arreglan la asimetría. Permiten que un contrato smart account haga cumplir, a nivel EVM, un permiso estrictamente acotado para un firmante de terceros. El bot obtiene una clave. La clave funciona. La clave no puede hacer nada fuera de la política. La blockchain misma es el que hace cumplir.

La garantía criptográfica es precisa: aunque el servidor del bot esté completamente comprometido, el atacante solo puede ejecutar transacciones que coincidan con la política de sesión on-chain. Cualquier otra cosa revierte antes de tocar los fondos del usuario.

ERC-7579 en una página

ERC-7579 es un estándar para smart accounts modulares. Donde ERC-4337 definió cómo los smart accounts validan y ejecutan transacciones a través de un bundler, ERC-7579 define cómo esas cuentas componen funciones como módulos instalables. Tres tipos de módulos importan:

• Validadores — contratos que validan UserOps. Responden: "¿está autorizada esta firma?"
• Ejecutores — contratos que pueden ejecutar llamadas desde la cuenta.
• Hooks — contratos que corren antes o después de cada ejecución. Imponen invariantes.

Lee la especificación en eips.ethereum.org/EIPS/eip-7579.

Anatomía de una Smart Session

Una sesión, conceptualmente, es una tupla almacenada en el storage del contrato:

• Firmante de sesión (clave pública).
• Validador de sesión.
• Políticas de acción. Array de tuplas (contrato objetivo, selector de función).
• Políticas ERC-1271. Restricciones para firma de mensajes off-chain.
• Políticas user-op. Restricciones sobre UserOps (max gas, llamadas por op).
• Límites de gasto. Topes por token y agregados.
• Periodo de validez.

Políticas de permisos y validadores

El sistema de políticas en Smart Sessions es componible. Cada política es un contrato separado implementando la interfaz IPolicy, y una sesión puede apilar múltiples políticas que todas deben pasar.

• SudoPolicy — sin restricciones. Casi nunca apropiado para bots externos.
• UsageLimitPolicy — número máximo de llamadas.
• ValueLimitPolicy — máximo valor ETH.
• ERC20SpendingLimitPolicy — máximo monto de tokens, por token.
• UniswapPolicy / CallerPolicy — políticas especializadas.
• TimeFramePolicy — válido solo entre dos timestamps.

El SDK de módulos de Rhinestone provee contratos de política listos. Ver docs.rhinestone.wtf.

Ciclo de vida: otorgar, usar, revocar

Otorgar

Otorgar una sesión es una sola transacción firmada por el propietario (tu MetaMask). La transacción codifica la política completa y la instala en el módulo Smart Sessions de tu Safe.

Usar

Cada vez que el bot actúa, construye un UserOp ERC-4337, lo firma con la clave de sesión y lo envía a un bundler. El bundler reenvía al EntryPoint, que llama a la función de validación de tu Safe.

Revocar

Revocar llama a removeSession(sessionId). La clave de firma del bot se vuelve efectivamente inútil para tu cuenta el momento en que la transacción de revocación es minada.

Cómo encaja con ERC-4337

1. El bot construye un UserOp dirigido a tu Safe.
2. El bot firma el hash con la clave de sesión.
3. El bot envía el UserOp a un bundler.
4. El bundler simula y envía al EntryPoint.
5. EntryPoint llama validateUserOp en el Safe.
6. La lógica 7579 enruta validación al módulo Smart Sessions.
7. Smart Sessions verifica la firma y luego itera políticas.
8. Si todas pasan, el Safe ejecuta.
9. Si alguna falla, la transacción revierte completa.

Recorrido concreto — alcance bot trading

Supón que DCA Bot quiere correr un DCA USDC → WETH en Arbitrum. La sesión necesita:

1. Permiso para llamar SwapRouter02, específicamente exactInputSingle.
2. Pre-aprobación de USDC al router.
3. Tope de gasto: max 500 USDC por swap, 5.000 USDC por semana.
4. Whitelist de tokens: USDC y WETH.
5. Expiración: 30 días.

El usuario firma una vez. De ahí en adelante, cada DCA semanal el bot construye un UserOp, firma con la clave de sesión y envía. El trace on-chain muestra: Safe → SwapRouter02 → exactInputSingle → Pool → Safe recibe WETH. Los fondos nunca dejan el Safe.

Qué ataques derrota (y cuáles no)

Derrota

• Compromiso del servidor del bot. Atacante con la clave solo puede ejecutar swaps dentro de la política.
• Abuso interno en la plataforma. Igual: insider acotado por la política.
• Phishing al bot. Una dapp maliciosa no puede pretender ser el bot.
• Operador del bot volviéndose deshonesto. No puede exceder la política on-chain.
• Sesiones olvidadas. Acotadas por tiempo; expiran automáticamente.

NO derrota

• Usuario firmando una transacción de otorgamiento maliciosa.
• Bugs de smart contract en Safe, módulo Smart Sessions o políticas.
• El propio EOA del usuario siendo robado.
• Pérdidas de estrategia.

Comparado con multi-sigs y EOAs

Construyendo con Smart Sessions hoy

• Safe + ERC-7579 Adapter — Safe singletons configurados como cuentas 7579.
• Rhinestone Module SDK — librería TypeScript para construir, instalar y usar Smart Sessions.
• ZeroDev Kernel — cuenta 7579 alternativa con soporte nativo.
• Bundlers: Pimlico, Voltaire, Stackup.