O que aconteceu com o restaking?

Revisão profunda do caminho do restaking da EigenLayer: os obstáculos enfrentados, os méritos da EigenDA, tudo pavimentando o novo rumo da EigenCloud.

Autor: Kydo, responsável pela narrativa da EigenCloud

Tradução: Saoirse, Foresight News

De vez em quando, amigos me enviam tweets zombando do restaking, mas essas provocações nunca acertam o ponto. Por isso, decidi escrever eu mesmo um artigo de “desabafo” com um tom reflexivo.

Talvez você ache que estou envolvido demais para ser objetivo; ou que sou orgulhoso demais para admitir que “erramos”. Pode pensar que, mesmo que todos já tenham decretado o “fracasso do restaking”, eu ainda escreveria um longo texto para argumentar, sem nunca dizer a palavra “fracasso”.

Essas opiniões são razoáveis, e muitas têm fundamento.

Mas este artigo quer apenas apresentar os fatos de forma objetiva: o que realmente aconteceu, o que foi realizado, o que não foi feito e quais lições aprendemos.

Espero que as experiências aqui relatadas sejam universais e possam servir de referência para desenvolvedores de outros ecossistemas.

Após mais de dois anos integrando todos os principais AVS (Serviços de Validação Autônoma) na EigenLayer e desenhando a EigenCloud, quero fazer uma revisão honesta: onde erramos, onde acertamos e para onde vamos a seguir.

Afinal, o que é restaking?

Se hoje ainda preciso explicar “o que é restaking”, isso por si só mostra que, quando o restaking era o foco do setor, não conseguimos comunicar claramente. Esta é a “lição zero” — focar em uma narrativa central e repeti-la constantemente.

O objetivo da equipe Eigen sempre foi “fácil de explicar, difícil de executar”: aumentar a verificabilidade de cálculos off-chain para que as pessoas possam construir aplicações on-chain com mais segurança.

O AVS foi nossa primeira e clara tentativa nesse sentido.

O AVS (Serviço de Validação Autônoma) é uma rede Proof of Stake (PoS), composta por operadores descentralizados que executam tarefas off-chain. O comportamento desses operadores é monitorado e, em caso de violação, seus ativos em staking são penalizados. Para que esse “mecanismo de penalidade” funcione, é necessário haver “capital em staking” como garantia.

É aí que reside o valor do restaking: sem que cada AVS precise construir um sistema de segurança do zero, o restaking permite reutilizar o ETH já em staking para garantir a segurança de vários AVS. Isso reduz o custo de capital e acelera o lançamento do ecossistema.

Portanto, o framework conceitual do restaking pode ser resumido assim:

• AVS: a “camada de serviço”, que serve de base para novos sistemas de segurança criptoeconômica PoS;
• Restaking: a “camada de capital”, que reutiliza ativos em staking existentes para garantir a segurança desses sistemas.

Ainda acho essa ideia brilhante, mas a realidade não foi tão ideal quanto o diagrama — muitos resultados ficaram aquém do esperado.

O que não saiu como esperado

1. Escolhemos o mercado errado: nicho demais

Não queríamos “qualquer computação verificável”, mas sim sistemas que fossem descentralizados, baseados em penalidades e totalmente seguros criptoeconomicamente desde o primeiro dia.

Queríamos que o AVS fosse um “serviço de infraestrutura” — assim como desenvolvedores podem construir SaaS (Software as a Service), qualquer um poderia criar um AVS.

Essa posição pareceu de princípio, mas restringiu muito o público potencial de desenvolvedores.

O resultado foi um mercado “pequeno, lento e de alta barreira”: poucos usuários potenciais, alto custo de implementação e ciclos longos para ambos os lados (equipe e desenvolvedores). Tanto a infraestrutura da EigenLayer, quanto as ferramentas de desenvolvimento e cada AVS, levam meses ou até anos para serem construídos.

Avançando quase três anos: atualmente, temos apenas dois AVS principais em produção — DIN (Decentralized Infrastructure Network) da Infura e EigenZero da LayerZero. Essa “taxa de adoção” está longe de ser “ampla”.

Para ser honesto, nosso cenário inicial era “equipes querendo segurança criptoeconômica e operadores descentralizados desde o primeiro dia”, mas a demanda real do mercado era por soluções “mais graduais e centradas em aplicações”.

2. Limitados pelo ambiente regulatório, fomos forçados ao “silêncio”

