Renato Ulianov, fundador de DegenScan y SHIELD CryptoGuard explica cómo funciona su tecnología de trading automatizado, qué medidas aplica para proteger las claves API y por qué reconoce que sus herramientas todavía necesitan auditorías independientes.
La automatización del trading de criptomonedas promete liberar a los inversores de la necesidad de permanecer constantemente pendientes del mercado. Sin embargo, trasladar decisiones y operaciones a un sistema informático también introduce riesgos que no siempre resultan evidentes: órdenes duplicadas, interrupciones de conexión, discrepancias entre los registros de un bot y las posiciones reales de una cuenta o problemas relacionados con la custodia de credenciales.
Estos desafíos forman parte del trabajo de Renato Ulianov, fundador de DegenScan, una plataforma de trading automatizado que, según explica, cuenta actualmente con más de 50 suscripciones activas, principalmente entre traders particulares de su comunidad brasileña.
Ulianov también está detrás de SHIELD CryptoGuard, una extensión para Google Chrome diseñada para advertir sobre determinados sitios de phishing, aprobaciones de tokens potencialmente peligrosas y riesgos asociados a algunos contratos inteligentes.
Ambos productos son operados por Marbella Collins LLC, una compañía registrada en Florida, Estados Unidos, y comparten un pequeño equipo de desarrollo familiar.
En esta entrevista con Territorio Bitcoin, Renato Ulianov explica la arquitectura técnica de DegenScan, las medidas que aplica para proteger las claves de acceso a los exchanges y el estado actual de SHIELD CryptoGuard.
Sus respuestas incluyen detalles sobre pruebas formales de recuperación, limitaciones de seguridad todavía pendientes de resolver y la ausencia de auditorías externas independientes. También aclara que SHIELD, pese a haber sido presentada anteriormente como una herramienta basada en inteligencia artificial, todavía no utiliza esa tecnología.
DegenScan y su arquitectura de ejecución
¿Cómo nació DegenScan, qué problema pretende resolver y a qué tipo de usuario está dirigido actualmente?
DegenScan nació entre finales de 2024 y principios de 2025. Me molestaba depender de operar manualmente y perder oportunidades reales del mercado por no tener una plataforma automatizada.
En el trading manual puedes tener una buena estrategia, e incluso ganar bastante con ella, pero hay un límite de tiempo: las personas necesitamos dormir ocho horas al día.
DegenScan resuelve justamente eso: ejecuta estrategias de trading de forma automática, siguiendo condiciones que el usuario define previamente.
Hoy DegenScan tiene más de 50 suscripciones activas, de traders particulares, en su mayoría del público de mi canal en Brasil.
La nota técnica describe la recuperación determinista del sistema después de un reinicio. ¿Puedes explicar de manera accesible en qué consiste, qué función cumplen los 15 invariantes verificables y por qué son importantes en un sistema de trading automatizado?
Un bot de trading puede reiniciarse en cualquier momento: una actualización, un fallo del servidor, un corte de red. El peligro es que, al volver, el sistema no sepa qué órdenes dejó abiertas ni qué se ejecutó mientras estaba caído, y acabe duplicando una orden o dejando una posición sin control.
La recuperación determinista resuelve eso. Cada orden lleva un identificador propio que asignamos nosotros. Al reiniciar, el motor busca cada orden abierta por ese identificador en el exchange, reconcilia las ejecuciones que ocurrieron durante la caída y retoma exactamente desde donde estaba. Ante el mismo estado, el resultado es siempre el mismo.
Los 15 invariantes son reglas que el sistema no puede romper nunca. Un ejemplo: si el estado que el sistema tiene guardado no coincide con el estado real de la cuenta en el exchange, el bot solo puede reducir posiciones, nunca abrir nuevas, hasta que una persona revise la diferencia.
Son importantes porque convierten «creemos que funciona» en algo que se puede comprobar: cada invariante tiene pruebas automáticas, y el camino de recuperación lo modelamos formalmente en TLA+. El modelo reprodujo el fallo original en 7 estados y verificó la corrección en unos 5,6 millones de estados.
Un caso real: en un reinicio del 2 de octubre, el motor retomó 4 planes de trading, reconcilió 5 ejecuciones ocurridas durante la caída y no dejó ninguna orden huérfana, en 85 milisegundos.
Una precisión importante: esta recuperación determinista es la de la capa de ejecución que describe la nota técnica (el motor de los planes de trading), no la de todos los bots de la plataforma.
¿Cómo responde DegenScan ante situaciones como órdenes ejecutadas parcialmente, interrupciones en la conexión con el exchange, respuestas duplicadas de una API o diferencias entre el estado local y el estado real de la cuenta?
Ante órdenes ejecutadas parcialmente, el sistema no se fía de la cantidad que pidió, sino del tamaño real de la posición que informa el exchange, y trabaja a partir de ese dato.
Si se produce un corte de conexión o el exchange no responde en 10 segundos, el bot se detiene y no reenvía la orden a ciegas. En el ciclo siguiente consulta el estado real y decide a partir de ahí.
En la capa de ejecución, cada orden lleva su identificador propio, así que una respuesta repetida se reconoce como la misma orden y no genera una segunda. Los bots más simples de la plataforma no usan todavía este mecanismo; protegerlos igual está en nuestra lista de trabajo.
Cuando existen diferencias entre el estado local y el de la cuenta, el bot pasa a un modo en el que solo puede reducir posiciones, hasta que una persona revisa y reconcilia la diferencia.
El usuario debe proporcionar una clave API de su exchange. ¿Dónde se almacena, cómo se protege y qué impide que pueda utilizarse para retirar fondos? ¿Esta arquitectura o su implementación han sido auditadas o validadas por terceros?
Las claves se guardan en el servidor de producción de la plataforma, cifradas con AES-256-GCM. La clave de cifrado no está en el código: existe solo en el entorno de producción, y sin ella el servidor no arranca.
Las claves de los usuarios solo están descifradas en memoria mientras el bot está en funcionamiento. Este esquema lo reforzamos esta semana y hoy todas las claves guardadas en la plataforma principal están en ese formato.
El servicio de la capa de ejecución guarda sus claves en una base de datos cifrada aparte, y la misma revisión está en curso allí.
Sobre la retirada de fondos, quiero ser preciso, porque depende del exchange:
En Hyperliquid solo aceptamos una «agent wallet», una clave que por diseño de Hyperliquid puede operar pero no retirar fondos. Si alguien intenta guardar la clave principal de su cuenta, la plataforma la rechaza.
En el bot de arbitraje de OKX y en la herramienta fiscal de Binance comprobamos los permisos de la clave antes de aceptarla.
En los demás exchanges esa comprobación automática todavía no existe; la estamos desarrollando. Hoy la protección depende de que el usuario cree la clave solo con permiso de trading, sin permiso de retirada.
No ha habido ninguna auditoría independiente de esta parte. Tenemos pruebas automáticas y revisiones internas, pero ningún tercero ha validado todavía la implementación.
SHIELD CryptoGuard y la seguridad en Web3
¿Qué relación existe entre DegenScan y SHIELD CryptoGuard en términos de equipo, tecnología y estructura empresarial?
Las dos están operadas por la misma empresa, Marbella Collins LLC, en Florida.
Son productos distintos: DegenScan es una plataforma que ejecuta estrategias de trading automatizadas, y SHIELD es una extensión de navegador que avisa al usuario de posibles estafas.
El equipo es pequeño, eminentemente técnico y compartido entre los dos productos: mi mujer, mi hijo y yo. Mi hijo programa conmigo con apoyo de herramientas de inteligencia artificial.
La documentación pública atribuye SHIELD CryptoGuard en unas páginas a Edutech Wise FZCO, en Emiratos Árabes Unidos, y en otras a Marbella Collins LLC, en Florida. ¿Qué entidad desarrolla y opera actualmente la extensión y cuál es responsable del tratamiento de los datos?
Migré la operación de los dos productos, DegenScan y SHIELD, de una empresa con sede en Dubái, Edutech Wise FZCO, a una empresa estadounidense, Marbella Collins LLC, en Florida.
Lo hice por razones operativas: los pagos, la ficha en la Chrome Web Store y los contratos quedan centralizados en una sola empresa.
Hoy quien desarrolla, opera y responde por los datos de SHIELD y de DegenScan es Marbella Collins LLC.
Algunas páginas antiguas todavía mencionaban Edutech; ya las hemos corregido y seguimos revisando.
Para el usuario la experiencia no cambia: las suscripciones de los dos productos se cobran a través de Stripe, que antes operaba Edutech y ahora opera Marbella Collins LLC.
¿Qué funciones están realmente operativas en la versión disponible actualmente en Chrome y cuáles continúan en desarrollo?
La versión pública actual es la 1.0.4, publicada en la Chrome Web Store el 6 de octubre.
Avisa cuando el usuario entra en un sitio de phishing conocido, es decir, una dirección falsa que imita un sitio legítimo y conocido.
También avisa antes de firmar una aprobación ilimitada de tokens y otros tipos de firmas potencialmente peligrosas (setApprovalForAll, Permit y Permit2).
El aviso de aprobación ilimitada no funcionaba en la versión anterior; lo corregimos en esta. Todo eso es gratuito y no requiere cuenta.
En la versión PRO consultamos además la API de GoPlus Security para comprobar si un token es un honeypot, o sea, si se puede vender sin tasas prohibitivas. Esta función está disponible hoy en la red Ethereum.
Lo que sigue en desarrollo es la inteligencia artificial: hoy SHIELD no la usa y está prevista para próximas actualizaciones.
SHIELD se presenta como una herramienta basada en inteligencia artificial, pero también utiliza listas de dominios, reglas de detección y la API de GoPlus Security. ¿Qué parte del análisis emplea modelos de IA y qué decisiones se basan en reglas o servicios externos?
SHIELD todavía no usa inteligencia artificial; está previsto incorporarla en próximas actualizaciones.
Hoy la protección de navegación funciona con listas de sitios peligrosos, la comparación con nombres de sitios conocidos y reglas fijas, todo dentro del navegador del usuario.
La comprobación de honeypot de la versión PRO usa la API de GoPlus Security.
El texto antiguo de la ficha en la tienda hablaba de IA, y eso no era correcto. Lo hemos corregido en la nueva versión.
Existe además otra extensión con un nombre parecido, CryptoGuard, de otra empresa, que sí se anuncia con IA; no es la nuestra.
¿Qué permisos solicita la extensión y qué datos puede leer o transmitir cuando el usuario navega, conecta una cartera o prepara una transacción? ¿Qué información se procesa localmente, qué datos reciben vuestros servidores o proveedores externos y durante cuánto tiempo se conservan?
La extensión pide los permisos de Chrome activeTab, storage, webNavigation, tabs y notifications, y acceso a todas las páginas.
Ese acceso amplio es necesario para poder avisar de un sitio de phishing en el momento en que el usuario lo abre, sea cual sea.
Las direcciones que el usuario visita y las transacciones que prepara se analizan dentro del propio navegador y no se envían a nuestros servidores.
Solo salen datos en tres casos:
- El correo electrónico del usuario, únicamente si inicia sesión, para comprobar su suscripción.
- En la versión PRO, la dirección del token y la red se envían a la API de GoPlus Security para la comprobación de honeypot, nunca la dirección de la cartera ni el correo.
- La extensión descarga una lista pública de sitios peligrosos, que no contiene datos personales.
En cuanto a la conservación de datos, quiero explicarlo con franqueza.
En el navegador, los datos se guardan hasta que el usuario cierra sesión o desinstala la extensión. En GoPlus se aplica su propia política de privacidad.
En nuestro servidor, el correo y el estado de la suscripción se guardan hasta que se borran manualmente, porque hoy no hay un plazo automático.
Los registros de acceso del proveedor de hosting pueden incluir el correo y la IP, porque la extensión envía el correo en la dirección de la consulta, y su plazo de conservación lo define la plataforma.
Son dos puntos que no nos gustan y que estamos corrigiendo: el correo dejará de ir en la dirección de la consulta, y habrá un plazo de borrado automático y una opción para borrar la cuenta.
La corrección del servidor ya está preparada y probada, y la publicaremos en los próximos días.
¿Habéis medido los falsos positivos y falsos negativos en la detección de phishing, dominios similares, honeypots y aprobaciones peligrosas? ¿Qué metodología utilizáis y existe alguna auditoría independiente de la extensión o de sus resultados?
Todavía no hemos medido formalmente los falsos positivos ni los falsos negativos.
Un falso positivo ocurre cuando la herramienta avisa sobre algo legítimo.
SHIELD es una herramienta de aviso, no una garantía: ayuda al usuario a percibir un riesgo, pero la ausencia de una alerta no prueba que un sitio o una firma sean 100 % seguros.
Por ahora tampoco existe una auditoría independiente de la extensión.
Nuestro objetivo es mejorar la seguridad de la navegación en Web3.