A proposta da Solana para dobrar sua taxa anual de desinflação foi aprovada em uma votação de governança com 67% de apoio, colocando a rede no caminho para reduzir a emissão projetada de $SOL 18,9 milhões de tokens ao longo de seis anos.
Proposta de inflação da Solana supera por pouco a votação exigida
O painel oficial de governança da Solana mostrou que o SGP-0002, chamado Double Disinflation, terminou a votação com 176,29 milhões de SOL a favor, representando 67% da parcela em participação.
Mais 66,19 milhões de SOL, ou 25,16%, votaram contra a proposta, enquanto 20,63 milhões de SOL, ou 7,84%, se abstiveram. A participação na votação chegou a 60,7%, representando 433,49 milhões de SOL e superando o quórum de um terço exigido pelas regras de governança da Solana.
No processo de governança da Solana, uma proposta é aprovada quando pelo menos um terço do stake da rede participa e dois terços de todo o stake votante participando vota a favor. As abstenções contam para ambos: participação e o total usado para calcular o apoio, deixando o SGP-0002 apenas ligeiramente acima dos 66,67% exigidos.
O resultado fornece um mandato ponderado por stake para avançar com uma desinflação mais rápida. Ele não reduz imediatamente a emissão de SOL porque um SGP estabelece a direção preferida da rede, enquanto um Documento de Melhoria da Solana especifica as mudanças técnicas necessárias para executá-la.
O SIMD-0550, escrito pelos contribuidores da Helius Lostin e 0xIchigo, aumentaria a taxa na qual a inflação do SOL declina a cada ano de 15% para 30%. Em vez de cortar pela metade a taxa de inflação atual de uma vez, a proposta faria com que a inflação caísse duas vezes mais rápido a partir do nível em que a mudança se tornasse ativa.
De acordo com a especificação do SIMD-0550, a Solana atingiria sua taxa terminal de inflação existente de 1,5% em cerca de 2,8 anos, em comparação com 5,7 anos sob o cronograma atual. Os autores estimam que a mudança removeria 18,9 milhões de SOL da emissão projetada ao longo de seis anos, ou cerca de 2,6% da oferta esperada no cronograma atual.
A desinflação mais rápida ainda requer uma implementação técnica
Embora o painel de governança rotule o SGP-0002 como finalizado, o SIMD-0550 permaneceu em “Revisão” no repositório de documentos de melhoria da Fundação Solana no momento em que este texto foi escrito. O campo de recursos do documento também não identificava uma implementação concluída nem um cronograma de ativação.
Antes da ativação no mainnet, clientes de validadores precisam adicionar e dar suporte a um gate de recurso chamado double_disinflation_rate. O documento técnico diz que o recurso seria ativado em um limite de época, com o cronograma mais rápido aplicando-se às recompensas da época seguinte.
Os desenvolvedores projetaram a mudança para manter a emissão contínua na ativação, de acordo com o SIMD-0550. A Solana reancoraria sua fórmula de inflação no slot de ativação, evitando uma queda imediata na taxa ou uma alteração retroativa nas recompensas já conquistadas.
Como as recompensas de inflação afetam a capitalização bancária e o hash do banco da Solana, todo cliente de validador precisa calcular o novo cronograma da mesma forma. Uma diferença entre implementações poderia fazer os nós chegarem a estados de rede conflitantes, tornando a proposta uma mudança no nível de consenso e não um ajuste simples nas configurações do validador.
O documento técnico afirmou que o gate de recurso deve permanecer no software do cliente permanentemente para que nós que estejam reproduzindo o histórico da Solana possam aplicar a taxa de inflação correta antes e depois da ativação. As recompensas de épocas concluídas permaneceriam inalteradas.
A Solana anteriormente considerou o SIMD-0228, que vinculava as emissões à participação no staking em vez de seguir um cronograma fixo de redução. A proposta não conseguiu atingir quórum em março de 2025 depois que validadores e outros participantes levantaram preocupações sobre a renda do staking, a economia do validador e a complexidade do modelo.
O SIMD-0550 usa um cronograma fixo que não reage a mudanças na participação do staking. Os autores disseram que o design preservaria um caminho de inflação previsível, evitando uma redução súbita que poderia gerar pressão imediata na receita dos validadores.
Proposta de taxa de recurso falha em alcançar apoio de dois terços
Juntamente com o SGP-0002, os eleitores da Solana rejeitaram o SGP-0003, a proposta de Taxa de Recurso e Inclusão, apesar de 61,14% de participação.
O total final mostrou 53,9% de apoio, 18,92% de oposição e 27,18% de abstenções. O apoio, portanto, caiu quase 13 pontos percentuais abaixo do limite de dois terços.
O SGP-0003 pediu que validadores e delegadores apoiassem o SIMD-0553, que substituiria o modelo de taxa-base plana da Solana por uma taxa de inclusão de 2.500 lamports e uma cobrança separada com base nos recursos solicitados por cada transação. Os validadores receberiam as taxas de inclusão e de prioridade, enquanto o protocolo queimaria a parte integral baseada em recursos.
Atualmente, a Solana cobra uma taxa-base de 5.000 lamports por assinatura, dividida igualmente entre queima e pagamento ao validador produtor de blocos, de acordo com a documentação da rede. As taxas de prioridade vão integralmente para os validadores.
O modelo de taxas do SIMD-0553 propôs três estágios de taxa de recurso. Usando a atividade de rede de maio de 2026, seus autores estimaram que as queimas diárias seriam de 1.500 a 1.800 SOL no primeiro estágio, 3.750 a 4.500 SOL no segundo e 7.500 a 9.000 SOL na taxa final. Atualmente, a Solana queima cerca de 648 SOL por dia por meio de sua taxa fixa.
Mesmo na taxa mais alta proposta, o documento estimou que a queima adicional equivaleria a cerca de 0,5% da oferta anualmente contra uma taxa de inflação de aproximadamente 3,8%. Portanto, o SIMD-0553 não projetou que o modelo de taxas sozinho tornaria o SOL um ativo líquido-desinflacionário.
Os custos de transação também variariam de acordo com os recursos de rede solicitados. A proposta estimou que uma votação simples de validador poderia custar 12,3% a menos, enquanto uma troca de prioridade zero do Pump.fun usada como exemplo poderia enfrentar um aumento de 3.150%. Aplicações que definem limites de computação bem acima de suas necessidades reais pagariam mais porque a taxa usaria os recursos solicitados em vez da quantidade efetivamente consumida.