# BEYUL Whitepaper — Pre-Testnet Edition: Architektur und Offenlegungsmodell

> **Dies ist eine Übersetzung. Die englische Fassung ist die maßgebliche (canonical) Version und hat im Konfliktfall Vorrang.** Technische Bezeichner (BEYUL, BYL, `privacychain`, TDC, ADC, nullifier, commitment, viewing key, shielded pool, Groth16 usw.) bleiben unübersetzt auf Englisch.

**Projekt:** BEYUL　**Typ:** Forschungsprototyp einer Privacy-Public-Chain (pre-testnet). Die BEYUL-Protokollarbeit wird derzeit im Repository `privacychain` entwickelt.
**Dokumentstatus:** BEYUL-Whitepaper, **Pre-Testnet- (Forschungs-) Edition** — es beschreibt die Architektur des Protokolls, das Offenlegungsmodell und die aktuellen Grenzen vor dem öffentlichen Testnet. Es ist **keine** produktionsreife Protokollspezifikation, kein Investmentdokument, keine Compliance-Stellungnahme, kein Sicherheitsaudit, kein Token-Emissionsmaterial und keine Mainnet-Ankündigung. Fähigkeitsaussagen folgen der Evidenz-Disziplin in §3.1; nichts hier wird über seinen tatsächlichen Reifegrad hinaus beschrieben.
**Token-Status:** Die Tokenomics sind nicht final. **BYL** ist lediglich die Kurzform / das Ticker-Kürzel des Projekts; es ist **keine** eingefrorene Denomination — Denomination und Chain-Parameter stehen weiterhin unter dem ausdrücklichen Vorbehalt der Owner-Freigabe. Dieses Dokument definiert keine Token-Allokation und kein Utility-Design. Testnet-Token haben, falls verwendet, keinen Geldwert und keine zugesagte Mainnet-Umwandlung.
**Maßgebliche Sprache:** Die englische Fassung ist die einzige maßgebliche Version. Die chinesische Fassung (`beyul-whitepaper-pretestnet.zh.md`) ist ein begleitender Arbeitstext; bei Widersprüchen hat die englische Fassung Vorrang.

---

## Claims-Grenzbox (zuerst lesen)

Dieses Dokument erhebt **keine** der folgenden Behauptungen:

- Keine Behauptung von Anonymität, Unverfolgbarkeit oder „absoluter Sicherheit";
- Keine Behauptung produktionsreifer Zero-Knowledge-Sicherheit (die aktuelle Implementierung verwendet Development-Key-Material);
- Keine Behauptung produktionsreifer Privatsphäre (Einzahlungs- und Auszahlungsbeträge sind derzeit on-chain öffentlich);
- Keine Behauptung regulatorischer Genehmigung oder „Compliance by design";
- Das aktuelle Design enthält keinen projektkontrollierten globalen viewing key; diese Eigenschaft muss durch offene Implementierung, Tests und externes Audit verifiziert werden;
- Es existieren kein öffentliches Testnet und kein Mainnet; **die Testnet-Bereitschaft ist in Arbeit — das Multi-Node-Runbook und zugehörige Gates sind noch nicht abgeschlossen**;
- Keine Zusage von Token-Wert, Airdrops, Rendite, Erträgen oder Börsenlistings; dieses Dokument behandelt keine Wallet-Produkte und kein DeFi;
- Der 16-character disclosure code ist kein zugrunde liegendes kryptografisches Sicherheits-Credential (Abschnitt 7).

**Benennung und technische Bezeichner.** BEYUL ist der Projekt-/Produktname; die BEYUL-Protokollarbeit wird derzeit im Repository `privacychain` entwickelt. `privacychain` bleibt der aktuelle technische Bezeichner — Repository, Protokoll-/Modul-/Proto-Paket, Binary und Chain-ID — und wird unverändert beibehalten. **BYL** ist die Kurzform / das Ticker-Kürzel; Denomination und Chain-Parameter stehen weiterhin unter dem Vorbehalt der ausdrücklichen Owner-Freigabe, daher ist BYL keine eingefrorene Denomination. Diese Benennungs-Disziplin gilt nur vorwärtsgerichtet: historische Dokumente werden nicht rückwirkend umbenannt.

---

## 1. Kurzfassung

BEYUL ist ein Privacy-Public-Chain-Projekt im **Forschungsprototyp-Stadium (pre-testnet)**, das Zahlungsinfrastruktur mit **Privatsphäre standardmäßig (einem Designziel)** und nutzerkontrollierter Offenlegung erforscht. Im Zieldesign sind Transaktionsdetails standardmäßig nicht öffentlich sichtbar, aber der Vermögensinhaber kann freiwillig, mit begrenztem Umfang, gegenüber einer gewählten Partei offenlegen — ein Transaction Disclosure Code (TDC) erklärt eine einzelne Transaktion; ein Asset Disclosure Code (ADC) legt einen ausgewählten Vermögens-Snapshot offen. „Privatsphäre standardmäßig" beschreibt das Designziel, nicht den aktuellen Prototyp (siehe §5).

**Was heute existiert, ist lediglich ein client-seitiger disclosure-code-Ableitungsprototyp** (lokal getestet; das öffentliche Evidenzpaket steht noch zur Konsolidierung aus) sowie ein auf dem Cosmos SDK basierender Chain-Application-Prototyp. End-to-End-Server-seitige Grants, On-Chain-Verifikation und ZK-Balance-Proofs sind nicht implementiert; es gibt kein Trusted Setup, kein externes Audit, kein öffentliches Testnet und kein Mainnet; Einzahlungs- und Auszahlungsbeträge sind derzeit on-chain öffentlich. Zweck dieses Whitepapers (Pre-Testnet-Edition) ist es, die architektonische Richtung, das Offenlegungsmodell und die aktuellen Grenzen vor dem öffentlichen Testnet-Start akkurat festzuhalten — und erst dann durch eine Produktions-Edition ersetzt zu werden, wenn die entsprechende Evidenz und die Audits vorliegen.

