# BEYUL Whitepaper — Pre-Testnet Edition : Architecture et modèle de divulgation

> **Ceci est une traduction. La version anglaise est la version canonique (canonical) et prévaut en cas de conflit.** Les identifiants techniques (BEYUL, BYL, `privacychain`, TDC, ADC, nullifier, commitment, viewing key, shielded pool, Groth16, etc.) restent non traduits, en anglais.

**Projet :** BEYUL　**Type :** prototype de recherche d'une chaîne publique axée sur la confidentialité (pre-testnet). Le travail de protocole de BEYUL est actuellement développé dans le dépôt `privacychain`.
**Statut du document :** whitepaper de BEYUL, **édition pre-testnet (de recherche)** — il décrit l'architecture du protocole, le modèle de divulgation et les limites actuelles avant le testnet public. Ce **n'est pas** une spécification de protocole de production, ni un document d'investissement, ni un avis de conformité, ni un audit de sécurité, ni un matériel d'émission de jetons, ni une annonce de mainnet. Les affirmations de capacité suivent la discipline de preuve de §3.1 ; rien ici n'est décrit au-delà de sa maturité réelle.
**Statut du jeton :** la tokenomics n'est pas finalisée. **BYL** n'est que la forme courte / le ticker du projet ; ce **n'est pas** une dénomination figée — la dénomination et les paramètres de la chaîne restent soumis à l'approbation explicite de l'Owner. Ce document ne définit aucune allocation de jetons ni conception d'utilité. Les jetons de testnet, s'ils sont utilisés, n'ont aucune valeur monétaire ni conversion promise vers le mainnet.
**Langue canonique :** la version anglaise est la seule version canonique. La version chinoise (`beyul-whitepaper-pretestnet.zh.md`) est un texte de travail d'accompagnement ; en cas de conflit, cette version anglaise prévaut.

---

## Encadré des limites d'affirmations (à lire en premier)

Ce document ne fait **aucune** des affirmations suivantes :

