What privacy actually means in finance

“Privacy” is one of the most abused words in crypto. In institutional finance, it does not mean anonymity, secrecy, or evading oversight. It means confidentiality with accountability:

• Counterparties see only what they are entitled to see.
• Auditors and regulators can access full, verifiable records.
• Internal controls, reconciliations, and investigations remain possible.

Public, permissionless blockchains like Ethereum or Solana were not designed for this model. They optimize for openness and censorship resistance, not confidentiality. Transactions, balances, and contract interactions are globally observable. Pseudonymity helps only marginally: with social graph analysis, metadata, leaks, and deliberately revealed identities, addresses are often easily tied to an organization or individual.

Transparent ledgers expose not only individuals' balances, but investors’ positions, treasury movements, and trading strategies. In hostile environments, they expose people to real-world coercion. That is incompatible with institutional use.

There are at least three ways to deal with this:

1. Avoid public ledgers entirely (use private / permissioned DLTs).
2. Extend a public L1 with confidentiality features.
3. Add a privacy layer (L2s, sidechains, application-level protocols).

Each choice shifts complexity, trust assumptions, and operational risk. We’ll review concrete solutions.

Privacy dimensions

Privacy is not binary. Different use cases require different guarantees.

Address confidentiality (anonymity, unlinkability)

In other words: who sent what to whom?

Typical techniques are:

• One-time or stealth addresses.
• Mixing schemes.
• Zero-knowledge proofs (ZKP).

Mixing improves unlinkability but degrades quickly without adoption and is fragile under analysis.

ZKP-based systems provide stronger guarantees, at the cost of complexity and compute (on- and off-chain). To support compliance obligations (such as AML and Travel Rule obligations), ZKP-based systems often support selective disclosure features like "viewing keys.” Most systems also hide amounts transferred.

Amount confidentiality

How much value moved?

Encrypting amounts raises hard problems:

• How to prove sufficient balance without revealing it.
• How can wallets display balances.

Solutions relying on ZKPs, as pioneered by Zcash, solved those problems. Another class of techniques relies on fully homomorphic encryption (FHE), which unlike ZKPs tends not to hide addresses.

Execution confidentiality

What logic was executed, and with what inputs?

This generalizes private transfers. On a public blockchain, every node executes every instruction in the clear. Private execution systems usually rely on universal ZKP, which can process arbitrary programs rather than just fixed ones—Zcash ZKP is only for transfers, for example.

Such systems are orders of magnitude more complex than those protecting only transfers. They tend to be computationally heavy, involve convoluted protocols, and lack production maturity. They typically rely on a domain-specific language (DSL) to describe programs in a human-readable language that compiles into ZK proofs.

Note that “ZK rollup” L2 protocols generally don’t offer any privacy. These use ZKPs to reduce the L1’s workload but transactions details are exposed at least to the L2 network.

Privacy-oriented protocols and platforms

Below is a non-exhaustive list of prominent projects. Note that for full confidentiality, additional measures are often needed to avoid traffic analysis, IP address leak, and other side channels. Unless stated otherwise, protocols support selective disclosure and protect both amounts and addresses.

Aleo

URL: https://aleo.org/

Code: https://aleo.https//github.com/AleoNet

Type: Dedicated L1 for private program execution.

Details:

