EAV7 — Uma Blockchain de Camada 1 com Segurança Pós-Quântica e Camada Nativa de Inteligência Artificial

Whitepaper Técnico · Versão 1.0.1 · 15 de agosto de 2026

Protocolo eav20 · Símbolo EAV7 · EAVM Chain ID 72020 (mainnet) / 72021 (testnet)

Aviso preliminar. Este documento descreve a mainnet EAV7 em operação a partir de 15 de agosto de 2026. A Seção 13 (Estado de Maturidade) separa o que está ativo na rede ao vivo, o que permanece condicionado operacionalmente ou por altura de fork, e o que é roadmap. A Seção 14 (Fatores de Risco) e a Seção 15 (Aviso Legal) são partes integrantes deste documento e não devem ser lidas isoladamente. Nenhuma parte deste whitepaper constitui oferta, recomendação de investimento ou garantia de resultado.

Sumário

1. Resumo Executivo
2. Motivação e Posicionamento
3. Arquitetura e Pilha de Software
4. Consenso
5. Criptografia e Modelo Pós-Quântico
6. Estrutura de Dados e Compromisso de Estado
7. Modelo de Recursos e Taxas
8. Staking, Validação e Governança
9. EAVM — Máquina Virtual e Compatibilidade de Carteiras
10. Camada Nativa de Inteligência Artificial
11. Ponte Cross-Chain
12. Tokenomics
13. Estado de Maturidade
14. Fatores de Risco
15. Aviso Legal
16. Apêndice A — Parâmetros de Consenso

1. Resumo Executivo

A EAV7 é uma blockchain de camada 1 implementada em Rust, que combina três decisões de projeto pouco usuais quando tomadas em conjunto.

Assinatura híbrida pós-quântica obrigatória. Toda carteira, transação e bloco carrega duas assinaturas independentes — ECDSA sobre secp256k1 e ML-DSA-44 (NIST FIPS 204) — e ambas precisam verificar para que o objeto seja aceito. Não é um modo opcional nem uma migração planejada: é o único esquema que o protocolo conhece, chamado eav7-hybrid-1. Um adversário com computador quântico criptograficamente relevante que quebre a curva elíptica ainda enfrenta o reticulado; um adversário que encontre falha estrutural no ML-DSA ainda enfrenta a curva.

Camada de IA como primitiva de consenso, não como narrativa. A EAV7 define tipos de transação nativos para contratar, entregar, contestar e liquidar trabalho de inteligência artificial, com escrow on-chain, reputação de oráculo, quórum por commit-reveal, janela de contestação otimista com júri, leilão reverso de oráculos e liquidação imediata mediante atestação criptográfica. Igualmente importante é o que a IA não pode fazer: nenhum componente de IA da EAV7 tem poder vinculante sobre consenso, conjunto de validadores, stake ou código. Essa fronteira é arquitetural e verificável no código.

Economia deflacionária com emissão mínima. Cem bilhões de EAV7 no gênese, blocos de um segundo, 16 EAV7 de recompensa por bloco com halving a cada ~4 anos. A emissão do primeiro ano equivale a 0,50% do supply de gênese, e a emissão total ao longo de todos os halvings soma 4.036.608.000 EAV7 — cerca de 4,04% adicionais. Em contrapartida, 100% das taxas de transação são queimadas: não vão para o validador, não vão para a tesouraria. Sob uso relevante, a rede é estruturalmente deflacionária.

Sobre essa base a EAV7 implementa DPoS com finalidade BFT, votação em validadores com recompensa a eleitores, permissões multiassinatura por conta, cota de recursos GB com delegação, governança autorizada pelo owner com timelock, vesting, meta-transações sem gás e uma EAVM que executa bytecode EVM. EAV20 é o padrão de token de produto: contrato Solidity compatível com ERC-20 na EAVM.

A implementação de referência é um workspace Rust — biblioteca de consenso, nó completo, CLI de operador, SDK e módulo criptográfico WebAssembly — mais um explorador de blocos em Next.js. A Seção 3 descreve a pilha; a Seção 13 declara com precisão até onde ela foi levada.

2. Motivação e Posicionamento

2.1 O problema da colheita antecipada

A ameaça quântica à criptografia de curva elíptica não é simétrica no tempo. Um adversário pode capturar hoje o tráfego e o histórico público de uma blockchain e decifrá-lo anos depois, quando o hardware existir — a estratégia conhecida como *harvest now, decrypt later*. Para uma blockchain isso é particularmente grave: chaves públicas ficam permanentemente expostas no histórico assim que uma conta transaciona, e o registro é imutável e público por construção.

O NIST padronizou o ML-DSA em agosto de 2024 (FIPS 204). A resposta da maioria das redes existentes tem sido postergar: migrar um esquema de assinatura em uma cadeia com valor econômico significativo é uma das operações mais arriscadas que existem, porque exige coordenação de todo o ecossistema de carteiras, exchanges e contratos. A EAV7 parte do princípio de que nascer híbrida é substancialmente mais barato do que migrar depois, e aceita o custo — assinaturas maiores, verificação mais cara, mais largura de banda por transação — como preço de entrada.

2.2 Por que uma camada de IA nativa

Serviços de inferência de IA são hoje consumidos por APIs centralizadas, com três propriedades ruins para aplicações on-chain: o resultado não é verificável, o pagamento não é atômico com a entrega, e o provedor não tem nada em risco se mentir ou não entregar.

A EAV7 trata a inferência como um mercado de oráculos com garantias econômicas explícitas. O solicitante deposita a recompensa em escrow ao criar a tarefa. O oráculo tem stake em risco. A entrega pode ser validada por concordância de múltiplos oráculos independentes (commit-reveal), por ausência de contestação em uma janela (verificação otimista com júri e fiança) ou por assinatura de um atestador registrado — e neste último caso liquida imediatamente, sem depender de reputação.

2.3 Princípios de projeto

A EAV7 é uma L1 própria: supply de gênese de 100 bilhões, recursos regenerativos (cota GB) em vez de mercado de gás, DPoS com rodízio determinístico, caminho de tokens via contratos na EAVM (bytecode EVM), blocos de ~1 segundo, 51 assentos ativos com banco de 50, assinatura híbrida pós-quântica, camada de IA nativa, cota GB que não cobra bytes de assinatura e queima integral das taxas.

3. Arquitetura e Pilha de Software

3.1 Crates e responsabilidades

A implementação de referência é um único workspace Rust. As dependências correm em uma só direção — a biblioteca de consenso não depende de nada acima dela, e nenhum componente acima reimplementa uma regra de consenso.

