Código órfão: a cripto venera quem constrói, não quem mantém

A Ethereum financia, direta ou indiretamente, milhares de programadores. Paga hackathons, distribui grants, inspira creator coins e enche palcos de conferências com os nomes que a comunidade venera. Mas existe um grupo pequeno, talvez duas centenas de pessoas, que mantém o núcleo da rede a funcionar: os clientes de software sobre os quais assentam centenas de milhares de milhões de euros em ativos. E esse grupo pode ficar sem financiamento estável dentro de meses.

Não é um detalhe de engenharia. É o retrato invertido de tudo o que a cultura do builder celebra. O género do perfil de builder, que esta publicação tem dissecado ao longo de uma série, fotografa sempre o arquiteto da coisa nova: o fundador que lança, o programador que faz ship, o rosto que acumula atenção. Quase nunca fotografa quem mantém a coisa velha a funcionar depois de as luzes se apagarem.

Em 2026, esse ponto cego deixou de ser uma questão estética e passou a ser um risco sistémico. Oitenta e dois projetos fecharam as portas só este ano. A atividade de programadores caiu a pique à medida que a inteligência artificial absorveu talento. E a própria Ethereum, a rede-bandeira do open source com valor económico, debate-se para pagar a quem a mantém de pé. Este artigo é sobre o builder que o culto esquece: aquele que fica.

O retrato que nunca mostra o zelador

Um perfil de builder segue quase sempre a mesma coreografia. Há uma origem (o abandono de um emprego confortável), uma visão (a tese contra-intuitiva sobre o futuro), um momento de criação (a noite em claro no hackathon, o primeiro deploy) e uma tração (os utilizadores, o token, a ronda de investimento). O arco é o da fundação: alguém trouxe algo novo ao mundo. A palavra que a indústria escolheu para esse alguém, «builder», carrega o verbo da construção, não o da conservação.

O problema é que o software não termina no deploy. Começa aí. Um smart contract que gere liquidez precisa de ser vigiado, auditado, atualizado quando a biblioteca de que depende tem uma vulnerabilidade, migrado quando a rede faz um hard fork. Um cliente de execução da Ethereum precisa de acompanhar cada alteração ao protocolo, de responder a incidentes às três da manhã, de reescrever código aborrecido que ninguém vai celebrar. Essa é a parte da engenharia que não cabe no retrato, porque não tem narrativa: a manutenção é, por definição, a ausência de acontecimentos. Quando o trabalho de manutenção é bem feito, não acontece nada, e nada não dá uma boa história.

Há aqui uma assimetria que a cultura cripto herdou do resto da indústria de software e amplificou. Celebramos o engenheiro que escreve a primeira linha e ignoramos o que escreve a milésima correção. Fotografamos o arquiteto e esquecemos o zelador, aquele que limpa o que os outros deixaram, que tapa buracos, que mantém as luzes acesas. No universo cripto, onde o código gere dinheiro diretamente, essa assimetria não é apenas injusta. É perigosa.

Construir é glamour, manter é invisível

Por que razão a manutenção ficou tão desvalorizada? Em parte porque os incentivos da indústria pagam quase tudo ao lançamento e quase nada à continuidade. Um token tem um Token Generation Event, um momento de estreia com preço, liquidez e holofotes; não tem um equivalente para o quinto ano de patches de segurança. Um fundador angaria capital numa ronda, não numa fatura mensal de manutenção. Os mercados de atenção, que já cobrimos nesta série, medem quem está a falar agora, não quem está a sustentar silenciosamente algo que já ninguém comenta.

A mitologia do builder reforça isto. A figura venerada é a do criador solitário que vê o que mais ninguém vê e o traz à existência; não a do responsável paciente que herda código alheio e o impede de ruir. O primeiro é um herói romântico; o segundo é, na melhor das hipóteses, um profissional competente. Ninguém escreve threads épicas sobre a pessoa que, há oito anos, mantém uma biblioteca de criptografia de que dependem metade das carteiras do mercado. Essa pessoa não tem um creator coin. Muitas vezes, nem sequer tem salário.

