ExePay Technical Whitepaper

Table of Contents

• 1. Introduction
• 2. Background and Related Work
• 3. System Architecture
• 4. Cryptographic Foundations
• 5. Privacy Components
• 6. Payment Infrastructure
• 7. Security Analysis
• 8. Performance Evaluation
• 9. Future Work
• 10. Conclusion

1. Introduction

1.1 Motivation

Public blockchains provide unprecedented transparency and auditability, but this transparency creates significant privacy concerns for both individuals and enterprises. Every transaction on Solana is publicly visible, revealing wallet balances, transaction graphs, income patterns, and spending habits.

This transparency is incompatible with:

• Business requirements - Protecting revenue from competitors
• Individual privacy - Financial sovereignty and safety
• Regulatory compliance - GDPR and data minimization principles
• Real-world adoption - Mainstream users expect privacy

1.2 Design Goals

ExePay aims to achieve:

1. Privacy - Hide transaction participants and amounts while maintaining auditability
2. Performance - Sub-second transaction finality compatible with Solana's speed
3. Cost - Transaction costs under $0.01 via zero-knowledge state compression
4. Compatibility - Works with existing Solana wallets and infrastructure
5. Flexibility - Configurable privacy levels for different use cases
6. Compliance - Cryptographic payment proofs for auditing and dispute resolution

1.3 Key Contributions

• Novel adaptation of UTXO-based privacy (Monero) to account-based blockchains (Solana)
• Hybrid privacy architecture combining stealth addresses with ZK compression
• Payment proof protocol enabling privacy with regulatory compliance
• Performance optimizations (view tags, batch processing) for practical deployment
• Production implementation with comprehensive SDK and mainnet deployment

2. Background and Related Work

2.1 Privacy in Cryptocurrencies

✨ No existing solution combines stealth addresses, ZK compression, payment proofs, and production-ready implementation on Solana.

3. System Architecture

3.1 Overview

ExePay consists of three layers:

┌─────────────────────────────────────────────────────────┐
│                  Application Layer                       │
│  (Web App, Mobile, SDK, API)                            │
└────────────────────┬────────────────────────────────────┘
                     │
┌────────────────────┴────────────────────────────────────┐
│                  Privacy Layer                           │
│  • Stealth Addresses      • Payment Proofs              │
│  • ZK Compression         • Subaddresses                │
│  • Shielded Balances      • Scanning Engine             │
└────────────────────┬────────────────────────────────────┘
                     │
┌────────────────────┴────────────────────────────────────┐
│                Payment Infrastructure                    │
│  • Multi-token        • Batch Transfers                 │
│  • Recurring          • Payment Links                   │
└────────────────────┬────────────────────────────────────┘
                     │
┌────────────────────┴────────────────────────────────────┐
│                  Solana Blockchain                       │
│  (Account Model, <400ms finality, $0.00025/tx)          │
└─────────────────────────────────────────────────────────┘

3.2 Privacy Modes

Users can select privacy level based on their requirements:

4. Cryptographic Foundations

4.1 Elliptic Curve Diffie-Hellman (ECDH)

ExePay uses X25519 for ECDH key exchange, enabling two parties to establish a shared secret. Alice generates private key a and public key A = aG. Bob generates private key b and public key B = bG. The shared secret is S = aB = bA = abG.

Security: Relies on hardness of Computational Diffie-Hellman (CDH) problem. Requires O(2¹²⁸) operations for Curve25519 (128-bit security).

4.2 Key Derivation Functions

We use Keccak-256 for key derivation. Keccak-256 provides 256-bit output with:

• Collision resistance: O(2¹²⁸) operations
• Preimage resistance: O(2²⁵⁶) operations
• Used in Ethereum, proven secure

4.3 Zero-Knowledge Proofs

We utilize Groth16 pairing-based zk-SNARKs for proving statements without revealing witnesses:

• Completeness: Valid proofs always verify
• Soundness: Invalid proofs rejected with overwhelming probability
• Zero-knowledge: Proof reveals nothing about witness
• Succinctness: Proof size O(1), verification time O(|public inputs|)

5. Privacy Components

5.1 Stealth Addresses

Protocol:

1. Recipient Setup: Generate spend keypair (s, S) and view keypair (v, V). Publish meta-address M = (S, V)
2. Sender Payment: Generate ephemeral keypair (r, R). Compute shared secret P = rV. Derive stealth address K and view tag t
3. Recipient Scanning: For each transaction, check view tag. If match, compute stealth address and verify ownership
4. Recipient Claiming: Derive stealth private key and transfer funds

Security: Recipient anonymity relies on DLP hardness and collision resistance of Keccak-256.

5.2 Payment Proofs

Cryptographic proofs enabling senders to prove payment without revealing recipient identity. Proof includes transaction signature, ephemeral public key, amount, and recipient meta-address hash.

Use Cases: Tax audits, dispute resolution, compliance, business expense verification

5.3 Integrated Addresses

Extend stealth addresses to embed 8-byte payment ID for invoice/order tracking. Payment ID included in transaction memo, auto-matched by recipient during scanning.

5.4 Subaddresses

Hierarchical stealth identities: S_i = H(s || i) · G + S, V_i = H(v || i) · G + V. Each subaddress is cryptographically unlinkable (DLP hardness). Perfect for separating business/personal funds.

5.5 View Tags

1-byte hint attached to each payment. Recipient checks hint first (cheap), filtering 99% of transactions instantly. Only 1% require expensive ECDH computation. 100x performance improvement.

6. Payment Infrastructure

• Multi-Token: SOL, SPL tokens with automatic routing
• Batch Transfers: Combine multiple transfers (up to 30 per transaction)
• Recurring Payments: Authorized schedules with user control
• Payment Links: QR code generation, expiration, single-use links

7. Security Analysis

Threat Model

Adversary Capabilities:

• Monitors all on-chain transactions
• Controls multiple RPC nodes
• May compromise view key (but not spend key)
• Cannot break cryptographic primitives (128-bit security)

Assets Protected: Recipient identity, transaction linkability, payment amounts (in compressed mode)

Assets Not Protected: Sender identity (visible on-chain), transaction existence, metadata

Attack Mitigation

• Transaction Graph Analysis: Stealth addresses break transaction graph links
• Timing Analysis: Users can delay transactions, use varying intervals
• Amount Analysis: Shielded balances hide amounts
• Denial of Service: View tags filter 99% of spam

8. Performance Evaluation

Benchmarks (M1 MacBook Pro, 16GB RAM)

✅ View tags provide 101x speedup for scanning (18ms vs 1830ms)

Cost Analysis

• Standard Transfer: $0.00025
• Stealth Address Payment: $0.00025
• Compressed Transfer: $0.00000025 (1000x cheaper)
• Batch Transfer (10 recipients): $0.000025 per recipient

9. Future Work

• Sender Anonymity: Ring signatures for sender privacy (Monero's RingCT adapted to Solana)
• Advanced ZK Circuits: Single proof for entire transaction (sender + receiver + amount)
• Cross-Chain Privacy: ZK bridge protocol for Ethereum, Polygon
• Hardware Wallets: Ledger/Trezor integration for secure key management
• Mobile SDK: Native iOS/Android with GPU-accelerated ZK proving

10. Conclusion

ExePay demonstrates that strong privacy and high performance are not mutually exclusive. By adapting proven cryptographic protocols to high-performance blockchains and integrating cutting-edge ZK technology, we achieve:

Privacy is not a feature. It's a fundamental right.