A baseline for mandatory privacy
A reference for ordinary-payment defaults, with statistical inference and network exposure kept visible.
S89S91MONETARY PRIVACY / RESEARCH 01
Money need not reveal your life.
Start with fungibility, freedom to pay and financial security. Examine what a currency hides, from whom, and where its protection ends.
Study updated2026.10.01Mechanisms, evidence, interpretation
01 / EXPOSURE MAP
Mechanism model · not a real transactionThe same payment. A different observer.
Native BTC / L1 / ordinary self-custody
Reads confirmed ledger data only, without viewing keys, exchange records or network surveillance.
Spend originSpent inputs are publicVisible
RecipientOutput scripts / addressesVisible
Transfer amountEach output amountVisible
Flow linkageUTXO spend linksVisible
Timing & activityBlocks, ordering and activityVisible
Network identityIP is not a ledger fieldOutside this view
Addresses are pseudonyms; the payment graph is public.
Public inputs and outputs are not an identity registry. Clustering is an inference to test, not a complete statement of one person’s wealth.
“Absent from the ledger” does not mean “unknowable”; mechanism protection is not an unbreakability guarantee. This model excludes compromised devices, leaked keys and combined multi-party datasets.
02 / COMPARATIVE FINDINGS
Nine projects. Compare the actual path.
One currency name can describe different privacy states. Distinguish mandatory, optional and unverified protection before judging monetary value.
Strong shielding, with path conditions
Assess Orchard’s internal capabilities separately from defaults across the whole Zcash network.
S26S109Early potential cannot replace privacy evidence
Default shielding is unestablished for ordinary HAC/PRL payments; QTC’s documented link protection leaves endpoint amounts visible.
S64S74S82| Project / path | What it protects | Boundaries & unknowns | Sound-money interpretation |
|---|---|---|---|
| MoneroXMR Mandatory ordinary-payment privacy | One-time outputs, hidden amounts and obscured spend origin. S19S20S89S91S104 | Statistical inference, network and endpoints; scope is v0.18.5.1. | A baseline for default private payments, not evidence of stable purchasing power or investment returns. Project evidence |
| ZcashZEC Path-dependent: transparent / shielded | Within Orchard, payment origin, recipient and amount can be hidden. S25S26S109S110 | Cross-pool net values, transparent boundaries and wallet paths; a unified address is not an anonymity proof. | Separate cryptographic capability, actual defaults and use. Orchard needs no trusted setup; other pools differ. Project evidence |
| BitcoinBTC Transparent L1; additional paths separate | Ordinary transfers conceal neither amounts nor graph; Payjoin, collaborative transactions and Lightning need separate review. S05S09S111S112 | Fresh addresses do not erase spend links; off-chain identities amplify exposure. | Review reserve-money properties and payment privacy separately; tool capabilities are not L1 defaults. Project evidence |
| LitecoinLTC Transparent base; optional MWEB | Amount confidentiality and aggregation inside extension blocks. S40S96 | Entry/exit boundaries, broadcast observation and wallet support. | Test whether a specific wallet sustains the protected path, beyond protocol support. Project evidence |
| Bitcoin CashBCH Transparent L1; optional CashFusion | Collaborative transactions can obscure ownership; amounts remain public. S42S113 | Participation and later spending alter linkage clues. | Review the whole payment lifecycle; confidential coordination is not on-chain amount confidentiality. Project evidence |
| DogecoinDOGE Transparent ordinary transfers | Addresses do not directly register names; transactions and amounts are public. S47 | Address reuse, exchanges and order data can create links. | Payment convenience and privacy capability are different questions. Project evidence |
| HacashHAC Reviewed native transfers are transparent | Reviewed encoding includes addresses and amounts; default shielding is not established. S64S65 | Channels or future privacy plans cannot be credited to every HAC payment. | A private-sound-money case needs default payment protection and wallet evidence. Project evidence |
| PearlPRL Default shielding unestablished for ordinary payments | AI / computation proofs do not automatically hide token payments. S74S75S78 | Needs concrete evidence for public fields, wallets and broadcast paths. | Audit computational correctness and financial privacy separately. Project evidence |
| QuantusQTC Wormhole documentation: link protection | Conceals burn-to-exit pairing; endpoint addresses and amounts remain visible. S82S84S98 | Mainnet implementation, effective anonymity and independent audit need verification. | Assess post-quantum security and payment privacy separately; labels do not establish full-field protection. Project evidence |
03 / THE MONETARY CASE
Monetary interpretationWhy does privacy belong in sound money?
Fungibility: accept money without judging its history
Equal face values in a protocol need not receive equal market treatment. Public provenance supplies information for refusal, discounts or discrimination. Reducing that distinguishability is privacy’s most direct contribution to monetary quality.
This is an economic interpretation. Actual refusal or discounts require provider-, path-, date- and sample-specific evidence; design does not establish universal acceptance.
S05S40Sovereignty: payment need not disclose a financial profile
A wage, rent or retail payment requires confirmation of what is owed. Exposing savings, other income and relationships can create bargaining disadvantages, surveillance and targeting opportunities. Self-custody controls spending authority; privacy controls information exposure.
The two support each other but differ: a private custodial account depends on its custodian, while self-custody on a public ledger still exposes transactions.
S106S05Monetary use: protect the boundaries of ordinary commerce
Businesses need not publish suppliers and payroll to every competitor; individuals need not disclose financial histories to every payee. Privacy can reduce the information cost of money use, but enters the real economy only when payments are reliable, affordable and receivable.
Privacy improves payment conditions; it neither anchors purchasing power nor establishes fair issuance. Monetary value still requires demand, distribution, stability and settlement analysis.
S106S13S14“Privacy is the power to selectively reveal oneself to the world.”
Eric Hughes · A Cypherpunk’s Manifesto · 1993 S106The key is control over disclosure, rather than a public financial history as the price of making a payment.
04 / MECHANISMS & DEFAULTS
Look beyond the name of the technology.
A mechanism usually protects only part of the information; a real payment needs several layers to work together.
Amount commitments conceal values while allowing verification of balance across inputs, outputs and fees. Range proofs constrain values to prevent negative or out-of-range values bypassing checks. Amount confidentiality can coexist with supply-rule validation.
A commitment is not just an encrypted number. Security depends on mathematical assumptions, proof rules and implementation; confidential ordinary transfers do not imply hidden fees or block rewards.
S19S8905 / VERIFY RULES, PROTECT PEOPLE
Protect personal records. Verify monetary rules.
Seeing every amount, validating a transaction and independently recounting secret balances are different capabilities.
For an ordinary transferInputs = outputs + feeNew issuance is separately checked against subsidy rules
Are the rules enforced?
Full nodes validate transactions under consensus rules; both public and private ledgers depend on correct implementations.
Can hidden stock be independently recounted?
Summing secret notes in plaintext differs from verifying conservation. Retrospective investigation after proof failure also differs.
What do boundary checks establish?
Zcash pool net flows are checkable and rules reject out-of-range balances; staying within bounds does not prove no internal counterfeiting.
Use counterevidence to test the assessment.
Bitcoin Core · 2018
CVE-2018-17144 involved denial-of-service and inflation risk. A transparent ledger still depends on correct consensus-validation code.
The historical flaw was fixed. It refutes “public amounts prevent inflation bugs,” not the safety of a current patched version.
S11Zcash Sprout · 2018 / 2019
A counterfeiting flaw in the old Sprout proving system was fixed in 2018 and disclosed in 2019. ECC reported no evidence of exploitation, not proof that exploitation never occurred.
Orchard uses a different proving system. The case separates proof soundness from retrospective investigation of hidden state.
S94S26Privacy research · separate historical and current scope
Möser et al. studied early Monero traceability; Kappos et al. studied early Zcash usage. The 2025 OSPEAD work analyzes differences between Monero decoy distributions and real spending times.
These inform attack surfaces, not a universal present-day break rate. OSPEAD’s publication notes no formal peer review; a probabilistic guess does not confirm a real payer.
S115S116S91Selective disclosure: seeing is not spending.
Users can supply limited audit information to a chosen party. Its value is a narrower disclosure scope; different keys and proofs grant different capabilities.
The view key identifies incoming payments without spending authority. It alone does not reliably account for all spending; accurate spent status needs corresponding key images.
S107Incoming and full viewing differ. Sapling specifications qualify outgoing, recipient and balance information; nonstandard or out-of-band payments can affect completeness. No key should simply be called an omniscient audit.
S108S109A recipient can copy disclosed information. Future observation depends on key scope and subsequent address use; an interface revocation cannot recall copied history.
06 / A RESEARCH STANDARD
A credible privacy finding must be reviewable.
Technology labels, slogans and unexplained totals do not replace evidence. Use these questions alongside the site’s monetary framework.
01 · Define path and version
Record the asset, mainnet or testnet, node commit, wallet version and transparent / shielded / cross-pool path. A proposal or code merge alone does not prove activation.
S104S11702 · Define observers and information
Separate ledger readers, counterparties, nodes or wallet backends and viewing-key holders, including their combined information. A ledger-only test does not establish protection against a global observer.
S05S18S10803 · Test the ordinary user’s default path
Protocol mandates, wallet defaults and recipient support require three separate answers. A wallet’s shielded default does not remove transparent protocol paths.
S25S10904 · Follow the lifecycle, not one screenshot
Inspect acquisition, holding, payment, change, subsequent spending and exit. Include entry/exit, amount similarity, timing clusters and records across services.
S116S40S11305 · Separate nominal sets from effective anonymity
Pool balance is not user count; transaction count is not independent participation; ring size is not equal probability. Any anonymity percentage needs an attack model, sample, baseline and false-positive rate.
S91S115S11606 · Verify balance, authorization and double-spend checks
Locate validation rules and code, assumptions, setup, independent audits, historical flaws and fixes. Public pool net flows are not a direct inventory of every hidden note.
S89S26S110S11S9407 · Check disclosure authority and scope
Incoming views, outgoing views, balances, memos and payment proofs are distinct permissions. Disclosure should match its purpose; copied history cannot be recalled by revoking an interface permission.
S107S108S10908 · Measure cost and monetary access
Under common device and network conditions, record proving, sync, fees, failure rates, recipient support and exit costs. Private payments must remain usable; record liquidity costs as a separate dimension.
S13S40S111Measurements left open in this edition
There is no common-condition, nine-project dataset for effective anonymity, wallet-default coverage, proving latency, payment success or private-path exit costs. This edition compares mechanisms and evidence without invented live percentages or zero scores for missing data.
A useful next evidence package should include version and date, reproducible steps, lawfully controlled test funds, observer capabilities, results and failures. Publish records that do not expose real users’ privacy.
Six claims that can mislead the assessment
Put privacy back into the complete monetary assessment.
Privacy reduces information exposure when using money. Sound money also needs scrutiny of distribution, purchasing power, governance, settlement and valuation.
07 / PRIMARY SOURCES
41 referencesThe primary sources behind the findings.
Specifications describe constraints, code describes implementations, and research and disclosures test boundaries. A citation does not mean every conclusion has independent verification.
S05Protect your privacyDocumentation
Public graphs, address linkage, network metadata and privacy practices.
Read original sourceSource record & retrieval statusS09Transactions — Bitcoin Developer GuideTechnical documentation
UTXOs, signatures, scripts and transaction authorization.
Read original sourceSource record & retrieval statusS11Disclosure of CVE-2018-17144Security disclosure
A patched denial-of-service and inflation vulnerability, demonstrating the need for review and fixes.
Read original sourceSource record & retrieval statusS13Some things you need to knowUse & risk
Price volatility, confirmations and custody; not a substitute for a purchasing-power dataset.
Read original sourceSource record & retrieval statusS14Better Money: Gold, Fiat, or Bitcoin?Theory
Chapter 5 informs supply, demand and purchasing-power questions; it is not an endorsement of an asset assessment.
Read original sourceSource record & retrieval statusS18Monero — FAQProject documentation
Privacy limits, commitment validation and contributor coordination. Absolute anonymity or decentralization claims are not adopted.
Read original sourceSource record & retrieval statusS19Monero — RingCTProject documentation
Amount confidentiality for ordinary transactions; this does not hide all block rewards or fees.
Read original sourceSource record & retrieval statusS20Monero — Stealth addressesProject documentation
The relationship between one-time output addresses and recipient addresses.
Read original sourceSource record & retrieval statusS21Monero — Ring signaturesProject documentation
Candidate sets for spent inputs; a mechanism description is not an anonymity measurement.
Read original sourceSource record & retrieval statusS25Zcash — Shielded and transparent transactionsProject documentation
Transparent versus shielded paths; capability is not treated as actual usage.
Read original sourceSource record & retrieval statusS26ZIP 224 — Orchard Shielded ProtocolSpecification
Orchard, Halo 2, no trusted setup and cross-pool visibility. Guarantees are specific to Orchard.
Read original sourceSource record & retrieval statusS40LIP 3 — MimbleWimble via Extension BlocksDocumentation & specification
Optional extension blocks, privacy boundaries and validation requirements; design is not adoption data.
Read original sourceSource record & retrieval statusS42Bitcoin Cash — Transaction formatDocumentation & specification
Inputs, outputs and scripts; distinguishes the base ledger from additional privacy tools.
Read original sourceSource record & retrieval statusS47Dogecoin — PrivacyPrimary documentation & code
Public transfers and address linkage; pseudonyms are not mandatory privacy.
Read original sourceSource record & retrieval statusS64Hacash — Native transfer encodingPrimary documentation & code
Separate HAC, HACD, SAT and asset encoding; public addresses and amounts are not shielded payments.
Read original sourceSource record & retrieval statusS65Hacash Fullnode — Architecture and operationPrimary documentation & code
Pinned 1.2.0 commit; Rust node, SDK and VM architecture, not proof of activation or deployment shares.
Read original sourceSource record & retrieval statusS74Pearl — Floating Point Scheme SpecificationProject documentation & code
September 2026 FP8 protocol specification and security assumptions; not proof of economic usefulness or deployment.
Read original sourceSource record & retrieval statusS75Pearl — Node and walletProject documentation & code
Pinned c69bd43; node, wallet and operating paths. No full-node replay performed.
Read original sourceSource record & retrieval statusS78Pearl — Mainnet explorerProject documentation & code
Visible transaction values and activity; a single explorer is not an independent supply audit.
Read original sourceSource record & retrieval statusS79Quantus — Whitepaper v0.4.1Project documentation & code
2026-09-09 issuance, allocations and governance. Documentation, code and deployed rules require separate checks.
Read original sourceSource record & retrieval statusS82Quantus — Wormhole privacyProject documentation & code
Documented boundary: hides sender–receiver links, with entry/exit amounts and addresses visible. Not full-field confidentiality.
Read original sourceSource record & retrieval statusS84Quantus — Security and auditsProject documentation & code
At review, some report links are pending and some audits ongoing; not evidence of a completed full-stack audit.
Read original sourceSource record & retrieval statusS89Monero v0.18.5.1 — Consensus validationPrimary sources & data
RingCT, CLSAG and Bulletproofs+ checks and the emission counter boundary; no full-chain replay performed.
Read original sourceSource record & retrieval statusS90Monero v0.18.5.1 — Release disclosurePrimary sources & data
The 2026-07-08 release records wallet, daemon and multisig fixes, not adoption rates.
Read original sourceSource record & retrieval statusS91Monero Research Lab — OSPEADPrimary sources & data
Research on statistical privacy and decoy distributions; future FCMP is not a guarantee of the pinned version.
Read original sourceSource record & retrieval statusS94Zcash — Counterfeiting vulnerability disclosurePrimary sources & data
ECC disclosure of the historical Sprout counterfeiting flaw and remediation at Sapling; no detected exploitation is not proof of none.
Read original sourceSource record & retrieval statusS96Litecoin Core v0.21.5.8 — MWEB validationPrimary sources & data
MWEB block and aggregate validation; it does not mean every LTC payment uses this path.
Read original sourceSource record & retrieval statusS98Quantus — Runtime authorities and reward configurationPrimary sources & data
Root / FastUpgrade authority, technical-collective configuration and mining cap; deployed runtime still needs reconciliation.
Read original sourceSource record & retrieval statusS104Monero v0.18.5.1 — Fork schedulePrimary sources & data
Mainnet fork table in the pinned version; release/code records do not prove universal adoption.
Read original sourceSource record & retrieval statusS106A Cypherpunk’s ManifestoOriginal essay
A foundation for selective disclosure and data minimization, not a security proof for any protocol.
Read original sourceSource record & retrieval statusS107Monero — View-only walletsOfficial documentation
View keys identify incoming payments; accurate spent-status accounting also needs corresponding key images.
Read original sourceSource record & retrieval statusS108ZIP 310 — Security Properties of Sapling Viewing KeysDraft specification
Informational draft distinguishing guaranteed, unverified and undefined Sapling viewing-key information; not generalized to every pool.
Read original sourceSource record & retrieval statusS109ZIP 316 — Unified Addresses and Unified Viewing KeysSpecification
Unified addresses can contain multiple receiver types; appearance alone does not establish the actual payment path. Revision states differ.
Read original sourceSource record & retrieval statusS110ZIP 209 — Prohibit Out-of-Range Chain Value Pool BalancesConsensus specification
Pool net flows and boundary checks; not an independent enumeration of every hidden note.
Read original sourceSource record & retrieval statusS111BOLT 4 — Onion Routing ProtocolSpecification
Onion routing and per-hop fields; not protection against every timing correlation, endpoint or channel-boundary disclosure.
Read original sourceSource record & retrieval statusS112BIP 78 — A Simple Payjoin ProposalSpecification
Sender and receiver inputs weaken common-input-ownership heuristics; on-chain amounts remain public.
Read original sourceSource record & retrieval statusS113CashFusion ProtocolSpecification
Collaborative transactions increase ownership ambiguity; coordination commitments do not hide final BCH output amounts.
Read original sourceSource record & retrieval statusS114Cashu NUT-00 — Notation and ModelsSpecification
Blind signatures, mints and bearer tokens; private notes still depend on issuer redemption.
Read original sourceSource record & retrieval statusS115An Empirical Analysis of Traceability in the Monero BlockchainResearch paper
Historical analysis of early transactions and then-current decoy selection; its rates are not current tracing-success estimates.
Read original sourceSource record & retrieval statusS116An Empirical Analysis of Anonymity in ZcashResearch paper
Early Zcash usage-pattern and shielding-boundary analysis, not a contemporary measurement of Orchard anonymity.
Read original sourceSource record & retrieval statusS117ZIP 258 — Deployment of the NU6.3 Network UpgradeUpgrade draft
Marked Draft when read on 2026-09-30. Ironwood / NU6.3 is not credited as active protection on this basis.
Read original sourceSource record & retrieval statusThis study interprets the listed sources; it is not an independent network-wide privacy audit. Models fix observer and version scope; adoption and future upgrades are not assumed facts. Monetary interpretations are Crypto Sound Money’s, not endorsements by source authors.