Solana SIMD 547: Uma Taxa Base Baseada em Recursos Que É Totalmente Queimada — Potencialmente Adicionando Mais de 1.500 SOL em Queimas Diárias
Solana SIMD 547: Uma Taxa Base Baseada em Recursos Que É Totalmente Queimada — Potencialmente Adicionando Mais de 1.500 SOL em Queimas Diárias
O design de "taxas baixas, alto rendimento" da Solana ajudou-a a tornar-se um local principal para negociação on-chain, aplicações de consumo e pagamentos em tempo real. Mas, à medida que a atividade económica da rede escala, uma questão recorrente continua a surgir no mercado de criptomoedas mais amplo: deve a SOL capturar mais valor do uso intensivo em recursos, sem prejudicar a experiência do utilizador que tornou a Solana competitiva em primeiro lugar?
Uma nova proposta da comunidade, SIMD 547, explora uma resposta possível: introduzir uma taxa base baseada em recursos, precificada por "unidades de custo", e queimar essa taxa integralmente. A ideia está a ganhar atenção porque aborda diretamente a tokenomics da Solana — especificamente a lacuna entre a queima de taxas relativamente pequena de hoje e a emissão contínua da rede.
Abaixo está o que a proposta sugere, porque é importante e o que pode significar para desenvolvedores, traders e utilizadores comuns.
1) Por Que a Queima de Taxas da Solana Parece "Muito Pequena" Hoje
Sob o atual modelo de taxas da Solana, o custo da transação é amplamente:
- Taxa base (baseada em assinatura; atualmente 5.000 lamports por assinatura), mais
- Taxa de priorização (opcional; definida através de instruções de orçamento de computação). Ainda paga taxas mesmo que uma transação falhe. Veja a documentação da estrutura de taxas da Solana. (solana.com)
Crucialmente para a tokenomics:
- 50% da taxa base é queimada, e os outros 50% vão para o validador que produz o bloco.
- 100% da taxa de priorização vai para validadores (nenhuma é queimada). Os detalhes também são resumidos na mesma documentação da estrutura de taxas. (solana.com)
Na discussão do SIMD 547, o proponente argumenta que a queima atual das taxas base é economicamente minúscula, estimando aproximadamente 648 SOL/dia queimados do mecanismo de taxa base com suposições de alto rendimento — insignificante em comparação com o ritmo de inflação citado de ~60.000 SOL/dia. (github.com)
Esta lacuna é a motivação: se a SOL deve refletir a atividade da rede, alguns membros da comunidade desejam que a dinâmica de queima do protocolo escale mais com o consumo real de recursos, não apenas com assinaturas.
2) O Que o SIMD 547 Propõe (Em Linguagem Simples)
A sugestão principal do SIMD 547 é direta:
- Cada transação já recebe um "custo" estimado com base em múltiplas dimensões de recursos (não apenas computação).
- Adicionar uma nova taxa base calculada a partir desse custo, precificada em: 0.1 lamport por unidade de custo solicitada, e queimar 100% dela. (github.com)
Se precisar de uma rápida atualização, um lamport é a menor unidade de SOL (1 lamport = 0.000000001 SOL). Veja a referência de terminologia da Solana para lamport. (solana.com)
"Unidades de Custo" vs. "Unidades de Computação"
Muitos utilizadores estão familiarizados com unidades de computação porque aparecem no ajuste da taxa de prioridade. Mas o "custo" no agendador da Solana é mais amplo: leva em consideração itens como bloqueios de escrita e tamanho dos dados das contas carregadas, não apenas computação. Isto reflete-se na explicação da taxa e agendamento do protocolo na documentação da estrutura de taxas (ver como "custo" é usado no agendamento de transações). (solana.com)
No tópico do SIMD 547, o autor também enfatiza que as unidades de custo incluem computação mais outros recursos solicitados implicitamente (dados carregados, heap, bloqueios de escrita e mais). (github.com)
3) Impacto Esperado da Queima: "Significativo, Mas Não Mágico"
Um dos pontos mais discutidos é quanto SOL adicional realmente seria queimado.
No tópico, um membro da comunidade partilhou agregados recentes dos limites de unidades de computação solicitados por dia, concluindo que — aos níveis de uso atuais — o mecanismo provavelmente resultaria em cerca de 1.500–1.800 SOL/dia de queima adicional, com a possibilidade de mais durante picos de demanda. (github.com)
Isto é materialmente maior do que a queima atual da taxa base, mas ainda assim insuficiente por si só para "virar" a Solana num ativo consistentemente deflacionário em condições normais — especialmente se taxas mais altas reduzirem a demanda. Essa troca é central para o debate.
4) Quem Paga Mais? Criadores vs. Utilizadores de Retalho (E Por Que a Proposta Se Importa)
Um objetivo de design chave é evitar quebrar a estrutura de mercado de alta frequência, ao mesmo tempo que se cobra mais por transações pesadas em recursos.
Na redação do SIMD 547, o proponente argumenta que muitas atualizações de alta frequência (frequentemente associadas a criadores/atualizações de oráculos) tendem a solicitar poucas unidades de custo, portanto, a taxa adicionada poderia ser limitada a um aumento percentual de um único dígito baixo nesses fluxos de trabalho. (github.com)
No entanto, para utilizadores comuns que atualmente submetem transações com taxas de prioridade baixas ou nulas, o aumento relativo pode parecer dramático. O tópico inclui exemplos mostrando saltos percentuais de três dígitos, incluindo um cenário com um aumento de +639% ao passar de uma transação com taxa mínima para uma que também paga a nova taxa baseada em recursos. (github.com)
Conclusão prática
- Se já depende de taxas de prioridade (por exemplo, negociação competitiva), o impacto incremental pode ser modesto em termos percentuais.
- Se normalmente envia transações "baratas" (especialmente em contextos de baixa urgência), a sua sensibilidade ao custo pode ser maior.
É por isso que a proposta é controversa: melhora a captação de valor para detentores de SOL através da queima, mas também pode remodelar a experiência de utilizador "padrão barata" que muitos utilizadores associam à Solana.
5) A Dependência Alpenglow: Por Que o Timing Importa
O SIMD 547 não é apresentado como algo que pode ser ativado imediatamente.
A discussão observa explicitamente que os custos de votação dos validadores são importantes até que Alpenglow seja ativado, e o mecanismo é assumido para ativar após Alpenglow. (github.com)
O próprio Alpenglow é uma importante proposta de redesenho de consenso, formalizada como SIMD 0326, substituindo o atual consenso baseado em Proof-of-History + TowerBFT por Alpenglow (Votor) para melhor desempenho e resiliência. Veja o documento SIMD 0326. (github.com)
Portanto, na prática, o SIMD 547 é melhor entendido como parte de um roteiro mais amplo: primeiro mudar o consenso e os mecanismos de voto, depois revisitar os botões da tokenomics que seriam dolorosos sob as suposições atuais.
6) Questões Abertas Que a Comunidade Provavelmente Debaterá
Mesmo os apoiantes geralmente concordam que os detalhes importam. Com base no tópico e nos atuais mecanismos de taxas da Solana, espere debates sobre:
- Recursos solicitados vs. utilizados: cobrar pelo "custo solicitado" é simples e previsível, mas pode sobrecarregar transações mal configuradas (semelhante à forma como as taxas de prioridade dependem do limite de CU solicitado). (solana.com)
- Experiência do utilizador a nível de aplicação: carteiras e dApps podem precisar de uma melhor estimativa de taxas e divisões mais claras ("quanto é queima vs. gorjeta vs. base").
- Economia de spam e DoS: uma queima mais forte poderia dissuadir certos padrões abusivos, mas também pode penalizar casos de uso legítimos de alta complexidade (roteamento DeFi, interações avançadas com programas).
- Tokenomics vs. adoção: em 2025-2026, a tendência da indústria tem sido para mercados de taxas mais sustentáveis e captura de valor mais clara — mas redes que exageram podem empurrar a atividade para alternativas.
Para leitores que desejam a discussão principal, o melhor ponto de partida é o tópico original da comunidade SIMD 547. (github.com)
7) O Que Utilizadores e Construtores Podem Fazer Agora
Mesmo que o SIMD 547 ainda esteja em discussão e não ativo, é um bom momento para se preparar:
Para equipas de dApp
- Auditar transações que habitualmente solicitam limites altos "só por segurança". A documentação da Solana explica como as taxas de prioridade dependem dos limites de unidades de computação solicitados na documentação da estrutura de taxas. (solana.com)
- Monitorizar com que frequência os seus utilizadores dependem de fluxos de "sem taxa de prioridade"; estes são os mais expostos a um novo componente de queima obrigatório.
Para traders e utilizadores avançados
- Se executar automação, comece a modelar as taxas como (taxa base de assinatura + taxa de prioridade + potencial queima baseada em recursos), em vez de tratar a queima como um erro de arredondamento.
- Se agrupar ações, considere se transações menores e mais pesadas se tornariam menos atrativas do que interações mais granulares.
Para todos: auto-custódia ainda importa
Mecanismos de taxas e debates sobre tokenomics tendem a aumentar a experimentação on-chain (novo roteamento, novas estratégias MEV, novos bots). É também quando os ataques de phishing e as aprovações maliciosas aumentam.
Se detiver SOL a longo prazo ou interagir frequentemente com DeFi na Solana, uma carteira de hardware como a OneKey pode ajudar, mantendo as chaves privadas offline e exigindo aprovações explícitas de transações — útil quando a composição das transações (e as divisões de taxas) se tornam mais complexas.
Conclusão
O SIMD 547 é uma proposta focada em tokenomics que tenta encontrar um equilíbrio difícil: aumentar a queima de SOL de forma que escale com o consumo de recursos, evitando um aumento de taxas bruto que possa perturbar validadores e o fornecimento de liquidez de alta frequência.
Se implementado como proposto, estimativas da comunidade sugerem que poderia adicionar aproximadamente 1.500–1.800 SOL/dia de queima adicional aos níveis de uso atuais — ainda modesto em relação à emissão, mas já não negligenciável. (github.com)
Por agora, o ponto mais importante não é o número exato — é a direção: a Solana está a explorar ativamente como alinhar recursos da rede, mercados de taxas e a captura de valor da SOL, provavelmente em conjunto com mudanças de protocolo maiores como o Alpenglow. (github.com)
