# BEYUL Whitepaper — Pre-Testnet Edition: Arquitetura e modelo de divulgação

> **Esta é uma tradução. A versão em inglês é a versão canônica (canonical) e prevalece em caso de conflito.** Os identificadores técnicos (BEYUL, BYL, `privacychain`, TDC, ADC, nullifier, commitment, viewing key, shielded pool, Groth16, etc.) permanecem sem tradução, em inglês.

**Projeto:** BEYUL　**Tipo:** protótipo de pesquisa de uma cadeia pública com privacidade (pre-testnet). O trabalho de protocolo da BEYUL é atualmente desenvolvido no repositório `privacychain`.
**Status do documento:** whitepaper da BEYUL, **edição pre-testnet (de pesquisa)** — descreve a arquitetura do protocolo, o modelo de divulgação e os limites atuais antes do testnet público. **Não** é uma especificação de protocolo de produção, nem documento de investimento, nem parecer de conformidade, nem auditoria de segurança, nem material de emissão de tokens, nem anúncio de mainnet. As afirmações de capacidade seguem a disciplina de evidência de §3.1; nada aqui é descrito acima de sua maturidade real.
**Status do token:** a tokenomics não é definitiva. **BYL** é apenas a forma curta / o ticker do projeto; **não** é uma denominação congelada — a denominação e os parâmetros da cadeia permanecem pendentes de aprovação explícita do Owner. Este documento não define alocação de tokens nem desenho de utilidade. Tokens de testnet, se usados, não têm valor monetário nem conversão prometida para mainnet.
**Idioma canônico:** a versão em inglês é a única versão canônica. A versão em chinês (`beyul-whitepaper-pretestnet.zh.md`) é um texto de trabalho acompanhante; em caso de conflito, esta versão em inglês prevalece.

---

## Caixa de limites de afirmações (leia primeiro)

Este documento **não** faz nenhuma das seguintes afirmações:

- Nenhuma afirmação de anonimato, não rastreabilidade ou "segurança absoluta";
- Nenhuma afirmação de segurança zero-knowledge de produção (a implementação atual usa material de development-key);
- Nenhuma afirmação de privacidade de produção (os valores de depósito e saque são atualmente públicos on-chain);
- Nenhuma afirmação de aprovação regulatória ou "compliance by design";
- O desenho atual não inclui uma viewing key global controlada pelo projeto; esta propriedade deve ser verificada por implementação aberta, testes e auditoria externa;
- Não existem testnet público nem mainnet; **a preparação do testnet está em andamento — o runbook multinó e os gates relacionados ainda não estão completos**;
- Nenhuma promessa de valor do token, airdrops, rendimento, retornos ou listagens em exchanges; este documento não trata de produtos de wallet nem DeFi;
- O 16-character disclosure code não é uma credencial criptográfica de segurança subjacente (Seção 7).

**Nomenclatura e identificadores técnicos.** BEYUL é o nome do projeto/produto; o trabalho de protocolo da BEYUL é atualmente desenvolvido no repositório `privacychain`. `privacychain` continua sendo o identificador técnico atual — repositório, pacote de protocolo/módulo/proto, binário e chain-id — e é mantido inalterado. **BYL** é a forma curta / o ticker; a denominação e os parâmetros da cadeia permanecem pendentes de aprovação explícita do Owner, portanto BYL não é uma denominação congelada. Esta disciplina de nomenclatura é apenas prospectiva: documentos históricos não são renomeados retroativamente.

---

## 1. Resumo

BEYUL é um projeto de cadeia pública com privacidade em **estágio de protótipo de pesquisa (pre-testnet)** que explora infraestrutura de pagamentos com **privacidade por padrão (um objetivo de design)** e divulgação controlada pelo usuário. No design-alvo, os detalhes da transação não são publicamente visíveis por padrão, mas o proprietário do ativo pode divulgar voluntariamente, com escopo limitado, a uma parte escolhida — um Transaction Disclosure Code (TDC) explica uma única transação; um Asset Disclosure Code (ADC) divulga um snapshot de ativos selecionado. "Privacidade por padrão" descreve o objetivo de design, não o protótipo atual (veja §5).

**O que existe hoje é apenas um protótipo de derivação de disclosure-code do lado do cliente** (testado localmente; o pacote de evidência pública está pendente de consolidação) e um protótipo de chain-application baseado em Cosmos SDK. Os grants do lado do servidor de ponta a ponta, a verificação on-chain e as ZK balance proofs não estão implementados; não há trusted setup, nem auditoria externa, nem testnet público nem mainnet; os valores de depósito e saque são atualmente públicos on-chain. O propósito deste whitepaper (edição pre-testnet) é registrar com exatidão a direção arquitetônica, o modelo de divulgação e os limites atuais antes do lançamento do testnet público — e ser substituído por uma edição de produção apenas quando a evidência e as auditorias correspondentes existirem.

