Os pagamentos de staking da Solana continuam visíveis, mas a comissão dos validadores ficou mais difícil de verificar. Quando coletores personalizados estão ativos, o software Agave deixa vazio o campo da taxa nos metadados das recompensas. Por isso, a conferência exige dados históricos do validador e o valor recebido em SOL.

Em relatório publicado em 30 de outubro, a P2P.org afirmou que o registro desapareceu das recompensas desde 8 de setembro. Ainda assim, a empresa informou que as comissões continuaram sendo cobradas e que os valores distribuídos permanecem conciliados. Portanto, o problema afeta a evidência que explica os pagamentos, não os valores entregues.

A P2P.org comercializa serviços de staking e relatórios, o que representa um interesse comercial direto no assunto. Contudo, os documentos técnicos citados pela companhia descrevem mudanças concretas na disponibilidade dos dados. Eles também permitem distinguir a ausência do registro de uma eventual cobrança indevida.

Agave separa recompensa e comissão aplicada

A mudança aparece na pull request 12588 do Agave, incorporada em 20 de maio. Após a ativação dos coletores personalizados, o sistema esvazia o campo de comissão nas recompensas acumuladas e individuais. Dessa forma, a alteração alcança dados expostos por consultas e assinaturas de blocos.

Um campo vazio não significa que o validador deixou de cobrar a comissão. Em vez disso, a informação não aparece mais no registro final da recompensa. O código do Agave ainda envia a taxa ao cálculo antes de suprimi-la dos metadados.

Os coletores personalizados desempenham outra função dentro do protocolo. A especificação SIMD-0232 permite direcionar a receita para contas de coleta designadas. No entanto, o documento mantém o cálculo da comissão de inflação e altera somente as regras de recebimento.

Taxa pode pertencer a uma época anterior

A justificativa técnica indica que uma recompensa acumulada pode reunir receitas enviadas a um coletor. Nesse caso, uma única taxa não representaria adequadamente o total. Porém, a implementação também omite a comissão das recompensas individuais de contas de stake.

O histórico importa porque a Solana adia os efeitos das mudanças de comissão entre épocas. Pela regra SIMD-0249, a rede captura a taxa no início da época E-1. Depois, distribui as recompensas na época E e calcula os valores no início da época E+1.

Contas de voto novas usam alternativas quando não possuem histórico anterior. Por consequência, a configuração atual do validador pode divergir da taxa aplicada a uma recompensa passada. Assim, usar apenas o estado mais recente pode associar um pagamento antigo ao dado errado.

Fonte: regra SIMD-0249.

Desenvolvedores discutem acesso aos dados

A preocupação com a visibilidade surgiu antes do relatório publicado em outubro. Em uma discussão técnica de 16 de julho, desenvolvedores relataram que taxas efetivas e coletores permaneciam em um estado de execução em cache. Com isso, usuários não conseguiam inspecionar essas informações por uma leitura comum de conta.

Os desenvolvedores disseram que a regra de atraso da comissão já operava na rede principal. Ao mesmo tempo, discutiram uma solução separada para reduzir a dependência do estado em cache. Em 18 de outubro, o colaborador ax-x2 reforçou essa distinção em uma solicitação de RPC.

O pedido afirma que getVoteAccounts e os dados analisados das contas exibem apenas a configuração mais recente. Entretanto, o cálculo da recompensa pode utilizar uma taxa armazenada anteriormente. A proposta pede uma resposta opcional com a comissão efetiva, sua época e o slot do banco.

Em 30 de outubro, a solicitação permanecia aberta e sem implementação vinculada. Seu exemplo apresenta uma taxa atual baixa ao lado de outra taxa histórica mais alta. Apesar disso, o caso não identifica um incidente real nem comprova cobrança excessiva.

Ferramentas históricas ajudam na reconstrução

Associar um pagamento histórico à comissão exige mais informações do que o recibo da recompensa. É necessário combinar época, delegação da conta e taxa selecionada pela regra aplicável. Sobretudo, todos os registros precisam corresponder ao mesmo pagamento.

O Validator History Program da Jito documenta até 512 épocas por validador, incluindo a comissão observada. Sua instrução de cópia lê a taxa da conta de voto e registra época e slot. Mesmo assim, a observação não prova sozinha qual comissão efetiva produziu uma recompensa específica.

Já o parser de snapshots da Marinade acessa o estado em cache usado na seleção. A ferramenta extrai a comissão de inflação dos snapshots de epoch-stakes. Além disso, publica a versão temporal dos dados e os contadores de uso das alternativas.

A Marinade alerta para limitações nos arquivos e para saídas antigas sem metadados temporais. Consequentemente, um número sem contexto de captura não representa com segurança a taxa efetiva. O parser permite reconstruir dados, mas não garante arquivos completos para todas as contas e épocas.

Retorno líquido não comprova a taxa cobrada

A provedora Trillium utiliza outra abordagem para medir o rendimento dos delegadores. Sua metodologia de APY acompanha o crescimento das contas de stake desde a época 1070. Para isso, aplica verificações de elegibilidade e alternativas de RPC sem depender da comissão exibida.

Antes da época 1070, a Trillium emprega métodos diferentes. Desse modo, ainda consegue medir ganhos líquidos quando o registro omite a taxa aplicada. Todavia, a medição do retorno não confirma de forma independente a comissão que produziu o resultado.

A Trillium também separa um resultado desconhecido de uma taxa zero quando faltam evidências adequadas. Para os titulares, um registro útil deve conectar recompensa, período, validador e comissão efetiva. Caso exista reconstrução ou amostragem, o relatório também precisa informar seus limites de cobertura.

Propostas buscam restaurar a transparência

Algumas propostas tentam facilitar a conexão entre pagamentos e taxas históricas. Uma discussão sobre o estado de voto considera armazenar comissões junto das épocas em que entram em vigor. Por outro lado, a solicitação de RPC pretende expor a taxa efetiva usada pelo ambiente de execução.

Ambas permanecem como propostas nos registros disponíveis, sem evidência de uma correção implementada. Além do mais, comissão de inflação, comissão de MEV e compartilhamento de receita de blocos são componentes separados. Logo, restaurar uma taxa não explicaria isoladamente todo o retorno do staking.

Segundo a P2P.org, as recompensas da Solana continuam conciliadas. Ainda assim, a ausência da comissão nos registros obriga o titular a localizar a taxa histórica correta. Essa verificação depende de evidências que identifiquem claramente o período e a cobertura dos dados.

	Receba nossas últimas notícias em primeira mão.   Adicione-nos como sua fonte preferida no Google    e toque em “Favorito” para priorizar nossas atualizações.