NOVO: Helius adquire a Light Protocol
Banner de governança
Blog/Pesquisa

Governança da Solana: uma análise abrangente

PesquisadorLostin no X
29 min de leitura

Insights práticos

  • Os votos de governança na Solana não são vinculantes e têm caráter consultivo, servindo como indicadores do sentimento da comunidade. Permitir que os validadores sinalizem sua posição antes da implementação completa ajuda a orientar o desenvolvimento e minimizar conflitos. A decisão final ocorre quando os validadores escolhem qual software executar. As propostas podem mudar mesmo após uma votação e, em última análise, a governança reflete consenso, não imposição.
  • Os detentores de tokens SOL participam indiretamente ao delegar seus SOL em staking a validadores cujas escolhas de voto estejam alinhadas a seus valores ou preferências. Esse é um sistema de representação proporcional no qual os validadores podem ser considerados representantes eleitos. Os participantes de staking da Solana delegam sua participação aos validadores, e o poder de voto de cada validador é baseado na participação delegada a ele.
  • A votação de governança da Solana é realizada com tokens SPL. Os validadores recebem tokens proporcionalmente à participação ativa e enviam esses tokens a endereços designados que representam diferentes opções de voto. Os validadores podem dividir seus votos entre várias opções. Após o envio, os votos são definitivos e não podem ser alterados.
  • Todas as atualizações de protocolo que quebram o consenso são ativadas por meio de feature gates, que são hard forks sem compatibilidade retroativa. Diferentemente do Bitcoin ou Ethereum, onde um hard fork pode resultar em uma divisão permanente da cadeia em caso de discordância, a abordagem da Solana garante que os feature gates sejam ativados em todo o cluster em um slot específico. Os validadores fazem a atualização antecipadamente, evitando divisões da cadeia.
  • Diversas mudanças econômicas no início do desenvolvimento da Solana — especialmente a introdução de taxas de prioridade com queima de 50% — foram implementadas sem votos formais de governança, pois o sistema de governança ainda era imaturo na época.
  • O modelo atual de votação de governança — votação exclusiva de validadores — foi estabelecido após uma votação consultiva em outubro de 2023. Mais de 170 validadores participaram, representando 14,3% da participação total, e mais de 70% dessa participação apoiou a votação exclusiva de validadores como o ponto de partida mais prático e eficiente.
  • A votação recente sobre a SIMD-228 alcançou uma taxa recorde de participação de 74,3%, tornando-se o maior evento de governança de blockchain da história em número de participantes e capitalização de mercado, com 281 milhões de SOL (~US$ 35 bilhões) e mais de 900 validadores emitindo mais de 1.000 votos. Ela marcou a primeira participação ativa de validadores de grandes exchanges, como Coinbase, Kraken e Bybit, destacando o crescente envolvimento institucional da Solana.
  • Uma preocupação recorrente no processo de governança da Solana é o papel limitado dos delegadores na tomada de decisões. Hoje, não existe um mecanismo formal para que os delegadores expressem suas preferências ou revertam decisões dos validadores, o que gera situações em que os votos dos validadores podem entrar em conflito com as preferências de seus delegadores.
  • O papel de um quórum definido nas votações de governança da Solana também gera preocupações. Na prática, os quóruns podem criar incentivos perversos, levando participantes a reter estrategicamente seus votos para impedir que uma proposta alcance o limite exigido. Isso foi observado nos padrões de votação da SIMD-228.
  • O Solana Foundation Delegation Program delega 10% do total de SOL em staking (41,01 milhões) a 897 validadores, ampliando o poder de voto deles. Uma análise da recente votação da SIMD-288 indica que a participação do SFDP foi usada principalmente para votar contra a proposta. Se essa participação tivesse votado SIM, a proposta teria sido aprovada. Se a participação delegada pelo SFDP tivesse se abstido, a proposta ainda teria sido rejeitada, mas por uma margem menor — 64,77% contra os 61,39% efetivamente obtidos.
  • Ainda há incerteza sobre o que exige uma votação de governança. Em março de 2025, uma votação planejada sobre a SIMD-218 (IVC) foi retirada após surgir um consenso de que ela não exigia aprovação da governança. Da mesma forma, embora aprovada, a SIMD-123 não era claramente uma mudança econômica e talvez não justificasse uma votação formal.

Introdução

A governança é um componente essencial da descentralização, influenciando desde atualizações de protocolo e políticas econômicas até o comportamento dos validadores e os padrões da comunidade. Um sistema de governança eficiente melhora a transparência, a equidade e a confiança, enquanto uma governança ruim pode gerar confusão, estagnação ou centralização do poder.

A governança da Solana ainda está em um estágio inicial de desenvolvimento. Assim como muitas redes blockchain, ela não foi lançada com uma estrutura de governança plenamente madura ou formalizada. Em vez disso, evoluiu gradualmente, moldada pelas práticas da comunidade, por restrições técnicas e pelas lições aprendidas. O aprimoramento da governança da Solana é um processo contínuo e iterativo.

O ecossistema da Solana reúne grupos de partes interessadas diversos e sobrepostos: detentores de tokens, participantes de staking, usuários, validadores, operadores de RPC, desenvolvedores de aplicativos e engenheiros do protocolo principal. Cada grupo traz perspectivas, incentivos e objetivos diferentes. Embora esses incentivos possam estar alinhados em algumas áreas, eles frequentemente divergem, sobretudo quanto à distribuição de recursos, ao controle do protocolo e à política econômica.