O resultado é um sistema que produz, de forma estrutural, código órfão: software crítico, em produção, a mover valor real, cujo criador original seguiu em frente e cujo mantenedor atual ou não existe ou está esgotado. A indústria trata a manutenção como um custo a minimizar, não como um ativo a proteger. E depois surpreende-se quando o custo chega, invariavelmente sob a forma de uma falha que podia ter sido evitada.

Vale a pena notar que isto não é exclusivo da cripto. É uma inclinação de toda a cultura tecnológica, que durante anos glorificou a inovação e tratou a manutenção como trabalho de segunda. A diferença é que, no software financeiro, a conta chega mais depressa e é paga em fundos de utilizadores. Um banco tradicional tem departamentos inteiros dedicados a manter sistemas antigos a funcionar; boa parte da cripto terceirizou essa função para voluntários e torceu para que corresse bem.

A crise que a própria Ethereum não consegue financiar

Se há rede que devia estar imune a este problema, é a Ethereum. Tem uma fundação com um tesouro de milhares de milhões, um ecossistema inteiro construído à volta do financiamento de bens públicos e um fundador que fez da sustentabilidade do open source uma causa pessoal. E, ainda assim, é precisamente ali que o alarme soou mais alto em 2026.

Trent Van Epps, que contribuiu para a Ethereum Foundation entre maio de 2021 e abril de 2026, descreveu o que chamou uma crise de financiamento de combustão lenta para o desenvolvimento do núcleo. A sua estimativa, numa entrevista à CoinDesk, foi direta: «O nível de financiamento necessário para o desenvolvimento do núcleo é relativamente estável. Estimaria qualquer coisa como 30 milhões por ano. Já distribuímos quase 40 milhões a muitos destes core developers, mas isto ao longo de quatro anos e, no fim, não chega.» Trinta milhões de dólares por ano são cerca de 26,7 milhões de euros; os quase 40 milhões distribuídos ao longo de quatro anos dão uma média de dez milhões por ano, menos de metade do necessário.

O buraco agravou-se por uma razão concreta de calendário. O Client Incentive Program, um esquema financiado pela Fundação durante quatro anos que pagava recompensas em ETH às equipas que constroem e mantêm os clientes de software da rede (nomes como Geth, Erigon ou Lighthouse), expirou em abril de 2026, e, nas palavras de Van Epps, nenhum substituto parecia pronto. O resultado é um aviso que soa estranho vindo da segunda maior rede do mundo: as pressões de financiamento podiam materializar-se, disse ele, dentro de três a nove meses. A rede que distribui dinheiro a meio mundo pode não ter um mecanismo fiável para pagar às duas centenas de pessoas sem as quais deixa de funcionar.

Como se paga (mal) a manutenção de uma blockchain

A principal tentativa de resolver este problema chama-se Protocol Guild, e vale a pena perceber como funciona, porque é uma das engenharias financeiras mais interessantes que a Ethereum produziu. Em vez de depender do orçamento discricionário de uma fundação, a Protocol Guild é um fundo coletivo e on-chain para os contribuidores do núcleo. Assenta num «1% Pledge»: pede-se aos projetos que construíram negócios em cima da Ethereum que comprometam cerca de 1% dos seus tokens com quem mantém a camada base. Um multisig de seis em dez membros governa o fundo, um contrato de distribuição reparte-o e um contrato de vesting imutável segura os ativos durante um ano, libertando-os de forma linear.

A lógica é elegante: quem qualifica tem de ter contribuído de forma contínua para o protocolo durante pelo menos seis meses, e a fatia de cada um é ponderada pela antiguidade e pelo regime (tempo inteiro conta a dobrar de meio-tempo). É uma forma de alinhar o sucesso dos negócios do ecossistema com a sobrevivência da infraestrutura comum. Mas, como os números de Van Epps deixam claro, não chega. Depende da boa vontade de um punhado de projetos e de doações avulsas, e a soma fica estruturalmente abaixo do que a manutenção custa.