## 2. Positionierung und Problem

Öffentliche Ledger legen Zahlungsbeziehungen, Salden und Geldflüsse gegenüber jedem Beobachter offen; zugleich machen die meisten Strong-Privacy-Systeme *selektive* Offenlegung operativ schwierig — eine einzelne Transaktion einer Partei zu erklären bedeutet oft, die Fähigkeit zur Einsicht in alles abzugeben. Die Lücke, die BEYUL erforscht: „Offenlegung" zu einem erstrangigen Primitiv gleichrangig mit „Verbergen" zu machen, wobei jede Offenlegung vom Nutzer ausgeht.

BEYUL konkurriert nicht um — und zielt nicht auf — ein Narrativ „vollständig anonym, unverfolgbar".

**Vision.** Finanzielle Privatsphäre auf öffentlichen Ledgern ist invertiert: standardmäßig nackt, während Verbergen selbst verdächtig wirkt. BEYULs Ziel ist es, diesen Default umzukehren — Privatsphäre als Standardzustand und Offenlegung als bewusste, feingranulare Wahl des Nutzers: welche Transaktion, welche Felder, gegenüber wem und für wie lange.

**Designprinzipien.** Jeder Teil des Protokolls wird daran gemessen:

1. **Offenlegung ist ein erstrangiger Bürger** — Offenlegungs-Primitive werden auf gleichem Rang wie Verbergungs-Primitive entworfen und prototypisiert.
2. **Geringste Berechtigung** — jeder Schlüssel und jedes Credential trägt nur die Mindestberechtigung, die sein Zweck erfordert.
3. **Die Ausgabeberechtigung (spend authority) ist sakrosankt** — kein Offenlegungsfluss darf die spend authority berühren; die Mnemonic gelangt in keinen Offenlegungsschritt.
4. **Kein globales Privileg** — das Protokoll ist **so konzipiert**, dass es keinen globalen Einsichtskanal für das Projekt oder Dritte bereitstellt; das Fehlen eines solchen Zweigs ist eine **durch offene Implementierung, Tests und externes Audit zu verifizierende Designeigenschaft (§6)**, noch keine Garantie.
5. **Grenz-Ehrlichkeit** — jede Fähigkeit benennt, was sie nicht tut; Threat Model und Limitationen bleiben öffentlich.
6. **Evidenz zuerst** — Fähigkeitsaussagen werden erst hochgestuft, nachdem Evidenz (Code, Tests, Audits) existiert — gate-basiert, ohne Datumszusagen.

### 2.1 Wie sich BEYULs Offenlegung vergleicht

> Die Tabelle vergleicht BEYULs **Zieldesign** mit den **aktuellen, ausgelieferten Fähigkeiten** anderer Systeme. BEYULs unten genannte Unterscheidungsmerkmale (Ablauf, Widerruf, konsens-erzwungene Sichtbarkeit, per-Transaction-/per-Snapshot-Begrenzung mit Server- und On-Chain-Verifikation) sind weitgehend **geplant oder client-seitiger Prototyp** (siehe §3, §7), noch nicht ausgeliefert. Wettbewerber-Fakten sind konservativ formuliert; für dieses Whitepaper nicht unabhängig nachverifizierte Punkte sind mit **【to verify】** markiert.

| System | Offenlegungsmechanismus | Granularität | Ablauf-/widerrufbar | Sichtbarkeit erzwungen durch |
|---|---|---|---|---|
| Zcash (Sapling/Orchard) | Full viewing key (FVK/IVK) | Kontoweit, alles-oder-nichts | Nein | Ausgehende Sichtbarkeit hängt von einer Wallet-Konvention ab (ovk-verschlüsselter Ciphertext), nicht vom Konsens |
| Monero | View key | Kontoweit (eingehend) | Nein | Wallet / Protokoll; kein begrenztes per-Transaction-Primitiv |
| Mixer vom Tornado-Typ | Nativ keiner (externe Werkzeuge, z. B. Association-/Exclusion-Proofs) | — | — | — |
| Penumbra | Geschichtete viewing keys (FVK/IVK/OVK) + per-Address detection key (FMD / S-FMD) | Viewing keys kontoweit; detection key = **Empfänger-Erkennung (receiver discovery)** (nur Verknüpfung, kein Inhalt), per-Address delegierbar | In den Docs nicht angegeben 【to verify】 | Kryptografische Schlüssel-Delegation (Client/Wallet), nicht Konsens |
| Aztec | Eingehende/ausgehende + **master** viewing keys; **tagging-based** note discovery (kein FMD); verschlüsselte Logs | Master viewing key **alles-oder-nichts über alle Contracts hinweg**; begrenzte/temporäre Offenlegung nur über die App-Ebene (Noir), nicht protokoll-nativ | Nur als App-Ebenen-„temporary view access", nicht nativ 【to verify】 | App-/Contract-Logik + Client (PXE), nicht der Basiskonsens |
| Namada (MASP) | Shielded viewing key (zvknam), Sapling-abgeleitet, multi-asset | **Kontoweit** (Saldo & Historie eines shielded account, ein- und ausgehend); „selektive Offenlegung" = Teilen des viewing key (gesamtes Konto), nicht per-Transaction | Geteilter viewing key nicht nativ widerrufbar (genaue Semantik 【to verify】) | Viewing key (Wallet/Client) |
| **BEYUL (Zieldesign)** | **TDC** (per-Transaction) + **ADC** (per-Asset-Snapshot), **gestuft** (ADC L1/L2) | Per-Transaction / per-Snapshot; begrenzte Felder; Sender-/Empfänger-Rollen getrennt | **Ablauf + Widerruf (geplant)** | **Konsens-erzwungene Sichtbarkeitsgrenze (Designanforderung, §6); Zwei-Faktor + read-only** |