Em sistemas descentralizados, a governança envolve tanto o consenso social quanto o código. Embora blockchains sejam frequentemente descritas pela máxima “código é lei”, a história mostra que, quando o consenso da comunidade exige, o código pode — e de fato vai — mudar. Isso torna o design dos mecanismos de governança e a capacidade de fazê-los evoluir ao longo do tempo tão importantes quanto a arquitetura técnica inicial.

Este relatório busca esclarecer a estrutura, a evolução e o estado atual da governança na Solana. Ele oferece uma visão abrangente de como as decisões são tomadas na rede e de como sua governança se compara à de outros ecossistemas de blockchain. O trabalho está organizado em quatro seções principais:

  • Elementos da governança da Solana – Analisa os principais componentes do processo de governança da Solana, incluindo SIMDs, ativações de feature gates e votações formais on-chain.
  • Análise das votações de governança – Uma visão detalhada de todas as votações formais de governança realizadas até hoje, incluindo resultados, comportamento dos eleitores e métricas de participação.
  • Desafios e recomendações – Uma análise dos principais problemas enfrentados pelo atual modelo de governança da Solana, acompanhada de recomendações práticas quando pertinente.
  • Comparação com redes alternativas – Uma análise de como a governança funciona nos ecossistemas comparáveis Cosmos e Ethereum, destacando práticas que podem orientar melhorias na Solana.

Embora a leitura do relatório seja mais fluida na ordem apresentada, cada seção foi criada para ser independente e pode ser lida separadamente.

Elementos da governança da Solana

A tabela abaixo apresenta uma visão geral do sistema de governança da Solana, estruturada com base em uma estrutura analítica adaptada do artigo Análise da tomada de decisões na governança de blockchain de Schädler, Lustenberger e Spychiger (2023). Adaptamos essa estrutura para refletir os mecanismos e as dinâmicas específicos do ecossistema da Solana.

Off-chainOn-chain
Tomadores de decisãoEquipes de clientes (Anza, Firedancer)Operadores de validadores
IncentivosAumentar a adoção da rede
Aprimoramentos técnicos: IBRL
Aumentar a adoção da rede
Comissões de inflação
Recompensas de bloco
Comissões de MEV
AcessoPúblico / AbertoValidadores da Mainnet
CoordenaçãoGitHub de SIMDs
Discord Solana Tech
Fóruns da Solana
Canais sociais
Nenhuma
Condições de aprovaçãoNenhumaAlcançar o quórum da votação

As modificações no protocolo da Solana seguem um processo de várias etapas que varia de acordo com a natureza e o impacto da mudança. Entre os principais fatores estão se a mudança quebra o consenso, seu impacto nas partes interessadas e o nível de controvérsia ou complexidade envolvido. Uma mudança que quebra o consenso é qualquer atualização de protocolo que faça nós executando versões diferentes do software discordarem sobre o estado da blockchain. 

A tabela a seguir apresenta as etapas típicas de mudanças com diferentes níveis de magnitude. “Grandes mudanças” são aquelas com possível impacto econômico.

Magnitude da mudançaMudança pequenaMudança médiaMudança grande
ExemploRefatoração de códigoNovo programa principalModificação econômica
Quebra o consensoNãoSimSim
SIMD necessáriaNãoSimSim
Votação de governança necessáriaNãoNãoSim
Implementação entre clientes necessáriaNãoSimSim
Ativação de feature gate necessáriaNãoSimSim

A seguir, descreveremos em detalhes os processos de ativação de feature gates, SIMDs e votações de governança.

Ativações de feature gates

As principais equipes de desenvolvimento da Anza e da Firedancer lançam com frequência novos recursos, incluindo syscalls, programas nativos e mudanças econômicas que quebram o consenso. Esses recursos são criados, incluídos em novas versões do software cliente e desativados por padrão por trás de uma feature flag. O Feature Gate Program, que migrou recentemente para um programa Core BPF, acompanha cada novo recurso como uma conta. Uma chave privada exclusiva de cada feature gate pertence ao colaborador principal associado a ele. Depois que uma quantidade suficiente de validadores com participação em staking atualiza para a nova versão e ela é considerada estável, a chave de recurso do runtime é ativada manualmente com uma instrução, e o recurso entra em operação em todos os nós da rede no início da época seguinte. A ordem e o momento exatos das ativações podem ser acompanhados no cronograma de feature gates. A ativação de recursos independe do cluster: as ativações ocorrem primeiro na Testnet, depois na Devnet e, por fim, na Mainnet, permitindo consolidar a confiança nas novas versões antes da ativação final na Mainnet.

O “piso de versão” é a versão mínima de software atualmente compatível com um cluster. À medida que novos feature gates são ativados, o piso de versão é elevado para corresponder à versão do software em que o recurso foi incluído. As novas ativações de recursos na Solana seguem uma cadência regular, normalmente nos limites de época que ocorrem dentro do horário comercial em dias úteis. As ativações são pausadas durante transições de versão e retomadas cerca de duas épocas depois que 95% da participação atualiza para uma nova versão secundária (por exemplo, da versão 2.2 para a 2.3).

