Docs/Privacy & Identity/ANCORA Privacy Protocol Specification v1.0

ANCORA Privacy Protocol Specification v1.0

Last updated: June 2026 | Public Release v1.0

Formal Specification for Native Confidential Transaction Protocol

1. Privacy Design Objectives

The ANCORA Privacy Protocol (APP) delivers full transactional anonymity with mathematically provable privacy guarantees. The protocol simultaneously satisfies three core privacy properties:

Sender Anonymity: No third party can determine the origin of any transaction

Receiver Anonymity: No third party can determine the destination of any transaction

Amount Confidentiality: No third party can determine the value of any transaction

All privacy guarantees are enforced at the protocol level by default. Privacy is not an optional feature, layer-2 add-on, or premium service.

2. Cryptographic Privacy Primitives

2.1 Pedersen Commitments for Amount Confidentiality

All transaction amounts are hidden using Pedersen commitments over the secp256k1 elliptic curve.

Commitment Generation:

For amount v (64-bit unsigned integer) and cryptographically secure random blinding factor r:

Where:

G = Standard secp256k1 base point

H = Independent secondary base point with no known discrete logarithm relation to G

Perfect hiding property: Commitment reveals zero information about v

Computational binding property: It is infeasible to find v' ≠ v, r' such that Commit(v, r) = Commit(v', r')

2.2 CLSAG Ring Signatures for Sender Anonymity

All transaction inputs are signed using a Concise Linkable Spontaneous Anonymous Group (CLSAG) ring signature with a fixed ring size of 1024 decoy inputs.

Ring Construction:

True signer selects 1023 random decoy outputs from the global UTXO set

Ring size is fixed at 1024 for all transactions, eliminating size-based fingerprinting

Linkability property ensures the same input cannot be spent twice without detection

Anonymity set size = 1024 per input, providing ≥10 bits of anonymity per transaction

Security Guarantee: The probability of correctly guessing the true signer from a valid signature is exactly 1/1024, computationally indistinguishable from random.

2.3 Stealth Addresses for Receiver Anonymity

All transaction outputs use one-time stealth addresses to prevent linkage of multiple payments to a single user identity.

Stealth Address Generation:

Receiver publishes public view key v and public spend key s

Sender generates ephemeral random value r

Shared secret = H(r * v)

One-time public key = H(shared_secret) * G + s

Ephemeral public key = r * G published with transaction

Only the receiver, possessing the corresponding private keys, can detect and spend the output. No third party can link multiple stealth addresses to the same user.

2.4 zk-STARK Balance Proofs

Every transaction includes a zero-knowledge STARK proof that verifies:

The proof demonstrates conservation of funds without revealing any individual input or output amount. No trusted setup is required, and verification is O(1).

3. Transaction Privacy Flow

The complete private transaction lifecycle:

Input Selection: User selects UTXOs to spend

Ring Construction: 1023 decoys selected uniformly from global UTXO set

CLSAG Signature: Generate ring signature for each input

Stealth Address Generation: Generate one-time address for each output

Commitment Creation: Generate Pedersen commitments for all amounts

Balance Proof Generation: Generate zk-STARK proof of input-output balance

Broadcast: Transaction broadcast to network with zero plaintext value information

4. Privacy Security Model

4.1 Adversary Capabilities

The protocol is secure against adversaries with:

Full access to all historical and future blockchain data

Ability to monitor all network traffic

Ability to create arbitrary numbers of Sybil nodes

Ability to participate as a validator

Quantum computing capabilities (via zk-STARK post-quantum security)

4.2 Formal Privacy Guarantees

Computational Indistinguishability: All transactions are computationally indistinguishable from each other

Unlinkability: No two transactions can be proven to belong to the same user

Untraceability: No transaction input can be traced to its origin

Non-Discernibility: Transaction amounts cannot be bounded or estimated within 18 decimal places of precision