Das beabsichtigte Unterscheidungsmerkmal ist nicht „stärkeres Verbergen", sondern **feingranularere, zeitlich begrenzte, vom Nutzer ausgegebene Offenlegung**: Wo ein Zcash-/Monero-viewing-key eine kontoweite, alles-oder-nichts, unbefristete Lesegewährung ist, ist ein BEYUL-Disclosure-Credential auf eine Transaktion (TDC) oder einen Asset-Snapshot (ADC) begrenzt, trägt einen Ablauf und ist auf Widerrufbarkeit ausgelegt — wobei die sichtbare Feldmenge durch den Konsens statt durch eine Wallet-Konvention erzwungen wird. Diese Eigenschaften sind Designziele; ihr Implementierungsstand wird in §3 und §7 ehrlich nachgehalten.

> **Quellen.** Zcash/Monero: der ZEC/XMR-Tiefenforschungsbericht dieses Projekts (Primärquellen — Zcash Protocol Specification; Monero-Dokumentation; Stand 2026-06-12). Die Zeilen zu Penumbra / Aztec / Namada beschreiben die **offizielle Dokumentation des jeweiligen Projekts mit Stand 2026-06** (Penumbra: protocol.penumbra.zone — viewing keys, FMD; Aztec: docs.aztec.network — keys, note discovery; Namada: docs.namada.net — shielded accounts). Verbleibende 【to verify】-Punkte — Penumbra Ablauf/Widerruf & Transaction-Perspective-Semantik, Aztec native Ablauf/Widerruf, Namada genaue Widerruf-Semantik — stehen noch zur Bestätigung aus. Diese Zeilen geben wieder, was die Dokumentation des jeweiligen Projekts beschreibt, und sind keine Aussagen darüber, was andere Systeme „nicht können".

## 3. Aktueller Stand

| Bereich | Status | Anmerkungen |
|---|---|---|
| Chain-Application | Prototyp | Cosmos SDK / Ignite |
| Konsens / Validator-Modell | Testnet-Design | CometBFT BFT mit einem PoS-artigen initialen Validator-Set und Staking-Modul; kein PoW; keine mainnet-reife PoS-Ökonomie-Sicherheit |
| Shielded module | Prototyp | Einzahlung, Auszahlung, Spend, viewing-key-Registrierung, Note-Offenlegung |
| Commitments / Merkle tree / nullifiers | Prototyp | Deterministisches Verhalten und Double-Spend-Ablehnung durch Tests abgedeckt |
| Disclosure-code-Client-Key-Stack (TDC/ADC-Ableitung) | Prototyp, lokal getestet | **Öffentliches Evidenzpaket (commit/CI) steht zur Konsolidierung aus** |
| Server-Grant-Stack / On-Chain-Offenlegungsverifikation / ZK-Balance-Proof | Nicht implementiert | Geplant |
| Eingehend/ausgehend-view-key-Trennung / audit key / **server-/konsens-erzwungener** Ablauf & Widerruf der Offenlegung | Nicht implementiert | Geplant |
| Trusted Setup / externes Audit | Nicht abgeschlossen / nicht begonnen | Voraussetzungen für jede Produktionsaussage |
| Öffentliches Testnet / Mainnet | Nicht deployt | **Testnet-Bereitschaft in Arbeit: Multi-Node-Runbook und zugehörige Gates noch nicht abgeschlossen** |
| Offizielle Wallet | Existiert nicht | Nur Entwicklungs- und Test-Tooling; jede „offizielle Wallet" ist eine Fälschung |
| Token-Ökonomie | Nicht final | Dieses Dokument enthält kein Token-Design |

### 3.1 Evidenzkette

Jede Zeile „Prototyp implementiert" oben ist an einen Evidenzeintrag gebunden — nicht in Prosa behauptet. Die Evidenzkette (commit hash, CI-Eintrag, exaktes Testkommando und Ausgabe, reproduzierbare Ausführungsanweisungen) wird im **Evidence Appendix** geführt, und jede Fähigkeit wird auf einer Forschungsreife-Skala **L0–L5** eingestuft (Design → Prototyp → reproduzierbar → begutachtet → Netzwerk-Evidenz → Produktion). Dieses Whitepaper verweist auf dieses Register, statt Rohevidenz zu wiederholen.

| Fähigkeit | Reifegrad | Evidenzbindung |
|---|---|---|
| Disclosure-code-Client-Kern (TDC/ADC-Ableitung, Zwei-Faktor, Domain-Trennung, AEAD/AAD, Erasure Keys) | L1–L2 | Read-only reproduziert 2026-06-19: **13/13** lokale Tests bestanden; commit im Evidence Appendix E1 erfasst; CI **【to be supplied】** |
| Shielded module (commitment/nullifier/Merkle, Double-Spend-Ablehnung) | L1 | Read-only reproduziert 2026-06-19: Double-Spend- & nullifier-Tests bestanden; Evidence Appendix E3; CI **【to be supplied】** |
| Groth16-Spend-Pfad | L1 (dev-key) | dev/skeleton VK, kein Trusted Setup; dev-Pfad- + production-VK-guard-Tests reproduziert 2026-06-19; Evidence Appendix E4 |
| Server-Grant-Stack / On-Chain-Verifikation / ZK-Balance-Proof | L0 (geplant) | Nicht implementiert; siehe Roadmap §10 |

