BEYUL Whitepaper — Pre-Testnet Edition: Architecture and Disclosure Model

Project: BEYUL　Type: Privacy public chain research prototype (pre-testnet). BEYUL protocol work is currently developed in the privacychain repository. Document status: BEYUL whitepaper, pre-testnet (research) edition — it describes the protocol's architecture, disclosure model, and current boundaries before public testnet. It is not a production protocol specification, an investment document, a compliance opinion, a security audit, token-issuance material, or a mainnet announcement. Capability claims follow the evidence discipline in §3.1; nothing here is described above its real maturity. Token status: Tokenomics are not finalized. BYL is the project's short form / ticker only; it is not a frozen denomination — the denomination and chain parameters remain pending explicit owner approval. This document defines no token allocation or utility design. Testnet tokens, if used, have no monetary value and no promised mainnet conversion. Canonical language: This English version is the sole canonical version. The Chinese version (beyul-whitepaper-pretestnet.zh.md) is a working companion text; in any conflict, this English version prevails.

Claims Boundary Box (read this first)

This document does not make any of the following claims:

• No claim of anonymity, untraceability, or "absolute security";
• No claim of production zero-knowledge security (the current implementation uses development-key material);
• No claim of production privacy (deposit and withdraw amounts are currently public on-chain);
• No claim of regulatory approval or "compliance by design";
• The current design does not include a project-controlled global viewing key; this property must be verified through open implementation, tests, and external audit;
• No public testnet and no mainnet exist; testnet readiness is in progress — the multi-node runbook and related gates are not yet complete;
• No promise of token value, airdrops, yield, returns, or exchange listings; this document does not discuss wallet products or DeFi;
• The 16-character disclosure code is not an underlying cryptographic security credential (Section 7).

Naming and technical identifiers. BEYUL is the project/product name; BEYUL protocol work is currently developed in the privacychain repository. privacychain remains the current technical identifier — repository, protocol/module/proto package, binary, and chain-id — and is preserved unchanged. BYL is the short form / ticker; the denomination and chain parameters remain pending explicit owner approval, so BYL is not a frozen denomination. This naming discipline is forward-only: historical documents are not retroactively renamed.

1. Abstract

BEYUL is a research-prototype-stage (pre-testnet) privacy public chain project exploring payment infrastructure with privacy by default (a design goal) and user-controlled disclosure. In the target design, transaction details are not publicly visible by default, but the asset owner can voluntarily disclose, with bounded scope, to a chosen party — a Transaction Disclosure Code (TDC) explains a single transaction; an Asset Disclosure Code (ADC) discloses a selected asset snapshot. "Privacy by default" describes the design target, not the current prototype (see §5).

What exists today is only a client-side disclosure-code derivation prototype (locally tested; the public evidence package is pending consolidation) and a Cosmos-SDK-based chain-application prototype. End-to-end server-side grants, on-chain verification, and ZK balance proofs are not implemented; there is no trusted setup, no external audit, no public testnet or mainnet; deposit and withdraw amounts are currently public on-chain. The purpose of this whitepaper (pre-testnet edition) is to record, accurately, the architectural direction, the disclosure model, and the current boundaries before public testnet launch — and to be superseded by a production edition only when the corresponding evidence and audits exist.

2. Positioning and Problem

Public ledgers expose payment relationships, balances, and fund flows to any observer; meanwhile most strong-privacy systems make selective disclosure operationally difficult — explaining one transaction to one party often means handing over the ability to view everything. The gap BEYUL explores: make "disclosure" a first-class primitive on par with "hiding," with all disclosure initiated by the user.

BEYUL does not compete on — and does not target — a "fully anonymous, untraceable" narrative.

Vision. Financial privacy on public ledgers is inverted: naked by default, while concealment itself looks suspicious. BEYUL's aim is to flip that default — privacy as the default state, and disclosure as the user's deliberate, fine-grained choice: which transaction, which fields, to whom, and for how long.

Design principles. Every part of the protocol is held to these:

1. Disclosure is a first-class citizen — disclosure primitives are designed and prototyped at the same rank as hiding primitives.
2. Least authority — each key and credential carries only the minimum authority its purpose requires.
3. Spend authority is sacrosanct — no disclosure flow may touch spend authority; the mnemonic never enters any disclosure step.
4. No global privilege — the protocol is designed to provide no global viewing channel for the project or any third party; the absence of any such branch is a design property to be verified by open implementation, tests, and external audit (§6), not yet a guarantee.
5. Boundary honesty — every capability states what it does not do; the threat model and limitations stay public.
6. Evidence first — capability claims are upgraded only after evidence (code, tests, audits) exists — gate-based, no date promises.

2.1 How BEYUL's disclosure compares

The table compares BEYUL's target design against other systems' current, shipped capabilities. BEYUL's differentiators below (expiry, revocation, consensus-enforced visibility, per-transaction/per-snapshot scoping with server and on-chain verification) are largely planned or client-side prototype (see §3, §7), not yet shipped. Competitor facts are stated conservatively; items not independently re-verified for this whitepaper are marked 【to verify】.

The intended differentiator is not "stronger hiding" but finer-grained, time-bounded, user-issued disclosure: where a Zcash/Monero viewing key is an account-wide, all-or-nothing, indefinite read grant, a BEYUL disclosure credential is scoped to one transaction (TDC) or one asset snapshot (ADC), carries an expiry, and is designed to be revocable — with the visible field set enforced by consensus rather than by wallet convention. These properties are design targets; their implementation status is tracked honestly in §3 and §7.

3. Current Status

3.1 Evidence chain

Every "prototype implemented" row above is bound to an evidence record — not asserted in prose. The evidence chain (commit hash, CI record, exact test command and output, reproducible run instructions) is carried by the Evidence Appendix, and each capability is graded on a research-maturity scale L0–L5 (design → prototype → reproducible → reviewed → network evidence → production). This whitepaper references that register rather than restating raw evidence.

Current self-assessment: most material is L1–L2, none is L5. Until the Evidence Appendix entries are filled (commit/CI), public materials say "locally verified; public evidence package pending consolidation," not "implemented with public evidence." A capability without a registered evidence record may not be described above its maturity level.

4. Technical Model

The prototype centers on a shielded-pool state machine. For a non-cryptographer, the lifecycle of a private balance runs as follows:

1. Note. A spendable balance is a note — a record of (owner, amount, randomness). The note itself never appears on-chain.
2. Commitment. The chain stores only a commitment to the note (a one-way binding hash), appended to an append-only Merkle commitment tree. From the commitment alone, an observer learns neither owner nor amount.
3. Spend → nullifier. To spend a note, the owner publishes a nullifier derived from it. The nullifier is unlinkable to the commitment by outside observers, but is deterministic for that note — so the same note can be nullified only once.
4. Double-spend rejection. The chain keeps a nullifier set; a repeated nullifier is rejected. This prevents double-spends without revealing which note was spent.
5. Validity proof. A spend carries a zero-knowledge proof that "I own a note whose commitment is in the tree, and I derived its nullifier correctly," revealing none of those values. Verification is wired through a Groth16 path.

The current verifier uses development/skeleton verifying-key material with no trusted setup and establishes no production soundness or privacy. Standard external wording: "The prototype includes a development-key Groth16 verification path. It does not yet provide production zero-knowledge security." For the formal definitions of the note format, commitment scheme, nullifier derivation, and tree semantics, see the yellow paper §§5–7 and §10.

4.1 Why a standalone chain, and why Cosmos

The disclosure model needs control over things a smart-contract deployment on a shared L1, or a generic rollup, does not give cleanly:

• Consensus-enforced disclosure visibility (§6) and the shielded-pool supply-integrity rules must live at the state-transition / consensus layer, not inside a contract whose host chain's validators and fee market are outside the project's control.
• Native shielded state (commitment tree, nullifier set, value-balance accounting) is cheaper and auditable as first-class chain state than as contract storage, and avoids the host chain's public-mempool and metadata model leaking more than intended.
• A bonded-PoS validator set lets supply integrity be re-checked by every full node and gives instant finality suited to payments.

Cosmos SDK + CometBFT is chosen for a mature BFT-PoS stack with staking/slashing modules, sovereign upgrade governance, and instant finality — not as an endorsement of any token model (none is finalized). This is an architecture-selection rationale, not a claim that the standalone chain is deployed; see §3 and §8 for actual status.

5. Privacy Model and Current Limitations