A ironia mais aguda é o plano B informal que foi ganhando forma: em 2025, Vitalik Buterin moveu pessoalmente 16.384 ETH, na altura cerca de 45 milhões de dólares (perto de 40 milhões de euros), para financiar um conjunto de projetos de segurança e privacidade open source. Ou seja: quando o sistema não paga a quem mantém a infraestrutura, o criador da própria rede tira do bolso. É generoso e é exatamente o problema. Uma infraestrutura que vale centenas de milhares de milhões não devia depender da filantropia de uma pessoa. A tabela seguinte resume o estado dos canais que, em teoria, deviam sustentar quem mantém a Ethereum.

Oitenta e duas lápides num só ano

Enquanto a Ethereum discute como pagar a quem fica, a ponta oposta do mercado mostra o que acontece a quem parte. A 2 de novembro de 2026, a investigadora Stacy Muur publicou uma lista de projetos que encerraram operações durante o ano: oitenta e dois protocolos. A DeFiLlama, que acompanha os números de forma independente, chegou a uma contagem ainda maior, cerca de cem, com quarenta só nos últimos noventa dias. Juntos, estes projetos tinham angariado cerca de mil milhões de dólares (perto de 890 milhões de euros) e geraram, ao longo de toda a sua vida, cerca de 250 milhões em comissões. Nove deles tinham, cada um, mais de 50 milhões em financiamento.

A causa principal apontada não foi um hack nem um colapso de mercado, foi a ausência de product-market fit, seguida de financiamento esgotado e receita insuficiente. Por outras palavras: a maior parte destes projetos não morreu de forma dramática. Simplesmente deixou de ser mantida. O token continuou a existir, o contrato continuou on-chain, e o builder seguiu para o projeto seguinte. Muitos eram forks de baixa qualidade, lançadores de memecoins e experiências abandonadas que, no auge, inflacionaram as estatísticas de atividade da indústria inteira.

O detalhe incómodo é o que fica para trás. Quando um protocolo encerra, o código não desaparece: continua implantado, continua a poder guardar fundos de utilizadores que não leram o aviso, continua a depender de bibliotecas que ninguém vai voltar a atualizar. A concentração de liquidez e de infraestrutura que analisámos a propósito do apagão da Binance e da fuga para a DeFi tem uma versão silenciosa aqui: cada projeto morto é um pedaço de superfície de ataque que o mercado herda sem o saber.

Para o utilizador comum, o risco é concreto. Fundos deixados num protocolo encerrado podem ficar presos se a interface deixar de funcionar, mesmo que o contrato ainda responda; uma integração que dependia de um oráculo descontinuado pode comportar-se de forma imprevisível; e um token sem equipa é um alvo fácil para quem quiser explorar a última vulnerabilidade por corrigir. A morte de um projeto raramente é limpa: deixa um rasto de obrigações que ninguém assumiu.

O êxodo que esvazia a oficina

Por detrás das lápides está uma retirada de mão de obra. Os dados da Artemis, compilados pela CoinDesk, mostram uma queda vertiginosa na atividade de programação: os commits semanais caíram de cerca de 850 mil, no início de 2025, para perto de 210 mil, uma descida de aproximadamente 75%. O número de programadores ativos por semana recuou cerca de 56%, para uns 4.600. E a composição mudou: os recém-chegados, com menos de doze meses de experiência, caíram quase 60%, enquanto os veteranos passaram a produzir cerca de 70% de todo o código.

A causa imediata já a documentámos no êxodo do builder para a inteligência artificial: o talento que a cripto venerava foi atraído por salários e por um novo frisson tecnológico. Mas o efeito sobre a manutenção é duplo e perverso. Primeiro, saem precisamente as pessoas que conheciam o código por dentro, as que sabiam porque é que aquela função estranha estava ali. Segundo, a saída dos recém-chegados significa que não há quem os substitua: a oficina esvazia-se por cima e por baixo ao mesmo tempo.

Há uma leitura otimista, e é justo registá-la: se quem sai são sobretudo os forks oportunistas e os projetos sustentados só por narrativa, a concentração de veteranos em redes com utilizadores e receita reais pode ser saudável. O código a sério fica em mãos mais experientes. Mas essa consolidação tem um reverso: quando o conhecimento se concentra em poucas cabeças, cada uma dessas cabeças torna-se um ponto único de falha. É aqui que entra um conceito que a engenharia de software conhece há décadas e que a cripto teima em ignorar.

