O que se passa com o re-staking?

Escrito por: Kydo, Responsável pela Narrativa da EigenCloud

Tradução: Saoirse, Foresight News

De tempos a tempos, amigos enviam-me tweets a gozar com o restaking, mas essas críticas raramente acertam no alvo. Por isso decidi escrever eu mesmo um texto de reflexão, em tom de “desabafo”.

Talvez penses que estou demasiado envolvido para ser objetivo; ou que sou demasiado orgulhoso para admitir que “falhámos”. Podes achar que, mesmo que toda a gente já acredite que “o restaking falhou”, ainda assim escreveria um longo texto a defender a ideia, recusando-me sempre a usar a palavra “falhanço”.

Estas opiniões são razoáveis e, em muitos casos, fazem sentido.

Mas este artigo pretende apenas apresentar os factos de forma objetiva: o que aconteceu, o que conseguimos concretizar, o que falhou e que lições tirámos de tudo isto.

Espero que a experiência aqui partilhada seja útil e possa servir de referência para outros developers do ecossistema.

Após mais de dois anos a integrar todos os principais AVS (Serviços de Validação Autónoma) na EigenLayer e a conceber a EigenCloud, quero fazer uma revisão honesta: onde errámos, onde acertámos e para onde seguimos daqui.

Afinal, o que é o restaking?

O facto de ainda ser preciso explicar “o que é o restaking” demonstra que, mesmo quando o tema estava no centro das atenções, não conseguimos comunicá-lo bem. Eis a “lição zero”: focar numa narrativa central e repeti-la até à exaustão.

O objetivo da equipa Eigen sempre foi “fácil de dizer, difícil de fazer”: aumentar a verificabilidade de computação off-chain, permitindo que as pessoas construam aplicações na blockchain com mais segurança.

O AVS foi a nossa primeira tentativa concreta e assumida nesse sentido.

Os AVS (Serviços de Validação Autónoma) são redes Proof of Stake (PoS) compostas por operadores descentralizados que executam tarefas off-chain. As suas ações são monitorizadas e, em caso de violação, os ativos em stake podem ser penalizados. Para que haja penalização (“slashing”), é preciso existir capital em stake.

É aqui que o restaking revela o seu valor: sem necessidade de cada AVS criar o seu próprio sistema de segurança do zero, o restaking permite reutilizar o ETH já em stake para garantir a segurança de vários AVS. Isto reduz o custo de capital e acelera o lançamento de novos ecossistemas.

Assim, o quadro conceptual do restaking pode ser resumido assim:

AVS: a “camada de serviço”, onde assentam os novos sistemas de segurança criptoeconómica PoS;

Restaking: a “camada de capital”, que reutiliza ativos já em stake para garantir a segurança destes sistemas.

Continuo a achar esta ideia elegante, mas a realidade ficou longe do “diagrama ideal” — muita coisa ficou aquém do esperado.

O que não correu como planeado

1. Escolhemos o mercado errado: demasiado de nicho

Não queríamos “qualquer tipo de computação verificável”, mas sim sistemas que, desde o primeiro dia, fossem descentralizados, baseados em penalizações e com segurança criptoeconómica total.

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

Esta postura, embora de princípio, reduziu drasticamente o universo de potenciais developers.

O resultado foi um mercado “pequeno, lento e de acesso difícil”: poucos utilizadores potenciais, custos elevados para concretizar, e ciclos de desenvolvimento longos, tanto para a equipa como para os developers. Quer a infraestrutura base da EigenLayer, quer as ferramentas de desenvolvimento, quer cada AVS de topo, tudo demorou meses ou anos a ser construído.

Três anos depois: temos apenas dois AVS relevantes em produção — o DIN (Decentralized Infrastructure Network) da Infura e o EigenZero da LayerZero. Esta taxa de adoção está longe de ser “ampla”.

A verdade é que desenhámos o produto para equipas que “querem segurança criptoeconómica e operadores descentralizados desde o início”, mas o mercado pedia soluções “mais graduais e centradas na aplicação”.