As ativações de feature gates são hard forks sem compatibilidade retroativa que exigem adoção universal para entrar em vigor. Se um validador não atualizar para uma versão que reconheça um feature gate ativado, ele não poderá continuar validando o estado global e divergirá da rede.

Diferentemente do Bitcoin ou Ethereum, onde um hard fork pode resultar em uma divisão permanente da cadeia em caso de discordância, a abordagem da Solana garante que os feature gates sejam ativados em todo o cluster em um slot específico. Os validadores precisam atualizar antecipadamente, evitando divisões da cadeia. Portanto, embora os feature gates sejam hard forks por alterarem as regras de consenso, eles não podem gerar cadeias concorrentes.

As novas versões dos clientes também incluem muitas mudanças que não quebram o consenso, como refatorações de código e otimizações de eficiência, que não exigem feature gates.

Solana Improvement Documents (SIMDs)

As propostas de Solana Improvement Documents (SIMDs) são a documentação formal necessária para qualquer mudança substancial nos principais componentes da Solana. Mudanças “substanciais” são definidas como aquelas que normalmente alteram o protocolo da rede, a validade das transações ou a interoperabilidade. Mudanças não substanciais, como pequenas refatorações de código ou melhorias objetivas de desempenho, não exigem propostas. As propostas devem documentar a justificativa do recurso e fornecer documentação suficiente para compreender a implementação. 

Embora o envio de SIMDs não exija permissão, a maioria é apresentada por desenvolvedores das equipes de clientes que trabalham em tempo integral em melhorias do protocolo principal.

Há dois tipos de propostas: 

  • Propostas padrão: afetam recursos principais da Solana (por exemplo, consenso, rede e interfaces de API)
  • Metapropostas: tratam de processos ou diretrizes fora da base de código

As SIMDs normalmente passam pelas etapas de avaliação da ideia, elaboração, revisão e aceitação. Uma revisão formal ocorre publicamente no GitHub, e o autor da proposta é responsável por coletar feedback dos colaboradores principais relevantes das equipes dos clientes Agave e Firedancer. Eles determinam se a proposta será aceita, revisada ou retirada, considerando segurança, concessões e compatibilidade retroativa.

Os autores não são obrigados a implementar suas propostas, mas normalmente recomenda-se que o façam, pois essa é a melhor forma de garantir uma conclusão bem-sucedida. Quando aceitas, as propostas costumam incluir uma issue de acompanhamento para a implementação do recurso e normalmente exigem ativação por meio do mecanismo de feature gates da Solana. 

Embora nem todas as ativações de feature gates exijam uma SIMD, a maioria é acompanhada por uma para fornecer contexto, justificativa e um registro padronizado da mudança proposta.

Votações de governança

SIMDs que alteram significativamente o protocolo, sobretudo aquelas que afetam parâmetros econômicos, exigem votações de governança. O processo de governança da Solana, liderado por membros experientes da comunidade de validadores, concentra-se apenas em questões essenciais para preservar o engajamento e evitar a fadiga de governança. Como resultado, ocorrem apenas algumas votações por ano.  

As votações de governança servem principalmente como um mecanismo para avaliar o sentimento em relação às mudanças propostas. Permitir que os validadores sinalizem sua posição antes da implementação completa ajuda a orientar o desenvolvimento e minimizar conflitos. Implementar uma mudança sem amplo consenso pode gerar atritos, especialmente se mais de um terço da rede resistir à adoção.

A votação é realizada com tokens SPL. A conta de identidade de cada validador ativo recebe tokens proporcionalmente à sua participação ativa, medida em lamports. O validador pode então enviar esses tokens a endereços designados que representam diferentes opções de voto, incluindo a abstenção. Os validadores podem dividir seus votos entre várias opções — por exemplo, alocar 80% para SIM e 20% para NÃO —, o que lhes dá flexibilidade para refletir as diferentes preferências de seus participantes de staking. Após o envio, os votos são definitivos e não podem ser alterados.

Nessa estrutura, os detentores de tokens SOL participam indiretamente ao delegar seus SOL em staking a validadores cujas escolhas de voto estejam alinhadas a seus valores ou preferências. Esse é um sistema de representação proporcional no qual os validadores podem ser considerados representantes eleitos. Os participantes de staking da Solana delegam sua participação aos validadores, e o poder de voto de cada validador é baseado em sua participação ativa.

Os limites da governança on-chain

A governança na Solana não é vinculante e tem, em última análise, caráter consultivo. Na prática, a votação real ocorre quando os validadores escolhem qual versão do software executar. Embora as votações de governança possam indicar amplo apoio ou oposição da comunidade, elas não obrigam os validadores a adotar nenhum código específico. As propostas podem até mudar após a votação, e os validadores mantêm controle total sobre o que é executado em sua infraestrutura. Essa dinâmica significa que a governança trata mais de sinalizar consenso do que de impor resultados.

Colaboradores principais como Anza, Jump e Jito e provedores de infraestrutura como Helius e Triton exercem influência informal significativa nesse contexto. Como é improvável que os validadores se oponham a esses grupos e arrisquem perder participação ou ficar dessincronizados da rede, essas entidades podem efetivamente moldar os resultados das atualizações, tenham ou não autoridade formal de decisão.