Quando lançamos o projeto, estávamos no auge da “era Gary Gensler” (nota: Gary Gensler é presidente da SEC dos EUA, conhecido por sua postura regulatória rigorosa sobre cripto). Na época, várias empresas de staking estavam sob investigação e processos judiciais.

Como “projeto de restaking”, praticamente tudo que dizíamos em público podia ser interpretado como “promessa de investimento”, “publicidade de rendimento” e até atrair intimações.

Essa névoa regulatória determinou nossa forma de comunicação: não podíamos nos expressar livremente, mesmo diante de uma enxurrada de notícias negativas, parceiros nos culpando ou ataques de opinião pública, não podíamos esclarecer mal-entendidos em tempo real.

Nem mesmo podíamos dizer “não é bem assim” sem antes pesar o risco jurídico.

O resultado foi que, sem comunicação suficiente, lançamos tokens bloqueados. Olhando para trás, isso foi realmente arriscado.

Se você já achou que “a equipe Eigen foi evasiva ou estranhamente silenciosa” em algum assunto, provavelmente foi por causa desse ambiente regulatório — um tweet errado poderia trazer riscos consideráveis.

3. AVS iniciais diluíram o valor da marca

A influência inicial da marca Eigen vinha muito do Sreeram (membro central da equipe) — sua energia, otimismo e crença de que sistemas e pessoas podem melhorar trouxeram muita simpatia à equipe.

Bilhões em capital em staking reforçaram ainda mais essa confiança.

Mas nossa promoção conjunta dos primeiros AVS não correspondeu a esse “nível de marca”. Muitos AVS iniciais faziam barulho, mas só perseguiam tendências do setor, sem serem exemplos de “tecnologia de ponta” ou “integridade exemplar”.

Com o tempo, as pessoas passaram a associar “EigenLayer” a “novas oportunidades de mineração de liquidez e airdrops”. As dúvidas, fadiga e até aversão que enfrentamos hoje remontam a essa fase.

Se pudesse voltar atrás, começaria com “menos, mas melhores AVS”, seria mais criterioso com parceiros que recebessem endosso da marca e aceitaria um ritmo de promoção “mais lento e menos hype”.

4. Excesso de busca por “minimização de confiança” técnica levou a design redundante

Tentamos construir um “sistema de penalidade universal perfeito” — que fosse flexível, cobrisse todos os cenários de penalidade e alcançasse “minimização de confiança”.

Na prática, isso tornou nossa iteração de produto lenta e exigiu muito tempo explicando um mecanismo que “a maioria ainda não estava pronta para entender”. Até hoje, precisamos fazer repetidas explicações sobre o sistema de penalidade lançado há quase um ano.

Olhando agora, o caminho mais razoável seria: lançar primeiro uma solução simples de penalidade, deixar diferentes AVS testarem modelos mais focados e só então aumentar a complexidade do sistema. Mas colocamos o “design complexo” na frente e pagamos o preço em “velocidade” e “clareza”.

O que realmente conseguimos

As pessoas adoram rotular rapidamente as coisas como “fracasso”, mas isso é precipitado.

No capítulo do “restaking”, muita coisa foi feita com excelência, e esses resultados são cruciais para nosso futuro.

1. Provamos que podemos vencer em mercados competitivos

Preferimos “win-win”, mas não tememos competição — se entrarmos em um mercado, queremos liderar.

No restaking, Paradigm e Lido apoiaram juntos nosso concorrente direto. Na época, o TVL da EigenLayer era inferior a 1.1 billions.

O concorrente tinha vantagem de narrativa, canais, capital e “confiança padrão”. Muitos me disseram: “o time deles vai executar melhor e atropelar vocês”. Mas não foi assim — hoje temos 95% do market share de capital de restaking e atraímos 100% dos principais desenvolvedores.

No setor de Data Availability (DA), começamos mais tarde, com equipe menor e menos recursos, enquanto os pioneiros já tinham vantagem e marketing forte. Mas hoje, por qualquer métrica, a EigenDA (solução de DA da Eigen) detém grande parte do mercado de DA; com o lançamento total dos maiores parceiros, essa fatia crescerá exponencialmente.

Ambos os mercados são extremamente competitivos, mas conseguimos nos destacar.

2. EigenDA tornou-se um produto maduro que “transforma o ecossistema”

Lançar a EigenDA sobre a infraestrutura da EigenLayer foi uma grande surpresa.

Ela se tornou a base da EigenCloud e trouxe ao Ethereum algo muito necessário — um canal DA de escala massiva. Com ela, rollups podem operar em alta velocidade sem precisar sair do ecossistema Ethereum em busca de “velocidade” em outras blockchains.