2. O contexto regulatório obrigou-nos ao “silêncio”

Lançámos o projeto no auge da era “Gary Gensler” (Nota: Gary Gensler é presidente da SEC dos EUA e conhecido pela sua postura rigorosa face às criptomoedas). Nessa altura, várias empresas de staking estavam sob investigação e processos judiciais.

Como projeto de restaking, qualquer palavra dita em público podia ser interpretada como “promessa de investimento” ou “publicidade a retornos”, e até trazer uma intimação.

Este ambiente regulatório condicionou toda a nossa comunicação: não podíamos falar livremente, mesmo perante ondas de notícias negativas, culpabilização de parceiros ou ataques públicos, não podíamos esclarecer as coisas em tempo real.

Nem sequer podíamos dizer “não é bem assim” sem antes pesar o risco legal.

O resultado foi termos lançado um token com vesting sem comunicar devidamente. Hoje, reconheço que foi arriscado.

Se alguma vez achaste que a equipa da Eigen era evasiva ou estranhamente silenciosa sobre algum tema, provavelmente era por causa deste contexto — um tweet em falso podia ter consequências graves.

3. Os AVS iniciais diluíram o valor da marca

A força da marca Eigen vinha, em grande parte, de Sreeram (membro central da equipa) — o seu dinamismo, otimismo e crença de que “os sistemas e as pessoas podem sempre melhorar” geraram enorme goodwill.

Os milhares de milhões em capital em stake reforçaram ainda mais essa confiança.

Mas a promoção conjunta dos primeiros AVS não correspondeu à altura da marca. Muitos dos AVS iniciais fizeram muito barulho, mas apenas seguiam as tendências do setor — não eram exemplos de “tecnologia de topo” nem de “integridade máxima”.

Com o tempo, as pessoas começaram a associar a “EigenLayer” aos “novos ciclos de farming e airdrops”. As dúvidas, saturação e até rejeição que sentimos hoje têm raízes nessa fase.

Se pudesse voltar atrás, teria começado com “menos, mas melhores AVS”, teria sido mais seletivo com os parceiros que mereciam o selo da marca e aceitaria um crescimento “mais lento e discreto”.

4. O excesso de “minimização de confiança” tornou o design demasiado complexo

Tentámos construir um “sistema de penalização universal perfeito”: genérico, flexível, capaz de cobrir todos os cenários possíveis, minimizando a necessidade de confiança.

Na prática, isto tornou a iteração do produto muito lenta e obrigou-nos a gastar imenso tempo a explicar um mecanismo que “a maioria das pessoas ainda não está pronta para compreender”. Ainda hoje, temos de fazer pedagogia contínua sobre o sistema de penalização que lançámos há quase um ano.

Olhando para trás, teria sido melhor lançar primeiro um sistema de penalização simples, deixar cada AVS experimentar abordagens mais focadas e depois aumentar gradualmente a complexidade. Em vez disso, começámos pela “complexidade”, sacrificando velocidade e clareza.

O que realmente conseguimos

É demasiado fácil rotular tudo como “falhanço”, mas isso seria injusto.

No capítulo do “restaking” há conquistas importantes, essenciais para o futuro.

1. Provámos que sabemos vencer em mercados competitivos

Preferimos “win-win”, mas não tememos a concorrência — se entramos num mercado, é para liderar.

No restaking, Paradigm e Lido apoiaram um rival direto. Na altura, o TVL da EigenLayer era inferior a 1.000 milhões.

O rival tinha melhor narrativa, mais canais, capital e “confiança por defeito”. Muitos disseram-me “eles vão executar melhor e esmagar-vos”. Mas não foi o que aconteceu — hoje temos 95% do mercado de capital em restaking e atraímos 100% dos developers de topo.

No mercado de Data Availability (DA), começámos mais tarde, com equipa menor e menos recursos, e o líder já tinha grande vantagem e marketing forte. Agora, seja qual for o critério, o EigenDA ocupa uma grande fatia do mercado DA; e, com o maior parceiro a entrar, essa fatia vai crescer exponencialmente.