> Aktuelle Selbsteinschätzung: Der Großteil des Materials liegt bei **L1–L2**, nichts bei L5. Bis die Evidence-Appendix-Einträge gefüllt sind (commit/CI), sagen öffentliche Materialien „lokal verifiziert; öffentliches Evidenzpaket steht zur Konsolidierung aus", nicht „implementiert mit öffentlicher Evidenz". Eine Fähigkeit ohne registrierten Evidenzeintrag darf nicht über ihren Reifegrad hinaus beschrieben werden. Der Evidence Appendix liegt unter `docs/evidence-appendix.md` (intern; wird mit dem öffentlichen Evidenzpaket veröffentlicht); E1/E3/E4 wurden am 2026-06-19 read-only reproduziert, die CI-Bindung steht noch aus.

## 4. Technisches Modell

Der Prototyp zentriert sich um eine Shielded-Pool-Zustandsmaschine. Für Nicht-Kryptografen verläuft der Lebenszyklus eines privaten Guthabens wie folgt:

1. **Note.** Ein ausgebbares Guthaben ist eine *Note* — ein Datensatz aus (Eigentümer, Betrag, Zufallswert). Die Note selbst erscheint nie on-chain.
2. **Commitment.** Die Chain speichert nur ein *Commitment* auf die Note (ein Einweg-Bindungs-Hash), angehängt an einen ausschließlich anwachsenden **Merkle commitment tree**. Aus dem Commitment allein erfährt ein Beobachter weder Eigentümer noch Betrag.
3. **Spend → nullifier.** Um eine Note auszugeben, veröffentlicht der Eigentümer einen davon abgeleiteten *nullifier*. Der nullifier ist **darauf ausgelegt**, für Außenstehende nicht mit dem Commitment verknüpfbar zu sein (unter einer nullifier-key-PRF-Annahme; Yellow Paper §7.1), ist aber für diese Note deterministisch — sodass dieselbe Note nur einmal nullifiziert werden kann.
4. **Double-Spend-Ablehnung.** Die Chain führt ein nullifier-Set; ein wiederholter nullifier wird abgelehnt. Dies verhindert Double-Spends, **ohne preiszugeben, welche Note ausgegeben wurde**.
5. **Gültigkeitsbeweis.** Ein Spend trägt einen Zero-Knowledge-Beweis dafür, dass „ich eine Note besitze, deren Commitment im Baum liegt, und ihren nullifier korrekt abgeleitet habe", ohne einen dieser Werte preiszugeben. Die Verifikation läuft über einen Groth16-Pfad.

**Der aktuelle Verifier verwendet development/skeleton-verifying-key-Material ohne Trusted Setup und begründet keine produktionsreife Soundness oder Privatsphäre.** Standard-Außenformulierung: „Der Prototyp enthält einen development-key-Groth16-Verifikationspfad. Er bietet noch keine produktionsreife Zero-Knowledge-Sicherheit." Für die formalen Definitionen von Note-Format, Commitment-Schema, nullifier-Ableitung und Baum-Semantik siehe das Yellow Paper §§5–7 und §10.

### 4.1 Warum eine eigenständige Chain und warum Cosmos

Das Offenlegungsmodell benötigt Kontrolle über Dinge, die ein Smart-Contract-Deployment auf einer geteilten L1 oder ein generischer Rollup nicht sauber bieten:

- **Konsens-erzwungene Offenlegungs-Sichtbarkeit** (§6) und die **Supply-Integritäts-Regeln** des Shielded Pool müssen auf der Zustandsübergangs-/Konsensebene liegen, nicht in einem Contract, dessen Host-Chain-Validatoren und Gebührenmarkt außerhalb der Kontrolle des Projekts liegen.
- **Nativer Shielded-State** (commitment tree, nullifier-Set, Value-Balance-Buchführung) ist als erstrangiger Chain-State günstiger und auditierbarer als als Contract-Storage und vermeidet, dass das Public-Mempool- und Metadaten-Modell der Host-Chain mehr leakt als beabsichtigt.
- **Ein bonded-PoS-Validator-Set** lässt die Supply-Integrität von jedem Full Node neu prüfen und bietet sofortige Finalität, die für Zahlungen geeignet ist.

**Cosmos SDK + CometBFT** wird wegen eines ausgereiften BFT-PoS-Stacks mit Staking-/Slashing-Modulen, souveräner Upgrade-Governance und sofortiger Finalität gewählt — nicht als Befürwortung irgendeines Token-Modells (keines ist final). Dies ist eine Architektur-Auswahlbegründung, keine Behauptung, dass die eigenständige Chain deployt sei; für den tatsächlichen Stand siehe §3 und §8.

### 4.2 Performance-Eigenschaften

Zwei Arten von Kennzahlen werden getrennt gehalten. **Inhärent (Schema-Ebene, zitierbar):** Groth16 über die BN254-Kurve hat **konstant große Proofs** (drei Gruppenelemente: 2×G1 + 1×G2, ~128 B komprimiert / ~256 B unkomprimiert auf BN254) und **konstant-zeitige Verifikation** (eine feste, kleine Anzahl von Pairing-Prüfungen, unabhängig von der Schaltkreisgröße). Dies folgt aus dem Beweissystem selbst, nicht aus BEYULs Implementierung. **System-Ebene (noch nicht gemessen):** Beweiszeit, Transaktionsdurchsatz (TPS) und Schaltkreisgröße (Constraint-Anzahl) hängen vom Produktions-Schaltkreis ab, der **nicht gebaut ist** — der aktuelle Pfad verwendet einen dev/skeleton-verifying-key (§4). Jede solche Zahl ist daher ein **target / 【to be supplied】**, das zu benchmarken ist, sobald der Produktions-Schaltkreis und ein Trusted-Setup- oder transparenter Beweispfad existieren (Roadmap §10, Phase 6). Oberhalb dieser Linie wird keine Performance-Zahl auf System-Ebene behauptet.

## 5. Privacy-Modell und aktuelle Grenzen

