cryptosnifSolana (SOL)
solana-mainnet · Ativo nativo · pilot-1Sem nota · 0% Cobertura das evidências
Promessa documentada. Verificação independente pendente.
As evidências disponíveis são insuficientes para atribuir uma nota geral. O mecanismo descrito exige verificação do funcionamento atual.
Consultar as evidênciasA revisão das fontes explica os mecanismos documentados. As verificações independentes da rede continuam pendentes.
Promessa e Escopo
Este dossiê examina o SOL nativo na rede solana-mainnet. O foco está estritamente nos mecanismos documentados: execução de instruções, cálculos de taxas vinculados à versão, parâmetros padrão de inflação e a interface de linha de comando (CLI) de ativação de recursos do Agave. Analisamos como esses componentes são definidos no código e na documentação. Esta revisão não avalia o desempenho da rede ao vivo, a disponibilidade atual dos validadores ou os custos reais das transações em tempo real. Também exclui qualquer avaliação de segurança operacional independente ou status de auditoria.
Execução de Instruções e Atomicidade
As transações Solana consistem em instruções, que são as operações individuais que os programas executam. Uma propriedade técnica chave descrita na documentação é a atomicidade. Isso significa que, dentro de uma única transação, todas as instruções têm sucesso e suas mudanças de estado são aplicadas, ou falham e suas mudanças de estado de instrução são revertidas. Embora esse mecanismo garanta a consistência interna para uma transação específica, ele não prova que os aplicativos estejam livres de bugs, nem garante a confiabilidade geral da rede. Auditorias independentes de contratos inteligentes específicos permanecem fora do escopo desta observação.
Mecânica de Taxas e Cálculos Vinculados à Versão
As taxas na Solana são pagas em SOL e compreendem uma taxa base e uma taxa de priorização opcional. A documentação afirma que a taxa base é dividida igualmente, com 50% queimados e 50% alocados ao validador. A taxa de priorização vai inteiramente para o validador. Essas regras descrevem a lógica de distribuição pretendida, mas não medem custos ao vivo ou emissão líquida. No cliente Agave v4.3.0, a queima da taxa base é calculada usando aritmética inteira a 50%. A parte não queimada e toda a taxa de priorização são adicionadas a um depósito do coletor. Se esse depósito falhar, todo o valor é queimado. Dependendo de um sinalizador de recurso, o destinatário pode ser a identidade do líder ou um coletor permitido associado à conta de voto do líder.
Exemplo Hipotético de Cálculo de Taxa
Para ilustrar a aritmética sem implicar valores da rede ao vivo, apresentamos um cenário hipotético baseado nos cálculos originais da Cryptosnif. Assuma uma taxa base de 5000 lamports (a unidade de taxa inteira neste exemplo) e uma taxa de priorização de 1000 lamports. A taxa total é de 6000 lamports. Sob condições normais com um depósito aceito, 2500 lamports são queimados (50% da base), e 3500 lamports vão para o coletor (2500 restantes da base mais 1000 de priorização). Se o depósito do coletor falhar, todos os 6000 lamports são queimados. Em um caso com uma taxa base ímpar de 5001 lamports e uma taxa de priorização de 1000 lamports, o cálculo de queima usa divisão inteira: floor(5001 * 50 / 100) equivale a 2500 lamports queimados. O coletor recebe 3501 lamports. Estas entradas são apenas ilustrativas e não estabelecem taxas reais na mainnet nem fornecem uma base para comparação de custos contra outras redes como Ethereum.
Parâmetros Padrão de Inflação
A versão 3.2.0 do pacote solana-inflation define uma fórmula padrão para a taxa anual total de inflação: max(0.015, 0.08*(1-0.15)^year). Este modelo suporta configurações de inflação desativada, fixa e completa. É crucial distinguir esses padrões de código da configuração observada na mainnet. A fórmula representa um cronograma teórico, não a emissão realizada, datas de calendário ou mudanças líquidas de oferta. Além disso, a inflação total difere do rendimento de um detentor de staking. Um ano de modelo neste contexto não tem origem de calendário estabelecida nesta revisão.
Ilustração da Taxa de Inflação
Aplicar a fórmula padrão produz taxas específicas para anos de modelo hipotéticos. No ano de modelo 0, a taxa é de 8%. No ano de modelo 1, cai para 6.8%. No ano de modelo 2, é de 5.78%. A redução é de 15% da taxa anterior a cada ano até atingir o piso de 1.5%. A porcentagem se aplica à taxa precedente a cada ano de modelo. Esses números ilustram o comportamento matemático das configurações padrão. Eles não preveem a inflação futura, a oferta circulante ou os retornos para apostadores na rede ao vivo.
CLI de Ativação de Recursos e Verificações de Prontidão
A CLI de recursos do Agave v4.3.0 verifica a identidade de gênese do cluster e consulta o estado da conta antes de construir uma transação assinada de ativação de recurso. Sua verificação ordinária de prontidão compara os conjuntos de recursos de software reportados contra estatísticas mostrando que pelo menos 95% do stake e 95% dos nós RPC (servidores de interface de consulta) reportam o mesmo conjunto de recursos que a CLI. A CLI expõe um caminho de força explícito que ignora esta verificação de sanidade local. No entanto, essa substituição não prova que usuários arbitrários podem ativar recursos ou compelir cada validador a adotar uma regra. Autorização de transação, contas de recursos, assinaturas e comportamento do cliente implantado exigem verificação separada. Esta observação identifica um mecanismo de controle de mudança, mas não confirma quem detém as chaves de ativação ou quais recursos estão atualmente ativos.
Desconhecidos e Limitações
Vários elementos críticos permanecem não verificados nesta revisão piloto. A concentração atual de propriedade, poderes de controle privilegiados, uso medido independentemente, histórico de remediação de incidentes e liquidez executável localmente são desconhecidos. A presença de uma substituição de força na CLI não equivale a poder administrativo irrestrito, pois as regras de consenso e a adoção pelos validadores são camadas distintas. Da mesma forma, as divisões de taxas documentadas não refletem resultados econômicos ao vivo. Nenhuma transação de rede ou ativação foi realizada pela Cryptosnif durante esta análise.
Consequências e Veredito
A cobertura de evidências é insuficiente para uma pontuação geral. Um mecanismo documentado sozinho não pode estabelecer resiliência atual, segurança ou retornos esperados. A distinção entre padrões de código e implantação ao vivo é significativa; inferir oferta líquida ou rendimento de staking a partir de fórmulas é inválido. Para comparações, diferentes entradas de taxas não podem estabelecer um vencedor de custo sem dados normalizados e medidos. O veredito permanece pendente de verificação independente. Observações de rede reproduzíveis, mapas de controle atuais, regras de oferta documentadas e registros independentes de incidentes permitiriam que as verificações pendentes fossem avaliadas.
Fatos documentados
O documento primário abaixo está disponível e descreve a promessa do projeto. As verificações independentes do funcionamento continuam pendentes.
The Solana documentation presents a network for applications and transactions. Documentation describes the proposed mechanisms; current operation requires independent observation. [1]
O que ainda é desconhecido
A concentração dos detentores, os poderes de controle, o uso atual, os incidentes e a liquidez local ainda precisam ser verificados.
As evidências disponíveis são insuficientes para atribuir uma nota geral. O mecanismo descrito exige verificação do funcionamento atual.
Cada verificação exige evidências.
| Verificação | Peso | Resultado |
|---|---|---|
| Identidade exata do ativoEssencial | 3% | Verificação pendente |
| Uso observável | 15% | Verificação pendente |
| Papel econômico do token | 10% | Verificação pendente |
| Mecanismos de ofertaEssencial | 10% | Verificação pendente |
| Concentração dos detentores | 8% | Verificação pendente |
| Captura de valor | 7% | Verificação pendente |
| Poderes de controleEssencial | 10% | Verificação pendente |
| Verificação de segurança | 7% | Verificação pendente |
| Processo de decisão | 8% | Verificação pendente |
| Responsabilidades | 7% | Verificação pendente |
| Histórico de incidentes | 6% | Verificação pendente |
| Continuidade operacional | 4% | Verificação pendente |
| Condições de execução | 5% | Verificação pendente |
Verificações específicas da família: Independência do validador, atualizações, execução e taxas.
Consultar as evidências
Fontes desta análise
Os títulos e resumos das fontes estão em inglês.
Agave v4.3.0: pinned feature activation CLI
The Agave v4.3.0 feature CLI checks a cluster's genesis identity and queries account state before constructing a signed feature-activation transaction. Its ordinary readiness check compares reported software feature sets with 95% of stake and 95% of RPC nodes in the collected version statistics. The CLI exposes an explicit force path that bypasses this local sanity check. That override does not prove that arbitrary users can activate arbitrary features or compel every validator to adopt a rule: transaction authorization, feature accounts, signatures and deployed client behavior require separate checks. This code observation identifies a change-control mechanism. The present holders of activation keys, actual activated features, network adoption and independence of operators remain unverified. No network transaction or activation was performed by Cryptosnif.
Consultar a fonte primária ↗Solana documentation: transaction fees
Solana documentation describes fees paid in SOL with a base fee and an optional prioritization fee. It states that the base fee is divided 50% burned and 50% to the validator, while the prioritization fee goes entirely to the validator. These documented rules do not measure live costs, utilization or net issuance.
Consultar a fonte primária ↗Solana documentation: transactions
Solana documentation describes transactions containing instructions, the individual operations that programs execute. Execution is atomic: all instructions succeed or their state changes revert. This technical property does not prove independent audits of applications, absence of bugs, or present network reliability.
Consultar a fonte primária ↗Solana SDK 3.2.0: pinned inflation model
The solana-inflation 3.2.0 source, matched to its package commit, defines a default total annual rate of max(0.015, 0.08*(1-0.15)^year). It also supports disabled, fixed and full inflation configurations. The default total model differs from the separate validator/foundation allocation functions. These are code parameters, not observed mainnet configuration, realized issuance, calendar dates, net supply change or a staking holder's yield. A model year has no calendar origin established in this review. Original Cryptosnif calculation (platform-mechanisms-1) gives default total annual inflation rates 8%, 6.8% and 5.78% at model years 0, 1 and 2, with a 1.5% floor. The reduction is 15% of the rate each model year until the floor, not a reduction of 15 percentage points. This illustrates defaults only, not today's mainnet inflation, a future dated forecast, circulating supply or staking returns.
Consultar a fonte primária ↗Agave v4.3.0: pinned transaction fee distribution
Agave v4.3.0 computes the ordinary base-fee burn with integer arithmetic at 50%, adds the unburned base portion and the entire priority fee to a collector deposit, then attempts that deposit. A failed deposit is also burned. Depending on a feature flag, the recipient is the leader identity or a permitted collector associated with the leader's vote account. This reviewed client version does not establish current feature activation, deployed versions, live transaction cost, total issuance or beneficial control. Illustrative inputs stay within non-overflowing fee amounts. Original Cryptosnif arithmetic (platform-mechanisms-1) assumes a hypothetical base fee 5000 lamports and priority fee 1000 lamports with accepted deposit: total 6000, burned 2500, collector 3500 lamports. With a failed collector deposit, all 6000 lamports are burned. With odd base fee 5001 and priority 1000 the accepted-deposit burn is floor(5001*50/100)=2500 and collector 3501. These hypothetical inputs do not establish fees on the live network or a comparison of cost against Ethereum.
Consultar a fonte primária ↗[1] Solana documentação primáriaAfirmação do projeto
The project publishes the mechanism described above.
Observação 2026-10-03 · Válido até 2026-11-02
Consultar a fonte primária ↗Somente resumos originais são distribuídos. Os dados brutos de mercado sob licença permanecem privados.
O que mudaria este parecer
Observações reproduzíveis da rede, um mapa dos poderes de controle e a verificação das regras de emissão permitiriam completar os testes.
Nenhuma correção registrada para pilot-1. As revisões preservam suas fontes e os pareceres anteriores.