¿Qué pasa con el re-staking?

Redacción: Kydo, responsable de narrativa de EigenCloud

Traducción: Saoirse, Foresight News

De vez en cuando, amigos me envían tuits burlándose del restaking, pero esas burlas no dan en el clavo. Así que he decidido escribir yo mismo un texto de “desahogo” con cierto carácter reflexivo.

Quizá pienses que estoy demasiado implicado para ser objetivo; o que soy demasiado orgulloso para admitir que “nos equivocamos”. Puede que creas que, incluso cuando todo el mundo da por hecho que “el restaking ha fracasado”, yo seguiré escribiendo textos extensos para defenderlo, negándome a pronunciar la palabra “fracaso”.

Estas opiniones son comprensibles, y muchas tienen su parte de razón.

Pero este artículo solo pretende presentar los hechos de forma objetiva: qué ha ocurrido, qué se ha conseguido, qué no ha salido como esperábamos y qué lecciones hemos aprendido en el proceso.

Espero que la experiencia aquí compartida tenga valor universal y pueda servir de referencia a otros desarrolladores del ecosistema.

Tras más de dos años integrando todos los AVS (servicios de validación autónoma) principales en EigenLayer y diseñando EigenCloud, quiero repasar con honestidad: en qué nos equivocamos, en qué acertamos y hacia dónde nos dirigimos.

¿Qué es exactamente el restaking?

Si todavía tengo que explicar “qué es el restaking”, eso ya indica que, cuando el restaking era el centro de atención del sector, no supimos transmitirlo con claridad. Esta es la “lección 0”: enfócate en una narrativa central y repítela constantemente.

El objetivo del equipo Eigen siempre ha sido “fácil de decir, difícil de hacer”: permitir construir aplicaciones de forma más segura en la cadena mejorando la verificabilidad de los cálculos off-chain.

AVS fue nuestro primer intento claro en esa dirección.

Un AVS (servicio de validación autónoma) es una red proof-of-stake (PoS) formada por un grupo descentralizado de operadores que ejecutan tareas off-chain. El comportamiento de estos operadores está monitorizado y, si actúan de forma indebida, su stake puede ser penalizado. Para que exista este “mecanismo de penalización”, es necesario que haya “capital apostado” como respaldo.

Ahí es donde reside el valor del restaking: sin que cada AVS tenga que construir desde cero su propio sistema de seguridad, el restaking permite reutilizar el ETH ya staked para brindar protección a varios AVS. Esto no solo reduce el coste de capital, sino que acelera el arranque del ecosistema.

Así, el marco conceptual del restaking puede resumirse así:

AVS: la “capa de servicios”, donde se asientan los nuevos sistemas PoS de seguridad criptoeconómica.

Restaking: la “capa de capital”, que reutiliza los activos ya staked para proteger estos sistemas.

Sigo pensando que esta idea es brillante, pero la realidad no ha sido tan ideal como en los esquemas: muchas implementaciones no alcanzaron las expectativas.

Lo que no salió como esperábamos

1. Elegimos mal el mercado: demasiado nicho

No queríamos “cualquier tipo de cálculo verificable”, sino sistemas que desde el primer día fueran descentralizados, basados en penalizaciones y con seguridad criptoeconómica total.

Aspirábamos a que los AVS fueran “servicios de infraestructura”, como SaaS (software como servicio), de forma que cualquiera pudiera construir un AVS.

Esa postura, aunque firme en principios, redujo mucho el espectro de desarrolladores potenciales.

El resultado: nos enfrentamos a un mercado “pequeño, lento, con alta barrera de entrada”, pocos usuarios potenciales, alto coste de implementación y ciclos largos para ambos lados (equipo y desarrolladores). Tanto la infraestructura de EigenLayer, como las herramientas de desarrollo y cada AVS por encima, requieren meses o incluso años de construcción.

Tres años después: solo dos AVS principales están en producción — DIN (Decentralized Infrastructure Network) de Infura y EigenZero de LayerZero. Esta “tasa de adopción” está lejos de ser “amplia”.

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

2. Limitados por el entorno regulatorio, nos vimos obligados a “guardar silencio”

