Análise: registros de recompensas da Solana omitem taxas de comissão e complicam a verificação de tarifas

O software Agave, da Solana, omite taxas de comissão dos metadados de recompensas quando coletores personalizados estão ativos, embora os pagamentos de staking possam continuar visíveis. A P2P.org afirmou em um relatório de 30 de outubro que os registros de recompensas de votação e staking não incluíam entradas de comissão desde 8 de setembro. A P2P.org disse que os validadores continuaram cobrando comissão e que os valores das recompensas foram conciliados. O problema diz respeito às evidências necessárias para explicar os pagamentos, não a uma insuficiência identificada nos pagamentos. A P2P.org tem interesse comercial na questão porque a provedora oferece serviços de staking e relatórios.

A pull request #12588 do Agave, incorporada em 20 de maio, especifica a omissão após a ativação de coletores personalizados, abrangendo comissões acumuladas de validadores e recompensas individuais de staking. As informações afetadas sobre recompensas chegam aos usuários por meio de consultas a blocos e assinaturas. O código de cálculo do Agave continua fornecendo a comissão ao cálculo da recompensa antes de excluir a taxa do registro resultante. Portanto, a ausência de uma taxa indica metadados ausentes, não uma cobrança de comissão igual a zero. A SIMD-0232 permite que validadores direcionem a receita de comissão a contas de coleta designadas sem alterar a forma como a comissão de inflação é calculada.

A pull request explica que recompensas acumuladas podem combinar receitas direcionadas a um coletor, de modo que uma única taxa de comissão pode não descrever adequadamente o total. No entanto, a implementação também remove a taxa das recompensas individuais de staking, reduzindo as evidências disponíveis para verificar uma única conta de staking. O atraso da Solana na aplicação de mudanças de comissão torna necessárias as taxas históricas para a verificação. Segundo a SIMD-0249, as recompensas obtidas durante a época E normalmente usam uma taxa registrada no início da E-1, e o cálculo ocorre no início da E+1. Contas de voto recém-criadas podem usar o estado posterior da conta quando o histórico anterior necessário não está disponível. Consequentemente, a configuração mais recente de um validador pode ser diferente da taxa aplicável a um pagamento mais antigo.

Uma discussão de engenharia em 16 de julho identificou informações sobre comissão efetiva e coletores no estado de execução em cache, que leituras comuns de contas não conseguiam revelar. Desenvolvedores disseram que a regra de atraso da comissão já estava em vigor na mainnet e discutiram separadamente como resolver a dependência do estado em cache. O colaborador do Agave ax-x2 apresentou em 18 de outubro uma solicitação de RPC explicando que getVoteAccounts e os dados analisados da conta de voto expõem a configuração mais recente, embora os cálculos de recompensas possam usar uma taxa salva. A solicitação propõe uma resposta opcional que mostraria a comissão de inflação efetiva, a época relevante e o slot do banco. Em 30 de outubro, a solicitação ainda estava aberta, sem uma implementação vinculada. O exemplo da solicitação associa uma taxa exibida baixa a uma taxa salva alta, mas não identifica um incidente observado envolvendo um validador nem comprova cobrança excessiva.

A verificação de uma comissão histórica exige associar o período da recompensa, a delegação do validador da conta de staking e a taxa escolhida segundo a regra histórica aplicável. O Programa de Histórico de Validadores da Jito documenta o histórico de comissões e outras informações de validadores, abrangendo até 512 épocas por validador. A instrução de cópia da Jito registra a comissão de uma conta de voto junto com a época e o slot, mas essa observação, por si só, não estabelece a taxa efetiva com atraso para um pagamento específico. O analisador de snapshots da Marinade acessa as informações em cache de forma mais direta, extraindo a comissão de inflação de snapshots de participações por época e publicando a data de referência do valor e contadores de fallback. A Marinade alerta que os limites dos arquivos históricos e arquivos de saída mais antigos, sem metadados sobre a data de referência, limitam a interpretação das taxas armazenadas. O analisador oferece uma técnica de reconstrução, não a garantia de arquivos completos para todas as contas e épocas.

A metodologia de APY da Trillium mede os retornos da inflação por meio do crescimento das contas de staking a partir da época 1070, aplicando verificações de elegibilidade e alternativas via RPC em vez de usar a comissão exibida. A Trillium usa outros métodos para épocas anteriores. Assim, os ganhos líquidos podem continuar sendo mensuráveis sem que seja possível verificar de forma independente a comissão que os gerou. A Trillium trata a ausência de evidências adequadas da conta como um resultado desconhecido, não como zero. Um registro de renda útil para detentores de SOL ou produtos de staking vincularia as recompensas líquidas ao período relevante, à delegação do validador e às evidências da comissão efetiva, além de informar limitações de reconstrução ou amostragem.

Uma discussão de outubro sobre o estado de votação propõe manter as taxas de comissão junto com as épocas em que essas taxas passam a vigorar. A proposta para o estado de votação e a solicitação de RPC ainda em aberto são soluções propostas, não evidências de uma correção implantada. Comissão de inflação, comissão de MEV e compartilhamento de receitas de blocos são componentes distintos; portanto, tornar visível uma taxa não explicaria o retorno total do staking. A cobertura de setembro sobre créditos de voto vinculados a recompensas também estabeleceu que as medições de desempenho, por si sós, não podiam quantificar a perda de pagamentos em SOL de um detentor específico sem evidências no nível da conta. Detentores que verificam taxas de comissão omitidas precisam associar os pagamentos a evidências históricas cujo período e cobertura possam ser verificados.