Bot de trading no-custodial: cómo funciona (y por qué importa después de FTX)

Por qué importa esta pregunta ahora

Durante diez años, "trading cripto automatizado" significaba registrarse en 3Commas o Cryptohopper y pegar tus claves API de Binance en su panel. El modelo funcionaba porque los exchanges eran rápidos, profundos y aparentemente seguros. Luego llegó 2022. FTX colapsó con 8.000 millones de dólares de fondos de clientes congelados. Celsius y BlockFi siguieron. En 2024, Bybit sufrió el mayor hack de exchange de la historia.

Cada evento reinició la pregunta que cada trader minorista debe responder: ¿confío a este venue mis claves, mi saldo y mi cola de retiros? Para una fracción creciente de usuarios, la respuesta es no. Se han movido al trading no-custodial — y los bots los han seguido.

Qué significa realmente "no-custodial"

Custodia es el derecho a mover los activos de alguien. Un sistema custodial retiene tus fondos en su propia wallet y le pides amablemente que haga cosas; un sistema no-custodial retiene tus fondos en una wallet que tú controlas, y cualquier acción requiere una firma de una clave que solo tú posees.

Si la empresa que ejecuta este bot desapareciera de la noche a la mañana, ¿podrías seguir retirando el 100% de tus fondos sin ayuda de nadie?

Para un bot no-custodial bien construido la respuesta es sí. Tus fondos viven en un contrato inteligente cuya clave de propietario generaste tú mismo. El bot tiene un permiso limitado para llamar una función en un contrato — usualmente el router del DEX. Si el operador del bot desapareciera, simplemente revocarías la sesión y tus activos seguirían en tu Safe, intactos.

Cómo se construye un bot no-custodial

1. Smart Account (Safe)

Los fondos del usuario viven en un contrato inteligente — típicamente un Safe (antes Gnosis Safe), el smart account más probado en batalla en Ethereum, custodiando decenas de miles de millones de dólares. El Safe tiene un propietario: tu cuenta externamente controlada (EOA), gobernada por tu seed phrase de MetaMask. El bot no es propietario. La plataforma no es propietaria. No hay clave de admin.

2. Módulo: ERC-7579 Smart Session

ERC-7579 es el estándar de smart accounts modulares que convierte un Safe en una wallet programable. Un módulo Smart Session adjunto a tu Safe registra, on-chain, exactamente qué puede hacer el bot:

• Validador: contrato que verifica la firma del bot.
• Políticas de acción: qué contratos puede llamar (p.ej. solo Uniswap V3 SwapRouter02).
• Restricciones de selector: qué funciones (p.ej. solo exactInputSingle).
• Límites de gasto: topes por token y por transacción.
• Expiración: timestamp Unix después del cual la sesión muere.

Lee más en EIP-7579 y la implementación de Smart Sessions de Rhinestone.

3. Servicio del bot

El propio bot es un servicio backend que retiene una clave de firma de sesión — una clave que solo puede firmar acciones que coincidan con las políticas anteriores. Si la clave del bot es robada, el atacante aún no puede hacer nada fuera de los límites de la sesión.

Smart Sessions: limitadas, revocables, on-chain

La propiedad única de una Smart Session es que los permisos son impuestos por la blockchain, no por un servidor. Una clave API normal es impuesta por el código de Binance. Si el código de Binance tiene un bug, o un insider abusa del acceso, la promesa de "solo lectura" puede fallar. Una Smart Session, en cambio, es impuesta por el consenso de Ethereum — el mismo mecanismo que asegura 400.000M de dólares en valor.

Lo que el bot NO puede hacer (y por qué)

• Enviar tokens a ninguna dirección externa — la única llamada permitida es el swap del DEX.
• Retirar fondos del Safe — no hay función de transferencia en la política.
• Añadirse como propietario del Safe — eso requiere aprobación del propietario (tu MetaMask).
• Aprobar tokens ilimitados a un contrato malicioso.
• Ejecutar operaciones después de revocación.
• Tocar fondos en otras cadenas o wallets — las sesiones son por-Safe.

Comparado con bots CEX por API

Compromisos honestos

• Configuración más pesada. Desplegar un Safe y otorgar una sesión toma 10-15 minutos vs los 60 segundos de pegar una clave API.
• Menos apalancamiento e instrumentos. La mayoría de bots no-custodiales cubren spot DEX. Perpetuos, opciones y estrategias de alto apalancamiento viven principalmente en CEXes todavía.
• Pagas gas. En L2 esto son centavos; en Ethereum mainnet puede ser significativo para operaciones pequeñas.
• Responsabilidad de auto-custodia. Si pierdes tu seed phrase, nadie puede recuperar tus fondos. No hay flujo "olvidé contraseña".

Para quién es un bot no-custodial

• Tienes más de 1.000 USD en cripto — no-custodial elimina riesgo de contraparte.
• Crees que el próximo fallo de exchange aún no ha ocurrido.
• Quieres DCA de horizonte largo sin estrés mensual sobre la integridad de la plataforma.
• Vives en una jurisdicción donde el acceso al exchange es inestable.

Cómo configurarlo sin las trampas

1. Usa hardware wallet para la clave de propietario. El propietario de tu Safe es la única parte que puede revocar o cambiar permisos.
2. Empieza en testnet. Sepolia es gratis. Despliega un Safe, otorga una sesión, ejecuta una estrategia, verifica que el bot hace lo que dice.
3. Lee la política antes de firmar. La transacción de otorgamiento muestra exactamente qué se le permitirá al bot.
4. Establece topes ajustados por token. Aunque el bot no puede transferir fuera, topes ajustados reducen el peor impacto de bugs.
5. Empieza con expiraciones cortas. Por defecto 30 días. Después de un mes ejecutándose bien, extiende a 90.
6. Verifica en un block explorer. Cada operación es una transacción on-chain pública.

Señales de alarma a evitar

• "Guardamos tu seed phrase encriptada." Cualquier producto que toca tu seed phrase es custodial disfrazado.
• Multi-sig con la plataforma como cofirmante. Si la plataforma es necesaria para autorizar un retiro, no estás en control.
• Sesiones sin expiración. Una sesión que dura para siempre derrota el propósito.
• Permisos vagos. Si no puedes ver exactamente qué contrato y qué función llamará el bot, no otorgues.
• Sin UI de revocación. La revocación debe ser un clic y completamente on-chain.
• Contratos de política de código cerrado. Los contratos que imponen la sesión deben estar verificados en Etherscan.