ZEROK.ID

Modern digital identity operates on the principle of universal linkability. Every service demands an email address, phone number, or government ID—persistent identifiers that connect every action to a single, permanent persona. The result is comprehensive surveillance:

• Cross-context tracking: Your dating profile knows about your LinkedIn, your shopping history informs your insurance rates, your political donations affect your employment prospects.
• Permanent digital shadows: Data breaches expose not just credentials, but entire graphs of relationships, preferences, and behaviors spanning decades.
• Compelled disclosure: KYC requirements force identity revelation even for pseudonymous contexts, creating regulatory chokepoints for mass surveillance.

Reputation is equally broken. Trust scores accumulated on one platform cannot transfer to another without revealing identity. A professional with 10 years of 5-star reviews on one marketplace must start from zero on another, while simultaneously being unable to prevent their professional reputation from affecting their personal dating life.

Current solutions—OAuth, federated identity, blockchain-based IDs—merely redistribute the surveillance apparatus. They create different points of centralization but preserve fundamental linkability.

Users face an impossible choice: participate in digital society and accept total surveillance, or opt out entirely and sacrifice the benefits of reputation, commerce, and social connection. This paper rejects this false dichotomy.

ZEROK.ID is built on three cryptographic guarantees:

• Unlinkability: No observer can determine whether two identities belong to the same master key, even with access to all on-chain data.
• Selective disclosure: Users prove reputation properties (e.g., "aggregate trust score > 95") without revealing which identities contributed to that score.
• Non-transferability: Reputation cannot be sold or transferred, only proven by the holder of the private key.

The protocol consists of four layers:

Shadow identities are generated using BIP32/BIP44 hierarchical deterministic (HD) key derivation. A single master seed generates an unlimited tree of cryptographically isolated keypairs:

master_seed → m/44'/501'/0'/0'/n' → shadow_keypair_n

Each shadow appears as an independent Ed25519 keypair on Solana. Without the master seed, no observer can link shadows, even if they control the network.

Critical property: The master seed never leaves the user's device. All derivation happens client-side.

Reputation aggregation uses ZK-SNARKs (specifically Groth16 on the BN254 curve) to prove statements about reputation without revealing:

• Which specific shadows hold reputation
• How much reputation each shadow contributes
• The relationship graph between shadows

Example proof circuit:

PROOF:
  PUBLIC INPUTS:
    - threshold: 95
    - proof_hash

  PRIVATE INPUTS:
    - shadow_keys[]: [k1, k2, ..., kn]
    - reputation_scores[]: [r1, r2, ..., rn]

  CONSTRAINTS:
    1. ∀i: verify_signature(shadow_keys[i])
    2. sum(reputation_scores) ≥ threshold
    3. ∀i: verify_on_chain(shadow_keys[i], reputation_scores[i])

When one shadow vouches for another, ring signatures hide the voucher among a set of possible signers. The verifier learns: "One of these N shadows vouched for this shadow" but cannot determine which one.

This prevents graph analysis attacks where reputation patterns reveal identity clusters.

On-chain reputation scores are stored at stealth addresses derived from shadow public keys. Each reputation update uses a fresh address, preventing transaction graph analysis.

stealth_addr = H(shadow_pubkey || nonce) · G

function create_shadow(master_seed, context_id):
  derivation_path = m/44'/501'/0'/0'/context_id'
  shadow_keypair = derive_keypair(master_seed, derivation_path)
  shadow_address = shadow_keypair.public_key

  // Burn ceremony (optional)
  if user_requests_burn:
    create_burn_transaction(shadow_keypair)
    mark_shadow_as_burned(shadow_address)

  return shadow_keypair

Shadows accumulate reputation through verifiable on-chain interactions:

• Successful transactions (escrow release, payment completion)
• Explicit vouches from other shadows (using ring signatures)
• Time-locked commitments (proof of longevity)
• Platform-specific metrics (reviews, ratings, endorsements)

Each interaction is recorded at a stealth address to prevent clustering.

function generate_reputation_proof(shadows, threshold):
  // 1. Gather reputation data
  reputation_data = []
  for shadow in shadows:
    score = fetch_on_chain_reputation(shadow.address)
    reputation_data.push({shadow.private_key, score})

  // 2. Generate ZK proof
  proof = zksnark.prove({
    public: {threshold, commitment},
    private: {reputation_data},
    circuit: reputation_circuit
  })

  // 3. Return proof (does NOT reveal shadows)
  return proof

function verify_reputation_proof(proof, threshold):
  // Verifier checks proof without learning:
  // - Which shadows contributed
  // - How much each contributed
  // - Total number of shadows

  return zksnark.verify(proof, threshold)

ZEROK.ID assumes:

• Honest majority: >51% of vouchers are honest (standard assumption for reputation systems)
• Blockchain integrity: Solana validators do not collude to censor or reorder transactions
• Client security: User devices are not compromised; master seeds are stored securely

Under the discrete logarithm assumption and with honest ZK-SNARK setup, ZEROK.ID provides computational unlinkability: no polynomial-time adversary can link shadows with probability greater than random guessing.

Unlike tokens, reputation in ZEROK.ID is:

• Non-transferable: Bound to private keys, cannot be sold
• Context-specific: Dating reputation ≠ professional reputation
• Time-dependent: Decays without continued positive interactions

This creates proper incentive alignment: reputation must be earned and maintained, not purchased.

ZEROK.ID benefits from cross-sided network effects:

• More users → more vouchers → more valuable reputation proofs
• More platforms → more contexts → more use cases for shadows
• More reputation data → better ZK proof efficiency → lower costs

// Reputation Registry (Solana Program)
program reputation_registry {

  // Store reputation at stealth address
  instruction add_reputation(
    stealth_address: Pubkey,
    encrypted_score: u64,
    proof: RingSignature
  )

  // Verify reputation proof
  instruction verify_proof(
    proof: ZKProof,
    threshold: u64
  ) -> bool

  // Burn shadow (irreversible)
  instruction burn_shadow(
    shadow_address: Pubkey,
    master_signature: Signature
  )
}

A user maintains separate shadows for different marketplaces. They aggregate reputation across all shadows to prove trustworthiness on a new platform, without revealing their purchase history or linking their personas.

A journalist separates professional work (shadow A) from political activism (shadow B) from personal social media (shadow C). If shadow C is doxxed, shadows A and B remain cryptographically protected.

A whistleblower uses ZK proofs to demonstrate they work at the relevant company (via professional shadow's verified employment) while posting anonymously, without revealing their identity or enabling correlation attacks.