Lanzamos el proyecto en pleno auge de la “era Gary Gensler” (nota: Gary Gensler es el presidente de la SEC de EE. UU., conocido por su postura regulatoria estricta con el sector cripto). Varias empresas de staking estaban siendo investigadas o demandadas.

Como proyecto de restaking, casi cada palabra que pronunciábamos en público podía interpretarse como “promesa de inversión” o “publicidad de rendimientos”, e incluso atraer una citación.

Esta niebla regulatoria marcó nuestra comunicación: no podíamos hablar libremente, ni desmentir en tiempo real rumores, acusaciones o malentendidos, incluso ante oleadas de prensa negativa o cuando socios nos culpaban públicamente.

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

El resultado: lanzamos un token bloqueado sin suficiente comunicación previa. Viéndolo ahora, fue arriesgado.

Si alguna vez te pareció que el equipo de Eigen evitaba pronunciarse o guardaba un silencio inusual sobre algún tema, probablemente fue por este contexto regulatorio: un solo tuit erróneo podía acarrear consecuencias considerables.

3. Los AVS iniciales diluyeron el valor de la marca

La influencia inicial de la marca Eigen se debía en gran parte a Sreeram (miembro clave del equipo): su energía, optimismo y fe en que tanto los sistemas como las personas pueden mejorar nos aportaron mucha buena reputación.

Los miles de millones en capital staked reforzaron esa confianza.

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

Poco a poco, “EigenLayer” se asoció con “el último farming de liquidez o airdrop”. Muchas críticas, saturación e incluso rechazo actuales tienen su origen en esa etapa.

Si pudiera volver atrás, habría preferido empezar con “menos AVS, pero de mayor calidad”, ser más selectivo con los socios merecedores de nuestro aval de marca y aceptar un lanzamiento “más lento y menos mediático”.

4. Exceso de búsqueda de “mínima confianza” técnica, lo que llevó a un diseño redundante

Intentamos construir un “sistema de penalización universal perfecto”: debía ser versátil, flexible y cubrir todos los escenarios posibles, para lograr la “mínima confianza”.

Pero en la realidad, esto ralentizó nuestra iteración de producto y nos obligó a invertir mucho tiempo explicando un mecanismo “para el que la mayoría aún no estaba preparada”. Incluso hoy seguimos haciendo divulgación sobre el sistema de penalización lanzado hace casi un año.

A posteriori, el camino razonable habría sido: lanzar primero una penalización sencilla, permitir a los AVS explorar modelos más enfocados y luego ir aumentando la complejidad del sistema. Nosotros pusimos el “diseño complejo” por delante, pagando el precio en “velocidad” y “claridad”.

Lo que sí logramos

La gente tiende a etiquetar las cosas de “fracaso” de forma apresurada.

En la historia del “restaking” se han hecho muchas cosas muy bien, y estos logros son clave para nuestro futuro.

1. Demostramos que podemos vencer en mercados competitivos

Preferimos el “ganar-ganar”, pero no tememos la competencia: si entramos en un mercado, queremos liderarlo.

En restaking, Paradigm y Lido apoyaron juntos a nuestro competidor directo. Por entonces, el TVL de EigenLayer no llegaba a 1.000 millones.

El rival tenía ventaja narrativa, recursos, capital y “confianza por defecto”. Muchos me decían “ese combo es imbatible, os van a barrer”. Pero no fue así: hoy tenemos el 95% de la cuota de mercado en restaking y hemos atraído al 100% de los desarrolladores de primer nivel.

En el sector de “data availability (DA)”, empezamos más tarde, con menos equipo y recursos, cuando los pioneros ya tenían ventaja y un marketing fuerte. Pero ahora, bajo cualquier métrica relevante, EigenDA (la solución DA de Eigen) posee gran parte del mercado DA, y esa cuota crecerá exponencialmente con la integración de nuestros mayores socios.

La competencia fue feroz en ambos mercados, pero logramos destacar.

2. EigenDA: un producto maduro que ha cambiado el ecosistema

El lanzamiento de EigenDA sobre la infraestructura de EigenLayer fue una gran sorpresa.

Se ha convertido en la piedra angular de EigenCloud y ha aportado a Ethereum algo muy necesario: un canal DA de gran escala. Gracias a él, los rollups pueden operar a gran velocidad sin verse obligados a abandonar Ethereum por otras cadenas nuevas.

