Project: Beyul Type: Privacy public chain research prototype (pre-testnet)
Document status: Technical draft. This document is not a protocol whitepaper, a production protocol specification, an investment document, a compliance opinion, a security audit, token-issuance material, or a mainnet announcement.
Token status: Tokenomics are not finalized. This document contains no token symbol, 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-technical-draft-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).
1. Abstract
Beyul is a research-prototype-stage (pre-testnet) privacy public chain project exploring payment infrastructure with privacy by default and user-controlled disclosure: 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.
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 draft is to record, accurately, the architectural direction, the disclosure model, and the current boundaries before public testnet launch.
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.
3. Current Status
| Area | Status | Notes |
|---|---|---|
| Chain application | Prototype | Cosmos SDK / Ignite |
| Consensus / validator model | Testnet design | CometBFT BFT with a PoS-style initial validator set and staking module; not PoW; not mainnet-grade PoS economic security |
| Shielded module | Prototype | Deposit, withdraw, spend, viewing-key registration, note disclosure |
| Commitments / Merkle tree / nullifiers | Prototype | Deterministic behavior and double-spend rejection covered by tests |
| Disclosure-code client key stack (TDC/ADC derivation) | Prototype, locally tested | Public evidence package (commit/CI) pending consolidation |
| Server grant stack / on-chain disclosure verification / ZK balance proof | Not implemented | Planned |
| Incoming/outgoing view-key split / audit key / disclosure expiry and revocation | Not implemented | Planned |
| Trusted setup / external audit | Not completed / not started | Preconditions for any production claim |
| Public testnet / mainnet | Not deployed | Testnet readiness in progress: multi-node runbook and related gates not yet complete |
| Official wallet | Does not exist | Development and test tooling only; any "official wallet" is an impostor |
| Token economics | Not finalized | This document contains no token design |
4. Technical Model
The prototype centers on a shielded-pool state machine: assets are represented as notes; only commitments appear on-chain, inserted into a Merkle commitment tree; spending publishes a nullifier, and duplicates are rejected — preventing double-spends without revealing which note was spent. Spend verification is wired through Groth16 verification code — 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."
5. Privacy Model and Current Limitations
| Dimension | Target model | Current prototype |
|---|---|---|
| In-pool amounts and sender/receiver linkage | Hidden | Prototype path, not production |
| Deposit / withdraw amounts | Design pending | Public |
| Timing / fee side channels / mempool | Mitigation pending or out of scope | Not mitigated |
| Validator ordering / censorship / MEV | Partly out of protocol scope | Not mitigated |
| Network-layer and exchange/bridge metadata | Out of protocol scope | Out of scope |
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.
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
| Capability | Reveals | Does not reveal | Status |
|---|---|---|---|
| TDC — Transaction Disclosure Code | Scoped fields of one transaction/output, sender/receiver role separation | Spend authority, full history, future transactions | Client derivation prototype; server and chain verification not implemented |
| ADC_L1 — Asset Disclosure Code, lower-bound tier | A user-selected proof-of-funds / lower-bound statement | Complete balance, notes, nullifiers, counterparties, history | Client derivation prototype; proof system not implemented |
| ADC_L2 — Asset Disclosure Code, exact tier | Exact selected-asset balance snapshot at a finalized height | Notes, nullifiers, counterparties, history | Design only; requires a completeness source + ZK balance proof |
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
| Question | Answer |
|---|---|
| What is a TDC? | A transaction disclosure code; it discloses only scoped information about one transaction/output |
| What is an ADC? | An asset disclosure code; it discloses a user-selected asset balance snapshot |
| Does an ADC reveal balance? | Yes — an ADC discloses the selected balance snapshot |
| Can a disclosure code spend funds? | No. Every disclosure credential must carry canSpend=false (a protocol-level invariant) |
| Is a disclosure code permanent? | It should not default to permanent: the design includes expiry / maxViews / revocation / erasure keys; until revocation ships, disclosed content must be treated as irretrievable |
| How is a disclosure code protected? | Two factors (link_secret + 16-character code), AEAD envelopes, AAD binding, a slow-hash verifier; server-side rate limiting and unified error responses are still to be implemented |
| Is a disclosure code a private key? | No. It cannot move assets and cannot substitute for the Spend/View/Audit keys; but do not share it casually — information once disclosed cannot be taken back |
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 draft.
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)
Timing/amount correlation, fee side channels, mempool observation, validator ordering and censorship (not mitigated); network-layer and bridge/exchange metadata (out of scope); disclosure forwarding uncontrollable, revocation not implemented, ADC time-series and net-worth exposure, coerced issuance (not mitigated / stated plainly); phishing and social engineering, fake wallets and fake official channels (not mitigated; addressed via user education and an official channel list); circuit bugs, trusted setup, external audit (unverified / unresolved / not completed); testnet token-value and reward confusion (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.
| Phase | Goal | Exit criteria (summary) |
|---|---|---|
| Phase 0 — Evidence closure and document scoping ← current | Close the evidence appendix; scope public narrative to the testnet | Every implemented claim evidenced; no token/wallet/DeFi/mainnet implications |
| Phase 1 — Testnet readiness | Complete the Section 8.2 checklist | 3+ node devnet stable; runbook reproducible; PR checks green |
| Phase 2 — Public testnet | Controlled public experimentation | External nodes can join; faucet abuse controlled; no mainnet or yield misleading |
| Phase 3 — TDC MVP | End-to-end single-transaction grant | Wrong-code/expired/exhausted behavior safe; grant existence not leaked; scoped fields only |
| Phase 4 — ADC_L1 | Lower-bound proof of funds | Never described as exact balance; time-series risk public; TDC/ADC mutually unopenable |
| Phase 5 — On-chain disclosure verification | Root-bound verification | Wrong chain/root/scope/asset all rejected; replay protection |
| Phase 6 — Production ZK path | Auditable proof system | Dev verifying keys retired; external cryptographic audit; no "production ZK" claim before completion |
| Phase 7 — ADC_L2 | Exact balance snapshot | Completeness provable; no history leak; never becomes a long-lived viewing key |
| Phase 8 — External audit and pre-mainnet | Pre-mainnet review | Protocol/cryptographic/implementation audits; legal review; public evidence package |
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.