Skip to content

TECHNOLOGY

Protocol overview.

What exists today, how it fits together, and where the boundaries are. This page states implementation status as it is — prototype claims are labeled as prototype claims.

Research prototype · no testnet · no mainnet · unaudited · not production-private · not safe for funds

The three disclosure primitives

Viewing key

Prototype

Read-only access to your own transaction history, separate from spending authority. The current implementation registers a single account-level viewing key. Planned but not implemented: income/expense key separation, time-limited audit keys, and expiry or revocation of issued disclosures.

Transaction disclosure code (TDC)

Prototype · client

Prove one specific transaction to a chosen party — as sender or recipient — without exposing full history and without touching spending authority. The client core implements domain-separated canonical encoding, 16-character Crockford codes, two-factor derivation (link secret + code), sender/recipient role binding, a dual-layer AEAD envelope with AAD binding, and erasure-key crypto-shredding, against frozen cross-language test vectors.

Asset disclosure code (ADC)

Partial prototype

A system that hides ownership cannot simultaneously promise a complete balance statement, no history leakage, and no surrendered viewing key. ADC therefore ships in tiers: ADC_L1 proves a lower bound of funds (client derivation implemented); ADC_L2 — an exact snapshot at a final height — remains in design until a completeness mechanism and zero-knowledge balance proof exist.

Architecture components

Chain base

Prototype

Built on Cosmos SDK / Ignite. Consensus is CometBFT-style BFT with a PoS-style initial validator set and staking module — a testnet validator model, not finalized mainnet economics. It is not proof-of-work.

Shielded module

Prototype

The shielded pool is the core state machine: notes are represented as commitments inserted into a Merkle commitment tree; spending consumes notes via nullifiers, and duplicate nullifiers are rejected to prevent double-spends. Deposit, withdraw, spend, viewing-key registration and single-note disclosure all have tested prototype implementations. Deposit and withdrawal amounts are currently public on-chain.

Zero-knowledge status

Prototype

The prototype includes a development-key Groth16 verification path. It does not yet provide production-grade zero-knowledge security: no trusted setup has been performed, circuit soundness is unverified, and no external cryptographic audit has been completed.

Test evidence

Client tests 40/40

The disclosure-code client core passes 40/40 tests (local verification, 2026-06-10, Node v26). Not yet implemented: the server-side grant stack, on-chain inclusion verification, and production-grade Argon2id / XChaCha20-Poly1305 adapters.

Current boundaries

Deposit and withdrawal amounts are still public; timing, fee patterns, mempool and network-layer metadata are observable; server-side disclosure verification is not production-ready; nothing here has been externally audited. The threat model states all of this in full.