Um fork poderia ocorrer em um cenário extremo no qual os validadores recusassem uma atualização. O DAO Fork do Ethereum em 2016, que levou à criação do Ethereum Classic, continua sendo um exemplo que exige cautela. À medida que o processo de governança da Solana evolui, esclarecer a relação entre votos de sinalização, lançamentos de software e adoção efetiva pelos validadores garantirá transparência e evitará os riscos extremos de divisões da cadeia.

Análise das votações de governança

O início da governança da Solana: 2020–2022

A abordagem inicial da Solana à governança era muito diferente da estrutura atual. A governança inicial se concentrava no Feature Proposal Program, que permitia aos validadores votar em mudanças de protocolo usando tokens SPL ponderados pela participação. Quando uma nova versão de um recurso ficava disponível para ativação, os validadores recebiam tokens de votação proporcionalmente à sua participação ativa. Ao devolver esses tokens a uma conta designada durante um período de duas semanas, os validadores podiam sinalizar aprovação para ativar o recurso proposto. Ao atingir o limite de 67% da participação, a mudança era ativada diretamente on-chain na época seguinte.

O Feature Proposal Program foi usado várias vezes para realizar votações de governança entre validadores tanto na Testnet quanto na Mainnet, sobretudo para ativar o cronograma de inflação atual.

PropostaDataCluster(s)Detalhes da proposta
Inflação PICODez. de 2020Testnet e MainnetHabilitar inflação de 0,01% para fins de validação antes da inflação total
Inflação totalJan./fev. de 2021Testnet e MainnetHabilitar a inflação total, seguindo o cronograma de inflação
Delegação mínima de participaçãoSet. de 2022TestnetIntroduzir uma delegação mínima de participação de 1 SOL

Os registros on-line dessas primeiras votações de governança são escassos, pois os fóruns originais da Solana foram retirados do ar e agora só podem ser acessados por versões arquivadas na Wayback Machine.

Embora esse mecanismo tenha introduzido certo grau de coordenação on-chain, ele foi amplamente criticado. Os validadores não tinham como expressar discordância — apenas os votos SIM eram contabilizados, e não havia um método formal para sinalizar oposição ou abstenção. Esse sistema também criava pressão social para aprovar mudanças, especialmente depois que esforços significativos de engenharia já haviam sido investidos na implementação. 

Mais importante, o sistema não oferecia sinalização antecipada. Isso significava que recursos complexos podiam ser desenvolvidos sem saber se seriam aceitos, gerando ineficiências e desperdício de tempo de desenvolvimento.

De modo geral, embora o Feature Proposal Program tenha sido uma etapa inicial importante na trajetória de governança da Solana, suas limitações ajudaram a orientar o desenvolvimento dos mecanismos de governança mais flexíveis usados hoje.

Vale observar que várias mudanças econômicas importantes nesse período inicial — como a introdução de taxas de prioridade com queima de 50% — foram implementadas sem votações formais de governança, refletindo uma época em que o sistema de governança ainda estava em seus primeiros passos.

A governança atual da Solana: de 2023 em diante

Após o uso do Feature Proposal Program, a Solana evoluiu para seu atual sistema de votação de governança. Até agora, foram realizadas cinco votações oficiais de governança:

Votação consultiva inicial

Uma decisão inicial essencial para moldar a atual estrutura de governança da Solana foi determinar quem deveria participar do processo de votação. Três opções foram apresentadas à comunidade:

  1. Votação exclusiva de validadores, com votos ponderados pela participação
  2. Validadores e contas de participação, permitindo que os delegadores revertam o voto de seu validador
  3. Validadores, contas de participação e outras partes interessadas, como operadores de RPC e desenvolvedores

A votação consultiva teve a participação de mais de 170 validadores, representando 14,3% da participação total. Da participação que votou, mais de 70% apoiou a votação exclusiva de validadores, enquanto 24% preferiu um modelo com validadores e delegadores. Nenhum limite mínimo de participação foi aplicado a essa votação.

A votação exclusiva de validadores foi considerada o ponto de partida mais prático e eficiente, pois a infraestrutura já existia e havia sido testada na prática. Sistemas mais complexos envolvendo delegadores ou outras partes interessadas foram considerados prematuros e potencialmente onerosos para um processo de governança incipiente. A comunidade reconheceu que modelos de votação alternativos poderiam ser introduzidos e aprimorados por propostas futuras à medida que a governança amadurecesse.

Padrões das votações de governança

Desde a votação consultiva inicial, ocorreram mais quatro votações de governança, com as mesmas três opções: SIM, NÃO e Abstenção. Essas opções indicam concordância com a SIMD proposta. Para que uma votação seja aprovada, pelo menos dois terços dos votos SIM e NÃO combinados devem ser favoráveis (ou seja, SIM). 

A SIMD-33: Créditos de voto oportunos foi aprovada com apoio esmagador, recebendo 98,4% de votos SIM. Essa mudança de consenso sem controvérsias corrigiu incentivos desalinhados ao eliminar o benefício que os validadores obtinham anteriormente ao enviar votos atrasados, melhorando assim o comportamento e a equidade da rede.