El lanzamiento de MegaETH se debió precisamente a que el equipo confiaba en que Sreeram podía romper el cuello de botella de la DA; Mantle propuso a BitDAO montar un L2 por esa misma razón.

EigenDA también es el “escudo defensivo” de Ethereum: con una solución DA nativa de alto rendimiento dentro del propio ecosistema, a otras cadenas les resulta más difícil “captar atención con la narrativa de Ethereum y drenar su valor”.

3. Impulsamos el desarrollo del mercado de preconfirmaciones

Uno de los temas clave en los inicios de EigenLayer fue cómo desbloquear la preconfirmación de Ethereum mediante EigenLayer.

Desde entonces, las preconfirmaciones han ganado atención gracias a Base, aunque su implementación sigue siendo un reto.

Para fomentar el desarrollo, lanzamos el programa Commit-Boost: aborda el “efecto lock-in” de los clientes de preconfirmación y crea una plataforma neutral donde cualquiera puede innovar a través de compromisos de los validadores.

Actualmente, miles de millones de dólares fluyen a través de Commit-Boost y más del 35% de los validadores ya participan. Con la llegada de servicios de preconfirmación principales en los próximos meses, esta cifra crecerá aún más.

Esto es vital para la “antifragilidad” de Ethereum y sienta la base para la innovación continua en el mercado de preconfirmaciones.

4. Mantenemos siempre la seguridad de los activos

Durante años, hemos garantizado la seguridad de decenas de miles de millones en activos.

Puede sonar anodino o hasta “aburrido”, pero basta pensar en cuántas infraestructuras cripto se han “caído” de mil maneras para apreciar el valor de esta “normalidad”. Para evitar riesgos, construimos una sólida infraestructura operativa de seguridad, reclutamos y formamos un equipo de seguridad de talla mundial e impregnamos la cultura del equipo con mentalidad adversarial.

Esta cultura es clave para cualquier negocio que maneje fondos de usuarios, IA o sistemas del mundo real, y “no se puede añadir después”: hay que forjarla desde el principio.

5. Impedimos que Lido superara de forma prolongada el 33% de participación

El restaking ha tenido un efecto poco valorado: grandes cantidades de ETH han ido a proveedores de LRT, evitando que Lido superase de forma estable el 33% del staking.

Esto es crucial para el “equilibrio social” de Ethereum. Si Lido ocupase más de un 33% de la participación durante mucho tiempo, sin alternativas fiables, surgirían grandes disputas de gobernanza y tensiones internas.

El restaking y las LRT no han “milagrosamente descentralizado todo”, pero sí han cambiado la tendencia hacia la concentración de stake, y eso no es un logro menor.

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

El mayor “aprendizaje” ha sido a nivel conceptual: hemos comprobado que “el mundo necesita más sistemas verificables”, pero también hemos visto que “el camino hasta ellos” era erróneo.

El camino correcto no es “partir de una seguridad criptoeconómica genérica, crear desde el primer día una red de operadores totalmente descentralizada y esperar a que todo el mundo se sume”.

Lo que realmente acelera el avance de la “frontera” es ofrecer herramientas directas a los desarrolladores para que logren verificabilidad en sus aplicaciones concretas, junto con los primitivos de validación adecuados. Debemos “acercarnos a las necesidades del desarrollador”, no exigirles que sean “diseñadores de protocolos” desde el primer día.

Por eso hemos empezado a construir servicios internos modulares: EigenCompute (cómputo verificable) y EigenAI (IA verificable). Algunas funciones que otros equipos tardarían años y cientos de millones en desarrollar, nosotros las lanzamos en meses.

Próximos pasos

Ante esta experiencia —aciertos de timing, éxitos, fracasos, “cicatrices” de marca—, ¿cómo debemos responder?

Aquí un resumen de nuestros próximos pasos y su lógica:

1. Que el token EIGEN sea el núcleo del sistema

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

El token EIGEN será:

El motor de seguridad económica de EigenCloud.

El activo que respalda los riesgos asumidos por la plataforma.

La herramienta central para la captación de valor de todos los flujos económicos y de tarifas del sistema.