A criptografia de consenso usa crates estabelecidos (k256, sha2, sha3, ripemd, a implementação de ML-DSA e ark-bn254 para o precompilado de pareamento), em vez de primitivas escritas no repositório. Os vetores em vectors/ fixam o comportamento byte a byte que qualquer implementação conforme precisa reproduzir: JSON canônico, identificadores de transação, derivação de endereço, folhas de estado, raízes de estado e envelopes da EAVM.

Não existe cliente de blockchain em JavaScript. O explorador é um front-end somente-leitura sobre a API HTTP do nó.

3.2 Cliente e caminho do operador

O eav7-core é a porta de entrada de quem quer rodar EAV7 sem ler o monorepo. Ele gera e guarda o par de chaves híbrido, escreve um arquivo de configuração em um diretório de dados nativo da plataforma, supervisiona um processo eav7-node e expõe as operações de stake e de validador através do SDK. O fluxo ancora-init cria backups dos owners e um keystore separado para a witness, sem colocar o material dos owners no servidor produtor.

Os diretórios de dados padrão são ~/.eav7 no Linux, ~/Library/Application Support/EAV7 no macOS e %APPDATA%\EAV7 no Windows, sobrescritíveis por EAV7_HOME. Definições de serviço para systemd, launchd e Windows (via sc.exe ou NSSM) acompanham o repositório em deploy/. Arquivos de release com checksum são publicados por tag para Linux x64, Linux arm64, macOS arm64 e Windows x64.

A higiene das chaves faz parte do modelo: a autoridade fria owner de uma Âncora é híbrida M-de-N (padrão de produto 2-de-3), enquanto a chave quente witness só produz blocos. A witness não pode autorizar governança nem operações de poder; os shares do owner ficam offline. Uma carteira de celular faz stake e vota; ela nunca assina blocos.

Esse caminho importa além da conveniência. Operadores externos rodando eav7-core são o único mecanismo pelo qual o conjunto de validadores se torna independente da entidade fundadora — ver Seções 13 e 14.

3.3 Superfícies do nó e transporte P2P

O tráfego entre pares corre sobre HTTP com um conjunto pequeno de mensagens: POST /tx para gossip de transação, POST /blocks para gossip de bloco e uma consulta paginada de faixa para sincronização. A descoberta de pares é por registro mútuo autenticado com token administrativo; a topologia legítima é semeada por uma lista de peers na inicialização, e o número de pares é limitado por MAX_PEERS = 64.

URLs de pares passam por um filtro anti-SSRF que normaliza formas não canônicas de IPv4 — codificações decimal, octal e hexadecimal resolvem para o mesmo endereço — antes de classificá-las como privadas ou públicas. Sem essa normalização, um par poderia levar o nó a falar com loopback ou com serviços de metadados de nuvem. Pares em faixa privada são recusados salvo autorização explícita, configuração destinada apenas a testnets locais.

O transporte em si não é autenticado nem cifrado na camada de protocolo. Deployments de produção devem colocar validadores atrás de proxy reverso ou túnel e jamais expor a API administrativa. P2P autenticado é item de roadmap (Seção 13.5).

4. Consenso

4.1 DPoS com rodízio determinístico por slot

O tempo é dividido em slots de BLOCK_TIME_MS = 1.000 ms. O slot de um instante é floor(timestamp / 1000), e o produtor esperado daquele slot é

validators[ slot mod N ]

onde validators é o conjunto ativo ordenado. Não há sorteio, VRF ou leilão: dado o relógio e o conjunto de validadores, o produtor de qualquer slot é uma função pura e universalmente computável.

O conjunto ativo é derivado do estado a cada bloco: contas com staked ≥ MIN_VALIDATOR_STAKE (1.000 EAV7), ordenadas por peso = stake próprio + votos recebidos em ordem decrescente, desempate por endereço ascendente, truncado em MAX_VALIDATORS (51 na mainnet). As 50 contas elegíveis seguintes formam o banco; o ecossistema ranqueado totaliza top 101. Só Âncoras ativas produzem blocos e votam; o banco é candidato à promoção. Contas gerenciadas pela EAVM são excluídas por construção, pois não possuem par de chaves híbrido e portanto não conseguem assinar blocos.

A mainnet opera com sete Âncoras da fundação desde a altura 0 (uma produtora por VM, malha completa) e deve preencher rumo a 51 conforme operadores independentes se qualifiquem. Cada Âncora de lançamento usa owner frio M-de-N e witness quente separada; a witness assina bloco sem ganhar autoridade sobre governança, stake, comissão ou permissões do owner.

4.2 Regras de admissão de bloco

Um bloco é aceito somente se satisfizer, em ordem:

1. Integridade criptográfica — ambas as assinaturas verificam, o hash confere com o payload canônico.
2. height == head.height + 1 e previousHash == head.hash.
3. timestamp > head.timestamp.
4. Um bloco por slot: slot(bloco) > slot(head). Esta regra elimina o *slot grinding* — produzir múltiplos candidatos no mesmo slot para escolher o mais favorável.
5. txCount ≤ MAX_TXS_PER_BLOCK (500).
6. Slot não pertencente ao futuro além de SLOT_FUTURE_TOLERANCE_MS (400 ms) e deriva de relógio dentro de MAX_CLOCK_DRIFT_MS (2.000 ms).
7. Acima de STRICT_PRODUCER_HEIGHT, o produtor deve ser exatamente o produtor esperado do slot.
8. Acima de STATEROOT_HEIGHT, a raiz de estado recomputada deve bater com a declarada no cabeçalho.

A transição de estado é sempre simulada sobre um clone antes de ser comprometida, e a gravação em disco precede a mutação em memória.

4.3 Regra de escolha de cadeia e finalidade BFT

A regra base é cadeia mais longa, restringida por dois pisos de finalidade.

O piso dinâmico é derivado dos próprios produtores já presentes na cadeia: um bloco é considerado final quando pelo menos floor(2N/3) + 1 validadores distintos produziram blocos acima dele. Não existe subprotocolo de votação, mensagem de *precommit* nem rodada de consenso separada — a finalidade é lida da história. Reorganizações que tentem reverter altura finalizada são rejeitadas.

A finalidade é desativada quando o conjunto ativo tem menos de FINALITY_MIN_VALIDATORS = 3 validadores, pois abaixo disso um quórum de dois terços não oferece garantia significativa.

A profundidade de reorganização é adicionalmente limitada por REORG_WINDOW = 5.000 blocos.

4.4 Armazenamento e recuperação

Blocos são persistidos em blocks.jsonl, arquivo append-only com um objeto JSON por linha, indexado em memória por offsets[altura] = (byteOffset, tamanho) — acesso aleatório em O(1) por leitura posicionada, sem materializar o arquivo. Uma janela dos blocos recentes permanece em memória; blocos que saem da janela avançam um estado-base por reaplicação. O armazém lida com LINHAS e delega o parse ao formato de bloco, o que o mantém correto quando o formato mudar.