## 2. Posicionamento e problema

Ledgers públicos expõem relações de pagamento, saldos e fluxos de fundos a qualquer observador; enquanto isso, a maioria dos sistemas de forte privacidade torna a divulgação *seletiva* operacionalmente difícil — explicar uma transação a uma parte muitas vezes significa entregar a capacidade de ver tudo. A lacuna que a BEYUL explora: tornar a "divulgação" um primitivo de primeira classe no mesmo nível do "ocultamento", com toda divulgação iniciada pelo usuário.

BEYUL não compete por — nem mira — uma narrativa de "totalmente anônimo, não rastreável".

**Visão.** A privacidade financeira em ledgers públicos está invertida: nua por padrão, enquanto o ocultamento em si parece suspeito. O objetivo da BEYUL é inverter esse padrão — privacidade como estado padrão, e divulgação como escolha deliberada e granular do usuário: qual transação, quais campos, para quem e por quanto tempo.

**Princípios de design.** Cada parte do protocolo é mantida a estes:

1. **A divulgação é um cidadão de primeira classe** — os primitivos de divulgação são projetados e prototipados no mesmo nível dos primitivos de ocultamento.
2. **Autoridade mínima** — cada chave e credencial carrega apenas a autoridade mínima que seu propósito exige.
3. **A spend authority é sacrossanta** — nenhum fluxo de divulgação pode tocar a spend authority; a mnemônica nunca entra em nenhuma etapa de divulgação.
4. **Sem privilégio global** — o protocolo é **projetado para não fornecer** nenhum canal de visualização global ao projeto ou a terceiros; a ausência de qualquer ramo desse tipo é uma **propriedade de design a ser verificada por implementação aberta, testes e auditoria externa (§6)**, ainda não uma garantia.
5. **Honestidade de limites** — cada capacidade declara o que não faz; o threat model e as limitações permanecem públicos.
6. **Evidência primeiro** — afirmações de capacidade são elevadas apenas após a existência de evidência (código, testes, auditorias) — baseado em gates, sem promessas de data.

### 2.1 Como a divulgação da BEYUL se compara

> A tabela compara o **design-alvo** da BEYUL com as **capacidades atuais e entregues** de outros sistemas. Os diferenciais da BEYUL abaixo (expiração, revogação, visibilidade imposta por consenso, escopo por-transação/por-snapshot com verificação de servidor e on-chain) são em grande parte **planejados ou protótipo do lado do cliente** (veja §3, §7), ainda não entregues. Fatos sobre concorrentes são expostos de forma conservadora; pontos não reverificados de forma independente para este whitepaper são marcados com **【to verify】**.

| Sistema | Mecanismo de divulgação | Granularidade | Expirável / revogável | Visibilidade imposta por |
|---|---|---|---|---|
| Zcash (Sapling/Orchard) | Full viewing key (FVK/IVK) | No nível da conta, tudo-ou-nada | Não | A visibilidade de saída depende de uma convenção de wallet (ciphertext cifrado com ovk), não do consenso |
| Monero | View key | No nível da conta (entrada) | Não | Wallet / protocolo; sem primitivo limitado por-transação |
| Misturadores estilo Tornado | Nenhum nativo (ferramentas externas, p. ex. provas de associação/exclusão) | — | — | — |
| Penumbra | Viewing keys em camadas (FVK/IVK/OVK) + detection key por-endereço (FMD / S-FMD) | Viewing keys no nível da conta; detection key = **descoberta do destinatário** (apenas ligação, sem conteúdo), delegável por-endereço | Não indicado na documentação 【to verify】 | Delegação criptográfica de chaves (cliente/wallet), não consenso |
| Aztec | Viewing keys de entrada/saída + **master**; **note discovery baseado em tagging** (não FMD); logs cifrados | Master viewing key **tudo-ou-nada em todos os contratos**; divulgação limitada/temporária apenas via camada de aplicação (Noir), não nativa do protocolo | Apenas como "temporary view access" no nível da aplicação, não nativo 【to verify】 | Lógica de app/contrato + cliente (PXE), não o consenso base |
| Namada (MASP) | Shielded viewing key (zvknam), multi-ativo derivado de Sapling | **No nível da conta** (saldo e histórico de entrada+saída de uma shielded account); "divulgação seletiva" = compartilhar a viewing key (conta inteira), não por-transação | Viewing key compartilhada não revogável nativamente (semântica precisa 【to verify】) | Viewing key (wallet/cliente) |
| **BEYUL (design-alvo)** | **TDC** (por-transação) + **ADC** (por-snapshot de ativo), **em camadas** (ADC L1/L2) | Por-transação / por-snapshot; campos limitados; papéis de emissor/destinatário separados | **Expiração + revogação (planejado)** | **Limite de visibilidade imposto por consenso (requisito de design, §6); dois fatores + somente leitura** |