Ambos os mercados são hipercompetitivos, mas conseguimos destacar-nos.

2. O EigenDA tornou-se um produto maduro e transformador

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

Tornou-se a base da EigenCloud e trouxe ao Ethereum o que mais faltava: um canal de DA em escala massiva. Agora, os Rollups mantêm alta performance sem precisarem de sair do ecossistema Ethereum para procurar outras chains.

O projeto MegaETH só arrancou porque a equipa acreditou que Sreeram lhes poderia resolver o bottleneck da DA; o Mantle propôs construir uma L2 ao BitDAO pela mesma razão.

O EigenDA é também um “escudo protetor” para o Ethereum: com uma solução de DA nativa e de alta performance dentro do ecossistema, torna-se mais difícil para chains externas “atraírem developers graças à narrativa Ethereum e drenarem valor”.

3. Impulsionámos o mercado de pré-confirmações (pre-confirmations)

Um dos temas centrais da EigenLayer foi como desbloquear pré-confirmações no Ethereum através da nossa infraestrutura.

Desde então, as pré-confirmações ganharam notoriedade com a rede Base, mas a adoção ainda é difícil.

Para ajudar, lançámos o programa Commit-Boost — para resolver o “efeito de lock-in” dos clientes de pré-confirmação, criando uma plataforma neutra onde qualquer pessoa pode inovar usando compromissos de validadores.

Hoje, já circulam milhares de milhões através do Commit-Boost, e mais de 35% dos validadores aderiram. Com a chegada iminente dos principais serviços de pré-confirmação, este número vai crescer.

Isto é chave para a “antifragilidade” do Ethereum e para manter a inovação neste mercado.

4. Sempre protegemos os ativos dos utilizadores

Durante anos, mantivemos seguros milhares de milhões de dólares.

Pode parecer banal — até “aborrecido” — mas, considerando quantos projetos de infraestrutura colapsaram de todas as maneiras possíveis, esta “normalidade” é valiosa. Construímos sistemas operacionais robustos, recrutámos e formámos uma equipa de segurança de nível mundial e incutimos uma cultura de “pensamento adversarial”.

Esta cultura é crucial para qualquer negócio que lide com fundos, IA ou sistemas com impacto real — e não se pode “adicionar depois”, tem de estar presente desde o início.

5. Evitámos que a Lido ultrapassasse os 33% de participação em staking

Um efeito subestimado do restaking: enormes quantidades de ETH foram para fornecedores de LRT, impedindo que a Lido se mantivesse acima dos 33% de participação.

Isto foi vital para o “equilíbrio social” do Ethereum. Se a Lido tivesse mais de 33% de forma sustentada, sem alternativa fiável, teríamos conflitos graves de governação.

O restaking e os LRT não trouxeram “descentralização mágica”, mas inverteram a tendência de concentração do staking — e isso é uma conquista importante.

6. Clarificámos onde está a verdadeira “fronteira”

A maior “vitória” foi de conceito: validámos que “o mundo precisa de mais sistemas verificáveis”, mas também percebemos que a via escolhida não era a certa.

O caminho certo não é “começar com segurança criptoeconómica universal, exigir operadores totalmente descentralizados desde o dia 1 e esperar que todos adiram”.

O que acelera a inovação é dar ferramentas diretas aos developers para implementar verificabilidade nas suas aplicações, com primitivas adequadas ao caso de uso. Devemos “aproximar-nos das necessidades dos developers”, não exigir que sejam “arquitetos de protocolos” desde o início.

Por isso, começámos a criar serviços internos modulares — EigenCompute (computação verificável) e EigenAI (IA verificável). O que a outros exigiria centenas de milhões e anos de trabalho, conseguimos lançar em meses.

O que aí vem

Então, perante esta experiência — timing, sucessos, falhas, “cicatrizes” de marca — como reagir?

Segue um resumo do nosso próximo plano e da lógica por trás dele:

1. Tornar o token EIGEN o coração do sistema