En los inicios, existía una brecha entre las expectativas sobre “qué valor capturaría el token EIGEN” y “cómo funcionaba en realidad”, lo que generó confusión. En la siguiente etapa, cerraremos esa brecha con diseños y sistemas concretos. Daremos más detalles próximamente.

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

Nuestra premisa sigue siendo la misma: mejorar la verificabilidad de los cálculos off-chain para construir aplicaciones más seguras on-chain. Pero las herramientas para lograr “verificabilidad” ya no serán únicas.

A veces será seguridad criptoeconómica, otras ZK proofs, TEE (entorno de ejecución confiable) o soluciones híbridas. Lo importante no es “apostar por una sola tecnología”, sino que la “verificabilidad” sea un primitivo estándar accesible para desarrolladores.

Queremos reducir la brecha entre dos estados:

De “tengo una aplicación” a “tengo una aplicación que usuarios, socios o reguladores pueden verificar”.

Hoy, la combinación “criptoeconomía + TEE” es la mejor opción: equilibra la “programabilidad” (lo que el desarrollador puede construir) y la “seguridad” (no solo teórica, sino real y aplicable).

En el futuro, cuando pruebas ZK y otros mecanismos estén maduros y sean útiles para los desarrolladores, también los integraremos en EigenCloud.

3. Apostar fuerte por la IA

La mayor revolución actual en la computación mundial es la IA, especialmente los agentes inteligentes. El sector cripto tampoco puede ignorarlo.

Un agente inteligente es, en esencia, “un modelo de lenguaje envuelto en herramientas, que ejecuta acciones en un entorno”.

Hoy, no solo los modelos de lenguaje son “cajas negras”, también lo es la lógica de los agentes inteligentes, lo que ya ha provocado ataques por la necesidad de “confiar en el desarrollador”.

Pero si los agentes inteligentes son “verificables”, ya no hará falta confiar en el desarrollador.

Para que un agente inteligente sea verificable, deben cumplirse tres condiciones: que el proceso de inferencia del LLM (modelo de lenguaje) sea verificable, que el entorno de ejecución lo sea y que la capa de datos donde se almacena, recupera y entiende el contexto también lo sea.

EigenCloud está diseñado para estos escenarios:

EigenAI: inferencia LLM verificable y determinista.

EigenCompute: entorno de ejecución de operaciones verificable.

EigenDA: almacenamiento y recuperación de datos verificables.

Creemos que los “agentes inteligentes verificables” serán una de las aplicaciones más competitivas de nuestro “cloud verificable”, y ya hemos formado un equipo dedicado a ello.

4. Redefinir la narrativa sobre “staking y rendimientos”

Para obtener ingresos reales, hay que asumir riesgos reales.

Estamos explorando aplicaciones de staking más amplias, para que el capital staked respalde riesgos tales como:

Riesgo de contratos inteligentes.

Riesgo de distintos tipos de cálculo.

Riesgos que puedan describirse claramente y con precios cuantificables.

Los rendimientos futuros reflejarán de forma fiel los “riesgos asumidos, transparentes y comprensibles”, y no solo perseguirán el “farming de liquidez de moda”.

Esta lógica se integrará de forma natural en los casos de uso, respaldo y mecanismos de captura de valor del token EIGEN.

Palabras finales

El restaking no ha llegado a ser esa “capa universal” que yo (y otros) esperábamos, pero tampoco ha desaparecido. En su largo recorrido, se ha convertido en lo que suele ser cualquier “producto de primera generación”:

Un capítulo importante, un conjunto de lecciones costosas y la infraestructura que ahora soporta negocios más amplios.

Seguimos manteniendo las operaciones relacionadas con restaking y lo valoramos, pero ya no queremos quedarnos atados a la narrativa original.

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

Ahora nos adentramos en un campo con un “TAM mucho mayor”: por un lado, servicios cloud; por otro, aplicaciones dirigidas al desarrollador. También exploramos el “inexplorado sector de la IA”, con la misma intensidad de siempre.

El equipo sigue tan motivado como nunca y estoy deseando demostrar a los escépticos que —sí, podemos.

Nunca he tenido tanta confianza en Eigen, sigo acumulando tokens EIGEN y pienso seguir haciéndolo en el futuro.

Aún estamos empezando.