O diferencial pretendido não é "ocultar mais forte", mas **divulgação mais granular, limitada no tempo e emitida pelo usuário**: onde uma viewing key de Zcash/Monero é uma concessão de leitura no nível da conta, tudo-ou-nada e indefinida, uma credencial de divulgação da BEYUL é limitada a uma transação (TDC) ou um snapshot de ativo (ADC), carrega uma expiração e é projetada para ser revogável — com o conjunto de campos visíveis imposto pelo consenso em vez de por uma convenção de wallet. Essas propriedades são objetivos de design; seu status de implementação é rastreado honestamente em §3 e §7.

> **Fontes.** Zcash/Monero: o relatório de pesquisa aprofundada ZEC/XMR deste projeto (fontes primárias — Zcash Protocol Specification; documentação da Monero; em 2026-06-12). As linhas de Penumbra / Aztec / Namada descrevem a **documentação oficial de cada projeto em 2026-06** (Penumbra: protocol.penumbra.zone — viewing keys, FMD; Aztec: docs.aztec.network — keys, note discovery; Namada: docs.namada.net — shielded accounts). Os pontos 【to verify】 restantes — expiração/revogação e semântica de transaction-perspective da Penumbra, expiração/revogação nativa da Aztec, semântica precisa de revogação da Namada — ficam pendentes de confirmação. Essas linhas expõem o que a documentação de cada projeto descreve, não afirmações sobre o que outros sistemas "não conseguem fazer".

## 3. Status atual

| Área | Status | Notas |
|---|---|---|
| Chain-application | Protótipo | Cosmos SDK / Ignite |
| Modelo de consenso / validador | Design de testnet | CometBFT BFT com um conjunto inicial de validadores estilo PoS e módulo de staking; não PoW; não segurança econômica PoS de nível mainnet |
| Shielded module | Protótipo | Depósito, saque, spend, registro de viewing-key, divulgação de note |
| Commitments / Merkle tree / nullifiers | Protótipo | Comportamento determinístico e rejeição de double-spend cobertos por testes |
| Stack de chaves de cliente disclosure-code (derivação TDC/ADC) | Protótipo, testado localmente | **Pacote de evidência pública (commit/CI) pendente de consolidação** |
| Stack de grants de servidor / verificação de divulgação on-chain / ZK balance proof | Não implementado | Planejado |
| Separação de view-key entrada/saída / audit key / expiração e revogação de divulgação **impostas por servidor/consenso** | Não implementado | Planejado |
| Trusted setup / auditoria externa | Não concluído / não iniciado | Pré-requisitos para qualquer afirmação de produção |
| Testnet público / mainnet | Não implantado | **Preparação do testnet em andamento: runbook multinó e gates relacionados ainda não completos** |
| Wallet oficial | Não existe | Apenas ferramentas de desenvolvimento e teste; qualquer "wallet oficial" é falsificação |
| Economia do token | Não definitiva | Este documento não contém design de token |

### 3.1 Cadeia de evidência

Cada linha "protótipo implementado" acima está vinculada a um registro de evidência — não afirmada em prosa. A cadeia de evidência (commit hash, registro de CI, comando de teste e saída exatos, instruções de execução reproduzíveis) é mantida no **Evidence Appendix**, e cada capacidade é classificada em uma escala de maturidade de pesquisa **L0–L5** (design → protótipo → reproduzível → revisado → evidência de rede → produção). Este whitepaper referencia esse registro em vez de reexpor a evidência bruta.

| Capacidade | Maturidade | Vínculo de evidência |
|---|---|---|
| Núcleo de cliente disclosure-code (derivação TDC/ADC, dois fatores, separação de domínio, AEAD/AAD, erasure keys) | L1–L2 | Reproduzido em somente leitura 2026-06-19: **13/13** testes locais passam; commit registrado no Evidence Appendix E1; CI **【to be supplied】** |
| Shielded module (commitment/nullifier/Merkle, rejeição de double-spend) | L1 | Reproduzido em somente leitura 2026-06-19: testes de double-spend e nullifier passam; Evidence Appendix E3; CI **【to be supplied】** |
| Caminho de spend Groth16 | L1 (dev-key) | VK dev/skeleton, sem trusted setup; testes de dev-path + production-VK-guard reproduzidos 2026-06-19; Evidence Appendix E4 |
| Stack de grants de servidor / verificação on-chain / ZK balance proof | L0 (planejado) | Não implementado; veja Roadmap §10 |