No futuro, toda a EigenCloud e os produtos que construirmos à sua volta terão o EIGEN como centro.

O EIGEN será:

O núcleo da segurança criptoeconómica da EigenCloud;

O ativo que responde por todos os riscos da plataforma;

A ferramenta central para captar valor de todas as taxas e atividades económicas.

Inicialmente, muitos tinham uma expectativa irrealista sobre “que valor capta o EIGEN” vs. “a mecânica real” — isso causou confusão. Agora, vamos fechar essa lacuna com design e sistemas concretos. Mais pormenores em breve.

2. Permitir aos developers construir “aplicações verificáveis”, não só AVS

O nosso argumento central mantém-se: aumentar a verificabilidade da computação off-chain para segurança on-chain. Mas as ferramentas para isso não serão só uma.

Pode ser segurança criptoeconómica, provas ZK, TEE (ambientes de execução confiáveis) ou soluções híbridas. O importante não é “evangelizar uma tecnologia”, mas tornar a “verificabilidade” uma primitiva acessível na stack dos developers.

Queremos reduzir o fosso entre:

“Tenho uma aplicação” e “tenho uma aplicação que qualquer utilizador, parceiro ou regulador pode verificar”.

Atualmente, “criptoeconomia + TEE” é a escolha ideal — equilibra programabilidade e segurança prática.

No futuro, quando as provas ZK e outras soluções amadurecerem, também as integraremos na EigenCloud.

3. Apostar a sério na IA

A maior revolução atual em computação é a IA — especialmente agentes inteligentes (AI Agents). No cripto, isto não passa ao lado.

Agentes de IA são, basicamente, “modelos de linguagem com ferramentas, a executar ações em contexto”.

Hoje, não só os modelos são “caixas negras”, como a lógica dos agentes também não é transparente — já vimos ataques porque “é preciso confiar cegamente no developer”.

Com verificabilidade nos agentes de IA, deixamos de depender da confiança no developer.

Para isso, são precisas três condições: inferência do LLM verificável, ambiente de execução verificável e camada de dados (armazenamento, acesso, contexto) verificável.

A EigenCloud foi desenhada para isto:

EigenAI: serviço de inferência LLM determinístico e verificável;

EigenCompute: ambiente de execução verificável;

EigenDA: armazenamento e acesso a dados verificável.

Acreditamos que “IA verificável” é uma das aplicações mais competitivas dos nossos serviços — por isso, já temos uma equipa dedicada a este domínio.

4. Redefinir a narrativa sobre “staking e rendimento”

Para haver rendimento real, tem de haver risco real.

Exploramos “casos de uso de staking” mais amplos, onde o capital em stake cobre riscos como:

Risco de smart contracts;

Riscos de diferentes tipos de computação;

Riscos claramente descritos e com preço quantificável.

Os rendimentos refletirão o risco real, não apenas a moda do “farming de liquidez”.

Esta lógica integrará naturalmente os casos de uso, o alcance e os fluxos de valor do token EIGEN.

Palavras finais

O restaking não se tornou a “camada universal” que eu (e outros) esperava, mas também não desapareceu. No seu percurso, tornou-se aquilo em que muitos “produtos de primeira geração” acabam:

Um capítulo importante, um conjunto de lições caras, e uma infraestrutura que agora sustenta negócios mais vastos.

Continuamos a manter e valorizar o restaking — só não queremos ficar presos à narrativa original.

Se és membro da comunidade, developer de AVS ou investidor que ainda associa a Eigen ao “projeto do restaking”, espero que este artigo te ajude a perceber “o que aconteceu” e “para onde vamos”.

Agora, entramos num setor com um TAM (Total Addressable Market) maior: de um lado, cloud services, do outro, necessidades diretas dos developers. Exploramos o “novo campo da IA” e vamos manter o ritmo de execução.

A equipa mantém-se motivada, e estou ansioso por provar aos céticos — somos capazes.

Nunca estive tão otimista com a Eigen. Continuo a aumentar a minha posição em EIGEN e assim continuarei.

Estamos só no começo.