A SIMD-96: Taxa de prioridade integral para validadores foi aprovada com 77,7% de votos SIM. Essa proposta econômica buscava desestimular o processamento de transações por canais paralelos, direcionando 100% das taxas de prioridade aos validadores. Embora eficaz no alinhamento de incentivos, ela gerou alguma controvérsia devido a um aumento modesto da inflação e à percepção de favorecimento dos validadores em detrimento dos detentores de SOL.

A SIMD-123: Distribuição de recompensas de bloco no protocolo foi aprovada com 74,91% de votos SIM. A proposta introduziu um mecanismo opcional e padronizado para os validadores distribuírem recompensas de bloco diretamente aos participantes de staking. Embora vários validadores já fizessem isso por métodos mais manuais, incorporar a prática ao protocolo gerou debates sobre pressão competitiva, com receios de que isso pudesse levar a uma “corrida para zero” nas taxas de comissão das recompensas de bloco.

A SIMD-228: Mecanismo de emissões baseado no mercado não foi aprovada, com apenas 61,39% de votos SIM. A proposta buscava tornar a taxa de inflação da Solana mais sensível à participação em staking, argumentando que as emissões atuais são altas demais, não respondem à demanda por rendimento e fazem a rede pagar em excesso pela segurança.

Os opositores levantaram preocupações sobre a viabilidade econômica dos validadores menores e a incerteza adicional que a proposta poderia introduzir nos rendimentos de staking. A votação mostrou-se altamente controversa, gerando amplo debate e destacando visões divergentes sobre o modelo econômico de longo prazo da Solana.

Para conhecer em detalhes o comportamento dos eleitores, recomendamos consultar os painéis de votação de código aberto da SIMD-96, SIMD-123 e SIMD-228. Também disponibilizamos uma planilha com os dados da votação aqui.

Limites de quórum de 33% de participação — incluindo votos de abstenção — foram aplicados à SIMD-228 e à SIMD-123. Em contraste, propostas anteriores, como a SIMD-96 e a SIMD-33, não tinham exigência mínima de participação, o que significa que poderiam ser aprovadas independentemente de quanto da participação total votasse.

Taxas de participação

As taxas de participação nas votações apresentaram uma tendência de alta ao longo do tempo. A votação consultiva inicial de outubro de 2023 teve engajamento mínimo, com apenas 14,3% da participação votando. Desde então, a participação aumentou de forma constante, culminando na votação de março de 2025 sobre a SIMD-228, o Mecanismo de Emissões Baseado no Mercado, que alcançou uma taxa de participação de 74,3%. As outras três votações realizadas até hoje apresentaram níveis de participação relativamente consistentes, variando de 51,2% a 57,1%.

A votação da SIMD-228 foi o maior evento de governança da história das criptomoedas tanto em número de participantes quanto em capitalização total de mercado representada. Na época do debate, a capitalização de mercado da Solana era comparável à do Bitcoin durante as disputas sobre o tamanho dos blocos em meados de 2017, ressaltando a importância da decisão. Um total de 281 milhões de SOL, avaliados em US$ 35 bilhões, participou da votação, com mais de 900 validadores enviando mais de 1.000 votos. Vale destacar que essa foi a primeira vez que validadores de grandes exchanges — incluindo Coinbase, Kraken e Bybit — participaram ativamente da governança on-chain da Solana, sinalizando uma presença institucional crescente no processo decisório da rede. Esse recente aumento da participação, sobretudo de entidades sediadas nos EUA, também pode ser atribuído em parte a um ambiente regulatório mais favorável às blockchains sob a atual administração.

Problemas e recomendações

Na próxima seção, analisaremos os principais desafios do processo de votação de governança e, quando pertinente, apresentaremos recomendações para melhorar a transparência, a segurança e a eficiência.

Falta de participação dos participantes de staking

Uma preocupação recorrente no processo de governança da Solana é o papel limitado dos delegadores na tomada de decisões. Embora os validadores votem nas propostas usando poder de governança ponderado pela participação, não existe um mecanismo formal para que os delegadores expressem suas preferências ou revertam decisões dos validadores. Isso pode gerar situações em que os votos dos validadores entrem em conflito com os interesses de seus delegadores, deixando os participantes de staking sem uma forma direta de influenciar os resultados da governança.

Validadores com milhares de delegadores têm dificuldade para coletar preferências individuais de voto, e as taxas de engajamento dos participantes de staking costumam ser baixas. Vários validadores abordam parcialmente essa questão consultando seus maiores delegadores antes de votar e dividindo os votos de acordo com as preferências deles. Outros testaram ferramentas personalizadas que reproduzem o sistema existente de votação com tokens, emitindo novos tokens de governança para seus participantes de staking com base na participação proporcional de cada um. No entanto, essa ainda é uma solução específica de cada validador, não um recurso padronizado para todo o protocolo.

Quem se opõe à participação dos participantes de staking argumenta que a maioria dos delegadores não possui conhecimento técnico, raramente acompanha de perto as decisões de governança e não tem a compreensão aprofundada dos mecanismos e das concessões de uma blockchain necessária para tomar decisões bem fundamentadas. Os defensores, porém, afirmam que depender apenas dos validadores cria um conflito de interesses — não é realista esperar que a maioria dos validadores vote em propostas que beneficiem a rede se elas prejudicarem seus próprios incentivos econômicos.

