Una auditoría estudiantil del agente de trading con IA **«Omo»**, basado en Solana (SOL), reveló que ninguna de las 174 órdenes registradas en la cadena coincidía con las firmas de la cartera que el propio Omo había proporcionado. El proyecto había llamado la atención al mostrar públicamente una cartera cuyo valor superaba los 200.000 dólares.

Puntos clave:

  • Un investigador estudiantil verificó una decisión no pública (sellada) de Omo y confirmó que la transacción correspondiente en la cadena era una transferencia de tokens desde otra cartera.

  • Tras revisar todos los datos publicados por Omo, ninguna de las 174 órdenes comprometidas estaba vinculada a una firma de la cartera que el agente había indicado.

  • El artículo propone usar claves de firma almacenadas en dispositivos de seguridad de hardware, pero el autor aclara que el hardware por sí solo no habría evitado los demás fallos del agente.

Resultados de la auditoría estudiantil

**Charlie Sneed**, miembro del club de blockchain de la Universidad de Oregón, en Estados Unidos, publicó un informe de auditoría el 28 de septiembre en el marco de un concurso de investigación organizado por **Ledger**, empresa de carteras de hardware. Ledger sostiene que no respalda el contenido del informe. Sneed inició la investigación cuando el panel de Omo mostraba ganancias de cartera que crecían rápidamente. Más tarde, Omo dejó de operar y su sitio web quedó fuera de servicio.

Omo comenzó a funcionar el 9 de agosto y operó principalmente con memecoins hasta el 31 de agosto. Antes de enviar cada orden, registraba en la cadena de bloques de Solana el proceso de toma de decisiones como una huella criptográfica en forma de hash y, unos 20 minutos después, publicaba el texto completo de esa decisión para que cualquiera pudiera comparar y verificar ambos datos.

Según la documentación del proyecto, cualquier persona ajena puede realizar cuatro verificaciones usando únicamente las herramientas de hash y un nodo público de Solana, siguiendo la guía de verificación publicada en GitHub. La cuarta y última consiste en comprobar «si la cartera de Omo publicada firmó realmente esa operación». El documento especifica que «si se detecta una firma de otra clave, la ejecución queda invalidada». Precisamente esta verificación no se superó en la auditoría.

Sneed cotejó manualmente uno de los compromisos más antiguos entre aquellos en los que la operación llegó a ejecutarse. La transacción on-chain asociada a esa decisión, tomada el 21 de agosto, era una simple transferencia de tokens a varias direcciones, incluida la cartera de Omo, y no había indicios de que se tratara de una orden de compra firmada por Omo. Además, la cartera firmante no era la de Omo que había señalado el proyecto, sino otra distinta.

Artículo relacionado: Los robotaxis de Tesla tendrán restricciones de circulación después de las 11 de la noche… la tarea de las «mascotas» de Musk

La observación de Sneed sobre la «gestión de claves»

En su informe, Sneed evaluó que «la estructura criptográfica en sí funcionó según lo previsto». Explicó que la mayoría de los problemas ya eran visibles en el código y que no encontró indicios de fraude intencionado ni de información falsa. La impactante cifra de cero de 174 también se calculó a partir de la página de datos que Omo publicó directamente.

Sneed señaló que la verdadera vulnerabilidad era la «custodia» (el almacenamiento de activos y claves). Omo funcionaba trasladando al servidor una clave copiada desde una aplicación móvil, y el código que emparejaba las ejecuciones tampoco verificaba correctamente las firmas de las carteras. Según el análisis, el diseño hacía inevitable una discrepancia estructural entre las supuestas «órdenes de Omo» y quien realmente las firmaba on-chain.

Propuso tres medidas de mejora. La principal es «usar claves de firma en un módulo de seguridad de hardware controlado directamente por el agente», una categoría de productos que ofrecen empresas de carteras de hardware como Ledger. Sin embargo, Sneed matizó que «las claves de hardware por sí solas no habrían resuelto ni el problema de una tasa de éxito (rentabilidad) de apenas el 7,1 %, ni el de la función de búsqueda web, que permaneció averiada durante varios días». Es decir, mejorar la gestión de claves es un «requisito indispensable», pero no garantiza el rendimiento del agente ni permite controlar todos sus riesgos.

Se extienden los riesgos del trading con agentes de IA

Desde principios de este año, las principales plataformas han ido abriendo sus puertas al trading con IA y agentes autónomos. Binance, una de las mayores plataformas de intercambio del mundo, permitió operar a los agentes de IA a partir del 20 de agosto. En una entrevista, el vicepresidente de producto, **Jeff Li**, afirmó: «Ni siquiera nosotros podemos examinar realmente el proceso de toma de decisiones (razonamiento) de las órdenes de estos agentes».

La correduría minorista estadounidense Robinhood también afirmó que, a 29 de septiembre, había más de 150.000 cuentas en las que agentes de IA operaban en nombre de sus titulares, y declaró oficialmente que no llevaba a cabo una supervisión directa ni auditorías de esos agentes. En el informe anual de supervisión publicado en 2026 por la Autoridad Reguladora de la Industria Financiera de EE. UU. (FINRA), la «autonomía de los agentes» y la «auditabilidad» se señalaron asimismo como preocupaciones importantes entre los riesgos relacionados con la IA generativa.

En un contexto de rápida expansión del trading basado en agentes de IA, el caso de Omo en Solana se considera un claro ejemplo de los riesgos estructurales de confiar la gestión de activos a agentes autónomos sin contar con sistemas adecuados de gestión de claves, verificación de firmas, concordancia entre datos on-chain y off-chain, ni mecanismos para verificar su rendimiento.

Para seguir leyendo: Robinhood, Binance y Coinbase ya permiten que los agentes de IA también envíen órdenes: ¿qué deben saber los inversores?