P1. Para los lectores que quizás solo conocen TEN por los titulares recientes, ¿cómo explicarías la misión central de TEN Protocol y el problema que está fundamentalmente diseñado para resolver dentro del panorama de ejecución de Ethereum?
Ethereum hizo algo radical: hizo que la computación fuera verificable globalmente al hacer todo público. Ese sacrificio desbloqueó las finanzas sin confianza, pero también, de forma silenciosa, rompió una enorme clase de aplicaciones reales.
Hoy, cuando usás la mayoría de las L2 de Ethereum, no solo estás ejecutando una transacción. Estás transmitiendo tu intención, tu estrategia, tu timing y, muchas veces, tu razonamiento económico a cada bot, competidor y adversario que observa la cadena. Esa visibilidad permite la verificación, pero también habilita front-running, extracción de estrategias, vigilancia de comportamientos y mercados enteros de ataques basados en copiar intenciones más rápido de lo que los humanos pueden reaccionar.
TEN existe para romper ese falso binomio.
Nuestra misión es fácil de enunciar pero difícil de ejecutar: permitir que las personas usen aplicaciones de Ethereum sin revelar lo que están intentando hacer, pero conservando la verificabilidad al nivel de Ethereum. Con la criptografía y el modelo de ejecución correctos, podés probar que una computación fue correcta sin revelar los inputs, los pasos intermedios o la lógica privada detrás de ella.
En la práctica, esto lo cambia todo. Los operadores de nodos no pueden hacer front-running. Los agentes de IA pueden guardar secretos de forma segura. Los juegos pueden existir en on-chain sin exponer el estado oculto. Las ofertas no se copian. Las aplicaciones no tienen que filtrar información sensible solo para ser comprobables.
TEN trata de devolver algo que las blockchains eliminaron accidentalmente: la capacidad de computar con confianza.
P2. TEN posiciona el “computar con confianza” como un elemento fundamental que falta en el stack blockchain actual. ¿Por qué la confidencialidad selectiva es cada vez más necesaria para casos de uso reales en DeFi, IA, gaming y empresas?
Todo sistema de software exitoso en el mundo depende del control de acceso. En Facebook, no ves todos los posteos, solo lo que estás autorizado a ver. En la banca, tu saldo no es público. En los juegos, tus oponentes no ven tus cartas. En las empresas, la lógica interna y los datos están protegidos porque exponerlos destruye valor.
Las blockchains invirtieron este modelo. Hicieron de la transparencia total la norma, lo cual es genial para la auditabilidad, pero desastroso para muchas aplicaciones reales.
En DeFi, los usuarios filtran estrategias y se vuelven presas predecibles. En gaming, la información oculta, la aleatoriedad y el fair play son imposibles de implementar correctamente. En IA y empresas, exponer datos, modelos o lógica interna de decisión viola regulaciones o elimina por completo la ventaja competitiva.
Lo que falta no es la confianza, sino la confidencialidad programable con garantías criptográficas. No privacidad agregada a través de servidores centralizados o promesas legales, sino control de acceso impuesto por el propio protocolo.
Eso es lo que restaura el “computar con confianza”: la capacidad de decidir quién puede ver qué, manteniendo el sistema verificable.
P3. Su arquitectura se basa en Trusted Execution Environments en lugar de enfoques solo ZK o basados en MPC. ¿Qué concesiones hicieron al elegir este diseño y cómo mitigan las suposiciones de confianza asociadas?
Desde el primer día, nuestra restricción fue clara: los desarrolladores deben poder desplegar aplicaciones EVM reales sin tener que reescribir todo.
Ejecutar la EVM completa dentro de un Trusted Execution Environment permite a los desarrolladores usar los mismos lenguajes, herramientas y modelos mentales que ya conocen, mientras obtienen confidencialidad selectiva. La liquidación, la liquidez y la composabilidad siguen ancladas a Ethereum.
Los enfoques ZK y MPC son potentes y avanzan rápidamente, pero hoy suelen imponer concesiones serias: complejidad de circuitos, cuellos de botella de performance, programabilidad limitada o sobrecarga operativa que hace que las aplicaciones de propósito general sean difíciles de construir y aún más de escalar.
Utilizar TEEs introduce una suposición de confianza arraigada en hardware, y somos explícitos al respecto. TEN la mitiga mediante un diseño en capas: hosting solo en la nube para reducir vectores de ataque físicos, atestación remota obligatoria, redundancia, restricciones de gobernanza e ingeniería de seguridad rigurosa.
El resultado es un modelo híbrido. Público donde debe serlo—liquidación, auditabilidad, resultados. Confidencial donde debe ser—inputs, flujo de órdenes y estados sensibles. No es pureza ideológica; es pragmatismo ingenieril.
P4. ¿Cómo preserva TEN la verificabilidad y composabilidad al nivel de Ethereum mientras permite que partes de la ejecución, como inputs, flujo de órdenes o estrategias, permanezcan confidenciales?
TEN separa lo que debe ser comprobable de lo que debe ser visible.
Las reglas de los smart contracts permanecen públicas. Cualquiera puede inspeccionarlas. La ejecución ocurre dentro de un TEE atestado, y la red puede verificar criptográficamente que el código correcto se ejecutó sobre inputs válidos, incluso si esos inputs estaban encriptados.
Como Layer 2, TEN sigue publicando rollups y transiciones de estado en Ethereum. La finalidad, la liquidación y la composabilidad permanecen exactamente donde los usuarios esperan que estén.
Lo que desaparece es la exposición innecesaria. Estrategias intermedias, umbrales privados y lógica sensible no tienen que filtrarse solo para demostrar corrección.
La confidencialidad se convierte en una capacidad de primer nivel, no en una solución provisoria.
P5. Desde el punto de vista de la experiencia del usuario, ¿en qué se diferencia interactuar con una aplicación potenciada por TEN respecto a usar una L2 típica de Ethereum hoy?
La mayor diferencia es psicológica—y es inmediata.
Los usuarios ya no sienten que los están observando. No hay ansiedad de mempool, ni configuraciones defensivas de slippage, ni acrobacias con RPC privadas solo para evitar ser explotados. La intención es privada por defecto.
Enviás una oferta, una estrategia o un movimiento asumiendo que no se va a copiar en tiempo real—porque no lo será. Ese simple cambio hace que Web3 se sienta más parecido a cómo funciona el software tradicional.
La privacidad deja de ser una funcionalidad avanzada para usuarios expertos y pasa a ser una propiedad invisible de la propia aplicación.
P6. Una de las narrativas insignia de TEN es reducir el MEV y la explotación de mercado. ¿Cómo funcionan en la práctica mecanismos como las ofertas selladas, el flujo de órdenes oculto o el enrutamiento privado, y qué mejoras medibles permiten?
TEN cambia lo que es visible durante la ejecución.
En una subasta de ofertas selladas, las ofertas están encriptadas y se procesan dentro de un TEE. Nadie ve las ofertas individuales en tiempo real. Según el diseño, las ofertas pueden incluso no revelarse nunca—solo el resultado final.
El flujo de órdenes oculto sigue el mismo principio. Las estrategias no se transmiten al mundo, así que no hay nada que copiar, simular o sandwichear. El MEV no necesita ser “combatido”—simplemente no tiene nada de qué alimentarse.
Lo fundamental es que esto no sacrifica la confianza. Las reglas son públicas, la ejecución está atestada y los resultados son verificables. Se puede probar la equidad sin exponer la intención.
P7. TEN ha destacado casos de uso como agentes de IA verificables y iGaming demostrablemente justo. ¿Cuál de estos ves como el principal motor de adopción real a corto plazo y por qué son más adecuados para TEN que para cadenas transparentes por defecto?
El iGaming con dinero real es el encaje más claro a corto plazo.
El gaming requiere información oculta, aleatoriedad rápida y baja latencia. Las cadenas transparentes rompen esos supuestos. En el testnet de TEN, vimos decenas de miles de wallets únicas y más de un millón de apuestas—varios órdenes de magnitud más participación que los testnets típicos.
House of TEN, el primer poker onchain jugado por agentes de IA, fue un gran éxito durante el lanzamiento beta.
Los agentes de IA verificables son igualmente transformadores, aunque de ciclo un poco más largo. Permiten gestión confidencial de tesorería, toma de decisiones privada y sistemas de IA que pueden probar cumplimiento de reglas sin exponer modelos o datos propietarios.
Ambas categorías se benefician directamente de la confidencialidad selectiva, y ambas son imposibles de implementar correctamente en cadenas transparentes por defecto.
P8. El hardware confiable introduce una clase diferente de riesgo operativo. ¿Cómo está diseñado TEN para asegurar que las fallas sean detectables, contenidas y recuperables en vez de sistémicas?
El hardware confiable cambia el modo de falla—no lo elimina.
TEN asume que pueden ocurrir problemas y diseña para la detectabilidad y contención. La atestación remota asegura que las ejecuciones incorrectas sean observables. Los operadores redundantes evitan que las fallas de un solo nodo se vuelvan sistémicas. Los mecanismos de gobernanza permiten aislar o reemplazar componentes comprometidos.
El objetivo no es la confianza ciega, sino la confianza acotada con fuertes garantías.
P9. Cambiando brevemente a operaciones de red: ¿cómo es el modelo actual de operadores y cómo planea el roadmap pasar de una fase inicial hacia mayor descentralización y resiliencia?
TEN comienza con un conjunto de operadores restringido para asegurar la seguridad y el rendimiento, y expande progresivamente la participación a medida que maduran las herramientas, el monitoreo y la gobernanza.
La descentralización no es una casilla para marcar, es una secuencia. Cada fase aumenta la resiliencia sin comprometer las garantías de confidencialidad.
P10. El lanzamiento de tokens suele confundirse con la preparación del producto. ¿Cómo separan internamente los eventos de mercado del desarrollo del protocolo y qué hitos son los más relevantes para evaluar el progreso técnico de TEN en los próximos 6 a 12 meses?
De forma muy deliberada.
Los eventos de tokens no definen la preparación. Lanzar productos sí.
Internamente, el progreso se mide por lanzamientos auditados, aplicaciones en vivo, expansión de operadores, actividad de desarrolladores y casos de uso reales que requieren confidencialidad y generan ingresos.
En los próximos 6–12 meses, el éxito se mide por capacidades entregadas, no por narrativas mantenidas.
P11. Mirando hacia atrás, ¿qué lecciones operativas ha extraído el equipo tras lanzar un protocolo de infraestructura complejo en un entorno de mercado altamente reflexivo?
Que la tecnología sola no alcanza.
La ejecución, la comunicación y el timing se potencian mutuamente, especialmente en mercados donde la percepción alimenta directamente la realidad. Incluso los sistemas robustos sufren si las expectativas no están alineadas.
La lección es simple pero implacable: la confianza se reconstruye entregando, no explicando. La infraestructura funcional supera siempre al mensaje perfecto.
P12. Mirando al futuro, ¿cómo se vería el éxito para TEN dentro de un año en términos de capacidades lanzadas, adopción de desarrolladores y aplicaciones reales corriendo en producción?
El éxito significa aplicaciones corriendo en producción que simplemente no podrían existir en cadenas transparentes.
iGaming en vivo. Flujos de trabajo DeFi protegidos. Agentes de IA verificables gestionando valor real. Desarrolladores usando la confidencialidad como un elemento central del diseño, no como un agregado.
En ese punto, TEN no es “un proyecto de privacidad”. Es infraestructura fundamental—la capa que faltaba para que Ethereum finalmente soporte todo el espectro de aplicaciones reales.