Entre as possíveis melhorias estão canais de comunicação melhores entre validadores e delegadores, como painéis de governança, ferramentas de acompanhamento de sentimento ou até notificações nas carteiras sobre eventos de governança. Uma seção posterior deste relatório retomará esse tema ao analisar a abordagem do ecossistema Cosmos.

Desafios no debate sobre governança

Uma governança eficaz em ecossistemas descentralizados depende de uma comunicação clara e relevante. Contudo, durante a recente proposta SIMD-288, debates acalorados, ataques pessoais e partidarismo criaram um ambiente de governança nocivo, prejudicando o diálogo produtivo. As discussões sobre propostas importantes na Solana podem sofrer com ineficiências e perda de qualidade das informações em diferentes plataformas. Embora as discussões técnicas no GitHub e nos fóruns oficiais da Solana ofereçam debates estruturados e ponderados, quando as conversas chegam ao Discord e ao Twitter, o diálogo relevante às vezes degenera em confrontos hostis e ataques ad hominem, reduzindo a qualidade geral da tomada de decisões.

Além disso, a maioria dos participantes só se envolve nos últimos dias antes da votação, em vez de aproveitar todo o período de discussão. Incentivar a participação antecipada e estruturar melhor os cronogramas de governança — por exemplo, garantindo que as principais discussões ocorram bem antes da janela final de votação — pode ajudar a reduzir esses problemas.

As chamadas de governança mostraram-se eficazes, permitindo interação direta, esclarecimentos rápidos e menos oportunidades para provocações ou desinformação. Reforçar a moderação, promover discussões estruturadas e priorizar análises baseadas em fatos em vez de confrontos hostis são medidas essenciais para manter um processo de governança construtivo.

Agrupamento de propostas de governança

As decisões de governança costumam ser mais eficazes quando cada proposta é votada separadamente, permitindo que os eleitores avaliem cada questão por seus próprios méritos. Uma preocupação importante com o agrupamento de propostas é o viés inconsciente: eleitores com opiniões fortes sobre uma questão podem, sem intenção, deixar que ela influencie sua posição sobre outras, mesmo sem relação entre elas. Isso reduz a probabilidade de decisões ponderadas e pode impedir a implementação de mudanças que seriam benéficas.

Outro risco é que o agrupamento aumenta a complexidade operacional, elevando a probabilidade de erros. Isso foi observado durante o período de votação conjunta da SIMD-228 e da SIMD-123, quando uma pequena quantidade de tokens destinada à SIMD-123 foi enviada por engano ao endereço de abstenção da SIMD-228. Embora raros, esses erros distorcem os resultados das votações e prejudicam a confiança no processo de governança.

Por outro lado, o argumento a favor do agrupamento é que consolidar várias decisões em menos períodos de votação pode reduzir a fadiga dos eleitores e estimular taxas de participação mais altas. Embora isso possa melhorar o engajamento, o custo é uma perda de clareza e precisão na tomada de decisões. Além disso, quando as propostas agrupadas são complexas, elas costumam exigir períodos mais longos de discussão e revisão antes do início da votação para que os eleitores — sobretudo aqueles que normalmente participam no último minuto — tenham tempo suficiente para compreender e avaliar cada componente a fundo.

Uma abordagem mais eficaz pode ser separar as propostas de governança sempre que possível, garantindo que cada questão seja avaliada de forma independente. Se o agrupamento for necessário, ele deve ser claramente justificado.

Quóruns de votação

O papel de um quórum definido nas votações de governança da Solana gera preocupações. Na prática, os quóruns podem criar incentivos perversos, levando participantes a reter estrategicamente seus votos para impedir que uma proposta alcance o limite exigido. Na recente votação da SIMD-228, isso ficou particularmente evidente entre os eleitores do NÃO, que, durante as duas primeiras épocas de votação, consideraram a abstenção uma estratégia mais eficaz do que votar ativamente contra a proposta. 

A visibilidade da contagem de votos em andamento influencia a participação. Alguns validadores podem optar por não votar se o resultado esperado já estiver alinhado às suas preferências. Para evitar a manipulação do quórum, uma possível melhoria seria adiar a divulgação dos votos até o fim do período de votação.

Diante desses desafios, cresce o apoio à reavaliação ou eliminação das exigências de quórum para incentivar uma participação mais direta e transparente na governança.

Efeitos do SFDP

No momento da redação deste relatório, o Solana Foundation Delegation Program delega SOL a 897 validadores, que representam 66% de todos os validadores ativos da rede. O valor total delegado é de 41,01 milhões de SOL, ou 10% do total de SOL em staking. Para ver todos os detalhes do programa e de suas estratégias de delegação, consulte o relatório anterior do blog da Helius sobre o SFDP.

No modelo de governança atual, os validadores participantes do programa têm efetivamente seu poder de voto ampliado e votam em nome da Solana Foundation. Nossa análise interna e o painel público da recente votação de governança da SIMD-288 confirmam que a participação do SFDP desempenha um papel importante nos resultados das votações. Nessa votação, a participação do SFDP foi usada principalmente para votar NÃO à proposta. Se a participação controlada pelo SFDP que votou NÃO ou se absteve tivesse votado SIM, a proposta teria sido aprovada. Se toda a participação controlada pelo SFDP tivesse permanecido neutra e se abstido, a proposta ainda teria sido rejeitada, mas por uma margem menor — 64,77% contra os 61,39% efetivamente obtidos (eram necessários 66,6% para a aprovação).