> Autoavaliação atual: a maior parte do material está em **L1–L2**, nada em L5. Até que as entradas do Evidence Appendix sejam preenchidas (commit/CI), os materiais públicos dizem "verificado localmente; pacote de evidência pública pendente de consolidação", não "implementado com evidência pública". Uma capacidade sem registro de evidência registrado não pode ser descrita acima de seu nível de maturidade. O Evidence Appendix está em `docs/evidence-appendix.md` (interno; a ser publicado com o pacote de evidência pública); E1/E3/E4 foram reproduzidos em somente leitura em 2026-06-19, com o vínculo de CI ainda pendente.

## 4. Modelo técnico

O protótipo gira em torno de uma máquina de estados de shielded pool. Para um não-criptógrafo, o ciclo de vida de um saldo privado ocorre assim:

1. **Note.** Um saldo gastável é uma *note* — um registro de (proprietário, valor, aleatoriedade). A note em si nunca aparece on-chain.
2. **Commitment.** A cadeia armazena apenas um *commitment* sobre a note (um hash de ligação unidirecional), anexado a uma **Merkle commitment tree** somente-anexação. A partir do commitment sozinho, um observador não aprende nem proprietário nem valor.
3. **Spend → nullifier.** Para gastar uma note, o proprietário publica um *nullifier* derivado dela. O nullifier é **projetado para não ser vinculável** ao commitment por observadores externos (sob uma suposição PRF de nullifier-key; yellow paper §7.1), mas é determinístico para aquela note — de modo que a mesma note só pode ser nulificada uma vez.
4. **Rejeição de double-spend.** A cadeia mantém um conjunto de nullifiers; um nullifier repetido é rejeitado. Isso impede double-spends **sem revelar qual note foi gasta**.
5. **Prova de validade.** Um spend carrega uma prova zero-knowledge de que "possuo uma note cujo commitment está na árvore e derivei seu nullifier corretamente", sem revelar nenhum desses valores. A verificação passa por um caminho Groth16.

**O verificador atual usa material de verifying-key development/skeleton sem trusted setup e não estabelece soundness nem privacidade de produção.** Formulação externa padrão: "O protótipo inclui um caminho de verificação Groth16 de development-key. Ele ainda não fornece segurança zero-knowledge de produção." Para as definições formais do formato de note, esquema de commitment, derivação de nullifier e semântica da árvore, veja o yellow paper §§5–7 e §10.

### 4.1 Por que uma cadeia independente e por que Cosmos

O modelo de divulgação precisa de controle sobre coisas que um deploy de smart-contract em uma L1 compartilhada, ou um rollup genérico, não fornecem de forma limpa:

- A **visibilidade de divulgação imposta por consenso** (§6) e as **regras de integridade de oferta** do shielded pool devem residir na camada de transição de estado / consenso, não dentro de um contrato cujos validadores da cadeia hospedeira e mercado de taxas estão fora do controle do projeto.
- O **estado shielded nativo** (commitment tree, conjunto de nullifiers, contabilidade de value-balance) é mais barato e auditável como estado de cadeia de primeira classe do que como armazenamento de contrato, e evita que o modelo de mempool público e metadados da cadeia hospedeira vaze mais do que o pretendido.
- Um **conjunto de validadores bonded-PoS** permite que a integridade de oferta seja reverificada por cada full node e dá finalidade instantânea adequada a pagamentos.

**Cosmos SDK + CometBFT** é escolhido por um stack BFT-PoS maduro com módulos de staking/slashing, governança soberana de upgrades e finalidade instantânea — não como endosso de qualquer modelo de token (nenhum é definitivo). Esta é uma justificativa de seleção de arquitetura, não uma afirmação de que a cadeia independente esteja implantada; para o status real, veja §3 e §8.

### 4.2 Características de desempenho

Dois tipos de números são mantidos separados. **Inerentes (no nível do esquema, citáveis):** Groth16 sobre a curva BN254 tem **provas de tamanho constante** (três elementos de grupo: 2×G1 + 1×G2, ~128 B comprimido / ~256 B não comprimido em BN254) e **verificação em tempo constante** (um número fixo e pequeno de verificações de pairing, independente do tamanho do circuito). Isso decorre do próprio sistema de provas, não da implementação da BEYUL. **No nível do sistema (ainda não medidos):** tempo de prova, throughput de transações (TPS) e tamanho do circuito (número de constraints) dependem do circuito de produção, que **não está construído** — o caminho atual usa um verifying key dev/skeleton (§4). Qualquer número desse tipo é, portanto, um **target / 【to be supplied】**, a ser medido quando o circuito de produção e um caminho de trusted-setup-ou-prova-transparente existirem (Roadmap §10, Fase 6). Acima desta linha, nenhum número de desempenho no nível do sistema é afirmado.

