Four roles, one ledger

ZOIY separates client-side private execution, deterministic public execution, verification of state changes and consensus finality. These are distinct responsibilities, even when some run on the same device.

Private witnesses stay client-side. Validators verify public statements and effects before consensus finalizes the state.
Private witnesses stay client-side. Validators verify public statements and effects before consensus finalizes the state.
RoleResponsibility
Client and proverRecover owned notes, obtain authenticated paths, prepare witnesses and construct proofs.
Public executionRun explicit contract calls against the state produced by preceding transactions.
State verificationCheck proofs, roots, commitments, unused nullifiers, envelopes and resource limits.
ConsensusAuthenticate the validator set, order blocks and establish finality.

The summary state includes the note commitment root, spent-nullifier set, public contract state and validator-set commitment. A complete implementation also needs indexed commitments and encrypted-envelope data or an availability commitment.

Public and private execution

Private value transfer is intended to be the default where supported. Transparent contracts remain useful for shared prices, public governance outcomes and validator state.

A client prepares private effects and a sequence of queued public calls, all bound into the same authorization digest. Validators execute the calls at inclusion against current state in block order.

Development starts with private transfers and fees. The next step is a limited set of public settlement calls, tested to roll back correctly. General-purpose private contracts require further work.

Commit everything, or reject

The proposed execution model checks a transaction against temporary state. Proofs, authorization, private transfers, public calls and fees must all pass before changes can be committed.

In the proposed execution model, a failed public call rejects the block. Private inputs remain unspent and no fee is committed.
In the proposed execution model, a failed public call rejects the block. Private inputs remain unspent and no fee is committed.

If every check succeeds, note updates, nullifiers, public transfers and fees are staged together. If a queued public application reverts, the transaction is inadmissible and a block containing it is rejected.

Only successfully committed transactions pay fees in this profile. Charging for a reverted call would require a separate authorized and replay-protected fee debit. That alternative is not specified; the current choice leaves spam and denial-of-service economics open.

Account for every conversion

A public-to-private deposit must correspond to a real public debit. A private-to-public withdrawal must correspond to a real public credit. Declaring either amount inside a proof does not create the public-state change.

private inputs + public deposits
= private outputs + public withdrawals + fees

Accounting is per asset, with explicit fee denomination. The proof binds conversion quantities; the deterministic public transition validates the corresponding state changes before anything commits.

Conversion amounts and timing can reveal links. A distinctive deposit followed by an equal withdrawal may be correlated even if the intervening private note is hidden.

Proof validity is not finality

A valid proof does not choose between conflicting spends, select the authorized validator set or show that every party received the data. ZOIY investigates stake-weighted Byzantine fault-tolerant consensus with post-quantum-authenticated votes. The final protocol is not selected.

For an unchanged validator set, a quorum above two-thirds of voting weight overlaps another such quorum in more than one-third. With Byzantine weight below one-third, this motivates a safety argument, but only with correct locking, voting and reconfiguration rules.

RequirementStill to specify or evaluate
Vote authenticationBind chain ID, epoch, height, round, message type, block or nil ID, and validator-set version.
Safety and livenessLocking, timeouts, proposer rotation, evidence, reconfiguration and synchrony assumptions.
Post-quantum overheadSignature sizes, gossip, verification load and light-client certificates.
Economic supportFees or other explicitly authorized revenue, without continuing coin issuance.

Finality targets and validator requirements will depend on the selected consensus protocol and measured network performance. Validator funding must respect the fixed supply.