¿Qué pasa con el re-staking?

Análisis profundo del camino de restaking de EigenLayer: los obstáculos, los logros de EigenDA, todo allanando el camino para la nueva dirección de EigenCloud.

Autor: Kydo, responsable de narrativa de EigenCloud

Traducción: Saoirse, Foresight News

De vez en cuando, amigos me mandan tuits burlándose del restaking, pero esas burlas no dan en el clavo. Así que decidí escribir yo mismo una nota con tono reflexivo y algo de catarsis.

Quizás pienses que estoy demasiado involucrado como para ser objetivo; o que soy demasiado orgulloso para admitir que “nos equivocamos”. Puede que creas que, aunque todos ya den por “fracasado el restaking”, igual voy a escribir un texto largo para justificarme, sin pronunciar jamás la palabra “fracaso”.

Estas opiniones son razonables, y muchas tienen algo de cierto.

Pero este artículo solo busca exponer los hechos de manera objetiva: qué pasó realmente, qué cosas se concretaron, cuáles no, y qué aprendimos de todo eso.

Espero que las experiencias aquí contadas sean útiles y sirvan de referencia para desarrolladores de otros ecosistemas.

Después de más de dos años integrando todos los AVS (servicios de validación autónoma) principales en EigenLayer y diseñando EigenCloud, quiero hacer una revisión honesta: en qué nos equivocamos, en qué acertamos y hacia dónde vamos ahora.

¿Qué es realmente el restaking?

Que hoy todavía tenga que explicar “qué es el restaking” ya indica que, cuando era el foco de la industria, no supimos comunicarlo bien. Esta es la “lección cero”: enfocar la narrativa en un eje central y repetirlo hasta el cansancio.

El objetivo del equipo de Eigen siempre fue “fácil de decir, difícil de hacer”: aumentar la verificabilidad de los cálculos off-chain para que la gente pueda construir aplicaciones on-chain de forma más segura.

AVS fue nuestro primer intento concreto y con una postura clara para lograrlo.

AVS (servicios de validación autónoma) es una red proof-of-stake (PoS) donde un grupo descentralizado de operadores ejecuta tareas off-chain. El comportamiento de estos operadores es monitoreado y, si incumplen, su capital en staking es penalizado. Para que exista este “mecanismo de penalización”, es necesario contar con “capital en staking” como respaldo.

Ahí radica el valor del restaking: sin que cada AVS tenga que construir su propio sistema de seguridad desde cero, el restaking permite reutilizar ETH ya en staking para proteger varios AVS a la vez. Esto reduce el costo de capital y acelera el lanzamiento de nuevos ecosistemas.

Así, el marco conceptual del restaking se resume en:

• AVS: la “capa de servicios”, donde se asientan los nuevos sistemas de seguridad criptoeconómica PoS;
• Restaking: la “capa de capital”, que reutiliza activos ya en staking para brindar seguridad a esos sistemas.

Sigo creyendo que la idea es brillante, pero la realidad no fue tan ideal como el diagrama conceptual: muchos resultados no estuvieron a la altura de lo esperado.

Lo que no salió como esperábamos

1. Elegimos mal el mercado: demasiado de nicho

No buscábamos “cualquier cálculo verificable”, sino sistemas que, desde el día uno, fueran descentralizados, con penalización y seguridad criptoeconómica total.

Queríamos que los AVS fueran “servicios de infraestructura”, como los desarrolladores pueden montar SaaS (software como servicio), que cualquiera pudiera construir un AVS.

Parecía una postura de principios, pero en la práctica redujo mucho el universo de desarrolladores potenciales.

El resultado: un mercado “pequeño, lento y con alta barrera de entrada”: pocos usuarios potenciales, alto costo de implementación y ciclos largos tanto para el equipo como para los desarrolladores. Tanto la infraestructura de EigenLayer, las herramientas de desarrollo como cada AVS encima, llevan meses o años en construirse.

Saltemos casi tres años: hoy solo tenemos dos AVS principales en producción: DIN (Decentralized Infrastructure Network) de Infura y EigenZero de LayerZero. Esa “tasa de adopción” está lejos de ser “amplia”.

La verdad es que diseñamos pensando en equipos que quisieran seguridad criptoeconómica y operadores descentralizados desde el primer día, pero el mercado real pedía soluciones “más graduales y centradas en la aplicación”.

2. El entorno regulatorio nos obligó a “callar”

