Privacy is often discussed as if it were a single switch: either a market is transparent or it is private. That framing is too crude.
A useful privacy-preserving market should hide the participant, not the health of the market.
I’m writing this from the ZECpad project, a pre-launch effort exploring private ZEC-settled market exposure on Zcash. We are still testing the design. The important question is not how to hide everything; it is how to make the right things verifiable without making users linkable.
Below are seven signals I believe any shielded market should expose publicly.
1. Oracle freshness and source health
A price feed is not trustworthy merely because it returns a number. Users need to know when the value was last updated, which source set contributed to it, whether sources disagree, and whether the referenced market is currently open.
A useful public oracle status should include:
- the timestamp and age of the latest accepted update;
- the number and type of independent sources;
- deviation between those sources;
- the active aggregation rule;
- stale-price and outlier thresholds;
- the reference market’s session state.
What should remain private is which participant viewed or acted on a quote. Market data health can be public without turning user behavior into a public trail.
If the oracle becomes stale or sources diverge beyond a defined limit, the market should stop accepting risk rather than silently continuing with a questionable price.
2. Executable liquidity, not just headline TVL
“Total value locked” can look impressive while saying very little about the price at which a user can actually enter or exit.
A more useful interface shows executable depth at several distances from the current reference price. For example: how much capacity exists within 0.5%, 1%, and 2%? How has that depth changed over time? Is it one-sided?
These values can be published in aggregate. The identities, balances, and individual orders behind them do not need to be exposed.
This distinction matters especially for smaller or newly launched markets. A single liquidity number can conceal severe slippage, concentration, or an empty side of the book. Public depth curves make those conditions visible before a user commits funds.
3. Reserve and collateral coverage
If a market represents a claim, exposure unit, or redeemable balance, users need a way to evaluate whether the system can honor its obligations.
The relevant public signal is not every account balance. It is the aggregate relationship between liabilities and the assets or collateral backing them.
A robust disclosure can include:
- total outstanding liabilities;
- total eligible collateral;
- the valuation method and haircut applied to collateral;
- the current coverage ratio;
- concentration limits;
- the timestamp of the latest proof;
- the conditions that can pause issuance or redemption.
The proof mechanism may vary. A zero-knowledge proof can establish an invariant without revealing the holder set. A view-key-based review can support deeper inspection by a designated reviewer. A hybrid approach may be practical, but each model has different leakage and trust assumptions that should be documented honestly.
4. Issuance and supply invariants
Private balances should not imply an unknowable supply.
A shielded asset system needs publicly verifiable rules governing minting, burning, and the maximum relationship between issued units and backing. Users should be able to determine whether the system follows those rules without learning who owns each unit.
At minimum, the public specification should answer:
- Who can authorize issuance?
- What event permits new issuance?
- What proof or attestation is required?
- How are redemptions reflected in supply?
- Can administrators change the rules?
- Is there a delay or public notice before sensitive changes?
The goal is not to publish a holder map. It is to prevent privacy from becoming cover for arbitrary issuance.
5. Exact fees and destinations
A user should never have to discover the real fee structure after signing a transaction.
Interfaces should separate network fees, protocol fees, liquidity costs, oracle costs, and any issuer or market-specific charges. The calculation method and destination of each fee should be explicit.
This is a good example of the privacy boundary: fee rules and aggregate fee collection can be public; the identity of the person paying a particular fee can remain private.
A clear fee schedule also makes markets easier to compare. Two venues with the same headline price may deliver very different outcomes once spread, slippage, and settlement costs are included.
6. Circuit breakers and capacity limits
Every market has failure modes. Responsible design makes them visible before they are triggered.
Public status should show whether trading, issuance, or redemption is operating normally, rate-limited, or paused. It should also show the rule responsible for the state: stale oracle, abnormal deviation, reserve shortfall, reference-market closure, capacity limit, or administrative emergency action.
The thresholds should be defined in advance wherever possible. Emergency powers that cannot be fully automated should be narrow, logged, and time-bounded.
Privacy does not require hiding whether a circuit breaker is active. In fact, a private market needs especially clear operational signals because users cannot reconstruct the full state from a transparent transaction graph.
7. Aggregate participation and solvency proofs
The hardest signal is evidence that the system remains solvent and usable without exposing the participant set.
Frequent proofs improve freshness but can leak information when the anonymity set is small or when changes can be correlated with external events. Slow proofs reduce that leakage but leave a longer window of uncertainty.
Designers therefore need to publish more than “proof of reserves.” They should describe:
- what statement the proof actually establishes;
- which liabilities are included;
- how often the proof is generated;
- the minimum aggregation set;
- whether proof timing can reveal user activity;
- how failed or delayed proofs affect the market;
- who can reproduce or verify the result.
A proof is useful only when its scope and limitations are understandable.
The boundary we are testing
The design boundary we are exploring at ZECpad is straightforward to state, even if it is difficult to implement.
Public and verifiable:
- market rules and status;
- oracle freshness and source health;
- aggregate liquidity, reserves, and coverage;
- issuance invariants;
- fees and their destinations;
- circuit-breaker state and capacity limits.
Private by default:
- participant identity;
- wallet and account linkage;
- individual balances;
- position and order ownership;
- transaction-to-user linkage;
- withdrawal destination.
There is also an important Zcash Shielded Assets (ZSA) boundary. Before ZSA, the realistic scope is shielded ZEC settlement and private application-level balances. Native shielded custom-asset withdrawals and fully native shielded reference assets are future work. ZSA changes what can be built natively; it should not be marketed as if that capability is already live.
For reference-linked markets, price exposure is also not the same as direct ownership of an underlying share. Product language should preserve that distinction instead of borrowing the strongest possible claim from traditional brokerage.
ZECpad is pre-launch. No token sale is being promoted here, and this is not an investment pitch. The public project page is https://zecpad.com, and development updates are shared at https://x.com/Zecpad.
The useful outcome is not a market that reveals nothing. It is a market that reveals enough to be evaluated while revealing as little as possible about the people using it.
For builders and reviewers: which proof cadence and review model would you trust most for aggregate solvency, and what market-health signal would you refuse to let a private market hide?
Top comments (0)