Skip to main content

​
Core Privacy Principles

P2P Protocol is designed with privacy as a fundamental requirement, not an afterthought. The privacy model ensures that users can transact with confidence that their personal information remains protected while still meeting necessary compliance requirements.
Privacy Foundation:
  • Data minimization: Contracts store only commitments, verdicts, and reputation deltas
  • Selective disclosure: ZK-KYC proofs reveal only predicates required for identity verification and compliance tiers
  • Retention & Access: Governance-set retention of attestations; no raw PII on-chain
  • Linkability: User-facing guidance to avoid unintended linkage across sessions where feasible

​
Data Minimization

The protocol operates on the principle of storing the absolute minimum data necessary for functionality.

​
What’s Stored On-Chain

Smart Contract Storage: 
Order {
  order_id: hash,
  user_commitment: hash,
  merchant_commitment: hash,
  amount: uint256,
  rail_type: enum,
  timestamp: uint256,
  state: enum,
  reputation_delta: int256
}
NOT stored:
  • User names or identities
  • Wallet addresses linked to real identities
  • Payment account numbers
  • Bank details
  • KYC documents
  • Transaction evidence (except hashes)

​
What’s Stored Off-Chain

  • Private keys
  • ZK proof generation parameters
  • Complete KYC documents (optional local storage)
  • Transaction history details
  • Payment addresses
Security: Encrypted at rest, user controls access
  • Minimal identity data required for verification
  • Verification logs (time-limited retention)
  • Proof generation parameters
Security: Isolated systems, audited security practices Retention: Governance-defined limits (typically 90 days)
  • User preferences and settings
  • Cached transaction display data
  • Analytics (anonymized)
Security: Local storage only, no server-side PII Deletion: User can clear all client data

​
Selective Disclosure

ZK-KYC proofs reveal only predicates required for identity verification and compliance tiers. Bank transaction verification is planned (see Section 4.2).

​
ZK-KYC Disclosure Levels

Tier 1: Basic

What’s Proven:
  • User is a unique human (anti-Sybil)
  • Over 18 years old
  • Not on sanctions lists
What’s Hidden:
  • Name, address, date of birth
  • Document details
  • Country of residence (optional)
Unlocks: Up to $500/transaction

Tier 2: Standard

What’s Proven:
  • Tier 1 predicates +
  • Resident of permitted jurisdiction
  • Government ID verification
What’s Hidden:
  • Specific country (only region revealed)
  • ID numbers
  • Full name
Unlocks: Up to $5,000/transaction

Tier 3: Advanced

What’s Proven:
  • Tier 2 predicates +
  • Income/source of funds category
  • Enhanced due diligence completed
What’s Hidden:
  • Specific income amounts
  • Employer details
  • Bank names
Unlocks: Up to $50,000/transaction

Tier 4: Merchant

What’s Proven:
  • Tier 3 predicates +
  • Business registration (if applicable)
  • Liquidity proof
What’s Hidden:
  • Most details still minimized
  • Only commitments on-chain
Unlocks: Merchant privileges

​
Example: Age Verification Circuit

ZK Circuit for “Over 18” Proof:Inputs (Private):
  • Date of birth from passport/ID
  • Document signature
  • Issuing authority
Inputs (Public):
  • Current date
  • Required age (18)
  • Verifier address
Output:
  • TRUE/FALSE: age >= 18
  • Proof commitment hash
What’s revealed: Only that the user is over 18 What’s hidden: Exact age, date of birth, document details

​
Planned: Bank Transaction Verification

Future evidence module will extend selective disclosure to payment proofs:What will be proven:
  • A transaction of specific amount occurred
  • Transaction timestamp within valid window
  • Sender/receiver matches order requirements
What will remain hidden:
  • Account numbers
  • Bank names
  • Other transactions in account
  • Account balances
  • Personal identifiers

​
Retention & Access

​
On-Chain Data Retention

Permanent (by design):
  • Order commitments (hashes only)
  • Reputation deltas
  • Settlement outcomes
  • Governance decisions
Why permanent: Required for protocol function, reputation portability, and dispute history Privacy protection: Only hashes and numeric values, no PII

​
Off-Chain Data Retention

Retention Policy:
  • Verification attempts: 90 days
  • Successful verifications: 1 year
  • Unsuccessful attempts: 30 days
  • Suspicious activity: 2 years (compliance requirement)
User Rights:
  • Request deletion after retention period
  • Export personal data
  • Revoke verification (loses associated reputation)
Retention Policy:
  • Active disputes: Until resolution + appeal period
  • Resolved disputes: 6 months
  • Fraud cases: 2 years