| Dimension | Zielmodell | Aktueller Prototyp |
|---|---|---|
| Pool-interne Beträge und Sender-/Empfänger-Verknüpfung | Verborgen | Prototyp-Pfad, nicht produktionsreif |
| Einzahlungs-/Auszahlungsbeträge | Design ausstehend | **Öffentlich** |
| Timing / Fee-Seitenkanäle / Mempool | Entschärfung ausstehend oder außerhalb des Scopes | Nicht entschärft |
| Validator-Ordering / Zensur / MEV | Teilweise außerhalb des Protokoll-Scopes | Nicht entschärft |
| Netzwerk-Ebene und Exchange-/Bridge-Metadaten | Außerhalb des Protokoll-Scopes | Außerhalb des Scopes |

**Der aktuelle Prototyp ist keine produktionsreife Privatsphäre.**

Bei pre-testnet / geringer Nutzung ist das Anonymity-Set klein oder leer; ohne echte Nutzer ist Pool-interne Privatsphäre nicht sinnvoll etabliert — **starke Privatsphäre hängt von einem großen, aktiven Anonymity-Set ab und wird NICHT behauptet, bis echte Nutzung existiert**. Validator-Layer-Ordering/MEV und Netzwerk-Metadaten bleiben nicht entschärft.

Ein formales Anonymity-Set-Framework (wie das Anonymity-Set des Shielded Pool definiert und begrenzt wird) wird im Yellow Paper (§15) geführt; dieser Abschnitt benennt die Privacy-Ziele und aktuellen Grenzen, nicht jenes formale Modell.

## 6. Schlüssel- und Offenlegungsmodell

Von höchster zu niedrigster Berechtigung: **Spend Key** (alleinige Ausgabeberechtigung; verlässt nie das Gerät des Nutzers; nimmt nie an Offenlegungsflüssen teil) → **Full View Key** (read-only; geplante Trennung eingehend/ausgehend) → **Audit Key** (geplant: freiwillig vom Nutzer ausgestellt; zeitlich begrenzt, im Umfang begrenzt, widerrufbar; kein protokoll-vorgeschriebener Kanal) → **Disclosure Credential** (die minimale Offenlegungseinheit, gebunden an eine Transaktion oder einen Asset-Snapshot) → **16-character disclosure code** (Einstiegs-Kurzcode; kein Schlüssel).

**Grenze der Projekt-Einsichtsberechtigung**: Das aktuelle Design enthält keinen projektkontrollierten master viewing key. Diese Eigenschaft muss durch offene Implementierung, Tests und externes Audit verifiziert werden, statt auf Vertrauen ins Team zu beruhen — Schlüsselableitungspfade werden als Open Source ausgeliefert, und jeder Dritte kann den Ableitungsgraphen auf das Fehlen jedes zum Projekt führenden Zweigs auditieren. Bis ein externes Audit abgeschlossen ist, ist dies eine „zu verifizierende Designeigenschaft", keine Garantie.

**Mnemonic-Politik (Architekturplanung, kein ausgeliefertes Produkt)**: Der Wallet-Root-Key verwendet standardmäßig eine 24-Wort-Mnemonic (BIP39), wobei nachgelagerte Schlüssel per Domain-Trennung (HKDF + Domain-Tags) abgeleitet werden. **Die Mnemonic darf in keinem Offenlegungsfluss auftauchen**; weder disclosure codes noch das `link_secret` dürfen allein aus der Mnemonic ableitbar sein — TDC/ADC-Grants werden im Moment der freiwilligen Offenlegung mittels CSPRNG und lokaler Autorisierung erzeugt.

**Grenze der Offenlegungs-Sichtbarkeit (Designanforderung)**: Der sichtbare Umfang eines Disclosure Credential — einschließlich der Sichtbarkeit der ausgehenden Richtung — soll durch Konsensregeln statt durch Wallet-Implementierungskonvention garantiert werden (eine Branchenlehre aus Zcash, wo die ausgehende Sichtbarkeit von einer Wallet-Konvention abhängt); diese Anforderung landet mit dem On-Chain-Verifikations-Stack (Roadmap Phase 5) und ist heute nicht implementiert.

**Disclosure-Grant-Ebene (ausstehende unabhängige Prüfung)**: Die Disclosure-Grant-Ebene — Scope, Ablauf, Widerruf, Audit-Log und Viewer-Berechtigungen — steht unter dem Vorbehalt einer unabhängigen Produkt- und Sicherheitsprüfung. Bis diese Prüfung abgeschlossen ist, darf auf keine dieser Grenzeigenschaften vertraut werden, und kein Dokument darf implizieren, sie seien etabliert.

## 7. TDC/ADC-Offenlegungsprototyp

### 7.1 Terminologie und Kodierung

Der offizielle Begriff ist der „**16-character Crockford Base32 disclosure code**" (das Alphabet schließt die verwechselbaren Zeichen I/L/O/U aus; ~80 Bit Kurzcode-Entropie), abgekürzt „16-character disclosure code". Formulierungen wie „16-digit code" oder „16-digit security code" werden nicht verwendet — ein rein numerisches Schema (~53 Bit) wurde wegen unzureichendem Entropiebudget verworfen.

> **„Der 16-character disclosure code ist kein zugrunde liegendes kryptografisches Sicherheits-Credential. Er ist ein nutzerfreundlicher Zugangs-Einstiegspunkt; die echte Autorisierung muss gemeinsam durch ein hochentropisches Disclosure Credential, Signaturen, Umfangsbeschränkungen, Ablauf und Verifikationslogik geschützt werden."**

### 7.2 Tatsächlicher aktueller Stand (unbedingt lesen)

Was BEYUL hat, ist ein **lokal getesteter TDC/ADC-client-seitiger Ableitungsprototyp**. End-to-End-Server-Grants, Chain-State-Verifikation und ZK-Balance-Proofs sind **geplant und nicht implementiert**. Es darf daher NICHT behauptet werden, dass: verifizierbare Offenlegung implementiert sei; Guthaben bereits bewiesen werden könnten; ADC exakte Salden beweisen könne; oder disclosure codes on-chain verifiziert werden könnten.