## 5. Modelo de privacidade e limites atuais

| Dimensão | Modelo-alvo | Protótipo atual |
|---|---|---|
| Valores no pool e ligação emissor/destinatário | Ocultos | Caminho de protótipo, não de produção |
| Valores de depósito / saque | Design pendente | **Públicos** |
| Timing / canais laterais de taxas / mempool | Mitigação pendente ou fora do escopo | Não mitigado |
| Ordenação de validadores / censura / MEV | Parcialmente fora do escopo do protocolo | Não mitigado |
| Metadados de camada de rede e de exchange/bridge | Fora do escopo do protocolo | Fora do escopo |

**O protótipo atual não é privacidade de produção.**

Em pre-testnet / baixo uso, o anonymity-set é pequeno ou vazio; sem usuários reais, a privacidade dentro do pool não é estabelecida de forma significativa — **privacidade forte depende de um anonymity-set grande e ativo, e NÃO é afirmada até que exista uso real**. A ordenação/MEV da camada de validadores e os metadados de rede permanecem não mitigados.

Um framework formal de anonymity-set (como o anonymity-set do shielded pool é definido e limitado) é mantido no yellow paper (§15); esta seção declara os objetivos de privacidade e os limites atuais, não aquele modelo formal.

## 6. Modelo de chaves e divulgação

Da maior à menor autoridade: **Spend Key** (única autoridade de gasto; nunca sai do dispositivo do usuário; nunca participa de fluxos de divulgação) → **Full View Key** (somente leitura; separação entrada/saída planejada) → **Audit Key** (planejada: emitida voluntariamente pelo usuário; limitada no tempo, limitada em escopo, revogável; não é um canal imposto pelo protocolo) → **Disclosure Credential** (a unidade mínima de divulgação, vinculada a uma transação ou um snapshot de ativo) → **16-character disclosure code** (código curto de entrada; não é uma chave).

**Limite de autoridade de visualização do projeto**: o design atual não inclui uma master viewing key controlada pelo projeto. Esta propriedade deve ser verificada por implementação aberta, testes e auditoria externa em vez de confiar na equipe — os caminhos de derivação de chaves são entregues como open source, e qualquer terceiro pode auditar o grafo de derivação para verificar a ausência de qualquer ramo que leve ao projeto. Até que a auditoria externa seja concluída, isto é uma "propriedade de design a ser verificada", não uma garantia.

**Política de mnemônica (planejamento de arquitetura, não um produto entregue)**: a chave raiz da wallet usa por padrão uma mnemônica de 24 palavras (BIP39), com chaves derivadas por separação de domínio (HKDF + domain tags). **A mnemônica nunca deve aparecer em nenhum fluxo de divulgação**; nem os disclosure codes nem o `link_secret` podem ser derivados apenas da mnemônica — os grants TDC/ADC são gerados no momento da divulgação voluntária usando um CSPRNG e autorização local.

**Limite de visibilidade de divulgação (requisito de design)**: o escopo visível de uma credencial de divulgação — incluindo a visibilidade da direção de saída — é planejado para ser garantido por regras da camada de consenso em vez de por convenção de implementação da wallet (uma lição da indústria vinda da Zcash, onde a visibilidade de saída depende de uma convenção de wallet); este requisito chega com o stack de verificação on-chain (roadmap Fase 5) e não está implementado hoje.

**Camada de Disclosure Grant (pendente de revisão independente)**: a camada de Disclosure Grant — escopo, expiração, revogação, log de auditoria e permissões de viewer — está pendente de uma revisão independente de produto e de segurança. Até que essa revisão seja concluída, não se pode confiar em nenhuma dessas propriedades de limite, e nenhum documento pode dar a entender que estejam estabelecidas.

## 7. Protótipo de divulgação TDC / ADC

### 7.1 Terminologia e codificação

O termo oficial é o "**16-character Crockford Base32 disclosure code**" (o alfabeto exclui os caracteres confundíveis I/L/O/U; ~80 bits de entropia de código curto), abreviado "16-character disclosure code". Formulações como "16-digit code" ou "16-digit security code" não são usadas — um esquema apenas numérico (~53 bits) foi rejeitado por orçamento de entropia insuficiente.

> **"O 16-character disclosure code não é uma credencial criptográfica de segurança subjacente. É um ponto de entrada de acesso amigável; a autorização real deve ser protegida conjuntamente por uma disclosure credential de alta entropia, assinaturas, restrições de escopo, expiração e lógica de verificação."**

### 7.2 Estado atual real (leitura obrigatória)

