Skip to main content

Privacy Model

ZEclipse is a Solana privacy protocol that combines multi-hop routing, split transactions, fake paths, zero-knowledge proofs, and temporal obfuscation to break on-chain linkability between sender and recipient.

This page summarizes the model described in README.md and DOCUMENTATION.md from the BlackoutSOL repo.

Anonymity Set & Multi-Hop Routing​

  • 4 hops per transfer.
  • 48 paths per hop (4 real + 44 fake).
  • 5,308,416 total paths: (48^4).

At each hop:

  • Real value is split across 4 real paths.
  • 44 fake splits are created as decoys.
  • All 48 paths move through program-derived addresses (PDAs), so chain observers see 48 plausible candidates per hop.

After 4 hops, an attacker trying to guess the real path faces:

  • Hop 1: 1 in 48
  • Hop 2: 1 in 2,304
  • Hop 3: 1 in 110,592
  • Hop 4: 1 in 5,308,416

Combined with timing and amount hiding, the effective anonymity set is in the millions of possibilities for a single transfer.

Split Mechanism & Fake Splits​

The split mechanism has three goals:

  1. Hide flow direction: Real value is continuously split and recombined so no single path carries the full amount.
  2. Dilute signal with noise: Fake splits carry realistic-looking amounts but are provably fake to the program.
  3. Enable batching & efficiency: Splits can be processed in parallel (e.g., via batch_hop) to retain performance.

Real vs fake status is tracked via internal state (including Bloom filters and metadata fields) and never revealed on-chain. Only the program can distinguish them when verifying proofs and advancing state.

Zero-Knowledge Proofs​

ZEclipse uses a ZK stack built around:

  • HyperPlonk proofs for hop correctness.
  • Poseidon hash as the ZK-friendly commitment/hash primitive (BN254 curve parameters).
  • Range proofs to show amounts are in valid ranges without revealing values.
  • Merkle proofs to show membership in anonymity sets without revealing identities.

Roughly, each hop proves:

  • The sum of outputs equals the sum of inputs (conservation of value).
  • Exactly 4 real splits are consistent with the previous hop.
  • Fake splits are consistent with the fake-split rules.
  • All commitments and addresses are derived correctly using Poseidon and PDAs.

Important: As documented in DOCUMENTATION.md, the current proofs are experimental and not yet production-audited. Do not treat them as a finalized security construction.

Temporal Obfuscation​

Temporal obfuscation protects against timing correlation attacks (see docs/TEMPORAL_OBFUSCATION.md):

  • Each hop is executed with randomized delays.
  • Multi-recipient transfers are spread across time slices within a configurable window.
  • Delay distributions differ per hop and per strategy (MINIMAL, STANDARD, BALANCED, MAXIMUM_PRIVACY, CUSTOM).

This:

  • Breaks simple “in ↔ out” timing correlation.
  • Prevents clustering of related transfers.
  • Increases the effective anonymity set by roughly 1–5×, depending on the strategy (up to ~20M+ effective paths).

For implementers, temporal obfuscation lives primarily in the TypeScript SDK (TimeObfuscator, TemporalObfuscationManager, and TimingEnhancedConnector).

Multi-Recipient Privacy​

ZEclipse supports distributing funds across 3–6 recipient wallets:

  • Recipients are stored in a single transfer state account (up to 6).
  • Final outputs are split across these wallets with randomized proportions.
  • On-chain, it is unclear which wallets belong to the same entity.

This provides:

  • Horizontal anonymity: one transfer becomes many outputs.
  • Plausible deniability: observers cannot easily cluster wallets as “one user”.

See User Guides → Usability and the DApp Connector docs for user-facing and API details.

Threat Model & Guarantees (High-Level)​

ZEclipse is designed to resist:

  • Basic chain analysis (graph tracing, address linkage).
  • Amount-based correlation (amounts are hidden via ZK range/commitment schemes).
  • Timing correlation (via temporal obfuscation).
  • Simple clustering of recipients (via multi-recipient distribution).

It does not yet claim to match fully mature privacy chains (e.g., Monero) and comes with the explicit caveats in DOCUMENTATION.md:

  • ZKP components are not yet audited.
  • Sophisticated global adversaries may still perform advanced statistical analysis.
  • Operational security (wallet hygiene, usage patterns) remains critical.

For a precise, formal description of guarantees and limitations, see the Privacy Mechanism, Zero-Knowledge Proofs, and Security Considerations sections in DOCUMENTATION.md.