Der Client-Prototyp deckt ab (lokal getestet): Zwei-Faktor-KEK (`link_secret` + 16-character code, beide erforderlich); kanonische Kodierung; TDC-Sender-/Empfänger-Rollenbindung; TDC/ADC-Domain-Trennung (keiner kann den anderen öffnen); AEAD-Envelopes mit AAD-Manipulationsschutz (client-seitiger TDC/ADC-Envelope; der On-Chain-MsgDiscloseNote-Envelope-AAD ist noch ein Target — Yellow Paper §2.3); ein Slow-Hash-Code-Verifier (Zielsuite Argon2id; Produktionsadapter noch nicht angebunden); Erasure-Key-Crypto-Shredding.

### 7.3 TDC- und ADC-Semantik

| Fähigkeit | Gibt preis | Gibt nicht preis | Status |
|---|---|---|---|
| TDC — Transaction Disclosure Code | Begrenzte Felder einer Transaktion/eines Outputs, Sender-/Empfänger-Rollentrennung | Spend authority, vollständige Historie, künftige Transaktionen | Client-Ableitungsprototyp; Server- und Chain-Verifikation nicht implementiert |
| ADC_L1 — Asset Disclosure Code, Untergrenzen-Stufe | Eine nutzergewählte Proof-of-Funds-/Untergrenzen-Aussage | Vollständiger Saldo, Notes, nullifiers, Gegenparteien, Historie | Client-Ableitungsprototyp; **Beweissystem nicht implementiert** |
| ADC_L2 — Asset Disclosure Code, exakte Stufe | Exakter Saldo-Snapshot des gewählten Asset-Sets auf finalisierter Höhe | Notes, nullifiers, Gegenparteien, Historie | **Nur Design**; erfordert eine Vollständigkeitsquelle + ZK-Balance-Proof |

**Das Offenlegungs-Trilemma**: Ein System mit verborgenem Eigentum kann nicht gleichzeitig Saldovollständigkeit, kein Historie-Leak und keinen viewing key versprechen — ein Nutzer kann das Eigentum an ausgewählten Notes beweisen, aber ohne eine zusätzliche Vollständigkeitsquelle nicht beweisen, dass nichts ausgelassen wurde. ADC ist daher gestuft, und ein ADC legt genau den Saldo des gewählten Asset-Sets auf der gewählten Höhe offen — es darf nicht als „gibt den Saldo nicht preis" beschrieben werden.

ADC-Risiken (öffentlich gehalten): Wiederholte Snapshots gegenüber derselben Partei offenbaren Saldoänderungen im Zeitverlauf; die Offenlegung des Nettovermögens ist ein Risiko für die physische Sicherheit und für Nötigung (ADC ist standardmäßig aus und erfordert ausdrückliche Bestätigung); Rotation kann nicht zurücknehmen, was ein Betrachter bereits gesehen hat.

### 7.4 FAQ zum disclosure code

| Frage | Antwort |
|---|---|
| Was ist ein TDC? | Ein Transaction Disclosure Code; er legt nur begrenzte Informationen über eine Transaktion/einen Output offen |
| Was ist ein ADC? | Ein Asset Disclosure Code; er legt einen nutzergewählten Asset-Saldo-Snapshot offen |
| Legt ein ADC den Saldo offen? | Ja — ein ADC legt den gewählten Saldo-Snapshot offen |
| Kann ein disclosure code Guthaben ausgeben? | Nein. Jedes Disclosure Credential muss `canSpend=false` tragen (eine Protokoll-Invariante) |
| Ist ein disclosure code dauerhaft? | Nein. Die **24-Stunden-Lebensdauer ist ein Design-Default, keine derzeit erzwungene Eigenschaft** — Server-/konsens-erzwungener Ablauf und Widerruf sind nicht implementiert; sie werden vom künftigen Layer-2-Grant- und Verifikationsdienst erzwungen (Roadmap Phase 5), nicht heute. Client-seitiger Envelope-Ablauf wird nur im E1-Prototyp demonstriert und kann von jedem, der den Klartext besitzt, ignoriert werden, ist also keine erzwungene Eigenschaft. Per Design sind Credentials zeitlich begrenzt und nutzerkonfigurierbar: längerlebige Offenlegungen erfordern ausdrückliche Bestätigung, dauerhafte Offenlegung ist nicht der Default, und Widerruf (sobald erzwungen) verhindert künftigen Zugriff, kann aber bereits eingesehene oder kopierte Informationen nicht löschen |
| Wird ein disclosure code aus der Recovery-Phrase abgeleitet? | Nein. Disclosure Credentials sind read-only, werden **nie automatisch bei Wallet-Erstellung erzeugt, nie aus der Recovery-Phrase abgeleitet** und können keine spend authority gewähren (`canSpend=false`). TDCs sind per-Transaction-Offenlegungen; ADCs sind opt-in-Asset-Level-Grants |
| Wie ist ein disclosure code geschützt? | Zwei Faktoren (`link_secret` + 16-character code), AEAD-Envelopes, AAD-Bindung, ein Slow-Hash-Verifier; **server-seitiges Rate-Limiting und vereinheitlichte Fehlerantworten sind noch zu implementieren** |
| Ist ein disclosure code ein privater Schlüssel? | Nein. Er kann keine Assets bewegen und nicht die Spend-/View-/Audit-Keys ersetzen; aber teile ihn nicht leichtfertig — einmal offengelegte Informationen können nicht zurückgenommen werden |

## 8. Testnet-Plan (aktueller Fokus)

### 8.1 Validator-Modell