Lanzamos el proyecto en pleno auge de la “era Gary Gensler” (nota: Gary Gensler, presidente de la SEC de EE.UU., fue muy estricto con la industria cripto). Varias empresas de staking estaban siendo investigadas y demandadas.

Como proyecto de restaking, casi cualquier cosa que dijéramos en público podía interpretarse como “promesa de inversión”, “publicidad de rendimientos” e incluso atraer citaciones judiciales.

Esta niebla regulatoria condicionó nuestra comunicación: no podíamos hablar libremente, y aunque nos llovieran críticas, socios nos culparan o la opinión pública nos atacara, no podíamos aclarar malentendidos en tiempo real.

Ni siquiera podíamos decir “no es así” sin antes evaluar el riesgo legal.

El resultado: lanzamos el token bloqueado sin suficiente comunicación. Viéndolo en retrospectiva, fue arriesgado.

Si alguna vez sentiste que el equipo de Eigen evitaba ciertos temas o era inusualmente callado, probablemente fue por este entorno regulatorio: un solo tuit mal puesto podía traer riesgos enormes.

3. Los AVS tempranos diluyeron el valor de la marca

La influencia de la marca Eigen al principio se debía mucho a Sreeram (miembro clave del equipo): su energía, optimismo y fe en que los sistemas y las personas pueden mejorar nos ganaron mucha simpatía.

Los miles de millones en capital en staking reforzaron esa confianza.

Pero la promoción conjunta con los primeros AVS no estuvo a la altura de esa “marca”. Muchos AVS iniciales hacían mucho ruido, pero solo perseguían modas; no eran ni los “más sólidos técnicamente” ni los “más confiables”.

Con el tiempo, la gente empezó a asociar “EigenLayer” con “el último farming de liquidez o airdrop”. Muchas de las críticas, el hartazgo e incluso el rechazo actual vienen de esa etapa.

Si pudiera volver atrás, preferiría empezar con “menos pero mejores AVS”, ser más selectivo con los socios que llevan nuestro respaldo de marca y aceptar un ritmo de promoción “más lento y menos ruidoso”.

4. Exceso de búsqueda de “mínima confianza” técnica llevó a diseños redundantes

Intentamos construir un “sistema de penalización universal perfecto”: debía ser general, flexible y cubrir todos los escenarios posibles para minimizar la confianza.

Pero en la práctica, esto ralentizó la iteración del producto y nos obligó a gastar mucho tiempo explicando un mecanismo que “la mayoría aún no estaba lista para entender”. Incluso hoy, seguimos educando sobre el sistema de penalización que lanzamos hace casi un año.

Visto en retrospectiva, lo razonable hubiera sido: lanzar primero un esquema de penalización simple, dejar que los AVS prueben modelos más enfocados y luego aumentar la complejidad. Pero pusimos el “diseño complejo” primero y pagamos el precio en “velocidad” y “claridad”.

Lo que sí logramos

A la gente le encanta ponerle la etiqueta de “fracaso” a todo, pero eso es muy superficial.

En el capítulo del “restaking”, logramos muchas cosas muy bien, y esos logros son clave para nuestro futuro.

1. Probamos que podemos ganar en mercados competitivos

Preferimos el “win-win”, pero no le tememos a la competencia: si entramos a un mercado, vamos a liderar.

En restaking, Paradigm y Lido apoyaron juntos a nuestro principal competidor. En ese momento, el TVL de EigenLayer era menos de 1.1billions.

El rival tenía ventaja narrativa, recursos, capital y “confianza por defecto”. Muchos me decían: “ese combo va a ejecutar mejor y los va a aplastar”. Pero no fue así: hoy tenemos el 95% del mercado de capital de restaking y atraemos al 100% de los desarrolladores top.

En el área de “data availability” (DA), empezamos más tarde, con menos gente y menos fondos, mientras los pioneros ya tenían ventaja y un marketing fuerte. Pero hoy, por cualquier métrica, EigenDA (la solución DA de Eigen) tiene una gran cuota de mercado; y con la integración de los socios más grandes, esa cuota crecerá exponencialmente.

Ambos mercados eran hipercompetitivos, pero logramos sobresalir.

2. EigenDA se convirtió en un producto maduro que cambió el ecosistema

Lanzar EigenDA sobre la infraestructura de EigenLayer fue una gran sorpresa.

Se volvió la piedra angular de EigenCloud y le dio a Ethereum algo muy necesario: un canal DA de escala masiva. Gracias a esto, los rollups pueden funcionar rápido sin tener que irse de Ethereum ni migrar a otras chains nuevas.