O que a BEYUL tem é um **protótipo de derivação TDC/ADC do lado do cliente testado localmente**. Os grants de servidor de ponta a ponta, a verificação de estado de cadeia e as ZK balance proofs estão **planejados e não implementados**. Portanto, NÃO se deve afirmar que: a divulgação verificável está implementada; os fundos já podem ser provados; o ADC pode provar saldos exatos; ou os disclosure codes podem ser verificados on-chain.

O protótipo do cliente cobre (testado localmente): KEK de dois fatores (`link_secret` + código de 16 caracteres, ambos obrigatórios); codificação canônica; vínculo de papel emissor/destinatário do TDC; separação de domínio TDC/ADC (nenhum pode abrir o outro); AEAD envelopes com proteção anti-adulteração AAD (envelope TDC/ADC do lado do cliente; o AAD do envelope on-chain MsgDiscloseNote ainda é um target — yellow paper §2.3); um verificador de código slow-hash (suíte-alvo Argon2id; adaptador de produção ainda não conectado); crypto-shredding de erasure key.

### 7.3 Semântica de TDC e ADC

| Capacidade | Revela | Não revela | Status |
|---|---|---|---|
| TDC — Transaction Disclosure Code | Campos limitados de uma transação/output, separação de papel emissor/destinatário | Spend authority, histórico completo, transações futuras | Protótipo de derivação de cliente; verificação de servidor e cadeia não implementada |
| ADC_L1 — Asset Disclosure Code, nível de limite inferior | Uma declaração de proof-of-funds / limite inferior selecionada pelo usuário | Saldo completo, notes, nullifiers, contrapartes, histórico | Protótipo de derivação de cliente; **sistema de provas não implementado** |
| ADC_L2 — Asset Disclosure Code, nível exato | Snapshot de saldo exato do ativo selecionado em uma altura finalizada | Notes, nullifiers, contrapartes, histórico | **Apenas design**; requer uma fonte de completude + ZK balance proof |

**O trilema da divulgação**: um sistema de propriedade oculta não pode prometer simultaneamente completude de saldo, sem vazamento de histórico e sem viewing key — um usuário pode provar a propriedade de notes selecionadas mas, sem uma fonte de completude adicional, não pode provar que nada foi omitido. Por isso o ADC é em camadas, e um ADC divulga exatamente o saldo do conjunto de ativos selecionado na altura selecionada — não deve ser descrito como "não revela saldo".

Riscos do ADC (mantidos públicos): snapshots repetidos para a mesma parte revelam mudanças de saldo ao longo do tempo; a exposição do patrimônio líquido é um risco de segurança física e coação (o ADC fica desativado por padrão e requer confirmação explícita); a rotação não pode retratar o que um observador já viu.

### 7.4 FAQ do disclosure code

| Pergunta | Resposta |
|---|---|
| O que é um TDC? | Um transaction disclosure code; divulga apenas informações limitadas sobre uma transação/output |
| O que é um ADC? | Um asset disclosure code; divulga um snapshot de saldo de ativo selecionado pelo usuário |
| Um ADC revela o saldo? | Sim — um ADC divulga o snapshot de saldo selecionado |
| Um disclosure code pode gastar fundos? | Não. Toda disclosure credential deve carregar `canSpend=false` (uma invariante no nível do protocolo) |
| Um disclosure code é permanente? | Não. A **vida útil de 24 horas é um padrão de design, não uma propriedade atualmente imposta** — a expiração e a revogação impostas por servidor/consenso não estão implementadas; são impostas pelo futuro serviço de grant e verificação Layer 2 (roadmap Fase 5), não hoje. A expiração do envelope do lado do cliente só é demonstrada no protótipo E1 e pode ser ignorada por qualquer um que possua o texto em claro, portanto não é uma propriedade imposta. Por design, as credenciais são limitadas no tempo e configuráveis pelo usuário: divulgações de maior duração exigem confirmação explícita, a divulgação permanente não é o padrão, e a revogação (uma vez imposta) impede o acesso futuro mas não pode apagar informações já vistas ou copiadas |
| Um disclosure code é derivado da frase de recuperação? | Não. As disclosure credentials são somente leitura, **nunca geradas automaticamente na criação da wallet, nunca derivadas da frase de recuperação**, e não podem conceder spend authority (`canSpend=false`). Os TDC são divulgações por-transação; os ADC são grants opt-in no nível do ativo |
| Como um disclosure code é protegido? | Dois fatores (`link_secret` + código de 16 caracteres), AEAD envelopes, vínculo AAD, um verificador slow-hash; **o rate-limiting do lado do servidor e as respostas de erro unificadas ainda estão por implementar** |
| Um disclosure code é uma chave privada? | Não. Não pode mover ativos nem substituir as chaves Spend/View/Audit; mas não o compartilhe levianamente — uma informação uma vez divulgada não pode ser retratada |