Dois modos de falha são tratados de forma diferente, de propósito. Um rasgo na última linha do arquivo — crash no meio de um append — é recuperável: o arquivo é truncado no início dessa linha e o nó sobe com um bloco a menos, ressincronizando pela rede. Corrupção no meio do arquivo não é reparada em silêncio, porque isso significaria subir um nó sobre uma história que ele não consegue provar.

Snapshots do estado completo são gravados a cada SNAPSHOT_INTERVAL_BLOCKS = 5.000 blocos. Um snapshot carregado só é aceito se a raiz de estado recomputada bater com a raiz comprometida pelo bloco correspondente. É uma garantia mais forte do que selar o arquivo com uma chave do operador: um snapshot bem-formado e falso reprova na conferência da raiz, ao passo que um MAC só prova que quem escreveu o arquivo tinha a chave.

5. Criptografia e Modelo Pós-Quântico

5.1 O esquema eav7-hybrid-1

A verificação é uma conjunção estrita: ambas as assinaturas devem ser válidas. Um objeto com apenas uma assinatura correta é rejeitado exatamente como um objeto sem assinatura alguma. Chaves trafegam em PEM (privada PKCS#8, pública SPKI) e assinaturas em base64.

Um adversário que quebre só o ECDSA não redireciona a eleição nem a produção de blocos sem também forjar a assinatura PQ: o protocolo exige as duas em todo objeto de consenso.

O custo dessa escolha é explícito e assumido: a assinatura ML-DSA-44 é substancialmente maior que a ECDSA. Por isso o modelo GB de lançamento exclui campos de assinatura dos bytes úteis medidos, em vez de tornar o custo dependente da assinatura híbrida grande e variável.

5.2 Formato de hash e endereço

Todo hash da EAV7 tem 64 caracteres: o prefixo literal E7 seguido de 62 caracteres hexadecimais maiúsculos, correspondentes aos 248 bits mais significativos do SHA3-256. O prefixo é marca de identidade do protocolo, não entropia.

Endereços têm 34 caracteres: E7 + 28 hexadecimais + 4 hexadecimais de checksum.

corpo     = SHA3-256( DER(chave_secp256k1) ‖ DER(chave_mldsa) )[0:14]   → 28 hex
checksum  = SHA3-256( "EAV7-ADDR:" ‖ corpo )[0:2]                       → 4 hex
endereço  = "E7" ‖ corpo ‖ checksum

O endereço deriva de ambas as chaves públicas concatenadas, o que amarra a identidade da conta ao par híbrido completo.

Limitação declarada. O corpo do endereço tem 14 bytes = 112 bits. A resistência a colisão de aniversário é, portanto, da ordem de 2⁵⁶ operações — abaixo do patamar de 2⁸⁰ hoje considerado confortável. Isto está registrado como achado residual na auditoria interna do projeto, com a observação de que alterá-lo invalida todos os endereços já emitidos. Ver Seção 14.

5.3 Separação de domínio

Digests de propósito específico são separados por prefixo de domínio e pelo separador \x1f (ASCII *unit separator*), impedindo que uma assinatura colhida em um contexto seja reaproveitada em outro:

• EAV7-BRIDGE-IN — liberação de ativo da ponte
• EAV7-BRIDGE-COMMITTEE — rotação de comitê da ponte
• EAV7-AI-ATTEST — atestação de resultado de IA
• EAV7-ADDR: — checksum de endereço

6. Estrutura de Dados e Compromisso de Estado

6.1 Cabeçalho de bloco

O núcleo assinado do bloco contém protocol, version, scheme, height, timestamp, previousHash, txRoot, txCount, producer, publicKey, pqPublicKey e — acima de STATEROOT_HEIGHT — stateRoot. Ficam fora do núcleo: signature, pqSignature, hash e transactions.

Acima de CANONICAL_HASH_HEIGHT, o hash do bloco é calculado somente sobre o payload, excluindo as assinaturas. Isso torna o identificador imune à maleabilidade de assinatura ECDSA, na qual um adversário reescreve s como n − s, produzindo assinatura igualmente válida e portanto identificador diferente para o mesmo bloco.

6.2 Transações

Uma transação carrega protocol, scheme, type, from, to, amount, fee, nonce, timestamp, data, as duas chaves públicas e as duas assinaturas. O identificador deriva exclusivamente do payload canônico assinado, nunca dos bytes de assinatura — mesma defesa anti-maleabilidade aplicada ao bloco.

O campo fee é um limite de taxa (teto de queima autorizado pelo remetente), não um pagamento, e é limitado por MAX_FEE_LIMIT = 100 EAV7. O nonce deve ser exatamente o corrente mais um.

O protocolo define 58 tipos de transação, cobrindo transferência, staking, votação, permissões e multiassinatura, tokens EAV20, NFTs EAV721, serviço de nomes, governança, tesouraria, vesting, meta-transações, EAVM, ponte e a camada de IA. A lista é fechada: um nó precisa rejeitar um tipo desconhecido em vez de ignorá-lo, porque aceitar um tipo que não sabe executar diverge o estado.

A serialização canônica reproduz a forma JSON byte a byte com que o assinante se comprometeu, incluindo escape de strings e formatação de inteiros. Valores em ponto flutuante são deliberadamente ausentes do campo data: reproduzir em outra linguagem a formatação de menor round-trip de um motor JavaScript é fonte de divergências de um dígito, que mudariam o payload, mudariam o identificador e fariam da transação outro objeto. Aplicações que precisam de fração a codificam como texto, que é o que o resto do protocolo já faz com valores monetários.

6.3 Modelo de estado e raiz de estado

O modelo é de contas (não UTXO), com valores monetários em inteiros de 128 bits na menor unidade, chamada e7 (1 EAV7 = 10⁶ e7). O estado é particionado em domínios: contas, tokens, NFTs, nomes, contratos, oráculos, atestadores de IA, tarefas de IA, votos, permissões, delegações, propostas de governança, tesouraria, slashing, unbonding, vesting, comissões e ponte.

A raiz de estado é uma árvore de Merkle de folhas ordenadas — explicitamente não uma Merkle-Patricia Trie:

folha = H( domínio ‖ \x1f ‖ chave ‖ \x1f ‖ serialização_canônica(valor) )
raiz  = merkleRoot( sort(folhas) )

Isso habilita provas de inclusão de conta para clientes leves. O caminho está implementado de ponta a ponta: o nó serve a prova de uma conta, e o eav7-sdk a verifica localmente contra uma raiz de estado retirada de um cabeçalho cuja integridade o próprio cliente conferiu. Um nó pode recusar-se a servir a prova — o que é detectável —, mas não consegue forjá-la.

Limitação de escala declarada. A raiz é recomputada sobre o estado inteiro a cada bloco — custo O(|estado|) por bloco. Uma estrutura incremental (árvore persistente, árvore de Merkle esparsa ou estado com cópia sob escrita) é trabalho reconhecido como necessário antes que a cadeia atinja tamanho de estado relevante. Ver Seção 13.

7. Modelo de Recursos e Taxas

A EAV7 não tem mercado de gás. Não há preço de gás, leilão de prioridade nem gorjeta ao produtor. O modelo é de recursos regenerativos com queima como mecanismo de excedente.

7.1 GB · Assinatura Livre

O modelo de lançamento tem uma barra diária, GB: 1.000.000.000 bytes ponderados por conta, mais 1.000.000 por EAV7 efetivo em stake. Ela regenera em 86.400 blocos (~24 h) e não acumula além da capacidade diária.

bytes_úteis       = bytes da transação serializada sem signature, pqSignature e id
bytes_ponderados  = max(GB_MIN_WEIGHTED, bytes_úteis × fator_do_tipo)
cota_diária       = 1.000.000.000 + 1.000.000 × EAV7_efetivo_em_stake
queima            = max(0, bytes_ponderados − cota_restante) × BURN_PER_BYTE

GB_MIN_WEIGHTED é 1.024 bytes. O fator do tipo reutiliza a tabela legada de custo de energia; BURN_PER_BYTE é 5 e7. O campo fee continua sendo limite de queima, não preço: se a queima calculada excedê-lo, a transação falha.

As assinaturas híbridas são excluídas dos bytes úteis. Essa regra de assinatura livre impede que a assinatura PQ, grande e variável, vire superfície de taxa e preserva a defesa contra maleabilidade; as chaves públicas continuam incluídas. Dentro da cota, a conta não queima nada. DELEGATE_RESOURCE / UNDELEGATE_RESOURCE continuam aumentando o stake efetivo de recurso do destinatário e, portanto, sua cota GB, sem transferir voto.

A contabilidade legada de energia e largura de banda continua abaixo de GB_FEE_HEIGHT. Na mainnet (GENESIS_ACTIVE / perfil de altura zero), o GB · Assinatura Livre aplica-se desde o gênese. Builds locais sem esse overlay podem ainda usar heights distantes.

7.2 Queima integral das taxas

Toda taxa cobrada é queimada. O validador produtor não recebe fração alguma das taxas; sua receita é exclusivamente a recompensa de bloco. É uma escolha econômica deliberada, com três consequências:

1. Pressão deflacionária proporcional ao uso. Quanto mais a rede é usada, mais supply é destruído.
2. Eliminação do incentivo a censura por taxa. Como o produtor não lucra com a taxa, não há incentivo para ordenar ou censurar transações com base nela.
3. Ausência de mercado de MEV por gorjeta. O protocolo não oferece canal de pagamento de prioridade ao produtor.

Além das taxas, são queimados: 90% das penalidades de slashing (10% vão ao denunciante) e o custo de registro de nomes no EAV-NS.

8. Staking, Validação e Governança

8.1 Stake e unbonding

Fazer stake move saldo de balance para staked, o que simultaneamente concede elegibilidade a validador, poder de voto e cota GB diária adicional.

O UNSTAKE remove o stake imediatamente — poder de voto e posição de validador são perdidos no ato —, mas os fundos entram em fila de unbonding por UNBONDING_BLOCKS = 604.800 blocos (≈ 7 dias), sendo creditados de volta pelo processamento determinístico de cada bloco. Uma conta mantém no máximo MAX_UNBONDING_ENTRIES = 32 entradas simultâneas.

Três travas protegem a integridade da rede: não é possível fazer unstake abaixo do total votado, nem abaixo do delegado a terceiros, nem esvaziar o conjunto de validadores — a última posição ativa não pode ser removida.

8.2 Votação e recompensa a eleitores

Detentores de EAV7 alocam poder de voto (igual ao stake) a candidatos, em até 30 alvos por transação. Voto em si mesmo é proibido, e só candidatos já elegíveis podem receber votos.

A recompensa de bloco é repartida na seguinte ordem: primeiro a fração de tesouraria (TREASURY_PCT, 0% por padrão, governável até 50%); em seguida, se o produtor recebeu votos, ele retém sua comissão (padrão 20%, ajustável por validador com atraso de COMMISSION_DELAY_BLOCKS = 21.600 blocos) e o restante é distribuído proporcionalmente aos eleitores por um acumulador de precisão fixa que torna o resgate O(1). Se o produtor não recebeu votos, retém a totalidade.

Na mainnet, a votação está ativa desde o gênese, de modo que a ordenação usa stake próprio mais votos desde o início. O conjunto ativo tem até 51 Âncoras; as 50 contas elegíveis seguintes formam o banco, que não vota nem produz até ser promovido.

8.3 Governança on-chain

Apenas Âncoras ativas podem propor e votar. Uma proposta é aprovada com `floor(2N/3) + 1` dos validadores ativos, entra em estado QUEUED e só é aplicada após GOV_TIMELOCK_BLOCKS (padrão 40.000 blocos, ~11 h).

No lançamento, GOV_PROPOSE e GOV_VOTE exigem a autoridade fria owner da conta Âncora, inclusive o limiar M-de-N. A witness quente produz bloco ou atesta, mas não pode autorizar governança. A governança não é ponderada por holders, não há conselho off-chain com poder de protocolo e nenhuma IA tem voto, veto, chave de assinatura ou autoridade de submissão. Um advisor de IA pode apenas redigir; uma Âncora autorizada pelo owner precisa adotar e assinar.

Sete parâmetros são governáveis dentro de limites rígidos codificados no protocolo:

Um trilho anti-brick reverte automaticamente qualquer alteração de MIN_VALIDATOR_STAKE ou MAX_VALIDATORS que resultaria em conjunto de validadores vazio, impedindo que a governança inutilize a rede por erro de parametrização.

8.4 Slashing

O protocolo implementa penalização por dupla assinatura: dois blocos válidos, mesmo produtor, mesma altura, hashes diferentes. A penalidade é 10% do valor em risco — stake ativo mais fundos em unbonding, fechando a fuga de fazer unstake após a ofensa —, da qual 10% vai ao denunciante e 90% é queimada. Um nulificador por ofensor:altura impede punição dupla pela mesma evidência, e as verificações baratas precedem as duas verificações híbridas caras para evitar amplificação de DoS.

Na mainnet, o slashing por dupla assinatura está ativo desde a altura 0. Builds locais sem o overlay GENESIS_ACTIVE podem ainda manter heights distantes.

9. EAVM — Máquina Virtual e Compatibilidade de Carteiras

A EAVM é a máquina virtual da EAV7. Ela executa bytecode EVM, contabiliza gás e indexa logs e recibos. Na mainnet, publicação, execução e transações EAVM com valor estão ativos desde o gênese.

Os precompilados 0x01–0x09 estão implementados, incluindo modexp, as operações da curva BN254 (ecAdd, ecMul, ecPairing) e blake2f, com o gás cobrado antes da execução para que uma entrada hostil não compre computação que não pagou. O gás é limitado a MAX_EAVM_GAS = 5.190.000 por transação; o tamanho de contrato é limitado a 24.576 bytes (EIP-170) e o calldata a 3.072 bytes.

A EAVM expõe um endpoint JSON-RPC que fala o dialeto que as carteiras do ecossistema Ethereum entendem. Chain ID 72020 na mainnet, 72021 na testnet pública. Como carteiras assumem 18 decimais e o protocolo usa 6, a conversão é feita pelo fator EAVM_WEI_PER_E7 = 10¹²; valores não divisíveis por 10¹² são rejeitados.

Um endereço 0x é mapeado deterministicamente para um endereço E7. Adicionalmente, o protocolo aceita um destino E7 codificado dentro do campo de 20 bytes da transação EVM, com o prefixo 0xe7000000 seguido dos 32 hexadecimais do corpo e checksum do endereço E7 — permitindo que uma carteira comum envie para um endereço nativo com o checksum validado on-chain.

9.1 Compatibilidade — declaração precisa

Consequência prática. Carteiras adicionam a rede, exibem saldos, enviam transferências e interagem com contratos publicados. Bibliotecas cliente conseguem ler estado de contrato e consultar eventos históricos. O que falta é acesso bruto ao storage, provas EIP-1186 e streaming por assinatura ou filtro, de modo que ferramentas dependentes de eth_subscribe ou de instalação de filtros precisam fazer polling em eth_getLogs. As transações nativas EAVM_DEPLOY e EAVM_CALL continuam disponíveis e são o caminho usado pelo ferramental do próprio protocolo.

Os limites de faixa e de resultados em eth_getLogs são deliberados: uma consulta sem teto varreria a cadeia a cada chamada, que é o vetor clássico de negação de serviço contra esse método.

9.2 Padrão de token EAV20

EAV20 é um contrato Solidity compatível com ERC-20 na EAVM. Os contratos oficiais imutáveis são publicados via EAV20Factory, embora o deploy EAVM comum continue permissionless. EAV20 é o contrato mínimo para tokens permissionless; EAV20Managed adiciona funções administrativas explícitas, como mint, burn, pause, blacklist e permit. As duas formas são nomeadas separadamente para que controles de gestão nunca fiquem escondidos sob um rótulo EAV20 genérico.

As transações nativas TOKEN_* permanecem um caminho legado de protocolo. Elas não são o caminho de produto EAV20 e não devem ser apresentadas como forma de criar um token EAV20.

10. Camada Nativa de Inteligência Artificial

10.1 A fronteira que não se cruza

Antes de descrever o que a IA faz na EAV7, é necessário estabelecer o que ela não pode fazer, porque essa é a propriedade de segurança central do projeto.

A EAV7 contém dois conjuntos disjuntos de componentes que a palavra "IA" poderia confundir:

(A) O protocolo de oráculos de IA — consenso puro. Tipos de transação, escrow, reputação, quórum, contestação, atestação. É estado de consenso determinístico, replicado e verificável por qualquer nó. Nenhum modelo de linguagem participa da validação: o que a cadeia verifica são assinaturas e concordância de hashes.

(B) A camada operacional de IA — zero poder de consenso. Sentinela de segurança, conselheiro de governança, score de validador, roteamento de leitura do gateway e bloqueio de IPs abusivos.

A doutrina aplicada a (B) é explícita e uniforme: a IA age sozinha apenas onde a ação é operacional e reversível; em tudo que toca consenso, validadores, stake, tesouraria ou código, ela apenas propõe.

Não existe caminho de código pelo qual qualquer componente de IA assine ou submeta uma transação. Um rascunho gerado pelo conselheiro precisa ser adotado por uma Âncora humana, autorizado pelo owner ou multisig de owner, submetido, aprovado por dois terços mais um da governança e ainda cumprir o timelock.

10.2 O protocolo de oráculos

O fluxo base: ORACLE_REGISTER (oráculo registra endpoint e trava stake ≥ 500 EAV7) → AI_TASK (solicitante deposita a recompensa em escrow) → AI_RESULT (oráculo entrega) → liquidação. A reputação de cada oráculo nasce em 50 e evolui on-chain: +4 por entrega bem-sucedida, −12 por resultado derrubado ou não entrega, −8 por comprometer e não revelar, +2/−4 para jurados conforme votem com ou contra a maioria.

Na mainnet, os cinco mecanismos-base de garantia estão ativos desde o gênese. A atestação TEE/ZK continua condicionada separadamente (AI_TEE_HEIGHT permanece distante):

Responsabilização. Não entregando dentro do prazo, o oráculo é penalizado em 10 EAV7 retirados de seu stake travado e creditados ao solicitante como compensação, além do reembolso integral da recompensa.

Quórum por commit-reveal. A tarefa pode exigir N oráculos independentes (2 a 21). Cada um publica primeiro H(saída ‖ salt) numa janela de compromisso de 30 minutos, e só depois revela. Isso impede que um oráculo copie a resposta de outro. Quando o quórum de revelações concordantes é atingido, a recompensa é dividida entre os concordantes; a minoria divergente perde reputação.

Verificação otimista com júri. Um resultado de oráculo único entra em janela de contestação de 30 minutos. Sem contestação, qualquer um pode acionar a liquidação. Contestado — mediante fiança de 20 EAV7 —, um júri de oráculos registrados vota, com partes interessadas explicitamente excluídas. Ao atingir 3 jurados, a maioria simples decide: mantido, o oráculo leva a recompensa mais a fiança do contestante; derrubado, o solicitante é reembolsado, o oráculo é penalizado e o contestante recupera a fiança acrescida do prêmio.

Leilão reverso. Uma tarefa pode ser aberta com orçamento. Oráculos dão lances de preço; o solicitante adjudica; o excedente do orçamento é devolvido. Tarefa aberta e não adjudicada é reembolsável após a expiração.

Resultados privados e verificáveis. O oráculo pode publicar apenas o resultHash e, opcionalmente, um URI, mantendo a saída fora da cadeia — cifrada para o solicitante em tarefas privadas. A verificação é H(saída) == resultHash. O prompt e os parâmetros de entrada são apagados do estado após a entrega, contendo o crescimento do estado.

10.3 Atestação por ambiente confiável

O mecanismo mais forte de aceitação dispensa reputação e janela de contestação. A governança registra um atestador — um conjunto de chaves públicas com um quórum e uma *measurement* que identifica o código atestado. Um resultado acompanhado de assinaturas suficientes desse conjunto sobre o digest

keccak256( "EAV7-AI-ATTEST" ‖ \x1f ‖ taskId ‖ \x1f ‖ resultHash ‖ \x1f ‖ attesterId ‖ \x1f ‖ measurement )

liquida imediatamente e é marcado on-chain como verificado. A *measurement* usada no digest é sempre a registrada em cadeia, nunca a fornecida pelo remetente — é isso que amarra a assinatura à identidade do código atestado. A contagem de assinaturas deduplica por endereço recuperado e limita as recuperações de curva ao tamanho do conjunto, impedindo tanto inflação por maleabilidade quanto negação de serviço criptográfica.

Declaração precisa do modelo de confiança. A EAV7 verifica on-chain apenas assinaturas secp256k1 de um conjunto previamente registrado pela governança. Não existe no protocolo nenhum código de SGX, SEV-SNP, TDX ou Nitro, e nenhum parsing de *quote* DCAP. A verificação da atestação remota do enclave é feita off-chain, uma única vez, no momento do registro, pelo operador e pelos validadores que aprovam a proposta de governança. Do ponto de vista da cadeia, a *measurement* é uma string opaca.

>

Pela mesma razão, o tipo de atestador ZK é aceito e verificado de forma idêntica ao tipo TEE — por assinatura de um verificador registrado. A camada de IA não verifica provas SNARK nativamente. A EAVM expõe os precompilados de pareamento BN254, de modo que um verificador publicado como contrato é tecnicamente possível; ligar esse caminho à liquidação de tarefas é trabalho futuro, não capacidade presente.

11. Ponte Cross-Chain

11.1 Mecanismo

A ponte opera por *lock-and-release*. BRIDGE_OUT trava o ativo nativo ou o token na cadeia de origem, registrando o destino. BRIDGE_IN libera na cadeia de destino mediante prova.

A autoridade de liberação evolui em três eras, cada uma ativada por altura:

No modelo final, a autorização de relayer permanece apenas como controle anti-spam — não é mais a autoridade de cunhagem. O digest amarra todos os campos do evento:

keccak256( "EAV7-BRIDGE-IN" ‖ \x1f ‖ CADEIA ‖ \x1f ‖ txHashOrigem ‖ \x1f ‖ destino ‖ \x1f ‖ valor ‖ \x1f ‖ token )

Uma assinatura colhida para liberar 5 EAV7 não pode liberar 500: o valor está no digest.

A proteção contra replay separa a chave de replay (CADEIA:txHash) da chave de atestação (que inclui destino, valor e token). Essa separação tem uma consequência importante: um relayer malicioso que atestar valores incorretos forma um grupo próprio que nunca atinge quórum, sem bloquear o quórum honesto sobre o valor correto.

11.2 Rotação de comitê e o trilho anti-captura

O comitê da cadeia de origem rotaciona por *handoff* assinado: o comitê atual assina a transição para o novo conjunto e época, e as assinaturas precisam atingir o quórum vigente.

Uma propriedade de segurança merece destaque: a governança da EAV7 não pode substituir um comitê ativo. Uma proposta de governança só é capaz de *criar* um comitê quando nenhum existe para aquela cadeia (bootstrap). A razão é direta — sem esse trilho, dois terços dos validadores da EAV7 poderiam trocar o comitê por chaves próprias e drenar a ponte. Trocar um comitê em operação exige o handoff assinado pela origem.

11.3 Disjuntor de velocidade

Um limite determinístico de velocidade complementa o modelo: a soma das liberações de um mesmo ativo dentro de uma janela deslizante de 3.600 blocos (~1 h) não pode exceder uma fração do pool medido no início da janela — padrão 30%, governável entre 1% e 100%. Excedido, a liberação é rejeitada (falha fechada). Cada token possui orçamento independente.

O propósito é converter um cenário de dreno total — comitê ou relayer comprometido — em um vazamento lento e observável. Uma ponte pública com valor econômico exige disjuntor ativo no gênese, comitê de pelo menos três membros, adaptador real, política de confirmações e processo de pausa. Até essas condições serem atendidas, a ponte fica condicionada ou desligada na interface.

11.4 Declaração honesta do modelo de confiança

A ponte não é um light client. A especificação interna de uma ponte com relay de cabeçalhos, prova de inclusão de Merkle e profundidade mínima de confirmação existe, mas está marcada como proposta, não implementada. O que foi construído tem o comitê assinando o digest do evento diretamente, sem cabeçalho, sem prova de Merkle e sem verificação de profundidade de confirmação. A denominação correta é ponte atestada por comitê, não ponte trustless.

A confiança foi deslocada, não eliminada. Ela migrou do conjunto de relayers para o conjunto de chaves do comitê da cadeia de origem, o que é melhoria real e substancial. Mas um comitê comprometido em quórum ainda consegue cunhar, limitado apenas pelo disjuntor.

A ponte não custodia valor econômico na mainnet por padrão. O protocolo define uma interface de adaptador e é agnóstico à cadeia por construção. Um adaptador real, comitê constituído, disjuntor ativo e checklist operacional são pré-requisitos para custodiar valor; adaptador de *loopback* é somente teste. Light client continua roadmap.

12. Tokenomics

12.1 Parâmetros fundamentais

A emissão é geometricamente decrescente e converge para zero após 64 halvings. Como toda taxa é queimada, o supply em circulação é gênese + emitido − queimado, e sob volume de transações suficiente a queima supera a emissão, tornando a rede líquida deflacionária.

12.2 Distribuição do gênese

A distribuição do gênese prioriza o mercado aberto: a parcela pública é 45%, com Fundação/Tesouraria em 30,25%, venda privada em 14,75% e parceiro estratégico em 10%.

A parcela sob controle de insiders (Fundação, venda privada e parceiro) soma 55,00%.

Custódia e entrega (mainnet)

Os buckets não nascem numa carteira operacional única. No gênese ao vivo, a custódia dia 1 usa os endereços publicados abaixo. PublicVault e TimelockLpSeeder estão implantados na mainnet; SaleVault / PartnerTrancheVault permanecem o caminho de produto pretendido para os buckets privado e parceiro até esses vaults entrarem em produção.

Preço da venda privada no produto: patamares por USD arrecadado (ex.: Launch $0,005 → … → Last call $0,015), com preço travado no intent. A escassez de tier conta apenas intents paid/granted (pedidos pending não empurram o preço).

Vesting on-contract (produto). Nos vaults de venda, após o cliff a liberação é linear sobre (duration − cliff), não um lump no instante do cliff. O schedule da fundação na mainnet, porém, é o de 12 partes acima (cliff == duration por tramo).

Ponte no gênese. bridgeRelayers nasce vazio. As Âncoras de lançamento não são comitê de ponte no dia 1; mesmo com heights de ponte em 0 no overlay GENESIS_ACTIVE, a ponte econômica permanece condicionada até adaptador real, comitê e checklist operacional.

Nomes no gênese. Nomes EAV-NS das Âncoras foram re-registrados no dia 0; registro de oráculo de IA está disponível (stake mínimo 500 EAV7).

Sobre builds locais. Builds locais ainda podem usar um gerador que concentra supply numa única carteira para desenvolvimento. A mainnet materializou o fragmento de buckets (§12.2) com sete Âncoras e o schedule de vesting da fundação descritos acima. Ver Seção 13.

Sobre o vesting. Todo bucket não público tem cliff mínimo de 12 meses (ou equivalente em tranches com cooldown de 12 meses, no caso do parceiro), salvo a fração líquida de 1/12 da fundação no dia 1.

12.3 Tesouraria

O protocolo suporta direcionar uma fração da recompensa de bloco à tesouraria on-chain, mas o parâmetro nasce em 0%. Habilitá-lo requer proposta de governança aprovada por dois terços mais um dos validadores e sujeita a timelock, com teto codificado de 50%. Gastos da tesouraria são igualmente feitos por governança.

13. Estado de Maturidade

Esta seção existe para que nenhum leitor precise inferir o que está pronto. A classificação é conservadora por escolha, e vale para agosto de 2026.

13.1 Postura atual

A EAV7 está em mainnet ao vivo. O cliente Rust é o cliente de produção: a biblioteca de consenso, o nó completo e o binário de operador eav7-core compilam e rodam em Linux, macOS e Windows, com releases por tag publicando arquivos e digests SHA-256 para Linux x64, Linux arm64, macOS arm64 e Windows x64. A integração contínua roda no GitHub Actions sobre o workspace, e os vetores de conformidade em vectors/ fixam serialização canônica, criptografia, folhas de estado, raízes de estado e comportamento da EAVM.

O código-fonte é público em github.com/eav7-sys/eav7 sob licença MIT. O explorador público está em eavscan.com. Hash de gênese: 7aa09afcd542e6ec8fd4b977658ed522143991f20a8ce48aab8aca9aeb80e5fb. Sete Âncoras da fundação produzem desde a altura 0 (uma produtora por VM, malha completa). O perfil GENESIS_ACTIVE / heights zero é o perfil da mainnet ao vivo.

Cobertura de testes. Aproximadamente 1.000 funções de teste em 68 arquivos do workspace Rust, incluindo determinismo por replay de uma cadeia com múltiplos validadores e conformidade contra os vetores congelados.

13.2 Ativo na mainnet desde a altura 0

Na mainnet estão ativos desde o gênese: rodízio DPoS e finalidade BFT · produtor estrito, raiz de estado e slashing por dupla assinatura · assinaturas híbridas e identificadores imunes a maleabilidade · contabilidade GB · Assinatura Livre com delegação · staking, unbonding, votação, permissões v2 e governança de Âncora autorizada por owner (GOVERNANCE_HEIGHT=0) · tesouraria, vesting e meta-transações · execução EAVM com valor · fases-base de oráculos de IA (AI_ACCOUNTABILITY / QUORUM / CHALLENGE / MARKET / PRIVATE = 0) · nomes EAV-NS (incluindo re-registro das Âncoras no dia 0) · armazenamento resiliente · e modos do eav7-core, inclusive ancora-init.

PublicVault e TimelockLpSeeder estão ao vivo na mainnet (endereços na Seção 12.2); o marketing público do LBP permanece condicionado operacionalmente até o anúncio de TGE. SaleVault, PartnerTrancheVault e EAV20Factory permanecem o caminho pretendido para os demais buckets; até a implantação desses, a custódia dia 1 usa os endereços publicados na Seção 12.2. GENESIS_ACTIVE e heights zero descrevem a mainnet; builds locais sem esse overlay podem ainda usar heights distantes.

13.3 Condicionado operacionalmente e roadmap

Heights de fork são dados de consenso. O binário de mainnet confere seu modo de gênese contra o ambiente e recusa divergência.

13.4 Postura de descentralização

O conjunto ativo na mainnet é de sete Âncoras operadas pela fundação, produzindo desde a altura 0, até que operadores externos ocupem rumo aos 51 assentos ativos. Rodízio, voto, banco de 50 e ferramental existem, mas é a distribuição de stake que lhes dá sentido. As Âncoras não nascem como bridgeRelayers.

As metas incluem pelo menos dez Cores ouvintes externos, quinze candidatas com stake próprio no top 101 e maioria do conjunto ativo fora do grupo fundador. O teto ativo é 51; elevá-lo rumo ao teto governável de 101 exige conjunto preenchido, independente e desempenho PQ de finalidade medido.

13.5 Roadmap — não implementado ou fora do escopo de produto

• Raiz de estado incremental. O custo atual é O(|estado|) por bloco. Substituí-la por árvore persistente, árvore de Merkle esparsa ou estado com cópia sob escrita é pré-requisito para escala de estado relevante.
• Superfície JSON-RPC restante. eth_getStorageAt, eth_getProof, eth_subscribe e métodos de filtro.
• Adaptadores de cadeia da ponte. Nenhum adaptador de produção existe; o primeiro alvo especificado é uma cadeia externa com comitê de validadores assinado (tipicamente EVM L1).
• Ponte com light client. Relay de cabeçalhos, prova de inclusão de Merkle e profundidade mínima de confirmação.
• Verificação nativa de SNARK na camada de IA. Os precompilados da EAVM tornam viável um verificador em contrato; o caminho de liquidação não usa nenhum.
• P2P autenticado. O transporte atual é HTTP simples atrás de proxies geridos pelo operador.
• Compactação do formato de bloco. Material de chave em base64/PEM em todo bloco é caro em disco para o operador; um formato binário com referência de chave pública é um fork planejado.
• Infraestrutura pública de seeds. Seeds DNS estáveis e snapshots de bootstrap verificáveis, para que um operador novo não precise sincronizar desde o gênese.
• Carteira móvel de eleitor. Stake e voto pelo celular; a produção de blocos continua no Core.
• EAV721 como produto. O protocolo de nomes EAV-NS existe na mainnet (incluindo nomes das Âncoras); EAV721 permanece roadmap de produto/explorador e não faz parte da promessa EAV20.
• Auditoria externa independente. Ver Seção 14.

14. Fatores de Risco

Os riscos abaixo são materiais e devem ser lidos por qualquer pessoa que considere adquirir, custodiar ou construir sobre EAV7.

14.1 Risco regulatório — o mais relevante deste documento

A distribuição pública descrita na Seção 12.2 é uma venda de tokens ao público. Uma oferta dessa natureza tem alta probabilidade de ser caracterizada como oferta pública de valor mobiliário sob a legislação brasileira, sujeita à competência da Comissão de Valores Mobiliários, e sob a legislação dos Estados Unidos pelo teste de Howey. Não é hipótese remota: a SEC dos Estados Unidos já ajuizou ações contra emissores de tokens envolvendo, entre outras alegações, oferta e venda não registrada.

As consequências potenciais incluem exigência de registro prévio, restrição de jurisdições elegíveis, obrigações de verificação de identidade e origem de recursos, responsabilização pessoal dos administradores e nulidade das ofertas realizadas.

Nenhum conteúdo deste whitepaper substitui aconselhamento jurídico especializado, que deve ser obtido antes de qualquer captação.

14.2 Risco de centralização no lançamento

A mainnet opera com um conjunto de validadores de sete Âncoras operadas pela fundação (Seção 13.4), rumo a 51. Com N = 7, o quórum de finalidade BFT é 5; a indisponibilidade de operadores ainda degrada a rede, e um conjunto tão pequeno não oferece resistência significativa a conluio, coerção ou falha correlacionada de infraestrutura. A entidade que o opera pode, na prática, determinar a produção de blocos.

A EAV7 não é hoje uma rede descentralizada. A descentralização progressiva é objetivo declarado, com critérios de sucesso definidos, mas é objetivo, não estado presente, e o leitor deve tratar decisões de governança na rede atual como decisões do operador fundador.

O slashing por dupla assinatura está ativo desde a altura 0 (Seção 13.2): a ofensa é economicamente punida na mainnet.

14.3 Risco da ponte

A ponte não deve custodiar valor economicamente relevante até haver adaptador real, comitê de origem de pelo menos três membros, disjuntor ativo e procedimentos de confirmação e pausa testados. Um relayer único ou *loopback* serve somente para demo e teste.

14.4 Riscos criptográficos e estruturais

Espaço de endereços de 112 bits. O corpo do endereço tem 14 bytes, oferecendo resistência a colisão de aniversário da ordem de 2⁵⁶ operações — abaixo do patamar de 2⁸⁰ hoje considerado confortável. Corrigir invalidaria todos os endereços já emitidos.

Construção da árvore de Merkle. A árvore de transações duplica o último nó quando o número de folhas é ímpar e não aplica separação de domínio entre folha e nó interno. Essa construção é conhecida por permitir, em certos protocolos, que conjuntos distintos de transações produzam a mesma raiz. O impacto na EAV7 é limitado pelo fato de o identificador de transação derivar do payload assinado, mas a construção não é a mais robusta disponível.

ML-DSA é um padrão recente. O ML-DSA foi padronizado em 2024 e tem histórico de criptanálise pública substancialmente menor que o do ECDSA. A escolha híbrida existe precisamente para que uma falha em qualquer um dos dois esquemas não seja fatal — mas isso é mitigação, não garantia.

14.5 Risco de auditoria

O protocolo passou por múltiplas rodadas de revisão adversarial conduzidas internamente com assistência de modelos de linguagem, que identificaram e levaram à correção de vulnerabilidades relevantes — incluindo manipulação de slot de consenso, dreno da ponte, roubo de escrow da camada de IA, maleabilidade de hash de bloco, requisição forjada a partir do servidor por endereços de par não canônicos e negação de serviço por precompilados sem medição de gás e por consultas de log sem teto. As correções estão cobertas por testes de regressão.

Nenhuma firma de auditoria externa e independente revisou este código. Revisão interna, por mais rigorosa, não substitui avaliação adversarial independente, e este é risco material para qualquer valor custodiado na rede.

14.6 Riscos operacionais e de escala

A recomputação da raiz de estado é O(|estado|) por bloco. Conforme o estado cresce, o custo por bloco cresce proporcionalmente, e existe um ponto em que a produção a cada segundo deixa de ser sustentável. Esse limite não foi caracterizado empiricamente.

O transporte P2P é HTTP não autenticado e depende de proxies ou túneis geridos pelo operador para confidencialidade e controle de acesso. Um operador que exponha a API administrativa sem um token forte expõe o nó.

A camada de IA operacional depende de serviços externos quando configurada para tal; a indisponibilidade desses serviços degrada monitoramento, jamais consenso.

15. Aviso Legal

Este documento é fornecido exclusivamente para fins informativos e técnicos. Não constitui, e não deve ser interpretado como, oferta de venda, solicitação de oferta de compra, recomendação de investimento, aconselhamento jurídico, tributário, contábil ou financeiro, nem prospecto ou documento de oferta sob qualquer legislação.

Declarações prospectivas. Este whitepaper contém declarações sobre planos, roadmap, funcionalidades futuras e resultados pretendidos. Tais declarações refletem expectativas na data de publicação e envolvem riscos e incertezas conhecidos e desconhecidos. Os resultados efetivos podem diferir materialmente. Nenhuma obrigação de atualização é assumida.

Ausência de garantias. O software é fornecido "no estado em que se encontra", sem garantia de qualquer natureza, expressa ou implícita, incluindo garantias de comercialização, adequação a finalidade específica, disponibilidade, segurança ou ausência de defeitos. Nenhuma auditoria externa independente foi realizada sobre o código descrito.

Risco de perda total. Ativos digitais são de alto risco e alta volatilidade. O valor do EAV7 pode cair a zero. Falhas de software, exploração de vulnerabilidades, perda de chaves privadas, ação regulatória ou descontinuação do projeto podem resultar em perda total e irreversível. Não adquira EAV7 com recursos cuja perda integral comprometa sua situação financeira.

Restrições jurisdicionais. A aquisição ou detenção de ativos digitais é restrita ou proibida em determinadas jurisdições. É responsabilidade exclusiva do leitor verificar a legalidade de sua participação sob a legislação que lhe é aplicável.

Apêndice A — Parâmetros de Consenso

Os valores são os declarados em rust/src/config.rs, fonte canônica dos parâmetros de consenso.

A.1 Protocolo e consenso

A.2 Execução, recursos e rede

A.3 Camada de IA e ponte

A.4 Alturas ativas na mainnet

Estas são as alturas do perfil GENESIS_ACTIVE / altura zero da mainnet ao vivo. Builds locais sem esse overlay podem ainda usar heights distantes. A ponte econômica permanece condicionada operacionalmente mesmo com heights de ponte em 0 (ver Seção 13.3).

*EAV7 · Whitepaper Técnico v1.0.1 · 15 de agosto de 2026*