MegaETH nació porque el equipo confiaba en que Sreeram podía romper el cuello de botella de DA; Mantle propuso a BitDAO montar un L2 por la misma razón.

EigenDA también es el “escudo defensivo” de Ethereum: al tener una solución DA nativa y de alto throughput, es más difícil que otras chains externas “roben narrativa y valor del ecosistema”.

3. Impulsamos el desarrollo del mercado de pre-confirmaciones

Uno de los temas centrales de EigenLayer al principio era cómo desbloquear la función de pre-confirmación de Ethereum a través de EigenLayer.

Desde entonces, la pre-confirmación ganó mucha atención gracias a la red Base, pero su implementación sigue siendo un reto.

Para impulsar el ecosistema, lanzamos el programa Commit-Boost: busca resolver el “efecto lock-in” de los clientes de pre-confirmación y crear una plataforma neutral donde cualquiera pueda innovar con compromisos de validadores.

Hoy, decenas de miles de millones de dólares fluyen por Commit-Boost y más del 35% de los validadores ya están conectados. Con el lanzamiento de servicios de pre-confirmación mainstream en los próximos meses, ese porcentaje crecerá aún más.

Esto es clave para la “antifragilidad” de Ethereum y sienta la base para la innovación continua en pre-confirmaciones.

4. Siempre garantizamos la seguridad de los activos

Durante años, protegimos la seguridad de decenas de miles de millones de dólares.

Puede sonar aburrido, pero basta pensar cuántas infraestructuras cripto se “rompieron” de mil formas para entender lo valioso de esa “aburrida” estabilidad. Para evitar riesgos, construimos un sistema operativo seguro, reclutamos y formamos un equipo de seguridad de clase mundial e incorporamos el “pensamiento adversarial” en la cultura del equipo.

Esta cultura es esencial para cualquier negocio que maneje fondos de usuarios, IA o sistemas reales, y “no se puede agregar después”: hay que construirla desde el principio.

5. Evitamos que Lido mantuviera más del 33% del staking por mucho tiempo

El restaking tuvo un impacto subestimado: mucho ETH fue a proveedores de LRT, evitando que Lido mantuviera más del 33% del staking por largo tiempo.

Esto es clave para el “equilibrio social” de Ethereum. Si Lido hubiera superado el 33% sin alternativas confiables, habría generado enormes disputas de gobernanza y conflictos internos.

El restaking y los LRT no “lograron la descentralización total”, pero sí cambiaron la tendencia de concentración del staking: eso no es un logro menor.

6. Identificamos dónde está la “verdadera frontera”

El mayor “aprendizaje” fue conceptual: comprobamos que “el mundo necesita más sistemas verificables”, pero también entendimos el “camino correcto”: antes íbamos en la dirección equivocada.

El camino correcto no es “empezar por la seguridad criptoeconómica general, insistir en operadores totalmente descentralizados desde el día uno y esperar que todo se conecte a ese nivel”.

Lo que realmente acelera la “frontera” es dar herramientas directas a los desarrolladores para que logren verificabilidad en sus aplicaciones específicas y proveer los primitivas de verificación adecuadas. Hay que “acercarse a las necesidades del desarrollador”, no exigirles que sean “diseñadores de protocolos” desde el primer día.

Por eso, ya estamos creando servicios modulares internos: EigenCompute (servicio de cómputo verificable) y EigenAI (servicio de IA verificable). Algunas funciones que a otros equipos les llevan años y cientos de millones de dólares, nosotros las lanzamos en meses.

El camino a seguir

Entonces, frente a estas experiencias —el timing, los éxitos, los fracasos, las “cicatrices” de marca—, ¿cómo respondemos?

Acá va un resumen de nuestros próximos pasos y la lógica detrás:

1. Hacer que el token EIGEN sea el núcleo del sistema

En el futuro, todo EigenCloud y los productos que construyamos girarán en torno al token EIGEN.

El rol del token EIGEN es:

• Motor central de seguridad económica de EigenCloud;
• Activo que respalda los riesgos asumidos por la plataforma;
• Herramienta principal para capturar el valor de todos los flujos de fees y actividades económicas de la plataforma.

Al principio, muchos tenían expectativas sobre “qué valor capturaría el token EIGEN” que no coincidían con el “mecanismo real”, lo que generó confusión. En la próxima etapa, vamos a cerrar esa brecha con diseños y sistemas concretos. Más detalles se anunciarán pronto.