Clareza sobre os critérios para realizar votações

As votações de governança de março de 2025 incluíam originalmente três propostas: SIMD-228, SIMD-123 e SIMD-218: Créditos de voto intermediários (IVC). A IVC elimina a necessidade de mods executados por validadores que otimizam os créditos de votação do Tower BFT — a variante da Solana do algoritmo de consenso pBFT — ao preencher automaticamente, de forma retroativa, os créditos de todos os blocos ascendentes quando os validadores votam em um bloco descendente.

Durante o período de discussão, cresceu o consenso de que a SIMD-218 não deveria exigir aprovação da governança. A mudança foi amplamente considerada uma correção de bug, não uma alteração substancial do protocolo, pois apenas aprimorava ou corrigia a atualização dos Créditos de Voto Oportunos (TVC). A TVC já havia sido aprovada em uma votação de governança e demonstrado forte apoio da comunidade. Uma enquete informal entre validadores no Discord Solana Tech reforçou essa visão com concordância quase unânime.

Além disso, engenheiros da Anza observaram que a SIMD-123: Distribuição de recompensas de bloco no protocolo não era uma mudança econômica, apesar do que o nome poderia sugerir. A proposta introduziu um método opcional no protocolo para distribuir recompensas de bloco aos participantes de staking, formalizando uma prática que vários validadores já executavam por métodos alternativos e padronizando o que antes era uma atividade externa ao protocolo.

Isso levanta questões importantes sobre governança:

  • Quem decide se uma proposta exige votação? Atualmente, não existe um órgão oficial nem um processo estruturado para determinar se uma proposta deve passar pela governança ou ser implementada diretamente.
  • O que constitui uma “mudança substancial no protocolo” ainda é ambíguo. A distinção entre uma atualização rotineira e uma mudança que justifica a intervenção formal da governança não é clara, e as definições atuais dependem muito da noção um tanto vaga de “impacto econômico”.

Problemas de segurança

O atual processo de votação de propostas de governança depende de uma ferramenta de terceiros, a solgov-distributor, desenvolvida e hospedada por Laine, membro da comunidade. Essa ferramenta é um fork de um distribuidor de tokens baseado em Merkle originalmente desenvolvido pela Jito. Embora Laine seja um membro muito respeitado da comunidade, depender de uma ferramenta controlada externamente introduz pressupostos de confiança e riscos de segurança.

  • Mutabilidade – tanto a ferramenta quanto sua documentação são mutáveis, o que significa que podem ser alteradas unilateralmente a qualquer momento.
  • Uso dos pares de chaves de identidade dos validadores – os validadores precisam compilar a CLI e resgatar tokens usando seus pares de chaves de identidade de validador, que são altamente confidenciais. Qualquer processo que dependa de software externo para interagir com credenciais tão críticas representa um risco de segurança.
  • Dependência de um mantenedor individual – um processo oficial de governança não deve ter dependências críticas de terceiros externos sem garantias formais de segurança ou auditorias independentes.

Mecanismos alternativos de votação

Existe uma ferramenta SPL Feature Proposal (documentação aqui), inicialmente criada para facilitar a governança on-chain. No entanto, os processos recentes de governança não seguiram essa abordagem. Em vez disso, usaram a solgov-distributor, levantando dúvidas sobre a necessidade dessa ferramenta adicional.

Em princípio, o sistema de tokens SPL já oferece um método nativo para distribuir o poder de voto de governança. O responsável por iniciar o processo poderia simplesmente distribuir tokens SPL a todos os validadores, permitindo que votassem com a CLI padrão spl-token, em vez de depender de uma ferramenta externa. Isso eliminaria dependências desnecessárias e reduziria a necessidade de confiança no processo de votação.

Próximas ferramentas de governança on-chain: SIMD-133

A próxima SIMD-133: Obter participações da época, cuja ativação na Mainnet está prevista para breve, introduz novas ferramentas de governança que permitem aos programas consultar on-chain os pesos das participações. Atualmente, os programas on-chain não conhecem a distribuição da participação da época atual nem quanto está delegado a cada conta de voto.

Com a SIMD-133, os programas de governança podem criar snapshots on-chain dos valores de participação dos validadores por meio de uma nova sysvar, eliminando a necessidade de processos manuais ou off-chain de verificação da participação. Isso simplifica significativamente o fluxo atual de governança e elimina a necessidade de conciliação manual das participações.

Comparação com redes alternativas

Cosmos

As cadeias do Cosmos SDK oferecem um modelo de governança centrado nos delegadores, no qual os participantes de staking podem reverter diretamente o voto de seu validador por meio de carteiras populares como Keplr e Leap. Isso significa que, embora um validador inicialmente vote com todo o peso de sua participação, os delegadores que discordarem podem realocar sua parcela da participação para outra opção de voto. Por exemplo, se um validador detiver 2% da participação total, mas um delegador com peso de 1% discordar, ele poderá votar separadamente, reduzindo o voto efetivo do validador para 1% e transferindo seu 1% para outra opção.

