Intelligent Oracles en la jungla de la web

Para entender adónde vamos, primero tenemos que reconocer las limitaciones del punto en el que estamos. Los contratos inteligentes tradicionales son potentes, pero en esencia están aislados. Dependen de código determinista y del estado interno on-chain, y en la práctica funcionan dentro de una caja negra. Para «ver» el mundo exterior necesitan intermediarios externos (los oráculos estándar) que les hagan llegar los datos.

Los Intelligent Oracles rompen este aislamiento.

Construidos sobre GenLayer, actúan como una puerta al mundo exterior y funcionan en un entorno Python nativo capaz de ejecutar tareas no deterministas. En términos funcionales, un Intelligent Oracle es un Intelligent Contract diseñado para obtener cualquier dato público de la web (texto, HTML o imágenes), procesarlo con grandes modelos de lenguaje (LLM) y alcanzar sobre el resultado un consenso sin terceros de confianza. No se limitan a almacenar datos: tienen la lógica necesaria para interpretarlos.

El reto de ingeniería está en el consenso: ¿cómo se pone de acuerdo una red descentralizada sobre el contenido de un sitio web dinámico? Como los datos de la web y la inferencia de IA pueden ser no deterministas, distintos nodos pueden devolver resultados distintos para la misma tarea.

GenLayer lo resuelve con Optimistic Democracy. En lugar de depender de una única fuente de datos, se encarga a un conjunto de validadores elegidos al azar que alcancen un consenso. Un líder, también elegido al azar, propone un resultado, y un comité de validadores lo verifica según unas «reglas de acuerdo» predefinidas.

Estas reglas se conocen como Principios de Equivalencia:

• Equivalencia estricta (gl.eq_principle.strict_eq): los validadores ejecutan la tarea por su cuenta y exigen que su resultado coincida carácter a carácter con el del líder. Ideal para datos deterministas, como los precios históricos de los tokens.
• Equivalencia comparativa (gl.eq_principle.prompt_comparative): los validadores ejecutan la tarea por su cuenta. Para verificar, lanzan un prompt a un LLM que evalúa tanto el resultado del líder como el suyo propio según un criterio definido por el desarrollador. Hay acuerdo si el LLM determina que la relación entre ambos resultados cumple ese criterio.
• Equivalencia no comparativa (gl.eq_principle.prompt_non_comparative): los validadores no vuelven a ejecutar la tarea; en su lugar, usan un LLM como juez para comprobar si el resultado que propone el líder cumple de forma lógica un criterio definido por el desarrollador.
• Equivalencia personalizada: para casos de uso avanzados, los desarrolladores no están limitados a estas opciones predeterminadas. Puedes definir funciones de Python totalmente arbitrarias que dicten exactamente cómo deben alcanzar el consenso el líder y los validadores.

Nota: un análisis más profundo de la mecánica de Optimistic Democracy y de los Principios de Equivalencia queda fuera del alcance de este artículo. Si quieres una explicación completa de la arquitectura del consenso, puedes leer más aquí.

El panorama de los oráculos

La diferencia entre los Intelligent Oracles y las soluciones existentes se entiende mejor si clasificamos las formas en que los datos entran en la blockchain. Para funcionar, los contratos inteligentes dependen de oráculos: intermediarios off-chain que llevan los datos on-chain. Todos se reducen a dos arquitecturas dominantes: fuentes de datos en tiempo real o propuestas de datos de participantes humanos que se pueden impugnar.

Los oráculos basados en fuentes de datos (Chainlink, Pyth) son servicios de suscripción de alta velocidad. Son increíblemente eficientes para datos estándar, como los precios de los activos, pero rígidos: la existencia de tu aplicación depende de que exista una fuente de datos concreta para ella.

Para sortear esta limitación, los oráculos optimistas (UMA) permiten propuestas de datos más abiertas, aunque más lentas. Cualquiera puede enviar un resultado depositando una fianza, y el sistema lo da por cierto salvo que alguien lo impugne expresamente durante un «periodo de impugnación» (liveness period). Por flexible que sea, este modelo choca con un techo oculto: la atención humana. Las disputas requieren votación manual. No puedes pedir a una DAO que verifique 10.000 microtransacciones al día. Por eso estos modelos tienden de forma natural a los mercados de alto valor y baja frecuencia, y en la práctica ignoran la «larga cola» de disputas cotidianas en las que hay menos en juego.

GenLayer abre una tercera vía: los Intelligent Oracles acaban con la ceguera dando a tu aplicación un cerebro y acceso al mundo exterior. Abiertos y sin terceros de confianza.

¿Cómo funcionan los Intelligent Oracles?

