Privacy with Selective Disclosure

01Executive Summary

JIL Sovereign implements consensus-layer transaction privacy where all account balances and transfer amounts are encrypted on-chain using homomorphic commitments. Only the state tree Merkle root is publicly visible, while validators verify transaction validity through ZK-SNARK proofs without ever accessing plaintext financial data.

The system introduces a selective disclosure protocol that enables users to generate deterministic proofs of specific regulatory attributes - such as accredited investor status, sanctions compliance, tax compliance, and AML compliance - for authorized regulators. Because proof generation uses no randomness, every proof is fully reproducible, enabling verifiable regulatory audits without compromising user privacy.

02Problem Statement

Blockchain networks face a fundamental tension between transaction privacy and regulatory compliance. Public ledgers expose all financial activity to the world, while privacy-focused systems like Tornado Cash make compliance impossible. Neither extreme serves institutional users who need both confidentiality and regulatory access.

2.1 The Privacy-Compliance Paradox

• Transparent Chains: Every balance and transfer is visible to anyone. Corporate treasuries, fund managers, and individuals have zero financial privacy on networks like Ethereum and Bitcoin.
• Privacy Coins: Systems like Monero and Zcash provide strong privacy but offer no mechanism for regulatory compliance, making them unsuitable for institutional adoption.
• Mixer Protocols: Tools like Tornado Cash were sanctioned by OFAC precisely because they provide privacy without any compliance mechanism.

2.2 Why Existing Approaches Fail

03Technical Architecture

The privacy system operates at three layers: homomorphic commitment storage, ZK-SNARK validation, and selective disclosure proof generation. Each layer is enforced at the consensus level, meaning privacy guarantees hold regardless of application-layer behavior.

3.1 Homomorphic Commitment Layer

All account balances are stored as Pedersen commitments of the form C = g^v * h^r where v is the value and r is a blinding factor known only to the account holder. The additive homomorphic property allows validators to verify that inputs equal outputs (conservation of value) without knowing any individual amount.

3.2 Privacy Components

3.3 State Tree Structure

The encrypted state tree uses a sparse Merkle tree where each leaf contains a Pedersen commitment rather than a plaintext balance. The tree root is published in every block header, allowing anyone to verify state consistency. Validators compute state transitions over commitments using homomorphic operations, confirming transaction validity without decryption.

04Implementation

4.1 Encrypted Transaction Flow

1. Sender constructs transaction: Creates Pedersen commitments for the transfer amount and new balance, generates range proofs for both, and constructs a ZK-SNARK proving the state transition is valid.
2. Validator verification: Checks the ZK-SNARK proof, verifies range proofs confirm non-negative amounts, and confirms the commitment arithmetic balances (inputs = outputs + fee commitment).
3. State update: Validator updates the Merkle tree with new commitment leaves. No plaintext amount is ever stored, transmitted, or computed by any validator.
4. Block finalization: The new Merkle root is published in the block header. The full encrypted state is available for audit via selective disclosure.

4.2 Selective Disclosure Protocol

Users generate deterministic ZK proofs that reveal specific attributes without exposing the underlying data. The key innovation is the elimination of randomness from proof generation - given the same inputs, the same proof is always produced, enabling independent verification by multiple regulators.

4.3 Disclosure Types

4.4 Deterministic Proof Generation

Unlike standard ZK-SNARK implementations that use random witnesses, JIL's selective disclosure proofs are generated using a deterministic derivation function seeded by the user's private key and the disclosure request parameters. This means the same disclosure request always produces the same proof, allowing a second regulator to verify that the first regulator received an accurate disclosure.

05Integration with JIL Ecosystem

5.1 Consensus Layer Enforcement

Privacy guarantees are enforced at the validator consensus level. All 20 validators verify ZK-SNARK proofs as part of block validation. A transaction cannot be included in a block unless its privacy proofs are valid under the 14-of-20 BFT threshold. This means privacy is not optional or application-dependent - it is a protocol primitive.

5.2 Compliance API Integration

The compliance-api service provides endpoints for regulators to request selective disclosures. Requests are authenticated, logged, and rate-limited. Each disclosure request is recorded on-chain as a compliance event, creating an immutable audit trail of who requested what information and when.

5.3 Bridge Privacy

Cross-chain bridge operations maintain privacy through commitment-based transfers. When wrapping external assets (jBTC, jETH, jUSDC), the minted amount is immediately committed into the encrypted state. External observers can see that a bridge deposit occurred but cannot determine the amount or the recipient's total balance.

5.4 DEX Integration

The retail lane engine and RFQ system operate over encrypted order intents. Batch auction clearing uses homomorphic operations to match buyers and sellers without exposing individual order sizes. The clearing price is published but individual fill amounts remain private.

06Prior Art Differentiation

07Implementation Roadmap

08Patent Claim