- Aucune affirmation d'anonymat, de non-traçabilité ou de « sécurité absolue » ;
- Aucune affirmation de sécurité zero-knowledge de production (l'implémentation actuelle utilise du matériel de development-key) ;
- Aucune affirmation de confidentialité de production (les montants de dépôt et de retrait sont actuellement publics on-chain) ;
- Aucune affirmation d'approbation réglementaire ou de « compliance by design » ;
- La conception actuelle n'inclut pas de viewing key globale contrôlée par le projet ; cette propriété doit être vérifiée par une implémentation ouverte, des tests et un audit externe ;
- Il n'existe ni testnet public ni mainnet ; **la préparation du testnet est en cours — le runbook multi-nœuds et les gates associés ne sont pas encore terminés** ;
- Aucune promesse de valeur du jeton, d'airdrops, de rendement, de retours ou de listings sur des exchanges ; ce document ne traite ni de produits de wallet ni de DeFi ;
- Le 16-character disclosure code n'est pas une credential cryptographique de sécurité sous-jacente (Section 7).

**Nomenclature et identifiants techniques.** BEYUL est le nom du projet/produit ; le travail de protocole de BEYUL est actuellement développé dans le dépôt `privacychain`. `privacychain` reste l'identifiant technique actuel — dépôt, paquet de protocole/module/proto, binaire et chain-id — et est conservé inchangé. **BYL** est la forme courte / le ticker ; la dénomination et les paramètres de la chaîne restent soumis à l'approbation explicite de l'Owner, donc BYL n'est pas une dénomination figée. Cette discipline de nomenclature est uniquement prospective : les documents historiques ne sont pas renommés rétroactivement.

---

## 1. Résumé

BEYUL est un projet de chaîne publique axée sur la confidentialité au **stade de prototype de recherche (pre-testnet)** qui explore une infrastructure de paiement avec **confidentialité par défaut (un objectif de conception)** et divulgation contrôlée par l'utilisateur. Dans la conception cible, les détails de la transaction ne sont pas publiquement visibles par défaut, mais le propriétaire de l'actif peut divulguer volontairement, avec une portée limitée, à une partie choisie — un Transaction Disclosure Code (TDC) explique une seule transaction ; un Asset Disclosure Code (ADC) divulgue un instantané d'actifs sélectionné. « Confidentialité par défaut » décrit l'objectif de conception, pas le prototype actuel (voir §5).

**Ce qui existe aujourd'hui n'est qu'un prototype de dérivation de disclosure-code côté client** (testé localement ; le paquet de preuves publiques est en attente de consolidation) et un prototype de chain-application basé sur le Cosmos SDK. Les grants côté serveur de bout en bout, la vérification on-chain et les ZK balance proofs ne sont pas implémentés ; il n'y a pas de trusted setup, pas d'audit externe, pas de testnet public ni de mainnet ; les montants de dépôt et de retrait sont actuellement publics on-chain. L'objet de ce whitepaper (édition pre-testnet) est de consigner avec exactitude l'orientation architecturale, le modèle de divulgation et les limites actuelles avant le lancement du testnet public — et de n'être remplacé par une édition de production que lorsque les preuves et les audits correspondants existeront.

## 2. Positionnement et problème

Les registres publics exposent les relations de paiement, les soldes et les flux de fonds à tout observateur ; pendant ce temps, la plupart des systèmes à forte confidentialité rendent la divulgation *sélective* difficile sur le plan opérationnel — expliquer une transaction à une partie revient souvent à céder la capacité de tout voir. La lacune que BEYUL explore : faire de la « divulgation » une primitive de première classe au même rang que la « dissimulation », toute divulgation étant initiée par l'utilisateur.

BEYUL ne rivalise pas — et ne vise pas — un récit « totalement anonyme, non traçable ».

**Vision.** La confidentialité financière sur les registres publics est inversée : nue par défaut, alors que la dissimulation elle-même paraît suspecte. L'objectif de BEYUL est d'inverser ce défaut — la confidentialité comme état par défaut, et la divulgation comme choix délibéré et granulaire de l'utilisateur : quelle transaction, quels champs, à qui et pour combien de temps.

**Principes de conception.** Chaque partie du protocole y est tenue :

1. **La divulgation est une citoyenne de première classe** — les primitives de divulgation sont conçues et prototypées au même rang que les primitives de dissimulation.
2. **Moindre autorité** — chaque clé et credential ne porte que l'autorité minimale que son objet requiert.
3. **La spend authority est sacro-sainte** — aucun flux de divulgation ne peut toucher la spend authority ; la mnémonique n'entre jamais dans aucune étape de divulgation.
4. **Aucun privilège global** — le protocole est **conçu pour ne fournir** aucun canal de visualisation global au projet ou à un tiers ; l'absence d'une telle branche est une **propriété de conception à vérifier par une implémentation ouverte, des tests et un audit externe (§6)**, pas encore une garantie.
5. **Honnêteté des limites** — chaque capacité déclare ce qu'elle ne fait pas ; le threat model et les limitations restent publics.
6. **La preuve d'abord** — les affirmations de capacité ne sont relevées qu'après l'existence d'une preuve (code, tests, audits) — basé sur des gates, sans promesse de date.

### 2.1 Comment se compare la divulgation de BEYUL

> Le tableau compare la **conception cible** de BEYUL aux **capacités actuelles et livrées** d'autres systèmes. Les différenciateurs de BEYUL ci-dessous (expiration, révocation, visibilité imposée par le consensus, portée par-transaction/par-instantané avec vérification serveur et on-chain) sont en grande partie **planifiés ou au stade de prototype côté client** (voir §3, §7), pas encore livrés. Les faits relatifs aux concurrents sont énoncés de manière prudente ; les points non revérifiés de façon indépendante pour ce whitepaper sont marqués **【to verify】**.

| Système | Mécanisme de divulgation | Granularité | Expirable / révocable | Visibilité imposée par |
|---|---|---|---|---|
| Zcash (Sapling/Orchard) | Full viewing key (FVK/IVK) | À l'échelle du compte, tout-ou-rien | Non | La visibilité sortante dépend d'une convention de wallet (chiffré ovk), pas du consensus |
| Monero | View key | À l'échelle du compte (entrant) | Non | Wallet / protocole ; aucune primitive limitée par-transaction |
| Mélangeurs de type Tornado | Aucun natif (outillage externe, p. ex. preuves d'association/exclusion) | — | — | — |
| Penumbra | Viewing keys en couches (FVK/IVK/OVK) + detection key par-adresse (FMD / S-FMD) | Viewing keys à l'échelle du compte ; detection key = **découverte du destinataire** (liaison seulement, pas de contenu), délégable par-adresse | Non indiqué dans la documentation 【to verify】 | Délégation cryptographique de clés (client/wallet), pas le consensus |
| Aztec | Viewing keys entrante/sortante + **master** ; **note discovery basé sur le tagging** (pas FMD) ; logs chiffrés | Master viewing key **tout-ou-rien sur tous les contrats** ; divulgation limitée/temporaire uniquement via la couche applicative (Noir), non native au protocole | Uniquement en tant que « temporary view access » au niveau applicatif, pas natif 【to verify】 | Logique d'app/contrat + client (PXE), pas le consensus de base |
| Namada (MASP) | Shielded viewing key (zvknam), multi-actifs dérivé de Sapling | **À l'échelle du compte** (solde et historique entrant+sortant d'un shielded account) ; « divulgation sélective » = partager la viewing key (tout le compte), pas par-transaction | Viewing key partagée non révocable nativement (sémantique précise 【to verify】) | Viewing key (wallet/client) |
| **BEYUL (conception cible)** | **TDC** (par-transaction) + **ADC** (par-instantané d'actif), **par paliers** (ADC L1/L2) | Par-transaction / par-instantané ; champs limités ; rôles émetteur/destinataire séparés | **Expiration + révocation (planifié)** | **Limite de visibilité imposée par le consensus (exigence de conception, §6) ; deux facteurs + lecture seule** |

Le différenciateur visé n'est pas « une dissimulation plus forte » mais une **divulgation plus granulaire, limitée dans le temps et émise par l'utilisateur** : là où une viewing key Zcash/Monero est une autorisation de lecture à l'échelle du compte, tout-ou-rien et indéfinie, une credential de divulgation BEYUL est limitée à une transaction (TDC) ou un instantané d'actif (ADC), porte une expiration et est conçue pour être révocable — l'ensemble des champs visibles étant imposé par le consensus plutôt que par une convention de wallet. Ces propriétés sont des objectifs de conception ; leur état d'implémentation est suivi honnêtement en §3 et §7.

> **Sources.** Zcash/Monero : le rapport de recherche approfondie ZEC/XMR de ce projet (sources primaires — Zcash Protocol Specification ; documentation de Monero ; au 2026-06-12). Les lignes Penumbra / Aztec / Namada décrivent la **documentation officielle de chaque projet au 2026-06** (Penumbra : protocol.penumbra.zone — viewing keys, FMD ; Aztec : docs.aztec.network — keys, note discovery ; Namada : docs.namada.net — shielded accounts). Les points 【to verify】 restants — expiration/révocation et sémantique transaction-perspective de Penumbra, expiration/révocation native d'Aztec, sémantique précise de révocation de Namada — restent à confirmer. Ces lignes énoncent ce que décrit la documentation de chaque projet, et non des affirmations sur ce que d'autres systèmes « ne peuvent pas faire ».

## 3. État actuel

| Domaine | État | Notes |
|---|---|---|
| Chain-application | Prototype | Cosmos SDK / Ignite |
| Modèle de consensus / validateur | Conception de testnet | CometBFT BFT avec un ensemble initial de validateurs de type PoS et un module de staking ; pas PoW ; pas de sécurité économique PoS de niveau mainnet |
| Shielded module | Prototype | Dépôt, retrait, spend, enregistrement de viewing-key, divulgation de note |
| Commitments / Merkle tree / nullifiers | Prototype | Comportement déterministe et rejet de double-spend couverts par des tests |
| Stack de clés client disclosure-code (dérivation TDC/ADC) | Prototype, testé localement | **Paquet de preuves publiques (commit/CI) en attente de consolidation** |
| Stack de grants serveur / vérification de divulgation on-chain / ZK balance proof | Non implémenté | Planifié |
| Séparation view-key entrant/sortant / audit key / expiration et révocation de divulgation **imposées par serveur/consensus** | Non implémenté | Planifié |
| Trusted setup / audit externe | Non terminé / non commencé | Prérequis à toute affirmation de production |
| Testnet public / mainnet | Non déployé | **Préparation du testnet en cours : runbook multi-nœuds et gates associés pas encore terminés** |
| Wallet officielle | N'existe pas | Outils de développement et de test uniquement ; toute « wallet officielle » est une contrefaçon |
| Économie du jeton | Non finalisée | Ce document ne contient aucune conception de jeton |

### 3.1 Chaîne de preuves

Chaque ligne « prototype implémenté » ci-dessus est liée à un enregistrement de preuve — pas affirmée en prose. La chaîne de preuves (commit hash, enregistrement CI, commande de test et sortie exactes, instructions d'exécution reproductibles) est tenue dans l'**Evidence Appendix**, et chaque capacité est notée sur une échelle de maturité de recherche **L0–L5** (conception → prototype → reproductible → revu → preuve réseau → production). Ce whitepaper référence ce registre plutôt que de réénoncer la preuve brute.

| Capacité | Maturité | Liaison de preuve |
|---|---|---|
| Cœur client disclosure-code (dérivation TDC/ADC, deux facteurs, séparation de domaine, AEAD/AAD, erasure keys) | L1–L2 | Reproduit en lecture seule 2026-06-19 : **13/13** tests locaux passent ; commit enregistré dans Evidence Appendix E1 ; CI **【to be supplied】** |
| Shielded module (commitment/nullifier/Merkle, rejet de double-spend) | L1 | Reproduit en lecture seule 2026-06-19 : tests double-spend & nullifier passent ; Evidence Appendix E3 ; CI **【to be supplied】** |
| Chemin de spend Groth16 | L1 (dev-key) | VK dev/skeleton, pas de trusted setup ; tests dev-path + production-VK-guard reproduits 2026-06-19 ; Evidence Appendix E4 |
| Stack de grants serveur / vérification on-chain / ZK balance proof | L0 (planifié) | Non implémenté ; voir Roadmap §10 |

> Auto-évaluation actuelle : l'essentiel du matériel est en **L1–L2**, rien en L5. Tant que les entrées de l'Evidence Appendix ne sont pas renseignées (commit/CI), les supports publics disent « vérifié localement ; paquet de preuves publiques en attente de consolidation », pas « implémenté avec preuve publique ». Une capacité sans enregistrement de preuve enregistré ne peut pas être décrite au-delà de son niveau de maturité. L'Evidence Appendix se trouve à `docs/evidence-appendix.md` (interne ; à publier avec le paquet de preuves publiques) ; E1/E3/E4 ont été reproduits en lecture seule le 2026-06-19, la liaison CI restant en attente.

## 4. Modèle technique

Le prototype est centré sur une machine à états de shielded pool. Pour un non-cryptographe, le cycle de vie d'un solde privé se déroule ainsi :

1. **Note.** Un solde dépensable est une *note* — un enregistrement de (propriétaire, montant, aléa). La note elle-même n'apparaît jamais on-chain.
2. **Commitment.** La chaîne ne stocke qu'un *commitment* sur la note (un hash de liaison à sens unique), ajouté à un **Merkle commitment tree** en ajout-seul. À partir du seul commitment, un observateur n'apprend ni le propriétaire ni le montant.
3. **Spend → nullifier.** Pour dépenser une note, le propriétaire publie un *nullifier* qui en est dérivé. Le nullifier est **conçu pour ne pas être reliable** au commitment par des observateurs externes (sous une hypothèse PRF de nullifier-key ; yellow paper §7.1), mais il est déterministe pour cette note — de sorte que la même note ne peut être nullifiée qu'une seule fois.
4. **Rejet de double-spend.** La chaîne tient un ensemble de nullifiers ; un nullifier répété est rejeté. Cela empêche les double-spends **sans révéler quelle note a été dépensée**.
5. **Preuve de validité.** Un spend porte une preuve zero-knowledge attestant que « je possède une note dont le commitment est dans l'arbre, et j'ai dérivé son nullifier correctement », sans révéler aucune de ces valeurs. La vérification passe par un chemin Groth16.

**Le vérificateur actuel utilise du matériel de verifying-key development/skeleton sans trusted setup et n'établit ni soundness ni confidentialité de production.** Formulation externe standard : « Le prototype comprend un chemin de vérification Groth16 de development-key. Il ne fournit pas encore de sécurité zero-knowledge de production. » Pour les définitions formelles du format de note, du schéma de commitment, de la dérivation de nullifier et de la sémantique de l'arbre, voir le yellow paper §§5–7 et §10.

### 4.1 Pourquoi une chaîne autonome et pourquoi Cosmos

Le modèle de divulgation a besoin d'un contrôle sur des éléments qu'un déploiement de smart-contract sur une L1 partagée, ou un rollup générique, n'offrent pas proprement :

- La **visibilité de divulgation imposée par le consensus** (§6) et les **règles d'intégrité de l'offre** du shielded pool doivent résider dans la couche de transition d'état / consensus, pas dans un contrat dont les validateurs de la chaîne hôte et le marché des frais échappent au contrôle du projet.
- L'**état shielded natif** (commitment tree, ensemble de nullifiers, comptabilité value-balance) est moins coûteux et plus auditable en tant qu'état de chaîne de première classe qu'en tant que stockage de contrat, et évite que le modèle de mempool public et de métadonnées de la chaîne hôte ne fuite plus que prévu.
- Un **ensemble de validateurs bonded-PoS** permet à l'intégrité de l'offre d'être revérifiée par chaque full node et offre une finalité instantanée adaptée aux paiements.

**Cosmos SDK + CometBFT** est choisi pour une stack BFT-PoS mature avec modules de staking/slashing, governance souveraine des upgrades et finalité instantanée — et non comme une approbation d'un quelconque modèle de jeton (aucun n'est finalisé). C'est une justification de sélection d'architecture, pas une affirmation que la chaîne autonome est déployée ; pour l'état réel, voir §3 et §8.

### 4.2 Caractéristiques de performance

Deux types de chiffres sont tenus séparés. **Inhérents (au niveau du schéma, citables) :** Groth16 sur la courbe BN254 a des **preuves de taille constante** (trois éléments de groupe : 2×G1 + 1×G2, ~128 o compressé / ~256 o non compressé sur BN254) et une **vérification en temps constant** (un nombre fixe et faible de vérifications de pairing, indépendant de la taille du circuit). Cela découle du système de preuve lui-même, pas de l'implémentation de BEYUL. **Au niveau système (pas encore mesurés) :** le temps de preuve, le débit de transactions (TPS) et la taille du circuit (nombre de contraintes) dépendent du circuit de production, qui **n'est pas construit** — le chemin actuel utilise un verifying key dev/skeleton (§4). Tout chiffre de ce type est donc une **target / 【to be supplied】**, à mesurer une fois que le circuit de production et un chemin trusted-setup-ou-preuve-transparente existeront (Roadmap §10, Phase 6). Au-dessus de cette ligne, aucun chiffre de performance au niveau système n'est affirmé.

## 5. Modèle de confidentialité et limites actuelles

| Dimension | Modèle cible | Prototype actuel |
|---|---|---|
| Montants en pool et liaison émetteur/destinataire | Cachés | Chemin prototype, pas de production |
| Montants de dépôt / retrait | Conception en attente | **Publics** |
| Timing / canaux auxiliaires de frais / mempool | Atténuation en attente ou hors périmètre | Non atténué |
| Ordonnancement des validateurs / censure / MEV | Partiellement hors du périmètre du protocole | Non atténué |
| Métadonnées de couche réseau et d'exchange/bridge | Hors du périmètre du protocole | Hors périmètre |

**Le prototype actuel n'est pas une confidentialité de production.**

En pre-testnet / faible usage, l'anonymity-set est petit ou vide ; sans utilisateurs réels, la confidentialité au sein du pool n'est pas établie de façon significative — **une confidentialité forte dépend d'un anonymity-set large et actif, et N'EST PAS affirmée tant qu'un usage réel n'existe pas**. L'ordonnancement/MEV de la couche validateurs et les métadonnées réseau restent non atténués.

Un cadre formel d'anonymity-set (comment l'anonymity-set du shielded pool est défini et borné) est tenu dans le yellow paper (§15) ; cette section énonce les objectifs de confidentialité et les limites actuelles, pas ce modèle formel.

## 6. Modèle de clés et de divulgation

De la plus haute à la plus basse autorité : **Spend Key** (seule autorité de dépense ; ne quitte jamais l'appareil de l'utilisateur ; ne participe jamais aux flux de divulgation) → **Full View Key** (lecture seule ; séparation entrant/sortant planifiée) → **Audit Key** (planifiée : émise volontairement par l'utilisateur ; limitée dans le temps, limitée en portée, révocable ; pas un canal imposé par le protocole) → **Disclosure Credential** (l'unité minimale de divulgation, liée à une transaction ou un instantané d'actif) → **16-character disclosure code** (code court d'entrée ; pas une clé).

**Limite d'autorité de visualisation du projet** : la conception actuelle n'inclut pas de master viewing key contrôlée par le projet. Cette propriété doit être vérifiée par une implémentation ouverte, des tests et un audit externe plutôt que par confiance envers l'équipe — les chemins de dérivation de clés sont livrés en open source, et tout tiers peut auditer le graphe de dérivation pour vérifier l'absence de toute branche menant au projet. Tant que l'audit externe n'est pas terminé, il s'agit d'une « propriété de conception à vérifier », pas d'une garantie.

**Politique de mnémonique (planification d'architecture, pas un produit livré)** : la clé racine de la wallet utilise par défaut une mnémonique de 24 mots (BIP39), les clés en aval étant dérivées par séparation de domaine (HKDF + domain tags). **La mnémonique ne doit jamais apparaître dans aucun flux de divulgation** ; ni les disclosure codes ni le `link_secret` ne peuvent être dérivés de la seule mnémonique — les grants TDC/ADC sont générés au moment de la divulgation volontaire à l'aide d'un CSPRNG et d'une autorisation locale.

**Limite de visibilité de divulgation (exigence de conception)** : la portée visible d'une credential de divulgation — y compris la visibilité de la direction sortante — est prévue pour être garantie par des règles de la couche de consensus plutôt que par une convention d'implémentation de wallet (une leçon de l'industrie tirée de Zcash, où la visibilité sortante dépend d'une convention de wallet) ; cette exigence arrive avec le stack de vérification on-chain (roadmap Phase 5) et n'est pas implémentée aujourd'hui.

**Couche Disclosure Grant (en attente de revue indépendante)** : la couche Disclosure Grant — portée, expiration, révocation, journal d'audit et permissions de viewer — est en attente d'une revue indépendante de produit et de sécurité. Tant que cette revue n'est pas terminée, aucune de ces propriétés de limite ne peut être tenue pour acquise, et aucun document ne peut laisser entendre qu'elles sont établies.

## 7. Prototype de divulgation TDC / ADC

### 7.1 Terminologie et encodage

Le terme officiel est le « **16-character Crockford Base32 disclosure code** » (l'alphabet exclut les caractères confondables I/L/O/U ; ~80 bits d'entropie de code court), abrégé « 16-character disclosure code ». Des formulations comme « 16-digit code » ou « 16-digit security code » ne sont pas utilisées — un schéma uniquement numérique (~53 bits) a été rejeté pour budget d'entropie insuffisant.

> **« Le 16-character disclosure code n'est pas une credential cryptographique de sécurité sous-jacente. C'est un point d'entrée d'accès convivial ; l'autorisation réelle doit être protégée conjointement par une disclosure credential à haute entropie, des signatures, des restrictions de portée, une expiration et une logique de vérification. »**

### 7.2 État actuel réel (à lire impérativement)

Ce que BEYUL possède est un **prototype de dérivation TDC/ADC côté client testé localement**. Les grants serveur de bout en bout, la vérification de l'état de chaîne et les ZK balance proofs sont **planifiés et non implémentés**. Il ne faut donc PAS affirmer que : la divulgation vérifiable est implémentée ; les fonds peuvent déjà être prouvés ; l'ADC peut prouver des soldes exacts ; ou les disclosure codes peuvent être vérifiés on-chain.

Le prototype client couvre (testé localement) : KEK à deux facteurs (`link_secret` + code de 16 caractères, les deux requis) ; encodage canonique ; liaison de rôle émetteur/destinataire du TDC ; séparation de domaine TDC/ADC (aucun ne peut ouvrir l'autre) ; AEAD envelopes avec protection anti-altération AAD (envelope TDC/ADC côté client ; l'AAD de l'envelope on-chain MsgDiscloseNote reste une target — yellow paper §2.3) ; un vérificateur de code slow-hash (suite cible Argon2id ; adaptateur de production pas encore branché) ; crypto-shredding d'erasure key.

### 7.3 Sémantique TDC et ADC

| Capacité | Révèle | Ne révèle pas | État |
|---|---|---|---|
| TDC — Transaction Disclosure Code | Champs limités d'une transaction/output, séparation de rôle émetteur/destinataire | Spend authority, historique complet, transactions futures | Prototype de dérivation client ; vérification serveur et chaîne non implémentée |
| ADC_L1 — Asset Disclosure Code, palier de borne inférieure | Une déclaration de proof-of-funds / borne inférieure sélectionnée par l'utilisateur | Solde complet, notes, nullifiers, contreparties, historique | Prototype de dérivation client ; **système de preuve non implémenté** |
| ADC_L2 — Asset Disclosure Code, palier exact | Instantané de solde exact de l'actif sélectionné à une hauteur finalisée | Notes, nullifiers, contreparties, historique | **Conception uniquement** ; nécessite une source de complétude + ZK balance proof |

**Le trilemme de la divulgation** : un système à propriété cachée ne peut pas promettre simultanément complétude du solde, absence de fuite d'historique et absence de viewing key — un utilisateur peut prouver la propriété de notes sélectionnées mais, sans source de complétude supplémentaire, ne peut pas prouver que rien n'a été omis. L'ADC est donc par paliers, et un ADC divulgue exactement le solde de l'ensemble d'actifs sélectionné à la hauteur sélectionnée — il ne doit pas être décrit comme « ne révèle pas le solde ».

Risques de l'ADC (maintenus publics) : des instantanés répétés à la même partie révèlent les variations de solde dans le temps ; l'exposition du patrimoine net est un risque de sécurité physique et de coercition (l'ADC est désactivé par défaut et nécessite une confirmation explicite) ; la rotation ne peut pas retirer ce qu'un observateur a déjà vu.

### 7.4 FAQ du disclosure code

| Question | Réponse |
|---|---|
| Qu'est-ce qu'un TDC ? | Un transaction disclosure code ; il ne divulgue que des informations limitées sur une transaction/output |
| Qu'est-ce qu'un ADC ? | Un asset disclosure code ; il divulgue un instantané de solde d'actif sélectionné par l'utilisateur |
| Un ADC révèle-t-il le solde ? | Oui — un ADC divulgue l'instantané de solde sélectionné |
| Un disclosure code peut-il dépenser des fonds ? | Non. Toute disclosure credential doit porter `canSpend=false` (un invariant au niveau du protocole) |
| Un disclosure code est-il permanent ? | Non. La **durée de vie de 24 heures est une valeur par défaut de conception, pas une propriété actuellement imposée** — l'expiration et la révocation imposées par serveur/consensus ne sont pas implémentées ; elles sont imposées par le futur service de grant et de vérification Layer 2 (roadmap Phase 5), pas aujourd'hui. L'expiration de l'envelope côté client n'est démontrée que dans le prototype E1 et peut être ignorée par quiconque détient le texte en clair, ce n'est donc pas une propriété imposée. Par conception, les credentials sont limitées dans le temps et configurables par l'utilisateur : les divulgations à plus longue durée nécessitent une confirmation explicite, la divulgation permanente n'est pas le défaut, et la révocation (une fois imposée) empêche l'accès futur mais ne peut pas effacer les informations déjà vues ou copiées |
| Un disclosure code est-il dérivé de la phrase de récupération ? | Non. Les disclosure credentials sont en lecture seule, **jamais générées automatiquement à la création de la wallet, jamais dérivées de la phrase de récupération**, et ne peuvent pas accorder la spend authority (`canSpend=false`). Les TDC sont des divulgations par-transaction ; les ADC sont des grants opt-in au niveau de l'actif |
| Comment un disclosure code est-il protégé ? | Deux facteurs (`link_secret` + code de 16 caractères), AEAD envelopes, liaison AAD, un vérificateur slow-hash ; **le rate-limiting côté serveur et les réponses d'erreur unifiées restent à implémenter** |
| Un disclosure code est-il une clé privée ? | Non. Il ne peut pas déplacer d'actifs ni remplacer les clés Spend/View/Audit ; mais ne le partagez pas à la légère — une information une fois divulguée ne peut être reprise |

## 8. Plan de testnet (focus actuel)

### 8.1 Modèle de validateur

Le testnet utilise un **modèle de validateur BFT de type PoS** : Cosmos SDK + CometBFT, un ensemble initial de validateurs et des flux de test du module de staking. Ce n'est pas du PoW, et **ce n'est pas une sécurité économique PoS de niveau mainnet** — le modèle économique du mainnet est une recherche de long terme hors du périmètre de ce whitepaper.

### 8.2 Préparation du testnet (énoncé clairement)

La préparation du testnet est **en cours** : le runbook multi-nœuds et les gates associés ne sont pas encore terminés (les pull requests concernées ne sont pas toutes fusionnées et les checks ne passent pas). Tant que ces gates ne sont pas fermés et que la preuve n'est pas enregistrée, ce projet n'utilise pas le langage « testnet-ready ».

Checklist avant lancement : paquet de preuves clôturé ; chain-id et genesis du testnet ; guide d'onboarding des validateurs ; runbook multi-nœuds à 3+ nœuds ; politique de faucet et rate-limiting ; politique de RPC/API publique ; dashboard de monitoring ; processus de réponse aux incidents ; liste des limitations connues ; flux de commandes du participant ; avis « jeton de testnet sans valeur ».

### 8.3 Ce que le testnet peut valider / ne peut pas prouver

**Peut valider** : le fonctionnement des nœuds et la production de blocs, les flux du module de staking, le faucet, le RPC, le monitoring et la réponse aux incidents, le flux de démo du disclosure-code, le flux de prototype du shielded module.
**Ne peut pas prouver** : la confidentialité de production, la sécurité économique PoS du mainnet, la valeur du jeton, l'acceptation réglementaire, la soundness ZK de production. Le lancement du testnet ne doit pas être présenté comme une « validation de production ».

### 8.4 Avis au participant

Les jetons de testnet n'ont aucune valeur monétaire ni conversion promise vers le mainnet ; il n'y a pas de wallet officielle — participez uniquement avec l'outillage en ligne de commande et la documentation publiés officiellement ; **aucun flux n'exige jamais que votre mnémonique entre dans une étape de divulgation** — quiconque « officiel » demande votre mnémonique est un escroc ; il n'y a actuellement aucune vente de jetons, aucun tour privé, aucune whitelist ni inscription à un airdrop.

### 8.5 Governance, upgrades et limite économique

À ce stade pre-testnet, BEYUL **n'a pas de governance décentralisée**. Les upgrades du protocole et les pins critiques pour la sécurité — paramètres de genesis et le **verifying key épinglé (pinned)** — sont contrôlés par l'**ensemble initial de validateurs avec l'Owner**. Il s'agit d'un modèle de confiance centralisé, énoncé clairement ; il ne sera décentralisé progressivement qu'à mesure que le réseau et sa governance mûriront (pas de DAO, aucun calendrier de décentralisation promis). Exploiter un validateur ne confère pas en soi l'autorité d'upgrade ; le pinned VK et le genesis ne sont modifiés que par le chemin d'upgrade « ensemble de validateurs + Owner ».

**Limite économique.** La dénomination, l'offre et les paramètres économiques sont des **décisions de l'Owner — sous gate, et non définies dans ce whitepaper** (voir Statut du jeton, ci-dessus). Rien ici ne fixe une dénomination, une offre ou un modèle token-économique.

## 9. Threat Model (public jusqu'à atténuation)

Organisé par classe d'adversaire, aligné sur le modèle d'adversaire du yellow paper (A1–A4). Ceci est un résumé ; le yellow paper est la référence autoritative du threat model, et les deux documents ne doivent pas diverger — en cas de divergence, le yellow paper prévaut.

- **A1 — Observateur passif de la chaîne** (ne lit que les données publiques de la chaîne) : corrélation de montants sur les dépôts/retraits publics, corrélation de timing, canaux auxiliaires de frais/gas — **non atténué**. Commitments, nullifiers, anchors et le compte de flux net du pool sont publics par conception.
- **A2 — Adversaire réseau / infrastructure** (mempool, RPC, ordonnancement de validateurs, IP) : observation du mempool, ordonnancement et censure des validateurs, métadonnées de couche réseau — **non atténué** (ordonnancement/censure partiellement hors périmètre du protocole) ; métadonnées d'exchange/bridge hors protocole — **hors périmètre**.
- **A3 — Adversaire côté divulgation** (un destinataire de divulgation ou quelqu'un détenant un code) : le transfert d'une divulgation par un destinataire est **cryptographiquement incontrôlable** ; la révocation **n'est pas implémentée** ; exposition des séries temporelles et du patrimoine net de l'ADC lors d'instantanés répétés ; émission sous contrainte — **énoncé clairement, non atténué**.
- **A4 — Adversaire endpoint / social** (l'appareil de l'utilisateur, phishing) : phishing et ingénierie sociale pour des mnémoniques ou des codes, fausses wallets et faux canaux officiels — **non atténué** ; traité par l'éducation des utilisateurs et la liste des canaux officiels.

Transversal, non résolu : bugs de circuit, trusted setup, audit externe — **non vérifié / non résolu / non terminé**. L'intégrité de l'offre du pool (la gate G-S) est ouverte ; la conservation et le double-spend **ne sont pas affirmés comme propriétés de production**, en attente de value-balance in-circuit et keeper avec cohérence de largeur 128↔64 bits (miroir du yellow paper §12.3). La confusion sur la valeur des jetons de testnet et les récompenses **n'est pas autorisée** — les jetons de test n'ont aucune valeur et toute comptabilité de récompenses est simulée.

## 10. Roadmap (basée sur des gates, sans promesse de date)

> Chaque capacité doit se trouver dans exactement un état : Implemented / Local tested / Prototype / Documentation only / Planned / Unverified / Not implemented. Aucune affirmation ne peut être écrite comme « implémentée » sans commit, enregistrement CI, commande de test et sortie.

| Phase | Objectif | Critères de sortie (résumé) |
|---|---|---|
| Phase 0 — Clôture des preuves et cadrage du document **← actuel** | Clôturer l'evidence appendix ; cadrer le récit public sur le testnet | Chaque affirmation implémentée prouvée ; aucune implication token/wallet/DeFi/mainnet |
| Phase 1 — Préparation du testnet | Compléter la checklist de la Section 8.2 | Devnet 3+ nœuds stable ; runbook reproductible ; checks de PR au vert |
| Phase 2 — Testnet public | Expérimentation publique contrôlée | Des nœuds externes peuvent rejoindre ; abus de faucet contrôlé ; pas de tromperie mainnet ou rendement |
| Phase 3 — TDC MVP | Grant de transaction unique de bout en bout | Comportement sûr en cas de code erroné/expiré/épuisé ; existence du grant non divulguée ; champs limités uniquement |
| Phase 4 — ADC_L1 | Proof of funds de borne inférieure | Jamais décrit comme solde exact ; risque de série temporelle public ; TDC/ADC mutuellement non ouvrables |
| Phase 5 — Vérification de divulgation on-chain | Vérification root-bound | Chain/root/scope/asset erronés tous rejetés ; protection anti-replay |
| Phase 6 — Chemin ZK de production | Système de preuve auditable | Dev verifying keys retirés ; audit cryptographique externe ; aucune affirmation « production ZK » avant achèvement |
| Phase 7 — ADC_L2 | Instantané de solde exact | Complétude prouvable ; pas de fuite d'historique ; ne devient jamais une viewing key de longue durée |
| Phase 8 — Audit externe et pre-mainnet | Revue pre-mainnet | Audits protocole/cryptographie/implémentation ; revue juridique ; paquet de preuves public |

L'ordre n'est pas réversible : **testnet → TDC MVP → ADC_L1 → vérification root-bound → production ZK → ADC_L2 → audit → pre-mainnet.**

## 11. Limite de conformité

BEYUL n'est pas une solution de conformité : il n'implémente aucun flux d'AML, KYC, travel-rule, gel, screening de sanctions ou reporting, et ne prétend pas être « compliant by design ». Toute divulgation est initiée par l'utilisateur ; le protocole n'a aucun canal de divulgation forcée ; la conception actuelle n'inclut pas de viewing key globale contrôlée par le projet (à vérifier par implémentation ouverte et audit). Les institutions et les particuliers doivent évaluer de façon indépendante la posture réglementaire de leur juridiction à l'égard des actifs de confidentialité.

## 12. Déclaration de risque et avertissement

Ce document est fourni à titre informatif uniquement et ne constitue pas, et ne doit pas être interprété comme : une offre ou une vente d'un titre, d'une marchandise ou d'un instrument financier ; un conseil en investissement, juridique, fiscal ou financier ; ou une déclaration de conformité dans une quelconque juridiction. Il contient des déclarations prospectives (objectifs de conception, plans de testnet, roadmap) soumises à une incertitude importante ; les résultats réels peuvent différer sensiblement.

Ce projet n'a actuellement **aucun jeton émis** ; les jetons de testnet, s'ils sont utilisés, n'ont aucune valeur monétaire. Participer à des réseaux de crypto-actifs comporte des risques importants. Faites vos propres recherches et consultez des conseillers professionnels. Là où une traduction entre en conflit avec cette version canonique anglaise, cette version anglaise prévaut. Cet avertissement est un modèle générique et doit être revu par un conseil juridique dans la juridiction concernée avant toute publication publique formelle.

## 13. Conclusion

L'orientation de BEYUL est la confidentialité par défaut avec divulgation contrôlée par l'utilisateur. Ses atouts crédibles aujourd'hui : un prototype de chain-application, un prototype de dérivation TDC/ADC côté client testé localement, et une table d'état et un threat model maintenus strictement alignés sur l'implémentation. Le seul focus actuel concerne les **prérequis du lancement du testnet public** : clôture des preuves, le runbook multi-nœuds, faucet et monitoring, et documentation du participant. Tant que la preuve correspondante n'existe pas, ce projet ne fait aucune affirmation de mainnet, de jeton, de confidentialité de production ou de conformité.