O fator autocarro

Chama-se «fator autocarro» (bus factor) e mede uma coisa brutal: quantas pessoas teriam de ser atropeladas por um autocarro para que um projeto deixasse de poder avançar. Um fator autocarro de um significa que há uma única pessoa que, se desaparecer, leva com ela o conhecimento necessário para manter o software vivo. É a métrica de fragilidade que nenhum perfil de builder inclui, porque mede exatamente o oposto do que o género quer vender: não a genialidade de um indivíduo, mas a dependência insustentável de um indivíduo.

Os números do open source em geral são assustadores. Segundo o relatório de 2025 da Tidelift sobre o estado dos mantenedores, 60% dos mantenedores descrevem-se como amadores não pagos, 44% ponderaram desistir no último ano e, no dado mais alarmante, 22% dos projetos considerados críticos têm um único mantenedor ativo. O mantenedor mediano sustenta um projeto com mais de 100 mil downloads semanais. Traduzindo para a cripto: uma fatia enorme da infraestrutura sobre a qual corre dinheiro real assenta em pessoas que trabalham sozinhas, de graça, e que estão exaustas.

O fator autocarro tem ainda uma variante específica da cripto, a do mantenedor pseudónimo. Boa parte da infraestrutura é mantida por contas sem rosto, e já explorámos noutra parte desta série o que acontece quando o builder é um impostor ou quando é, afinal, várias identidades fabricadas. Quando o mantenedor é anónimo e único, a fragilidade do fator autocarro soma-se à impossibilidade de o substituir: ninguém sabe sequer a quem ligar.

Código zombie: a árvore de dependências que ninguém rega

A fragilidade não é hipotética, e a sua escala foi medida. O relatório OSSRA de 2026 da Black Duck, que auditou 947 bases de código em dezassete indústrias, encontrou um número que devia tirar o sono a qualquer responsável técnico: cerca de 93% das bases de código continham componentes «zombie», dependências sem qualquer atividade de desenvolvimento nos dois anos anteriores. São bibliotecas que continuam a ser enviadas em produção muito depois de o seu mantenedor ter desaparecido, que nunca são atualizadas porque já não há quem as atualize, e que acumulam vulnerabilidades por corrigir.

Nenhuma aplicação cripto é uma ilha. Uma carteira, um protocolo de empréstimo, uma ponte entre redes: todos assentam numa árvore de dependências, bibliotecas que importam outras bibliotecas que importam outras ainda, muitas delas mantidas por voluntários que a maioria dos utilizadores nunca ouviu nomear. Quando um ramo dessa árvore seca, a aplicação no topo continua a parecer saudável, até ao dia em que não continua. A promessa de que o código é imutável e auto-suficiente esconde esta verdade incómoda: o software vivo precisa de jardinagem constante, e boa parte da jardinagem da cripto deixou de ser feita.

O mundo fora da cripto já teve o seu aviso. Há alguns anos, uma falha numa biblioteca de registo chamada Log4j, mantida por um punhado de voluntários mas presente em incontáveis sistemas empresariais, desencadeou uma corrida global para tapar o buraco, o episódio que ficou conhecido como Log4Shell. A lição foi clara: a infraestrutura mais crítica do mundo digital é muitas vezes a menos visível e a pior financiada. A cripto, que depende do mesmo ecossistema de bibliotecas open source para carteiras, interfaces e ferramentas, herdou exatamente a mesma exposição, com a agravante de que os seus bugs não desligam serviços, drenam carteiras.

Quando o cansaço vira porta dos fundos

O exemplo que transformou esta discussão abstrata num pânico concreto não veio da cripto, mas aplica-se-lhe na íntegra. Em março de 2024, um engenheiro da Microsoft reparou que o início de sessão por SSH no seu sistema estava meio segundo mais lento do que devia. Puxou o fio e descobriu uma das operações de sabotagem mais sofisticadas da história do software: uma porta dos fundos (a vulnerabilidade registada como CVE-2024-3094) escondida no XZ Utils, uma ferramenta de compressão presente em praticamente todas as distribuições de Linux.

