
Avalanche (AVAX)
Sem 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
Este dossiê examina a finalidade documentada e os mecanismos do Avalanche nativo (AVAX) na rede avalanche-mainnet. O objetivo é verificar se o código e a documentação publicados estão alinhados com os objetivos operacionais declarados, sem fazer afirmações sobre o desempenho atual de mercado ou a saúde da rede em operação.
Fatos estabelecidos
O material de origem revisado consiste em documentação primária fixada e versões de software para a implementação do nó AvalancheGo. O arquivo README identifica a mainnet como a configuração padrão, distinta da rede de teste Fuji e das redes locais. Esclarece que um nó deve concluir o bootstrapping, que é o processo de obtenção das informações de estado necessárias, antes de poder participar do consenso ou expor APIs de forma confiável. O código-fonte da gênese constrói explicitamente um ativo chamado Avalanche com o símbolo AVAX. Constrói cadeias chamadas X-Chain e C-Chain dentro da construção da gênese revisada. A C-Chain utiliza o identificador EVM, onde EVM significa Ethereum Virtual Machine, um ambiente de execução para executar contratos inteligentes. O código inclui alocações e fundos apostados com cronogramas de desbloqueio. Esses documentos servem como instruções de implementação e não medem de forma independente a taxa de transferência, a latência, os custos, o tempo de atividade, a independência do operador, os poderes de governança, a implantação atual do cliente, o uso, a distribuição de suprimento, a concentração de propriedade, a liquidez ou um histórico completo de incidentes.
Desconhecidos
A verificação independente da propriedade beneficiária, dos padrões de uso reais, das taxas de adoção do cliente, da dinâmica do suprimento total, da concentração de tokens, da profundidade de liquidez e do registro histórico completo de incidentes de segurança permanece não verificada. Nenhuma observação de critério independente foi admitida neste lote documental para identidade, uso, função do token, suprimento, concentração, captura de valor, controle, segurança, governança, responsabilidade, incidentes, continuidade ou execução. Consequentemente, a cobertura de pontuação é de 0%, e o ativo mantém status não avaliado. Essas fontes documentais deixam os critérios operacionais não verificados.
Consequências
Mecanismos documentais por si sós não podem estabelecer o comportamento real da rede ou resultados de investimento. Sem observações de rede independentes datadas ou verificações de identidade reproduzidas, a força operacional da rede permanece não comprovada. A ausência de dados verificados sobre suprimento, controle e uso impede qualquer avaliação de risco ou resiliência além da revisão estática do código.
Veredito
Avalanche (AVAX) na avalanche-mainnet está não avaliado com 0% de cobertura de pontuação. Os resumos fornecidos descrevem documentação fixada e software, mas não constituem verificação operacional independente. O dossiê confirma a existência da estrutura de ativo definida no código, mas não pode validar sua operação no mundo real, segurança ou propriedades econômicas com base apenas nessas fontes.
O que mudaria isso
O veredito exigiria revisão se verificações de identidade reproduzidas, observações de rede independentes datadas e evidências específicas por critério fossem fornecidas. Tais evidências devem ser seguidas de calibração e revisão editorial para passar de um status não avaliado para uma avaliação pontuada. Até então, a falta de critérios essenciais, incluindo identidade, suprimento e controle, mantém o ativo em estado desconhecido.
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.
ava-labs/avalanchego: pinned client README
The pinned AvalancheGo README describes a node implementation for Avalanche. A node must finish bootstrapping, obtaining the information needed to participate, before healthy participation and APIs are ready. The repository distinguishes mainnet, the Fuji test network and local networks, with mainnet as the default configuration. Its versioning discussion separates network upgrades and implementation patches and warns that some interfaces may change. These are implementation and deployment instructions. They do not independently establish throughput, latency, costs, uptime, operator independence, governance powers, current client deployment, usage, supply, ownership, liquidity or a complete incident history. This dossier concerns native AVAX, excluding third-party representations.
Consultar a fonte primária ↗AvalancheGo: pinned genesis asset construction
The pinned genesis source constructs an asset named Avalanche with symbol AVAX and denomination 9 in its FromConfig code, then returns platform-chain genesis bytes and the AVAX asset identifier. It constructs chains named X-Chain and C-Chain with separate virtual-machine identifiers, with the C-Chain using the EVM identifier. A virtual machine defines the execution rules for a chain. The configuration contains allocations and staked and unstaked funds with unlock schedules. This code observation identifies native AVAX in the reviewed implementation; it neither independently reproduces deployed genesis nor measures current supply, allocations, unlock dates, burns, fees, client deployment or holder ownership.
Consultar a fonte primária ↗Somente resumos originais são distribuídos. Os dados brutos de mercado sob licença permanecem privados.