Recipient-controlled spending.
The receiver keeps the secret behind their future spend marker. Sending a payment does not give the payer that secret.
Follow the note →Keep the note private.
Make the rules verifiable.
ZOIY is designing a Layer 1 for private payments and public applications. Transaction details stay with their owners; cryptographic proofs let the network verify the rules.
PROTOCOL DESIGN · NATIVE NETWORK NOT YET LIVEThe protocol in three parts
A private transfer needs
more than a valid proof.
A payment needs an owner who controls the next spend, a proof that matches what they authorized, and a network that records the transfer only once.
One atomic transition.
Private transfers, public calls and fees settle together. If a public call fails, the private input must remain unspent.
See the execution rules →Separate trust boundaries.
Signatures authorize a spend. Encryption delivers the note. Proofs verify the transaction rules. Each part has a distinct role in the security design.
Read the security model →What changes on the ledger
New commitments.
One-time spend markers.
A private note commits to an asset, an amount, an owner and a policy. Spending creates a public nullifier and fresh output commitments. Validators check the proof and reject markers already used in the current state.
The intended default is private value transfer where supported. Public calls and conversions remain explicit, and their visible amounts or timing can reveal relationships.
Explore the network model →Base and the native network
One supply commitment.
Two distinct deployment stages.
The intended Base token is an initial distribution. A native privacy network requires its own proof system, wallet, consensus and migration design.
21,000,000
Intended maximum fixed supply of ZOIY.
No reserved share
No intended team or private-investor allocation.
100%
Target circulating supply at launch, subject to actual distribution and liquidity mechanics.
The planned Base token and the native network serve different purposes. Native privacy and post-quantum authorization are not features of a standard Base ERC-20.
Token policy and migration →Research status
From protocol design
to a working network.
A complete prover, tested consensus and independent security review are still ahead. Follow the work needed to make the design operational.
Review the open work →Does ZPS-1 have a working prover?
No. The spending relation has no completed prover/verifier, formal quantum-security proof or independent audit.
Does an accepted note guarantee delivery?
No. Baseline envelope binding protects authorized bytes, not their correct decryption by the recipient. Strict delivery is a separate proposed extension.
Are performance figures available?
Proof size, proving cost, verifier latency and network finality have not been measured for a completed implementation.
22 pages