• Based on the Zexe framework (https://eprint.iacr.org/2018/962), with Marlin as universal ZKP.
• BFT-like consensus with proof of stake and a proof of work called “proof of succinct work” involving ZKP-like operations.
• Custom VM (AVM).
• Custom DSL (Leo), compiling to R1CS constraints.
• Proofs verified by the L1’s VM.

Status: Mainnet live since September 2024 with active development, but tooling, audits, and production track record remain limited. In December 2025, Circle and Aleo announced USDCx on Aleo testnet: https://www.circle.com/blog/usdcx-on-aleo-testnet-via-circle-xreserve

Aleph Zero

URL: https://alephzero.org

Code: https://github.com/alephzero

Type: General-purpose L1 with optional privacy.

Details:

• Custom Substrate-based L1.
• Based on the Halo2 framework (https://github.com/zcash/halo2), with Ultraplonk as universal ZKP.
• BFT-like consensus.
• Privacy implemented via zkOS, enabling shielding and ZK validation through smart contracts.
• Proofs verified by the L1’s VM.
• EVM support existed but has been discontinued.
• Addresses visible unless relayers are used.

Status: Mainnet live since 2021. Privacy stack still evolving and partially experimental. Lower privacy guarantees than Aleo or Aztec.

Avalanche – Encrypted ERC-20 (eERC)

URL: https://docs.avacloud.io/encrypted-erc/getting-started/what-is-encrypted-erc

Code: https://github.com/ava-labs/EncryptedERC

Type: Privacy extension on an existing L1 (Avalanche C-Chain). Only hides amounts, not addresses.

Details:

• ElGamal-based homomorphic encryption for balances and transferred amounts.
• Groth16 ZKP to validate transfers and balance correctness.
• Explicit audit mode allows designated parties to decrypt data.
• Proofs verified by the L1’s VM.

Status: Running in production on Avalanche. Reasonable gas cost. Limited wallet support.

Aztec

URL: https://aztec.network

Code: https://github.com/AztecProtocol

Type: Ethereum L2 for private program execution.

Details:

• UTXO-based model, Zcash-inspired, with UltraPlonk as universal ZKP.
• Custom local wallet environment PXE (Private Execution Environment).
• Custom DSL (Noir).
• Proofs verified by the L2’s sequencer, and rollup proofs verified on the L1 via a smart contract (as opposed to built in the EVM).

Status: Mainnet launched Q4 2025 after years of R&D; ecosystem still young. Heavy local infrastructure, developer friction. Private version of the security token CMTAT developed by Taurus.

Canton Network

URL: https://www.canton.network

Code: https://github.com/digital-asset/canton

Type: Public-permissioned institutional DLT with built-in privacy.

Details:

• Network-of-networks architecture by Digital Asset.
• Established, simple cryptography (ECC, RSA, AES, HMAC, etc.) and access control mechanisms.
• Privacy achieved via restricted disclosure, not ZK: only transaction stakeholders see plaintext.
• Validators require governance approval.
• Custom DSL (Daml), processed by the Canton interpreter.

Status: Used in production by live institutional participants. In January 2026, J.P. Morgan and Canton announced a collaboration, to issue JPM Coins on the Canton Network.

Midnight

URL: https://midnight.network

Code: https://github.com/midnightntwrk

Type: Dedicated L1 for private program execution.

Details:

• Developed by IOG (Cardano).
• Mix of UTXO model for the consensus and account-based logic for the private layer.
• Based on the Kachina framework (https://www.iog.io/papers/kachina-foundations-of-private-smart-contracts), with Plonk as universal ZKP.
• Custom DSL (Compact).

Status: Testnet stage for privacy features; mainnet planned in 2026. Very recent, thin tooling and ecosystem.

Railgun

Type: EVM smart contract application for private transfers.

URL: https://railgun.org

Code: https://github.com/railgun-privacy

Details:

• Smart contracts implementing shielding via encrypted UTXO-style notes.
• Groth16 ZKP for transfers (not universal).
• Relatively gas-expensive.
• Attempt to support AML compliance blacklisting with “proofs of innocence”.
• Proofs verified by smart contracts.

Status: Live since 2021 with real usage, but privacy depends on adoption and relayer availability. No new chain required; integrates with existing EVM wallets. Limited to transfers, no private execution.

Solana – Confidential Transfer extension

Type: Privacy extension on Solana L1. Only hides amounts, not addresses.

URL: https://solana.com/docs/tokens/extensions/confidential-transfer

Code: https://github.com/solana-labs

Details:

• Extension for the Token-2022 program.
• ElGamal-based homomorphic encryption for balances and transferred amounts.
• Groth16 ZKP to validate transfers and balance correctness.
  
  

Status: First deployed in 2024, now "temporarily disabled on the mainnet and devnet as it undergoes a security audit". Reasonable gas cost. Minimal wallet support

Zama

Type: FHE-based privacy layer for smart contracts on EVM chains. For transfers, it may only hide amounts, not addresses.

URL: https://zama.ai

Code: https://github.com/zama-ai

Details:

• Uses lattice-based Fully Homomorphic Encryption (FHE) to keep data encrypted end-to-end. ZKPs are needed to ensure correctness.
• Actual FHE computation is done by off-chain coprocessors.
• Data decryption performed using multi-party computation (threshold decryption).
• Hides contract state, intermediate computation results.

Status: Mainnet launched in December 2025. Limited production deployment. Requires coordination between multiple parties: coprocessors for FHE computation, threshold decryption committee, and on-chain validators.

Conclusion

There is no universal, one-size-fits-all privacy solution. From an institutional custody and tokenization perspective, the following dimensions dominate:

• Regulatory compliance capabilities: selective disclosure, viewing keys, and jurisdictional compatibility.
• Trust assumptions and operational complexity: security model, number of dependencies, third-party reliance, and attack surface.
• Functionality scope: private execution vs transfers only; address and amount confidentiality vs amounts only.
• Deployment model: dedicated L1, L2, or extension on existing chain, affecting security inheritance, interoperability, and migration risk.
• Ecosystem integration: ERC-20 compatibility, DEX support, wallet availability, and developer tooling maturity.
• Project sustainability: long-term commitment, governance structure, community support, and institutional backing.
• Operational friction: key management complexity, proof generation requirements, user experience, and custody integration challenges.