Das Testnet verwendet ein **PoS-artiges BFT-Validator-Modell**: Cosmos SDK + CometBFT, ein initiales Validator-Set und Staking-Modul-Testabläufe. Es ist kein PoW, und es ist **keine mainnet-reife PoS-Ökonomie-Sicherheit** — das Mainnet-Ökonomiemodell ist Langzeitforschung außerhalb des Scopes dieses Whitepapers.

### 8.2 Testnet-Bereitschaft (klar gesagt)

Die Testnet-Bereitschaft ist **in Arbeit**: Das Multi-Node-Runbook und zugehörige Gates sind noch nicht abgeschlossen (die betreffenden Pull Requests sind nicht alle gemergt und Checks bestehen nicht). Bis diese Gates schließen und Evidenz registriert ist, verwendet dieses Projekt keine „testnet-ready"-Sprache.

Pre-Launch-Checkliste: Evidenzpaket geschlossen; Testnet-chain-id und Genesis; Validator-Onboarding-Leitfaden; Multi-Node-Runbook mit 3+ Nodes; Faucet-Politik und Rate-Limiting; Public-RPC/API-Politik; Monitoring-Dashboard; Incident-Response-Prozess; Liste bekannter Limitationen; Teilnehmer-Befehlsfluss; Hinweis „Testnet-Token ohne Wert".

### 8.3 Was das Testnet validieren kann / nicht beweisen kann

**Kann validieren**: Node-Betrieb und Blockproduktion, Staking-Modul-Abläufe, Faucet, RPC, Monitoring und Incident-Response, den disclosure-code-Demo-Fluss, den Shielded-module-Prototyp-Fluss.
**Kann nicht beweisen**: produktionsreife Privatsphäre, mainnet-PoS-Ökonomie-Sicherheit, Token-Wert, regulatorische Akzeptanz, produktionsreife ZK-Soundness. Der Testnet-Start darf nicht als „Produktionsvalidierung" vermarktet werden.

### 8.4 Teilnehmerhinweis

Testnet-Token haben keinen Geldwert und keine zugesagte Mainnet-Umwandlung; es gibt keine offizielle Wallet — nimm nur mit offiziell veröffentlichtem Kommandozeilen-Tooling und Dokumentation teil; **kein Fluss erfordert je, dass deine Mnemonic in einen Offenlegungsschritt gelangt** — jeder „Offizielle", der nach deiner Mnemonic fragt, ist ein Betrüger; es gibt derzeit keinerlei Token-Verkauf, Private Round, Whitelist oder Airdrop-Registrierung.

### 8.5 Governance, Upgrades und ökonomische Grenze

In diesem Pre-Testnet-Stadium hat BEYUL **keine dezentrale Governance**. Protokoll-Upgrades und die sicherheitskritischen Pins — Genesis-Parameter und der **gepinnte verifying key** — werden vom **initialen Validator-Set zusammen mit dem Owner** kontrolliert. Dies ist ein zentralisiertes Vertrauensmodell, klar gesagt; es soll erst dann schrittweise dezentralisiert werden, wenn das Netzwerk und seine Governance reifen (kein DAO, kein Dezentralisierungs-Zeitplan wird zugesagt). Das Betreiben eines Validators verleiht allein keine Upgrade-Berechtigung; der gepinnte VK und Genesis werden nur über den Upgrade-Pfad „Validator-Set + Owner" geändert.

**Ökonomische Grenze.** Denomination, Supply und ökonomische Parameter sind **Owner-Entscheidungen — gated und in diesem Whitepaper nicht definiert** (siehe Token-Status oben). Nichts hier legt eine Denomination, einen Supply oder ein Token-Ökonomiemodell fest.

## 9. Threat Model (öffentlich, bis entschärft)

Nach Angreiferklasse geordnet, abgestimmt auf das Angreifermodell des Yellow Paper (A1–A4). Dies ist eine Zusammenfassung; das Yellow Paper ist die maßgebliche Threat-Model-Referenz, und die beiden Dokumente dürfen nicht auseinanderdriften — bei Abweichungen hat das Yellow Paper Vorrang.

- **A1 — Passiver Chain-Beobachter** (liest nur öffentliche Chain-Daten): Betragskorrelation bei öffentlicher Einzahlung/Auszahlung, Timing-Korrelation, Fee-/Gas-Seitenkanäle — **nicht entschärft**. Commitments, nullifiers, Anchors und das Netto-Fluss-Konto des Pools sind per Design öffentlich.
- **A2 — Netzwerk-/Infrastruktur-Angreifer** (Mempool, RPC, Validator-Ordering, IP): Mempool-Beobachtung, Validator-Ordering und Zensur, Netzwerk-Ebenen-Metadaten — **nicht entschärft** (Ordering/Zensur teils außerhalb des Protokoll-Scopes); protokollfremde Exchange-/Bridge-Metadaten — **außerhalb des Scopes**.
- **A3 — Offenlegungsseitiger Angreifer** (ein Offenlegungsempfänger oder Inhaber eines Codes): Die Weiterleitung einer Offenlegung durch einen Empfänger ist **kryptografisch unkontrollierbar**; Widerruf ist **nicht implementiert**; ADC-Zeitreihen- und Nettovermögens-Exposition bei wiederholten Snapshots; erzwungene Ausstellung — **klar gesagt, nicht entschärft**.
- **A4 — Endpunkt-/Social-Angreifer** (das Gerät des Nutzers, Phishing): Phishing und Social Engineering nach Mnemonics oder Codes, gefälschte Wallets und gefälschte offizielle Kanäle — **nicht entschärft**; adressiert über Nutzeraufklärung und die offizielle Kanalliste.

