Crypto Privacy Stack for High-Net-Worth Users

DN Privacy Disclosure and Override Review

Primary-source review: 13 November 2026. This extension adds a field-level confidentiality review. It does not refresh older vendor figures or claim an independent security test.

What matters: confidentiality is a relationship between a particular fact and a particular observer. An agent’s trade can be hidden from the public mempool while remaining visible to its execution provider. A proof can conceal account details while an application publishes the transaction amount. Write the required confidentiality boundary before selecting a privacy product.

1. State exactly what should remain confidential

Separate the proposed trade, identity, account balance, counterparty, location, device and strategy. Specify who may see each item, for how long and for what purpose. A regulated counterparty receiving necessary identity evidence is a different disclosure from an analytics endpoint receiving an unnecessary personal identifier.

Ethereum’s current privacy-app guidance warns that public circuit inputs, events, calldata and surrounding application metadata can undermine a proof’s privacy goal. DN’s implication is to review the full data path, not merely the cryptographic primitive. Ethereum privacy-app guidance.

2. Separate proof validity from transaction confidentiality

A validity proof can establish that a defined computation follows its constraints without making the surrounding system private. Ethereum’s ZK-rollup documentation describes public data needed to reconstruct state. Therefore “uses zero knowledge” should not be translated into “hides every transaction.” Inspect the actual public inputs and published outputs. Ethereum ZK-rollup documentation.

For a trading workflow, ask whether the amount, destination and method are exposed before inclusion, after settlement or both. Also identify who receives the proposed action if submission fails. A provider’s failure logs can contain information that never appears in a successful on-chain transaction.

3. Treat private routing as a specified trust arrangement

Flashbots documents private submission and configurable privacy, speed and refund settings. Its quick-start documentation says fast mode shares transactions with registered builders and TEE searchers and explicitly identifies trust in builders not to disclose or front-run. These are product-specific boundaries, not proof of immunity against every source of information leakage. Flashbots Protect quick start.

DN’s proposed comparison records recipients of full transaction data, published hints, retention, fallback behavior and the user’s explicit acceptance of those conditions. Do not rank routes using an invented “time to trace the wallet” score. A measured result would need a declared observer, dataset, time window and success definition.

4. Read the compliance statement literally

A proof that a committed identifier is absent from a specified set establishes, at most, the statement encoded about that set under its construction and freshness assumptions. It does not establish that every relevant identity was resolved, every applicable list was included or a transaction satisfies every legal obligation. That conclusion follows from the difference between the narrow predicate and the broader claim.

Record the set’s owner, update date, membership rule, identifier mapping and revocation behavior. Determine which party decides whether the proof is acceptable for the actual service and jurisdiction. An operator must not treat a proof as permission to evade screening, reporting or account restrictions.

5. Distinguish the prover, sequencer and application operator

A prover produces a proof. A sequencer orders transactions in the architecture where that role exists. A frontend collects inputs; an RPC or gateway relays them. These roles may share an operator, but their names are not interchangeable. Map where plaintext exists and who can observe each stage.

A suspicious ordering pattern alone does not prove that a prover stole confidential data. A substantiated incident analysis needs the information-access path, timestamps, transaction relationships and competing explanations. Preserve an unexplained pattern as unresolved rather than publishing an accusation about a named provider.

6. Inventory administrator powers without inventing a backdoor

Distinguish a view key, a disclosure interface, an upgrade right, an emergency pause and a power to move or freeze assets. An administrator who can change future software does not necessarily possess a key that decrypts all historical records. Conversely, encrypted application data may be readable by an operator even when the public ledger is not.

For each power, record its scope, holders, threshold, delay, audit trail and recovery route. Identify whether a claim comes from deployed code, contractual terms or a proposal. This review establishes no universal government decryption backdoor and no universal emergency-reveal function.

7. Review tokenized assets at the claim and registry boundary

ERC-3643’s identity-registry documentation describes associations between identities, claims and eligibility checks. The association’s transfer explanation identifies identity and compliance checks in the token workflow. That is a reason to inspect the actual registry and offering configuration, not to assume a public price update reveals every investor’s legal name. ERC-3643 identity registry · Transfer checks.

Use a field-level exposure table: on-chain identifier, off-chain record, party controlling the association, public events and access conditions. A market price, an ownership record and a customer identity are different data objects. Linkability must be demonstrated through the specific design.

Worked review: private before settlement, visible afterwards

Fictional scenario: a treasury sends a proposed trade through a private relay. The relay and selected builders can see its calldata; the public does not see it through the ordinary mempool. After inclusion, the transaction and its events are public. The correct record says the design reduced one pre-trade disclosure path. It does not label the treasury anonymous, concealment permanent or the trade immune to MEV.

The action may still fit the treasury’s narrow goal. A confidentiality review is useful because it supports that specific decision rather than promising invisibility. If the requirement instead prohibits any infrastructure provider from viewing the trade, this route needs a different architecture or cannot satisfy that requirement.

FAQ: does privacy remove accountability? Not inherently. An organization can minimize unnecessary public disclosure while retaining authorized review evidence. The required balance depends on its actual duties and contracts; this worksheet does not decide legality or override mandatory controls.

Method and limits: This is DN’s original review method informed by the linked sources. No protocol source-code audit, incident-rate study, privacy-breaking test or legal determination was performed. The constructed scenario is not observed vendor performance. Existing commercial links remain separate from the conclusions.