2. Que los desarrolladores construyan “aplicaciones verificables”, no solo AVS

Nuestra premisa sigue igual: aumentar la verificabilidad de los cálculos off-chain para que la gente pueda construir aplicaciones on-chain más seguras. Pero las herramientas para lograr “verificabilidad” ya no serán solo una.

A veces será seguridad criptoeconómica; otras, ZK proofs, TEE (entornos de ejecución confiables) o esquemas híbridos. Lo importante no es “promover una tecnología”, sino que la “verificabilidad” sea una primitiva estándar que los desarrolladores puedan integrar directamente a su stack.

Queremos achicar la brecha entre dos estados:

De “tengo una aplicación” a “tengo una aplicación que cualquier usuario, socio o regulador puede verificar”.

Hoy, “criptoeconomía + TEE” es sin dudas la mejor opción: logra el mejor equilibrio entre “programabilidad para desarrolladores” (qué pueden construir) y “seguridad” (no solo teórica, sino práctica y real).

En el futuro, cuando los ZK proofs y otros mecanismos de verificación maduren y cubran las necesidades de los desarrolladores, también los integraremos a EigenCloud.

3. Apuesta fuerte al sector de IA

La mayor revolución global en cómputo hoy es la IA, especialmente los agentes inteligentes (AI Agents). El mundo cripto no puede quedarse afuera.

Un agente de IA es básicamente “un modelo de lenguaje envuelto en herramientas que ejecuta acciones en un entorno específico”.

Hoy, no solo los modelos de lenguaje son “cajas negras”, también la lógica de los agentes de IA es opaca. Por eso ya hubo ataques donde “confiar en el desarrollador” terminó mal.

Pero si los agentes de IA son “verificables”, la gente ya no necesita depender de la confianza en el desarrollador.

Para que un agente de IA sea verificable, hacen falta tres cosas: que el proceso de inferencia del LLM (modelo de lenguaje) sea verificable, que el entorno de ejecución sea verificable y que la capa de datos para almacenar, recuperar y entender contexto también lo sea.

EigenCloud está diseñado para estos escenarios:

• EigenAI: provee inferencia LLM determinística y verificable;
• EigenCompute: provee entornos de ejecución verificables;
• EigenDA: provee almacenamiento y recuperación de datos verificables.

Creemos que los “agentes de IA verificables” son uno de los casos de uso más competitivos de nuestro “cloud verificable”, por eso ya armamos un equipo dedicado a este campo.

4. Redefinir la narrativa de “staking y rendimientos”

Para obtener rendimientos reales, hay que asumir riesgos reales.

Estamos explorando escenarios de staking más amplios, para que el capital en staking respalde los siguientes riesgos:

• Riesgo de smart contracts;
• Riesgos de distintos tipos de cómputo;
• Riesgos que puedan describirse claramente y tener precios cuantificables.

Los rendimientos futuros reflejarán los “riesgos transparentes y comprensibles” asumidos, no solo la moda del “liquidity mining” de turno.

Esta lógica se integrará de forma natural en los usos, el respaldo y la circulación de valor del token EIGEN.

Palabras finales

El restaking no se convirtió en esa “capa universal” que yo (y otros) soñábamos, pero tampoco desapareció. En su largo recorrido, terminó como la mayoría de los “productos pioneros”:

Un capítulo importante, un montón de lecciones valiosas y la infraestructura que hoy sostiene negocios más amplios.

Seguimos manteniendo el negocio relacionado al restaking y lo valoramos, solo que ya no queremos quedar atados a la narrativa original.

Si sos miembro de la comunidad, desarrollador de AVS o inversor que aún asocia Eigen con “ese proyecto de restaking”, espero que este texto te ayude a entender mejor “qué pasó” y “hacia dónde vamos”.

Hoy, entramos en un campo con un “total addressable market (TAM)” mucho mayor: por un lado cloud services, por el otro, necesidades directas de la capa de aplicaciones para desarrolladores. También estamos explorando la “carrera de IA aún poco explotada” y vamos a avanzar en estas direcciones con la misma intensidad de siempre.

El equipo sigue con toda la energía y yo estoy ansioso por demostrarle a todos los escépticos: podemos lograrlo.

Nunca estuve tan optimista con Eigen y sigo acumulando tokens EIGEN; lo seguiré haciendo en el futuro.

Esto recién empieza.