Relatório de Rede de Fevereiro de 2026: Emissão, Interoperabilidade e Inclusão

Resumido

Fevereiro trouxe um panorama variado nas principais redes Layer-1. Algumas cadeias ativaram atualizações de mainnet; outras estabeleceram roteiros de mudanças para o restante do ano. Veja o que aconteceu e o que isso significa.

Fevereiro trouxe um panorama variado nas principais redes Layer-1. Algumas cadeias ativaram atualizações de mainnet; outras estabeleceram roteiros de mudanças para o restante do ano. Veja o que aconteceu e o que isso significa.

Cosmos Hub finalmente torna-se uma camada de emissão

O maior evento de mainnet do mês aconteceu em 18 de fevereiro, quando o Cosmos Hub atualizou para Gaia v26.0.0. A principal novidade é o x/tokenfactory, que permite que projetos criem tokens diretamente no Hub. O processo de governança seguiu o padrão: proposta publicada em 5 de fevereiro, versão marcada em 9 de fevereiro, atualização executada no bloco 29.837.600 em 18 de fevereiro.

Fonte: GitHub

Os parâmetros são importantes. A criação de denominação custa 10 ATOM (cerca de 50–60 dólares) e queima 2.000.000 de gás. Isso é suficiente para desencorajar spammers, mas baixo o bastante para que projetos legítimos possam absorver. Tokenfactory transforma o Hub de uma camada de coordenação em um verdadeiro local de emissão de ativos — as appchains agora podem iniciar suas tokenomics sem precisar de infraestrutura de minting separada.

Vale destacar: essa é uma atualização que altera o estado, o que exigiu uma coordenação rigorosa dos validadores. Nenhum incidente importante foi reportado, o que demonstra a maturidade operacional do Cosmos neste momento. O risco agora é mais econômico do que técnico — a governança precisará ajustar os parâmetros de taxas se o uso do tokenfactory crescer e a pressão de spam aumentar.

Polkadot realiza ataque cirúrgico

Polkadot realizou uma atualização de runtime sem fork por volta de 19 de fevereiro, que provavelmente não gerará manchetes fora do círculo de infraestrutura. A versão 2.0.7 do runtime adiciona uma coisa: “Adicionar hyperbridge ao root de cabeçalhos de parachains.” Ou seja, quando a parachain hospedeira do Hyperbridge passar a ser uma parathread, seus provas de cabeçalho poderiam ser quebradas. Essa correção evita isso.

Fonte: GitHub

A atualização foi aprovada via OpenGov, por meio de um referendo de Lista de Permissões — com baixa dramaticidade e alta confiança. O runtime 2.0.7 foi lançado em 16 de fevereiro, e até 19 de fevereiro a rede já o estava executando. Atualizações sem fork geralmente passam despercebidas pelos usuários, o que é o objetivo. O impacto é limitado, mas real: provas de clientes leves quebradas podem deixar ativos presos, portanto manter o Hyperbridge funcional é importante para a interoperabilidade mais ampla.

Cardano nomeia sua próxima era sem entrar nela

Cardano passou fevereiro se preparando. O nó 10.6.2 foi lançado em 12 de fevereiro, com recursos embutidos do Plutus (Array, Value, exponenciação modular, MSM BLS12-381) planejados para o Versão de Protocolo 11, além de proteções defensivas ao mempool e correções de estabilidade. Em 19 de fevereiro, a Intersect confirmou que o hard fork PV11 será chamado “van Rossem” — uma homenagem ao criador do Python, Guido van Rossum.

Fonte: GitHub

O mais importante: o PV11 ainda não foi ativado. Fevereiro foi dedicado à preparação: os operadores de nó já têm o software, e a governança sinalizou o nome por meio de uma ação informativa (uma prática de governança de baixo risco que ajuda a criar memória muscular). A atualização de desenvolvimento da Intersect em 20 de fevereiro descreveu isso como “preparação para hard fork,” o que é preciso. O verdadeiro teste acontecerá quando o cronograma de ativação for definido e as curvas de adoção começarem a importar.