O que torna o caso tão instrutivo não é a técnica, é o alvo humano. O XZ Utils era mantido há quase duas décadas, quase sozinho, por um programador chamado Lasse Collin, que tinha dito publicamente, meses antes, que a sua capacidade de cuidar do projeto andava limitada. Um atacante que operava sob o pseudónimo «Jia Tan» passou cerca de dois anos a construir confiança, a oferecer ajuda a um mantenedor esgotado, enquanto contas falsas pressionavam Collin para que aceitasse um coadjutor. Jia Tan acabou por receber as chaves e plantou a porta dos fundos. A falha não foi técnica. Foi humana: um mantenedor exausto, único, não pago, é a condição que um atacante paciente procura.

Não é um acidente isolado. Ao longo de 2026, investigadores de segurança documentaram várias tentativas credíveis de infiltrar projetos open source importantes pela mesma via, identificando mantenedores que manifestam exaustão em fóruns públicos e oferecendo-se para «ajudar». O esgotamento deixou de ser apenas um problema de recursos humanos e passou a ser uma superfície de ataque. Numa indústria onde o código move dinheiro, isto significa que a saúde mental de uma pessoa que ninguém fotografa pode ser a diferença entre uma rede segura e um assalto de milhares de milhões.

Porque é que o culto produz código órfão

Nada disto é acidental. O culto do builder produz código órfão porque recompensa precisamente aquilo que não é manutenção. Pensemos no que gera estatuto: o lançamento, o anúncio, a curva de preço, a entrevista. A estreia de um creator coin ou de um novo token atrai bots, especuladores e holofotes, e pode mover milhões em segundos; cinco anos de patches de segurança não movem nada e não dão manchete. O mercado paga pela novidade e ignora a continuidade. Um fundador que lança três projetos num ano acumula mais estatuto do que um mantenedor que impediu, em silêncio, que um protocolo existente fosse drenado.

Há também uma dinâmica de viés de sobrevivência. Os perfis que lemos são os dos builders cujos projetos vingaram; não lemos os dos que mantiveram durante anos algo aborrecido mas essencial, nem os dos que arderam por dentro a fazê-lo. A própria noção de que o trabalho sério é lançar coisas novas, e não sustentar as existentes, é cultural, e a cripto absorveu-a em dose dupla porque o seu modelo de financiamento, assente em tokens, premeia o evento inaugural acima de tudo.

O custo aparece quando um protocolo tem sucesso e os seus criadores perdem o interesse, ou saem de cena a meio de uma disputa. Vimo-lo na guerra civil da Aave, onde uma DAO se viu a braços com a possibilidade de perder quem a tinha construído. Um protocolo que vale milhares de milhões pode ficar, de um dia para o outro, sem as pessoas que entendiam o seu funcionamento interno. A governação herda o código, mas não herda o conhecimento. E o conhecimento, ao contrário do código, não é imutável: evapora-se quando quem o detém vai embora.

Os que ficam e o elogio da ossificação

Se há um antídoto cultural para o culto da novidade, ele chama-se ossificação, e a Ethereum transformou-o quase numa virtude. A ideia é simples e vai contra todo o instinto do builder: a dada altura, a melhor coisa que uma infraestrutura base pode fazer é mudar menos, estabilizar, tornar-se previsível e aborrecida. Uma camada de liquidação que move centenas de milhares de milhões não precisa de ser excitante; precisa de estar lá amanhã, exatamente igual a hoje. A manutenção, vista assim, não é o parente pobre da construção. É o objetivo final.

É curioso que a própria Ethereum Foundation tenha abraçado uma versão organizacional disto. Ao longo de 2026, Vitalik Buterin defendeu uma fundação mais pequena e focada, que privilegie a longevidade em vez da amplitude, uma entidade que faz menos para durar mais. E, no debate sobre o que financiar, ele próprio propôs trocar a expressão vaga «bens públicos», que considera carregada de bias de desejabilidade social, por um critério mais honesto: financiar o open source mais valioso, aquele de que o ecossistema realmente depende, e não o que soa melhor num tweet. É um reconhecimento, vindo do topo, de que a indústria tem gasto atenção e dinheiro no sítio errado.