## 8. Plano de testnet (foco atual)

### 8.1 Modelo de validador

O testnet usa um **modelo de validador BFT estilo PoS**: Cosmos SDK + CometBFT, um conjunto inicial de validadores e fluxos de teste do módulo de staking. Não é PoW, e **não é segurança econômica PoS de nível mainnet** — o modelo econômico do mainnet é pesquisa de longo prazo fora do escopo deste whitepaper.

### 8.2 Preparação do testnet (declarado com clareza)

A preparação do testnet está **em andamento**: o runbook multinó e os gates relacionados ainda não estão completos (os pull requests pertinentes não estão todos mesclados e os checks não passam). Até que esses gates fechem e a evidência seja registrada, este projeto não usa linguagem "testnet-ready".

Checklist pré-lançamento: pacote de evidência fechado; chain-id e genesis do testnet; guia de onboarding de validadores; runbook multinó de 3+ nós; política de faucet e rate-limiting; política de RPC/API pública; dashboard de monitoramento; processo de resposta a incidentes; lista de limitações conhecidas; fluxo de comandos do participante; aviso de "token de testnet sem valor".

### 8.3 O que o testnet pode validar / não pode provar

**Pode validar**: operação de nós e produção de blocos, fluxos do módulo de staking, faucet, RPC, monitoramento e resposta a incidentes, o fluxo de demo do disclosure-code, o fluxo de protótipo do shielded module.
**Não pode provar**: privacidade de produção, segurança econômica PoS de mainnet, valor do token, aceitação regulatória, soundness ZK de produção. O lançamento do testnet não deve ser comercializado como "validação de produção".

### 8.4 Aviso ao participante

Tokens de testnet não têm valor monetário nem conversão prometida para mainnet; não há wallet oficial — participe apenas com o tooling de linha de comando e a documentação publicados oficialmente; **nenhum fluxo jamais exige que sua mnemônica entre em uma etapa de divulgação** — qualquer "oficial" que peça sua mnemônica é um golpista; atualmente não há nenhuma venda de tokens, rodada privada, whitelist ou registro de airdrop.

### 8.5 Governança, upgrades e limite econômico

Nesta etapa pre-testnet, a BEYUL **não tem governança descentralizada**. Os upgrades do protocolo e os pins críticos de segurança — parâmetros de genesis e o **verifying key fixado (pinned)** — são controlados pelo **conjunto inicial de validadores junto com o Owner**. Este é um modelo de confiança centralizado, declarado com clareza; será descentralizado progressivamente apenas à medida que a rede e sua governança amadurecerem (sem DAO, nenhum cronograma de descentralização prometido). Operar um validador não confere por si só autoridade de upgrade; o pinned VK e o genesis são alterados apenas pelo caminho de upgrade "conjunto de validadores + Owner".

**Limite econômico.** A denominação, a oferta e os parâmetros econômicos são **decisões do Owner — com gate, e não definidas neste whitepaper** (veja Status do token, acima). Nada aqui fixa uma denominação, uma oferta ou um modelo token-econômico.

## 9. Threat Model (público até a mitigação)

Organizado por classe de adversário, alinhado ao modelo de adversário do yellow paper (A1–A4). Este é um resumo; o yellow paper é a referência autoritativa do threat model, e os dois documentos não devem divergir — onde divergirem, o yellow paper prevalece.

- **A1 — Observador passivo da cadeia** (lê apenas dados públicos da cadeia): correlação de valores em depósitos/saques públicos, correlação de timing, canais laterais de taxas/gas — **não mitigado**. Commitments, nullifiers, anchors e a conta de fluxo líquido do pool são públicos por design.
- **A2 — Adversário de rede / infraestrutura** (mempool, RPC, ordenação de validadores, IP): observação de mempool, ordenação e censura de validadores, metadados de camada de rede — **não mitigado** (ordenação/censura parcialmente fora do escopo do protocolo); metadados de exchange/bridge fora do protocolo — **fora do escopo**.
- **A3 — Adversário do lado da divulgação** (um destinatário de divulgação ou alguém de posse de um código): o encaminhamento de uma divulgação por um destinatário é **criptograficamente incontrolável**; a revogação **não está implementada**; exposição de séries temporais e patrimônio líquido do ADC em snapshots repetidos; emissão coagida — **declarado com clareza, não mitigado**.
- **A4 — Adversário de endpoint / social** (o dispositivo do usuário, phishing): phishing e engenharia social por mnemônicas ou códigos, wallets falsas e canais oficiais falsos — **não mitigado**; tratado por educação do usuário e a lista de canais oficiais.