Solana reforça sua transparência

Fevereiro na Solana foi mais sobre processos do que sobre protocolo. Em 3 de fevereiro, uma página oficial de “Atualizações de Rede” entrou no ar. Em 9 de fevereiro, a wiki de cronograma de lançamento do Agave v3.1 foi atualizada com avisos explícitos de que as datas são provisórias e que os operadores devem aguardar anúncios no Discord. Em 19 de fevereiro, o Agave v3.1.9 foi marcado como pré-lançamento.

Fonte: Solana

Isso é importante porque o mecanismo de atualização da Solana é incomum — lançamentos do cliente validadores, ativações por recurso e política de piso de versão (o mainnet-beta aumenta a versão mínima duas épocas completas após 95% do stake adotar). A versão v3.1 visa reduzir operações de disco durante a reprodução e melhorar a eficiência no processamento de transações. Se for bem-sucedido, os validadores terão requisitos de hardware mais baratos e os usuários menos problemas de congestionamento. Mas a história de fevereiro é, na verdade, sobre tornar esse processo visível e previsível. A política de piso de versão será realmente testada quando os limiares de adoção se aproximarem.

Ethereum confirma FOCIL para Hegotá

A grande novidade do Ethereum veio na ACDC #175, em 19 de fevereiro: os desenvolvedores principais confirmaram o FOCIL (EIP-7805) como destaque na camada de consenso para Hegotá, a atualização após Glamsterdam.

Fonte: Ethereum Magicians

FOCIL significa Fork-Choice Enforced Inclusion Lists. É um mecanismo a nível de protocolo para forçar ou incentivar fortemente a inclusão de transações válidas via incentivos de consenso, ao invés de confiar em relés e construtores fora do protocolo. A motivação é clara: após o merge, preocupações com centralização de construtores e conformidade com OFAC colocaram “quem realmente controla a inclusão” no centro dos debates de governança do Ethereum. FOCIL é a resposta escolhida.

Ainda não é uma mudança de mainnet. É uma decisão de roteiro — Hegotá será lançada quando a implementação estiver pronta, provavelmente no final de 2026 ou mais tarde. A chamada de fevereiro definiu a direção. Os trade-offs são reais: FOCIL adiciona complexidade ao consenso e às responsabilidades dos validadores, o que pode gerar efeitos de centralização secundários se a carga operacional aumentar. Algumas análises destacaram riscos de jurisdição para validadores obrigados a incluir transações que prefeririam evitar. Esses debates continuarão durante a especificação e os testes.

Bitcoin dá passo quântico (apenas no papel)

Em 11 de fevereiro, o BIP 360 (Pay-to-Merkle-Root) foi mesclado ao repositório oficial de BIPs do Bitcoin. Status: Rascunho. O repositório de BIPs observa que a mesclagem “não indica que seja uma boa ideia, que haja consenso da comunidade ou que esteja prestes a ser adotada.”

Fonte: GitHub

Ainda assim, a proposta merece atenção. P2MR é um tipo de saída semelhante ao Taproot, com a spend key-path removida. A justificativa é mitigação de risco quântico: ao eliminar a exposição da chave pública na cadeia (exceto na hora de gastar), ataques de “exposição prolongada” ficam mais difíceis. Os trade-offs incluem maior volume de dados na testemunha (custando mais taxas para gastos apenas com script-path) e implicações de privacidade (gastos revelam uso do script-path, ao invés de parecerem gastos com key-path).

A mesclagem é um marco de padrão, não um evento de ativação. Mas coloca uma proposta concreta no repositório que desenvolvedores de carteiras e contribuidores principais podem consultar. Segurança pós-quântica completa exigiria assinaturas pós-quânticas — esta é a primeira etapa, e a segunda está anos à frente, por qualquer cronograma realista. Cobertura do Decrypt e Cointelegraph a framing como o começo de um longo caminho de upgrades, o que é preciso.