La aplicación más habitual de un Intelligent Oracle es convertir la web, caótica y desestructurada, en hechos on-chain estructurados.

Para entender el potencial de los Intelligent Oracles no hacen falta escenarios hipotéticos. Todos los desarrolladores se apoyan en el mismo bucle sencillo, que rompe los límites de la EVM estándar:

1. gl.nondet.web.render(): la capacidad de salir de la blockchain y acceder a la web.
2. gl.nondet.exec_prompt(): la capacidad de procesar esos datos con un LLM.
3. gl.eq_principle: las reglas que obligan a la red de modelos de IA a alcanzar un consenso sobre una única verdad.

La elección del Principio de Equivalencia depende por completo de la naturaleza de los datos que necesitas:

• Usa la equivalencia sintáctica (strict_eq) si necesitas que el resultado sea idéntico en todos los nodos (por ejemplo, para extraer una dirección concreta o los datos históricos de un token).
• Usa la equivalencia semántica (prompt_non_comparative, prompt_comparative) si extraes texto cuya redacción puede variar pero cuyo significado debe ser el mismo (por ejemplo, para resumir una noticia o analizar el sentimiento).
• Usa una validación personalizada si obtienes datos muy volátiles (como precios de tokens en directo). Como estos valores cambian de un momento a otro, la equivalencia estricta suele fallar. Probablemente tampoco quieras hacer una llamada comparativa completa a un LLM, o al menos no es eficiente. En este caso, una equivalencia personalizada te permite definir un «margen de tolerancia» (por ejemplo, que los precios no difieran más de un 1 %) en lugar de exigir una coincidencia exacta.

El patrón «Reader» (“text” o “html”)

En este patrón, el contrato obtiene el contenido en formato texto o HTML (lo que hace que el nodo validador renderice una URL concreta) y después pasa ese contenido a un LLM para extraer una información concreta.

Ejemplo: un oráculo del precio de Bitcoin

En este fragmento, el contrato obtiene una página web y pide al LLM que extraiga el precio. En este ejemplo usamos la equivalencia estricta por sencillez, suponiendo que el LLM extrae el número entero exacto de una captura estática. En un entorno de producción de alta frecuencia sería más seguro usar el principio personalizado de «margen de tolerancia» que mencionamos antes.

Puedes ver el ejemplo completo aquí.

El patrón «Vision» (“screenshot”)

El texto da mucho de sí, pero algunas verdades son visuales. Este patrón aprovecha los LLM multimodales para procesar e interpretar imágenes.

A diferencia de la extracción de texto, el análisis visual es subjetivo por naturaleza: dos personas pueden describir la misma imagen de forma distinta. Por eso, este patrón funciona mejor cuando se busca una coincidencia semántica.

Ejemplo: el verificador «Proof of Steak»

En este fragmento, el contrato analiza la URL de una imagen para determinar si muestra un filete cocinado. Usa una comprobación comparativa para tolerar las distintas formas en que la IA podría expresar el «Yes».

Puedes ver el ejemplo completo aquí.

De la teoría a la práctica

Estos patrones no son hipotéticos: los desarrolladores ya los están desplegando para resolver problemas que antes eran imposibles on-chain.

• «Proof of Steak», de Luk: ganador del hackathon de GenLayer de noviembre de 2025, este proyecto usó el patrón Vision para crear un juego social divertido y verificable. Los usuarios suben fotos de su cena u otros contenidos, y el jurado descentralizado los valida y los puntúa.
• Price Prediction Oracle, de Ying: con el patrón Reader, Ying creó un sistema que obtiene el HTML sin procesar de los principales medios de noticias y exchanges, y así convierte cualquier URL pública en una posible fuente para un oráculo, sin necesidad de claves de API ni de permisos.
• «Watchdog», de Jay: una aplicación de seguridad que vigila el estado de servidores externos (como GitHub o CoinGecko). Usa el patrón Reader para detectar caídas y activa automáticamente interruptores de emergencia (circuit breakers) on-chain que pausan los contratos mientras dura la interrupción.
• «Guess the Picture», de Pavel: una versión gamificada del patrón Vision en la que los usuarios dibujan conceptos y un jurado de IA los puntúa según su precisión semántica.

Ya tenemos contratos que ven, leen y reaccionan. Sin embargo, cambiar la seguridad determinista de la EVM por la volatilidad de internet tiene sus riesgos. Para construir sistemas que duren, entender las limitaciones de los Intelligent Oracles es tan importante como entender sus capacidades.

Limitaciones actuales: la fragilidad de la «verdad»