Esse sistema garante que os delegadores sempre tenham a palavra final, criando um processo de governança transparente, intuitivo e eficiente. A participação na governança da Cosmos tem grande visibilidade, pois a votação é integrada diretamente às carteiras e aos exploradores de blocos, tornando-a facilmente acessível a todas as partes interessadas.

Um exemplo relevante de comportamento divergente entre participantes de staking e validadores ocorreu durante a votação do halving do ATOM da Cosmos (Proposta 848, nov. de 2023), na qual a proposta buscava reduzir a taxa máxima de inflação para 10%:

  • 94,93% dos participantes de staking votaram SIM, apoiando o limite da inflação.
  • Apenas 53,44% dos validadores votaram SIM, pois muitos buscavam preservar fontes de receita maiores.

Essa divergência destaca a importância da participação direta dos participantes de staking, garantindo que as decisões de governança reflitam o sentimento mais amplo da comunidade, não apenas as preferências dos validadores.

O módulo de governança da Cosmos está integrado ao protocolo, reforçando seu papel como recurso central da blockchain. Certas decisões de governança podem ser executadas automaticamente on-chain, aumentando a transparência e a prestação de contas. 

Embora esse modelo ofereça uma estrutura de governança democrática, ele depende da participação ativa e pressupõe que os delegadores tenham tempo e conhecimento para tomar decisões bem fundamentadas. A Cosmos oferece uma estrutura alternativa de governança convincente que a Solana pode estudar para identificar possíveis melhorias.

Ethereum

A governança do Ethereum segue um processo social e off-chain, em vez de uma votação direta baseada em participação. O processo decisório depende principalmente de Ethereum Improvement Proposals (EIPs), desenvolvedores principais e consenso da comunidade.

As mudanças no Ethereum são propostas por meio de EIPs, equivalentes às SIMDs da Solana. Essas EIPs descrevem novos recursos, padrões ou atualizações do protocolo Ethereum. As Ethereum Request for Comments (ERCs) definem padrões para recursos da camada de aplicativos, como tokens ERC-20 e NFTs ERC-721. Essas propostas são discutidas abertamente em fóruns de pesquisa do Ethereum (Ethereum Magicians), eventos populares do Ethereum (por exemplo, Devcon, ETHDenver e ETHCC), GitHub e chamadas dos desenvolvedores principais. A comunidade em geral participa da governança debatendo propostas em plataformas como Discord, Farcaster e X.

Diferentemente da Cosmos ou da Solana, o Ethereum não usa governança baseada em participação ou votação com tokens para decisões de protocolo. Desde a transição do Ethereum para Proof-of-Stake, os validadores assumiram um papel mais ativo no consenso, mas não votam formalmente. Em vez disso, um consenso aproximado é alcançado por meio de debates técnicos e amplo apoio da comunidade. As mudanças no protocolo Ethereum dependem fortemente dos desenvolvedores principais que mantêm os clientes de execução e consenso do Ethereum (por exemplo, Geth, Nethermind e Prysm).

Grandes atualizações são ativadas por meio de hard forks, que exigem que validadores e operadores de nós atualizem seu software. Os validadores aplicam as regras da rede ao decidir se adotarão novas atualizações. Embora seja raro, se uma mudança proposta for controversa e não houver consenso, ela poderá levar a uma divisão da cadeia, como ocorreu em forks anteriores, incluindo o DAO Fork (2016, Ethereum Classic) e, em menor escala, a transição do Ethereum para Proof-of-Stake (2022, EthereumPoW).

O modelo de governança social do Ethereum prioriza o consenso técnico e a discussão da comunidade em vez de mecanismos formais de votação. Embora isso tenha mantido o Ethereum flexível e descentralizado, também significa que as mudanças exigem discussões longas e prolongadas e coordenação social, em vez de governança direta baseada em tokens. Além disso, não existe uma forma oficial de detentores ou participantes de staking de ETH votarem em propostas, o que limita a influência direta dos usuários.

Conclusão

O sistema de governança da Solana ainda está em desenvolvimento e é moldado por experimentos no mundo real e pelas contribuições da comunidade. Este relatório analisou seus principais componentes — SIMDs, ativações de recursos e votações on-chain —, além de revisar todas as votações formais realizadas até hoje, os principais desafios e as comparações com redes semelhantes, como Cosmos e Ethereum. 

O ecossistema da Solana tem como base uma forte cultura orientada pela engenharia, que valoriza iterações e execução rápidas em vez de debates prolongados. Embora essa alta velocidade de atualização diferencie a Solana de muitas redes comparáveis, ela também cria tensão com modelos de governança que dependem de discussões prolongadas da comunidade e ampla coordenação social, gerando desafios únicos para equilibrar agilidade e inclusão na tomada de decisões.

A governança da Solana ainda está tomando forma, mas uma coisa é clara: o engajamento da comunidade nunca foi tão alto. Com mais partes interessadas moldando ativamente a rede, a Solana tem uma oportunidade única de construir um modelo de governança à altura de sua ambição, velocidade e ecossistema em expansão.

Recursos adicionais

Assine a Helius

Acompanhe as novidades mais recentes do desenvolvimento Solana e receba atualizações quando publicarmos

Imagem ampliada