Este elogio da estabilidade ecoa, de resto, debates que cobrimos sobre a forma de governar protocolos. A tese da governação mínima, a DAO que vota para deixar de governar, é precisamente uma aposta na ossificação: quanto menos uma infraestrutura depende de decisões ativas e de pessoas insubstituíveis, mais robusta fica. O reverso aparece quando a governação ainda é necessária mas se torna um campo de batalha, como no caso do guardião em julgamento, a DAO que vota para despedir o seu próprio veto. Entre a ossificação saudável e a captura, quem fica a mexer no código define o destino do protocolo, e quase nunca aparece no retrato.

Lisboa e a aposta na longevidade

O ecossistema lusófono oferece um contraexemplo útil à lógica do lançar-e-partir. Lisboa consolidou-se como um dos polos europeus de builders, com a ETHGlobal a organizar hackathons na cidade e com a Web Summit, de 9 a 12 de novembro de 2026, a trazer dezenas de milhares de pessoas. Mas o caso mais interessante não é o de uma estreia, é o de uma sobrevivência.

A Utrust nasceu em Portugal por volta de 2017, uma plataforma de pagamentos em cripto fundada por uma equipa que incluía Nuno Correia, no setor desde 2011. Em janeiro de 2022 foi adquirida pela Elrond (hoje MultiversX) e, em março desse ano, obteve uma licença de operação do Banco de Portugal. Hoje opera como xMoney, a partir de Braga, e a entidade portuguesa que a sustenta mantém o registo de prestador de serviços de ativos virtuais junto do supervisor nacional. Não é uma história de hype. É uma história de continuidade: um projeto que, ao fim de quase uma década, ainda está de pé, ainda envia código, ainda cumpre regras.

É esse o tipo de perfil que o género quase nunca escreve, porque a longevidade não cabe numa narrativa de ascensão meteórica. Contra as oitenta e duas lápides do ano, um projeto de nove anos que simplesmente persistiu é, à sua maneira, mais notável do que qualquer estreia. A manutenção, quando se estende por tempo suficiente, deixa de ser invisível e passa a ser a própria prova de valor.

O regulador dá um nome, não dá dinheiro

Onde entra a regulação nesta história? De forma reveladora, quase sempre do lado errado do problema. O regime europeu de ativos (o MiCA, supervisionado em Portugal pela CMVM na vertente de conduta e pelo Banco de Portugal no registo de prestadores e nas stablecoins) regula a pessoa coletiva: o prestador de serviços, o emitente. Não regula o protocolo open source nem quem o mantém. Quem escreve e sustenta a biblioteca crítica de que todos dependem fica, por desenho, fora do perímetro: não é supervisionado, não é responsabilizado e, sobretudo, não é financiado. A lei conhece o CASP; não conhece o zelador.

Há, no entanto, uma novidade regulatória que aponta, pela primeira vez, diretamente para este buraco. O Cyber Resilience Act europeu, que entrou em vigor no final de 2024, criou uma categoria jurídica inédita: o «open-source software steward», uma pessoa coletiva que, de forma sistemática e sustentada, apoia o desenvolvimento de software livre destinado a uso comercial. É o mais perto que a lei europeia chegou de dar um nome à função de manter. As obrigações são leves (ter uma política de cibersegurança, cooperar com as autoridades, reportar vulnerabilidades ativamente exploradas) e aplicam-se a partir de 11 de dezembro de 2027. Não há coimas, não há marcação CE, não há avaliação de conformidade.

O gesto é significativo e insuficiente ao mesmo tempo. Significativo porque a Europa reconheceu, no texto da lei, que alguém tem de manter o software de que a economia depende. Insuficiente porque lhe deu um nome sem lhe dar dinheiro: o estatuto de steward não vem com financiamento, nem resolve o problema de fundo, que é económico e não jurídico. A isto junta-se o DORA, que obriga as entidades financeiras a gerir o risco da sua cadeia de fornecimento de tecnologia, incluindo dependências open source, empurrando a responsabilidade para quem usa o código, não para quem o mantém. O enquadramento português, com a Lei n.º 69/2025 em vigor desde dezembro de 2025, segue a mesma lógica europeia. Em suma: o regulador aprendeu a nomear o problema muito antes de aprender a pagá-lo.