The current prototype is not production privacy.

6. Key and Disclosure Model

From highest to lowest authority: Spend Key (sole spending authority; never leaves the user's device; never participates in disclosure flows) → Full View Key (read-only; planned incoming/outgoing split) → Audit Key (planned: voluntarily issued by the user; time-limited, scoped, revocable; not a protocol-mandated channel) → Disclosure Credential (the minimal disclosure unit bound to one transaction or one asset snapshot) → 16-character disclosure code (entry shortcode; not a key).

Project viewing-authority boundary: the current design does not include a project-controlled master viewing key. This property must be verified through open implementation, tests, and external audit rather than trust in the team — key-derivation paths ship as open source, and any third party can audit the derivation graph for the absence of any branch leading to the project. Until external audit completes, this is a "design property to be verified," not a guarantee.

Mnemonic policy (architecture planning, not a shipped product): the wallet root key defaults to a 24-word mnemonic (BIP39), with downstream keys derived via domain separation (HKDF + domain tags). The mnemonic must never appear in any disclosure flow; neither disclosure codes nor the link_secret may be derivable from the mnemonic alone — TDC/ADC grants are generated at the moment of voluntary disclosure using a CSPRNG and local authorization.

Disclosure-visibility boundary (design requirement): the visible scope of a disclosure credential — including outgoing-direction visibility — is planned to be guaranteed by consensus-layer rules rather than wallet-implementation convention (an industry lesson from Zcash, where outgoing visibility depends on wallet convention); this requirement lands with the on-chain verification stack (roadmap Phase 5) and is not implemented today.

7. TDC / ADC Disclosure Prototype

7.1 Terminology and Encoding

The official term is the "16-character Crockford Base32 disclosure code" (alphabet excludes the confusable characters I/L/O/U; ~80 bits of shortcode entropy), abbreviated "16-character disclosure code." Phrasings such as "16-digit code" or "16-digit security code" are not used — a numeric-only scheme (~53 bits) was rejected for insufficient entropy budget.

"The 16-character disclosure code is not an underlying cryptographic security credential. It is a user-friendly access entry point; real authorization must be protected jointly by a high-entropy disclosure credential, signatures, scope restrictions, expiry, and verification logic."

7.2 Actual Current State (must read)

What BEYUL has is a locally tested TDC/ADC client-side derivation prototype. End-to-end server grants, chain-state verification, and ZK balance proofs are planned and not implemented. It must therefore NOT be stated that: verifiable disclosure is implemented; funds can already be proven; ADC can prove exact balances; or disclosure codes can be verified on-chain.

The client prototype covers (locally tested): two-factor KEK (link_secret + 16-character code, both required); canonical encoding; TDC sender/receiver role binding; TDC/ADC domain separation (neither can open the other); AEAD envelopes with AAD tamper protection; a slow-hash code verifier (target suite Argon2id; production adapter not yet wired); erasure-key crypto-shredding; frozen cross-language vectors.

7.3 TDC and ADC Semantics

The disclosure trilemma: a hidden-ownership system cannot simultaneously promise balance completeness, no history leakage, and no viewing key — a user can prove ownership of selected notes but, absent an additional completeness source, cannot prove nothing was omitted. ADC is therefore tiered, and an ADC discloses exactly the balance of the selected asset set at the selected height — it must not be described as "does not reveal balance."

ADC risks (kept public): repeated snapshots to the same party reveal balance changes over time; net-worth exposure is a physical-safety and coercion risk (ADC defaults to off and requires explicit confirmation); rotation cannot retract what a viewer has already seen.

7.4 Disclosure Code FAQ

8. Testnet Plan (current focus)

8.1 Validator Model

The testnet uses a PoS-style BFT validator model: Cosmos SDK + CometBFT, an initial validator set, and staking-module test flows. It is not PoW, and it is not mainnet-grade PoS economic security — the mainnet economic model is long-term research outside the scope of this whitepaper.

8.2 Testnet Readiness (stated plainly)

Testnet readiness is in progress: the multi-node runbook and related gates are not yet complete (the relevant pull requests are not all merged and checks are not passing). Until those gates close and evidence is registered, this project does not use "testnet-ready" language.

Pre-launch checklist: evidence package closed; testnet chain-id and genesis; validator onboarding guide; 3+ node multi-node runbook; faucet policy and rate limiting; public RPC/API policy; monitoring dashboard; incident-response process; known-limitations list; participant command flow; testnet-token no-value notice.

8.3 What the Testnet Can Validate / Cannot Prove

Can validate: node operation and block production, staking-module flows, faucet, RPC, monitoring and incident response, the disclosure-code demo flow, the shielded-module prototype flow. Cannot prove: production privacy, mainnet PoS economic security, token value, regulatory acceptance, production ZK soundness. Testnet launch must not be marketed as "production validation."

8.4 Participant Notice

Testnet tokens have no monetary value and no promised mainnet conversion; there is no official wallet — participate only with officially published command-line tooling and documentation; no flow ever requires your mnemonic to enter a disclosure step — anyone "official" asking for your mnemonic is a scammer; there is currently no token sale, private round, whitelist, or airdrop registration of any kind.

9. Threat Model (public until mitigated)

Organized by adversary class, aligned with the yellow paper's adversary model (A1–A4). This is a summary; the yellow paper is the authoritative threat-model reference, and the two documents must not drift — where they differ, the yellow paper governs.

• A1 — Passive chain observer (reads only public chain data): amount correlation on public deposit/withdraw, timing correlation, fee/gas side channels — not mitigated. Commitments, nullifiers, anchors, and the pool net-flow account are public by design.
• A2 — Network / infrastructure adversary (mempool, RPC, validator-ordering, IP): mempool observation, validator ordering and censorship, network-layer metadata — not mitigated (ordering/censorship partly out of protocol scope); off-protocol exchange/bridge metadata — out of scope.
• A3 — Disclosure-side adversary (a disclosure recipient or someone holding a code): disclosure forwarding by a recipient is cryptographically uncontrollable; revocation is not implemented; ADC time-series and net-worth exposure on repeated snapshots; coerced issuance — stated plainly, not mitigated.
• A4 — Endpoint / social adversary (the user's device, phishing): phishing and social engineering for mnemonics or codes, fake wallets and fake official channels — not mitigated; addressed via user education and the official channel list.

Cross-cutting, unresolved: circuit bugs, trusted setup, external audit — unverified / unresolved / not completed. Testnet token-value and reward confusion is not permitted — test tokens have no value and any reward accounting is simulated.

10. Roadmap (gate-based, no date promises)

Every capability must sit in exactly one state: Implemented / Local tested / Prototype / Documentation only / Planned / Unverified / Not implemented. No claim may be written as "implemented" without a commit, CI record, test command, and output.

The order is not reversible: testnet → TDC MVP → ADC_L1 → root-bound verification → production ZK → ADC_L2 → audit → pre-mainnet.

11. Compliance Boundary

BEYUL is not a compliance solution: it implements no AML, KYC, travel-rule, freezing, sanctions-screening, or reporting workflows, and does not claim to be "compliant by design." All disclosure is user-initiated; the protocol has no compelled-disclosure channel; the current design does not include a project-controlled global viewing key (to be verified through open implementation and audit). Institutions and individuals should independently assess their jurisdiction's regulatory posture toward privacy assets.

12. Risk Statement and Disclaimer

This document is for informational purposes only and does not constitute, and shall not be construed as: an offer or sale of any security, commodity, or financial instrument; investment, legal, tax, or financial advice; or a representation of compliance in any jurisdiction. It contains forward-looking statements (design goals, testnet plans, roadmap) subject to material uncertainty; actual outcomes may differ materially.

This project currently has no issued token; testnet tokens, if used, have no monetary value. Participating in crypto-asset networks involves material risk. Do your own research and consult professional advisors. Where any translation conflicts with this English canonical version, this English version prevails. This disclaimer is a generic template and must be reviewed by counsel in the relevant jurisdiction before any formal public release.

13. Conclusion

BEYUL's direction is privacy by default with user-controlled disclosure. Its credible assets today: a chain-application prototype, a locally tested TDC/ADC client-side derivation prototype, and a status table and threat model kept strictly aligned with the implementation. The single current focus is the prerequisites for public testnet launch: evidence closure, the multi-node runbook, faucet and monitoring, and participant documentation. Until the corresponding evidence exists, this project makes no mainnet, token, production-privacy, or compliance claims.