Read the complete specification
22 pages
Zoiy Whitepaper
A Privacy-Native, Post-Quantum Layer 1
For the full technical specification, read the transaction rules, security assumptions and network model together in the whitepaper.
What exists, and what does not
ZOIY is at the protocol-design stage. The core spending mechanism is specified as a candidate design; a complete prover and operational native network are not yet available.
The earlier model tested deterministic rejection behavior, including replay, changed outputs or fees, chain mismatch, and duplicate or stale nullifiers. It did not establish witness confidentiality, post-quantum soundness or consensus security.
The research sequence
- Pin the bytes and bindings. Specify canonical encodings, algorithm IDs and reproducible note/envelope test vectors.
- Resolve recipient delivery. Design a correct-encryption relation or a precisely scoped acknowledgement policy, with malicious-envelope tests.
- Measure private authorization. Build and benchmark ML-DSA verification within the proof system and compare reviewed alternatives.
- Check state invariants. Test replay, double spending, integer conservation and fail-closed public-call rollback.
- Evaluate operational privacy. Model descriptor reuse, wallet scanning, ciphertext discovery and public/private conversion leakage.
- Specify consensus and migration. Fix locking, reconfiguration and synchrony rules; test source-claim verification and economic-unit conservation.
Each stage needs measurable results before the next can be relied on. Testing may lead to changes in the architecture.
What a useful benchmark must disclose
A throughput number alone would not explain this design's cost. A future result needs the circuit hash, verifier ID, field and FRI parameters, input/output counts, hardware, software commit, proof size, proving time, verification time and peak memory.
Workloads should cover note creation, single- and multi-input spending, hidden authorization, scanning and public/private conversions. Until implementations and measurements exist, results are not measured.
State-machine conformance, proof security, network performance and privacy against a defined observer are separate evidence. Passing one set of tests does not establish the others.
Protocol terms, in plain language
| Term | Meaning in this proposal |
|---|---|
| Private note | An immutable output whose hidden fields are bound by a public commitment. |
| Commitment | A public cryptographic reference to hidden note fields. Hiding and binding need a concrete construction. |
| Nullifier | A public one-time spend marker used to reject reuse without publishing the original note commitment. |
| One-use descriptor | Recipient-authenticated public material for constructing an output, including a commitment to the recipient’s independent secret. |
| Envelope | Encrypted delivery data bound to a note, descriptor and transaction transcript. |
| Witness | The private data used to construct a proof. |
| STARK relation | Constraints the registered verifier requires a private witness and public statement to satisfy. |
| Atomic transition | A state change in which all required effects commit together, or none do. |
| Finality | Consensus establishes which ordered state is canonical. Proof acceptance alone does not do this. |
Open design questions
Is ZPS-1 a new signature scheme?
No. It proposes a composition and interface around existing primitives. It does not claim invention of signatures, commitments, nullifiers or private transfers.
Does ZOIY outperform existing privacy networks?
Performance comparisons require a complete implementation and reproducible benchmarks. Those results are not yet available.
Are CometBFT or HotStuff already selected?
No. They are references for consensus design. The actual protocol, locking rules and synchrony assumptions remain unselected.
Are private identity and DeFi products available?
The first priority is private value transfer. General-purpose private contracts and applications require additional engineering.