O lançamento da MegaETH só aconteceu porque a equipe confiava que Sreeram poderia ajudá-los a superar o gargalo de DA; o Mantle propôs ao BitDAO construir um L2 pelo mesmo motivo.

A EigenDA também virou o “escudo de defesa” do Ethereum: com uma solução DA nativa de alta capacidade, blockchains externas têm mais dificuldade em “atrair atenção com a narrativa Ethereum e sugar valor do ecossistema”.

3. Impulsionamos o desenvolvimento do mercado de pré-confirmação

Um dos temas centrais da EigenLayer no início era como desbloquear a função de pré-confirmação do Ethereum via EigenLayer.

Desde então, a pré-confirmação ganhou atenção via rede Base, mas a implementação ainda enfrenta desafios.

Para impulsionar o ecossistema, lançamos o programa Commit-Boost — para resolver o “efeito de bloqueio” dos clientes de pré-confirmação, criando uma plataforma neutra onde qualquer um pode inovar via compromissos de validadores.

Hoje, bilhões de dólares já circulam pelo Commit-Boost, e mais de 35% dos validadores aderiram ao programa. Com o lançamento dos principais serviços de pré-confirmação nos próximos meses, essa proporção aumentará ainda mais.

Isso é vital para a “antifragilidade” do ecossistema Ethereum e fundamenta a inovação contínua no mercado de pré-confirmação.

4. Sempre garantimos a segurança dos ativos

Ao longo dos anos, garantimos a segurança de dezenas de bilhões de dólares em ativos.

Isso pode soar banal, até “chato” — mas basta lembrar quantas infraestruturas cripto já “colapsaram” de várias formas para perceber o quão valiosa é essa “normalidade”. Para evitar riscos, construímos um sistema operacional sólido de segurança, recrutamos e treinamos uma equipe de segurança de classe mundial e incorporamos o “pensamento adversarial” à cultura da equipe.

Essa cultura é essencial para qualquer negócio que envolva fundos de usuários, IA ou sistemas do mundo real, e não pode ser “adicionada depois” — precisa ser a base desde o início.

5. Impedimos que a Lido mantivesse mais de 33% do staking por muito tempo

O restaking teve um impacto subestimado: grandes volumes de ETH migraram para provedores de LRT, evitando que a Lido mantivesse uma fatia de staking acima de 33% por muito tempo.

Isso é crucial para o “equilíbrio social” do Ethereum. Se a Lido mantivesse mais de 33% do staking sem alternativas confiáveis, haveria grandes controvérsias de governança e conflitos internos.

Restaking e LRT não “descentralizaram magicamente” tudo, mas mudaram a tendência de concentração do staking — e isso não é pouca coisa.

6. Esclarecemos onde está a “verdadeira fronteira”

O maior “ganho” foi conceitual: comprovamos que “o mundo precisa de mais sistemas verificáveis”, mas também percebemos que o “caminho” estava errado.

O caminho certo não é “começar com segurança criptoeconômica genérica, insistir em operadores totalmente descentralizados desde o primeiro dia e esperar que todos os negócios se conectem a esse nível”.

O que realmente acelera a “fronteira” é: dar ferramentas diretas aos desenvolvedores para que possam implementar verificabilidade em suas aplicações específicas, com primitivas de verificação adequadas. Precisamos “nos aproximar das necessidades dos desenvolvedores”, não exigir que virem “designers de protocolo” desde o início.

Para isso, já começamos a construir serviços modulares internos — EigenCompute (serviço de computação verificável) e EigenAI (serviço de IA verificável). Algumas funções que outras equipes precisariam de centenas de milhões de dólares e anos para lançar, conseguiremos em poucos meses.

Próximos passos

Diante dessas experiências — timing, sucessos, fracassos, “cicatrizes” de marca — como devemos agir?

Aqui está um resumo dos próximos planos e da lógica por trás:

1. Tornar o token EIGEN o núcleo do sistema

No futuro, toda a EigenCloud e todos os produtos ao seu redor terão o token EIGEN como centro.

O papel do token EIGEN será:

• Motor central de segurança econômica da EigenCloud;
• Ativo que respalda os diversos riscos assumidos pela plataforma;
• Ferramenta central de captura de valor de todos os fluxos de taxas e atividades econômicas da plataforma.

No início, muitos tinham expectativas sobre “que valor o token EIGEN pode capturar” diferentes do “mecanismo real” — isso gerou confusão. Na próxima fase, vamos preencher essa lacuna com design e sistemas concretos. Mais detalhes serão divulgados em breve.