Isto deixa a manutenção num limbo: demasiado crítica para ser ignorada, demasiado difusa para ser regulada, demasiado aborrecida para ser financiada pelo mercado. As soluções propostas existem, desde o modelo de vesting da Protocol Guild até à ideia de uma taxa sobre quem usa a infraestrutura para pagar a quem a mantém, mas todas esbarram no mesmo obstáculo cultural: exigem reconhecer que manter vale tanto como construir. E esse reconhecimento, mais do que qualquer lei, é o que ainda falta.

Como ler o builder pela manutenção, não pela estreia

Se há uma lição prática a tirar de tudo isto, é que o leitor de perfis de builder devia aprender a ler o que o género omite. Perante um fundador celebrado, as perguntas interessantes não são sobre a visão ou sobre a próxima ronda, são sobre o depois: o que é que esta pessoa manteve, e durante quanto tempo? Quantos dos seus projetos ainda estão de pé? Quem fica a cuidar do código quando a atenção se mudar para o lançamento seguinte?

A tabela abaixo propõe uma grelha simples para distinguir quem lança e parte de quem constrói para durar. Nenhum sinal isolado é decisivo, mas o padrão conta uma história que o retrato oficial raramente conta.

A cripto construiu uma mitologia inteira à volta de quem traz coisas novas ao mundo e esqueceu-se de construir uma à volta de quem as impede de ruir. O resultado está à vista em 2026: oitenta e duas lápides, uma árvore de dependências cheia de ramos secos e a rede-bandeira do setor a passar o chapéu para pagar a quem a mantém. O builder que o culto venera é o que lança; o builder de que a cripto precisa é o que fica. Até o retrato aprender a mostrar o segundo, continuaremos a celebrar a construção enquanto o edifício, por baixo, se enche de código órfão.

Perguntas frequentes

O que é código órfão em cripto?

Código órfão é software que continua em produção, muitas vezes a gerir fundos reais, mas cujo criador original seguiu em frente e cujo mantenedor atual ou não existe ou está sobrecarregado. Na cripto é especialmente perigoso porque o código move dinheiro diretamente, pelo que uma dependência abandonada pode transformar-se numa vulnerabilidade sem que ninguém esteja a vigiar.

Porque é que a Ethereum tem uma crise de financiamento dos core developers?

Segundo o antigo contribuidor da Ethereum Foundation Trent Van Epps, o desenvolvimento do núcleo precisa de cerca de 30 milhões de dólares por ano, mas os mecanismos existentes distribuíram menos de metade disso. O problema agravou-se porque o Client Incentive Program, que pagava às equipas de clientes, expirou em abril de 2026 sem um substituto pronto.

O que é a Protocol Guild?

A Protocol Guild é um fundo coletivo e on-chain que financia os contribuidores do núcleo da Ethereum através de vesting de longo prazo. Assenta num «1% Pledge», pelo qual projetos do ecossistema comprometem cerca de 1% dos seus tokens com quem mantém a camada base, mas a soma angariada tem ficado estruturalmente abaixo do necessário.

Quantos projetos cripto fecharam em 2026?

A investigadora Stacy Muur listou 82 protocolos que encerraram operações em 2026, e a DeFiLlama, de forma independente, contou cerca de cem. No conjunto, estes projetos tinham angariado perto de mil milhões de dólares e geraram apenas cerca de 250 milhões em comissões ao longo da sua vida.

O que é o fator autocarro (bus factor) no software?

O fator autocarro mede quantas pessoas teriam de desaparecer para que um projeto deixasse de poder ser mantido. Um fator autocarro de um indica que há um único responsável cujo conhecimento é insubstituível, uma fragilidade comum no open source, onde 22% dos projetos críticos têm um só mantenedor ativo.

Marcus Okafor escreve sobre cultura cripto e assina a série de perfis de builder da HOGE Wire.