Access Control:
  • Only authorized admins/arbitrators
  • Encrypted at rest
  • Audit log of all access
  • Automatic deletion after retention period
Retention Policy:
  • User choice (local storage)
  • No server-side storage of PII
  • Analytics anonymized and aggregated
User Control:
  • Clear cache anytime
  • Export history
  • Opt out of analytics

​
Data Access Rights

Who Can Access What:Users:
  • Full access to their own data
  • Export capabilities
  • Deletion rights (subject to legal retention)
Merchants:
  • Only encrypted payment addresses during active orders
  • No access to user identity data
Admins (Dispute Resolution):
  • Access to submitted dispute evidence only
  • Time-limited access
  • Audit trail of all access
  • Cannot access data outside disputes
Governance:
  • Aggregate statistics only
  • No individual user data
  • Protocol parameter decisions
Third Parties:
  • No access to user data
  • Public blockchain data only (commitments/hashes)

​
Linkability

User-facing guidance to avoid unintended linkage across sessions where feasible.

​
Linkability Vectors

Risk: All orders from same wallet address are linkableMitigation:
  • User guidance to use separate wallets for privacy
  • Support for wallet rotation
  • ZK-proof linking to new wallet while preserving reputation
Future: Anonymous reputation credentials that can be proven without revealing wallet
Risk: Unique transaction timing patterns may identify usersMitigation:
  • Batched order submission (coming)
  • Randomized settlement times
  • User guidance on timing privacy
Note: Some linkability inevitable for reputation system
Risk: Distinctive transaction amounts may be identifyingMitigation:
  • Round number suggestions
  • Privacy-preserving amount ranges
  • User education
Tradeoff: Exact amounts required for fiat transfers
Risk: Using same payment rail repeatedly creates patternsMitigation:
  • Encourage rail diversity
  • No requirement to use same rail
  • Payment details encrypted per-order
Benefit: Rail diversity also improves reputation

​
Privacy Best Practices (User Guidance)

Recommended Practices:
  1. Use separate wallets for different contexts if privacy important
  2. Vary transaction amounts to avoid patterns
  3. Don’t reuse the same payment accounts unnecessarily
  4. Be aware that reputation tracking requires some linkability
  5. Use fresh addresses for receiving crypto when possible
  6. Consider timing of transactions if correlation is a concern

​
Privacy vs. Compliance

The protocol navigates the tension between privacy and compliance through:

​
Programmable Compliance

  • Minimal disclosure: Prove only what regulations require
  • Tiered verification: Higher compliance for higher limits
  • Selective revelation: Reveal to counterparties only when needed
  • Jurisdiction-aware: Different rules for different regions

​
Travel Rule Compatibility (Planned)

For transactions involving regulated entities: 
IF (counterparty.isRegulatedEntity AND amount > threshold) {
  REQUIRE: selective_disclosure_to_counterparty({
    name: encrypted_to_counterparty,
    jurisdiction: revealed,
    amount: visible
  })
} ELSE {
  REQUIRE: minimal_disclosure()
}
This enables compliance where legally required without compromising privacy for peer-to-peer transactions between individuals.

​
Privacy Guarantees

​
What We Guarantee

No PII On-Chain

Never will user names, addresses, documents, or raw identity data be stored on public blockchains.

Cryptographic Protection

All proofs use zero-knowledge cryptography. Verification reveals only the predicate, not the data.

User Control

Users decide what to verify, when to disclose, and can export or delete data within legal limits.

No Selling Data

Protocol will never sell user data. Revenue comes from transaction fees, not data monetization.

​
What We Cannot Guarantee

Inherent Limitations:
  1. Blockchain permanence: Commitments on-chain are permanent
  2. Reputation linkability: Reputation system requires some transaction linkage
  3. Counterparty knowledge: Matched merchant knows payment address during order
  4. Legal requirements: May be required to disclose data by court order
  5. Network analysis: Sophisticated chain analysis may reveal patterns
  6. User mistakes: Cannot protect against user self-doxxing

​
Privacy Roadmap

​
Near-Term

  • Launch with current ZK-KYC selective disclosure
  • Publish privacy best practices guide
  • Implement encrypted messaging for order coordination

​
Medium-Term

  • Bank transaction ZK proofs
  • Enhanced wallet privacy features
  • Anonymous reputation credentials (research)

​
Long-Term

  • Fully anonymous credibility system
  • ZK-rollup for order privacy
  • Decentralized identity integration (DID)
  • Quantum-resistant privacy primitives
Privacy technology evolves rapidly. The protocol commits to adopting privacy-enhancing technologies as they mature while maintaining security and compliance requirements.

Build docs developers (and LLMs) love

Get started for freeTalk to us