2. Permitir que desenvolvedores construam “aplicações verificáveis”, não apenas AVS

Nossa tese central permanece: aumentar a verificabilidade de cálculos off-chain para que as pessoas possam construir aplicações on-chain com mais segurança. Mas as ferramentas para “verificabilidade” não se limitarão a uma só.

Às vezes, será segurança criptoeconômica; outras vezes, provas ZK, TEE (Ambiente de Execução Confiável) ou soluções híbridas. O importante não é “favorecer uma tecnologia”, mas tornar a “verificabilidade” uma primitiva padrão acessível diretamente na stack dos desenvolvedores.

Nosso objetivo é reduzir a distância entre dois estados:

De “tenho um aplicativo” para “tenho um aplicativo que usuários, parceiros ou reguladores podem verificar”.

Pelo cenário atual do setor, “criptoeconomia + TEE” é sem dúvida a melhor escolha — equilibra “programabilidade para desenvolvedores” (o que podem construir) e “segurança” (não só teórica, mas prática).

No futuro, quando provas ZK e outros mecanismos de verificação forem maduros e atenderem às necessidades dos desenvolvedores, também os integraremos à EigenCloud.

3. Investir profundamente em IA

A maior transformação global em computação hoje é a IA — especialmente os agentes inteligentes (AI Agents). O setor cripto não ficará de fora.

Agentes de IA são, essencialmente, “modelos de linguagem encapsulando ferramentas e executando operações em ambientes específicos”.

Hoje, não só os modelos de linguagem são “caixas-pretas”, mas também a lógica operacional dos agentes de IA é opaca — por isso, já ocorreram ataques hackers por “ter que confiar no desenvolvedor”.

Mas se agentes de IA forem “verificáveis”, as pessoas não precisarão mais depender da confiança no desenvolvedor.

Para que agentes de IA sejam verificáveis, três condições são necessárias: o processo de inferência do LLM (Large Language Model) deve ser verificável, o ambiente de execução das operações deve ser verificável e a camada de dados para armazenar, recuperar e entender contexto deve ser verificável.

A EigenCloud foi projetada para esses cenários:

• EigenAI: fornece serviço de inferência LLM determinístico e verificável;
• EigenCompute: fornece ambiente de execução de operações verificável;
• EigenDA: fornece serviço de armazenamento e recuperação de dados verificável.

Acreditamos que “agentes de IA verificáveis” serão um dos cenários mais competitivos para nosso “serviço de nuvem verificável” — por isso, já formamos uma equipe dedicada a esse campo.

4. Redefinir a narrativa de “staking e rendimento”

Para obter rendimento real, é preciso assumir riscos reais.

Estamos explorando cenários mais amplos de “aplicações de staking”, para que o capital em staking possa respaldar os seguintes riscos:

• Risco de contratos inteligentes;
• Riscos de diferentes tipos de computação;
• Riscos claramente descritos e com precificação quantificável.

Os rendimentos futuros refletirão de fato “os riscos transparentes e compreensíveis assumidos”, e não apenas a busca por “modismos de mineração de liquidez”.

Essa lógica será naturalmente incorporada ao uso, escopo de respaldo e mecanismo de fluxo de valor do token EIGEN.

Considerações finais

O restaking não se tornou a “camada universal” que eu (e outros) esperávamos, mas também não desapareceu. Ao longo de seu desenvolvimento, tornou-se o que a maioria dos “produtos de primeira geração” acaba sendo:

Um capítulo importante, um conjunto de lições valiosas e a infraestrutura que hoje sustenta negócios mais amplos.

Continuamos mantendo as operações relacionadas ao restaking e ainda o valorizamos — só não queremos mais ficar presos à narrativa inicial.

Se você é membro da comunidade, desenvolvedor de AVS ou investidor que ainda associa Eigen ao “projeto de restaking”, espero que este artigo ajude a entender melhor “o que aconteceu” e “para onde estamos indo”.

Agora, estamos entrando em um campo com um “Total Addressable Market (TAM) maior”: de um lado, serviços de nuvem; de outro, demandas diretas da camada de aplicação para desenvolvedores. Também estamos explorando a “corrida de IA ainda pouco explorada” e vamos avançar nesses rumos com nossa tradicional intensidade de execução.

A equipe continua cheia de energia, e mal posso esperar para provar a todos os céticos — nós conseguimos.

Nunca estive tão otimista com a Eigen e sigo aumentando minha posição em EIGEN, e continuarei fazendo isso no futuro.

Ainda estamos só no começo.