Transversal, não resolvido: bugs de circuito, trusted setup, auditoria externa — **não verificado / não resolvido / não concluído**. A integridade de oferta do pool (o gate G-S) está aberta; a conservação e o double-spend **não são afirmados como propriedades de produção**, pendentes de value-balance in-circuit e de keeper com consistência de largura 128↔64 bits (espelho do yellow paper §12.3). A confusão sobre o valor de tokens de testnet e recompensas **não é permitida** — tokens de teste não têm valor e qualquer contabilidade de recompensas é simulada.

## 10. Roadmap (baseado em gates, sem promessas de data)

> Cada capacidade deve estar em exatamente um estado: Implemented / Local tested / Prototype / Documentation only / Planned / Unverified / Not implemented. Nenhuma afirmação pode ser escrita como "implementada" sem commit, registro de CI, comando de teste e saída.

| Fase | Objetivo | Critérios de saída (resumo) |
|---|---|---|
| Fase 0 — Fechamento de evidência e escopo do documento **← atual** | Fechar o evidence appendix; limitar a narrativa pública ao testnet | Cada afirmação implementada com evidência; sem implicações de token/wallet/DeFi/mainnet |
| Fase 1 — Preparação do testnet | Concluir o checklist da Seção 8.2 | Devnet de 3+ nós estável; runbook reproduzível; checks de PR em verde |
| Fase 2 — Testnet público | Experimentação pública controlada | Nós externos podem entrar; abuso de faucet controlado; sem engano de mainnet ou rendimento |
| Fase 3 — TDC MVP | Grant de transação única de ponta a ponta | Comportamento seguro em código errado/expirado/esgotado; existência de grant não vazada; apenas campos limitados |
| Fase 4 — ADC_L1 | Proof of funds de limite inferior | Nunca descrito como saldo exato; risco de série temporal público; TDC/ADC mutuamente não abríveis |
| Fase 5 — Verificação de divulgação on-chain | Verificação root-bound | Chain/root/scope/asset errados todos rejeitados; proteção anti-replay |
| Fase 6 — Caminho ZK de produção | Sistema de provas auditável | Dev verifying keys aposentados; auditoria criptográfica externa; nenhuma afirmação "production ZK" antes da conclusão |
| Fase 7 — ADC_L2 | Snapshot de saldo exato | Completude provável; sem vazamento de histórico; nunca se torna uma viewing key de longa duração |
| Fase 8 — Auditoria externa e pre-mainnet | Revisão pre-mainnet | Auditorias de protocolo/criptografia/implementação; revisão jurídica; pacote de evidência público |

A ordem não é reversível: **testnet → TDC MVP → ADC_L1 → verificação root-bound → production ZK → ADC_L2 → auditoria → pre-mainnet.**

## 11. Limite de conformidade

BEYUL não é uma solução de conformidade: não implementa fluxos de AML, KYC, travel-rule, congelamento, screening de sanções ou reporte, e não afirma ser "compliant by design". Toda divulgação é iniciada pelo usuário; o protocolo não tem canal de divulgação forçada; o design atual não inclui uma viewing key global controlada pelo projeto (a verificar por implementação aberta e auditoria). Instituições e indivíduos devem avaliar de forma independente a postura regulatória de sua jurisdição em relação a ativos de privacidade.

## 12. Declaração de risco e isenção de responsabilidade

Este documento é apenas para fins informativos e não constitui, nem deve ser interpretado como: uma oferta ou venda de um valor mobiliário, commodity ou instrumento financeiro; aconselhamento de investimento, jurídico, fiscal ou financeiro; ou uma declaração de conformidade em qualquer jurisdição. Contém declarações prospectivas (objetivos de design, planos de testnet, roadmap) sujeitas a incerteza material; os resultados reais podem diferir materialmente.

Este projeto atualmente **não tem token emitido**; tokens de testnet, se usados, não têm valor monetário. Participar de redes de cripto-ativos envolve riscos materiais. Faça sua própria pesquisa e consulte assessores profissionais. Onde qualquer tradução conflitar com esta versão canônica em inglês, esta versão em inglês prevalece. Esta isenção é um modelo genérico e deve ser revisada por assessoria jurídica na jurisdição pertinente antes de qualquer publicação pública formal.

## 13. Conclusão

A direção da BEYUL é privacidade por padrão com divulgação controlada pelo usuário. Seus ativos críveis hoje: um protótipo de chain-application, um protótipo de derivação TDC/ADC do lado do cliente testado localmente, e uma tabela de status e um threat model mantidos estritamente alinhados à implementação. O único foco atual são os **pré-requisitos para o lançamento do testnet público**: fechamento de evidência, o runbook multinó, faucet e monitoramento, e documentação do participante. Até que a evidência correspondente exista, este projeto não faz afirmações de mainnet, token, privacidade de produção ou conformidade.