El mayor reto no es la IA, sino la propia jungla de la web, un entorno donde la estabilidad escasea. Una fuente fiable hoy puede quedar mañana tras un muro de pago, bloqueada por Cloudflare o fuera de línea. Eso crea una fricción peligrosa: si fijas en el código de tu contrato una URL concreta para no depender de terceros de confianza, estás apostando a que ese sitio nunca cambiará su política contra los bots. Depender de URL estáticas crea un punto único de fallo que puede obligarte a un costoso redespliegue.

Consejo para desarrolladores: antes de desplegar cualquier contrato, verifica tus fuentes. Puedes usar Intelligent Crawler para confirmar si el contenido de tu URL de destino es realmente accesible.

Por otro lado, permitir que los usuarios envíen cualquier URL es igual de peligroso. Un actor malicioso podría montar con facilidad un sitio de noticias falso o un clon de un dominio de prestigio para alimentar tu oráculo con datos falsos. La solución está en el término medio: la lista blanca de dominios. Los desarrolladores deben tratar las URL como estado mutable, no como código estático. Si mantienes on-chain una lista de dominios aprobados y creíbles (por ejemplo, coindesk.com, bbc.com), evitas la desinformación y das a tu protocolo la flexibilidad de cambiar de fuente si una URL concreta deja de funcionar, todo ello sin terceros de confianza.

Este es un fragmento para la lista blanca de dominios. Aquí comprobamos, tras normalizarla, si una URL está debidamente en la lista blanca. Es un paso importante, en el que defines la lógica (por ejemplo, si quieres rutas muy concretas para un dominio o si permites cualquier ruta dentro de él).

Consulta el código completo aquí.

Además, aunque técnicamente los Intelligent Oracles pueden obtener datos de cualquier API mediante peticiones HTTP estándar (GET/POST), hay un inconveniente: la privacidad. La mayoría de las API exigen una clave privada para autenticarse. En un servidor tradicional, esa clave se esconde en un archivo .env seguro. Pero en una blockchain todo es transparente. Si escribes tu OPENAI_API_KEY o tu BLOOMBERG_KEY directamente en el contrato, quedará a la vista de todos los validadores y exploradores de bloques de la red. Por eso, con el modelo actual no es realista integrar API privadas de suscripción: cualquier actor malicioso podría copiar tu clave al instante y agotar tu cuota.

Por último, está el coste de la inteligencia. GenLayer ejecuta varias inferencias de LLM en cada ronda de consenso. No uses una supercomputadora para hacer el trabajo de una calculadora. Si solo necesitas el precio de ETH, usa una fuente de datos dedicada y determinista como Chainlink o Pyth: para esa tarea concreta son más rápidas y más baratas. Reserva GenLayer para la «larga cola»: los millones de preguntas subjetivas, confusas y complejas que exigen comprensión, no solo aritmética.

Potencial: los Intelligent Oracles como agentes económicos

Aunque la privacidad sigue siendo una limitación, el sector está convergiendo hacia una solución que convierte los Intelligent Oracles de lectores pasivos en agentes económicos activos.

El estándar más prometedor en este sentido es el protocolo x402 (basado en el código HTTP 402, «Payment Required»).

x402 le da la vuelta al modelo de autenticación: en lugar de esconder una clave de API secreta, el oráculo simplemente paga por lo que consume. Cuando un contrato solicita datos premium, el servidor devuelve una dirección de pago en lugar del contenido. El oráculo firma entonces, de forma autónoma, una microtransacción para «desbloquear» la respuesta.

Así desaparece la necesidad de guardar secretos. La «autenticación» pasa a ser un «pago».

Aunque sigue habiendo fricciones (en concreto, con los micropagos entre cadenas para un oráculo que funcione en GenLayer), esta arquitectura abre una puerta enorme. Allana el camino hacia un futuro en el que los Intelligent Contracts no se limiten a extraer datos de la web abierta, sino que naveguen, negocien y paguen de forma nativa por información de calidad y de acceso restringido sin tener que guardar nunca una clave privada.

Conviene aclararlo: GenLayer no pretende ser otra L1 o L2 genérica que sustituya a tu cadena actual. Funciona como una capa de resolución que se conecta a otras dApps para encargarse de las decisiones no deterministas, un «tribunal de internet».

Hemos pasado de contratos «inteligentes» que calculan a Intelligent Contracts que comprenden. Si quieres empezar a construir ahora mismo, visita IntelligentOracle.com.

Allí no solo encontrarás documentación: también te espera un agente de IA especializado, listo para ayudarte en tiempo real a implementar tu primer patrón de Intelligent Oracle. La infraestructura ya está en marcha. El navegador está abierto. Lo único que falta es lo que decidas construir a continuación.

Empieza a construir tu primera dApp inteligente entre cadenas. No te pierdas nuestro Builders Program en points.genlayer.foundation.