Querschnittlich, ungelöst: Schaltkreis-Bugs, Trusted Setup, externes Audit — **unverifiziert / ungelöst / nicht abgeschlossen**. Die Pool-Supply-Integrität (das G-S-Gate) ist offen; Erhaltung und Double-Spend werden **nicht als Produktionseigenschaften behauptet**, ausstehend in-circuit- und Keeper-Value-Balance mit 128↔64-Bit-Breitenkonsistenz (spiegelt Yellow Paper §12.3). Verwechslung von Testnet-Token-Wert und Belohnungen ist **nicht zulässig** — Test-Token haben keinen Wert, und jede Belohnungsbuchung ist simuliert.

## 10. Roadmap (gate-basiert, keine Datumszusagen)

> Jede Fähigkeit muss sich in genau einem Zustand befinden: Implemented / Local tested / Prototype / Documentation only / Planned / Unverified / Not implemented. Keine Aussage darf als „implementiert" geschrieben werden ohne commit, CI-Eintrag, Testkommando und Ausgabe.

| Phase | Ziel | Exit-Kriterien (Zusammenfassung) |
|---|---|---|
| Phase 0 — Evidenzschluss und Dokument-Scoping **← aktuell** | Den Evidence Appendix schließen; das öffentliche Narrativ auf das Testnet begrenzen | Jede implementierte Aussage belegt; keine Token-/Wallet-/DeFi-/Mainnet-Implikationen |
| Phase 1 — Testnet-Bereitschaft | Die Checkliste aus Abschnitt 8.2 abschließen | 3+ Node-Devnet stabil; Runbook reproduzierbar; PR-Checks grün |
| Phase 2 — Öffentliches Testnet | Kontrolliertes öffentliches Experiment | Externe Nodes können beitreten; Faucet-Missbrauch kontrolliert; keine Mainnet- oder Rendite-Irreführung |
| Phase 3 — TDC MVP | End-to-End-Single-Transaction-Grant | Verhalten bei falschem Code/Ablauf/erschöpft sicher; Grant-Existenz nicht geleakt; nur begrenzte Felder |
| Phase 4 — ADC_L1 | Proof of Funds als Untergrenze | Nie als exakter Saldo beschrieben; Zeitreihen-Risiko öffentlich; TDC/ADC gegenseitig nicht öffenbar |
| Phase 5 — On-Chain-Offenlegungsverifikation | Root-gebundene Verifikation | Falsche Chain/Root/Scope/Asset alle abgelehnt; Replay-Schutz |
| Phase 6 — Produktions-ZK-Pfad | Auditierbares Beweissystem | Dev-verifying-keys ausgemustert; externes kryptografisches Audit; keine „production ZK"-Aussage vor Abschluss |
| Phase 7 — ADC_L2 | Exakter Saldo-Snapshot | Vollständigkeit beweisbar; kein Historie-Leak; wird nie zu einem langlebigen viewing key |
| Phase 8 — Externes Audit und Pre-Mainnet | Pre-Mainnet-Review | Protokoll-/Krypto-/Implementierungs-Audits; Rechtsprüfung; öffentliches Evidenzpaket |

Die Reihenfolge ist nicht umkehrbar: **Testnet → TDC MVP → ADC_L1 → root-gebundene Verifikation → production ZK → ADC_L2 → Audit → Pre-Mainnet.**

## 11. Compliance-Grenze

BEYUL ist keine Compliance-Lösung: Es implementiert keine AML-, KYC-, Travel-Rule-, Einfrier-, Sanktions-Screening- oder Meldeabläufe und beansprucht nicht, „compliant by design" zu sein. Jede Offenlegung geht vom Nutzer aus; das Protokoll hat keinen erzwungenen Offenlegungskanal; das aktuelle Design enthält keinen projektkontrollierten globalen viewing key (durch offene Implementierung und Audit zu verifizieren). Institutionen und Einzelpersonen sollten die regulatorische Haltung ihrer Jurisdiktion gegenüber Privacy-Assets eigenständig bewerten.

## 12. Risikohinweis und Disclaimer

Dieses Dokument dient ausschließlich Informationszwecken und stellt keines der Folgenden dar und ist nicht als solches auszulegen: ein Angebot oder Verkauf eines Wertpapiers, einer Ware oder eines Finanzinstruments; Anlage-, Rechts-, Steuer- oder Finanzberatung; oder eine Aussage über Compliance in irgendeiner Jurisdiktion. Es enthält zukunftsgerichtete Aussagen (Designziele, Testnet-Pläne, Roadmap), die wesentlicher Unsicherheit unterliegen; tatsächliche Ergebnisse können wesentlich abweichen.

Dieses Projekt hat derzeit **keinen ausgegebenen Token**; Testnet-Token haben, falls verwendet, keinen Geldwert. Die Teilnahme an Krypto-Asset-Netzwerken birgt wesentliche Risiken. Mache deine eigene Recherche und konsultiere fachkundige Berater. Wo eine Übersetzung dieser englischen maßgeblichen Fassung widerspricht, hat diese englische Fassung Vorrang. Dieser Disclaimer ist eine generische Vorlage und muss vor jeder formellen öffentlichen Veröffentlichung von Rechtsbeiständen in der betreffenden Jurisdiktion geprüft werden.

## 13. Fazit

BEYULs Richtung ist Privatsphäre standardmäßig mit nutzerkontrollierter Offenlegung. Seine glaubwürdigen Aktiva heute: ein Chain-Application-Prototyp, ein lokal getesteter TDC/ADC-client-seitiger Ableitungsprototyp sowie eine Statustabelle und ein Threat Model, die streng auf die Implementierung abgestimmt bleiben. Der einzige aktuelle Fokus sind die **Voraussetzungen für den öffentlichen Testnet-Start**: Evidenzschluss, das Multi-Node-Runbook, Faucet und Monitoring sowie Teilnehmer-Dokumentation. Bis die entsprechende Evidenz vorliegt, erhebt dieses Projekt keine Mainnet-, Token-, Produktions-Privacy- oder Compliance-Aussagen.