Technical Whitepaper v1.0

Cloak Protocol

A privacy layer for Solana using stealth addresses and relayer infrastructure

Contents

1. Abstract

Cloak is a privacy protocol built on Solana that enables private transactions through cryptographic stealth addresses and a decentralized relayer network. Unlike mixers which provide privacy by pooling funds, Cloak allows users to receive payments at unique one-time addresses that only they can identify and spend from, without ever revealing a connection to their public identity.

The protocol combines elliptic curve Diffie-Hellman key exchange with Solana's Program Derived Addresses (PDAs) to create a seamless privacy layer that maintains Solana's speed and cost advantages while providing strong unlinkability guarantees.

2. Introduction

Blockchain technology has revolutionized finance by providing transparency and immutability. However, this transparency creates significant privacy challenges. Every transaction on Solana is publicly visible, creating a permanent record that links addresses to each other and, through various heuristics, to real-world identities.

This lack of privacy has real consequences:

  • Traders reveal their strategies to competitors who can front-run or copy them
  • Individuals receiving payments expose their entire financial history
  • Businesses leak sensitive supplier and customer relationships
  • High-value holders become targets for social engineering attacks

Cloak addresses these issues by providing transaction privacy without sacrificing the benefits of public blockchain infrastructure.

3. The Problem

Consider a simple payment scenario: Alice wants to pay Bob for services rendered. On a standard blockchain:

Alice (0x1234...) → 10 SOL → Bob (0x5678...)

This transaction reveals:

  • Alice paid Bob (relationship exposed)
  • The exact amount transferred
  • Alice's wallet balance and history
  • Bob's wallet balance and all previous payments received

Existing privacy solutions have limitations:

Mixers/Tumblers

Require coordination between sender and receiver. Good for moving your own funds, poor for receiving payments from others.

Privacy Chains

Require bridging assets to separate networks, losing Solana's speed, ecosystem, and liquidity.

New Wallets

Creating fresh addresses for each transaction is operationally complex and doesn't solve the gas funding problem.

4. Solution Overview

Cloak provides privacy through two complementary mechanisms:

1

Stealth Addresses (Unlinkable Receiving)

Senders generate unique one-time addresses for each payment. Only the recipient can detect and spend from these addresses, while observers see no connection between transactions.

2

Relayer Network (Unlinkable Spending)

A decentralized network of relayers submit transactions on behalf of users, paying gas fees so users never need to fund stealth addresses from identifiable sources.

Together, these mechanisms break the link between sender, receiver, and their respective transaction histories.

5. Stealth Address Protocol

5.1 Key Generation

Recipients generate two keypairs on the Ed25519 curve:

// Spending keypair
s ← random scalar
S = s × G
// Viewing keypair
v ← random scalar
V = v × G
// Stealth meta-address (published)
meta = (S, V)

The spending key s remains offline in cold storage. The viewing key v can be shared with services or auditors to detect incoming payments without spending capability.

5.2 Sending Process

When Alice wants to pay Bob:

// Alice retrieves Bob's meta-address
(S, V) ← Bob.meta
// Generate ephemeral keypair
r ← random scalar
R = r × G
// Compute shared secret
shared = r × V = r × v × G
// Derive one-time address
P = S + hash(shared) × G
// Send funds
transfer(amount, P)
publish(R) // via memo or registry

5.3 Receiving Process

Bob scans for incoming payments:

// For each published ephemeral pubkey R
shared = v × R // = v × r × G = r × V
P = S + hash(shared) × G
// Check if P has funds
if (balance(P) > 0) {
// This payment is for Bob
// Spending key: p = s + hash(shared)
}

5.4 Privacy Properties

  • Unlinkability: Each payment creates a unique address with no mathematical connection to Bob's meta-address
  • Non-interactive: Senders derive addresses without any coordination with the recipient
  • Key separation: Viewing keys allow transaction detection without spending rights

6. Relayer Network

Stealth addresses solve the receiving problem but introduce a spending challenge: how does Bob spend from a stealth address without funding it with SOL for gas from an identifiable source?

6.1 The Gas Problem

// Without relayers - privacy leak!
Bob (0x5678) → 0.01 SOL → Stealth (P)
// Observer sees connection between Bob and P

6.2 Relayer Solution

Relayers are nodes that:

  • Accept signed transaction requests from users
  • Submit transactions on-chain and pay gas fees
  • Deduct a small fee from the transferred amount
// With relayers - no link!
Bob signs: "send 99.9 USDC from P to destination"
Relayer submits tx, pays gas
Relayer receives 0.1 USDC fee
// No connection between Bob and P

6.3 Decentralization

The relayer network is permissionless:

  • Anyone can run a relayer node
  • Relayers compete on fees and latency
  • Users can broadcast to multiple relayers simultaneously
  • No single point of failure or censorship

7. Solana Implementation

7.1 Program Architecture

Cloak is implemented as a Solana program with the following components:

// Core accounts
StealthRegistry: Stores ephemeral pubkeys (R values)
RelayerRegistry: Tracks active relayers and fees
// Instructions
register_meta_address(S, V)
send_stealth(recipient_meta, amount, R)
spend_via_relayer(signed_request, relayer)

7.2 PDA Integration

Stealth addresses are implemented as Program Derived Addresses (PDAs):

stealth_pda = PDA([
"stealth",
recipient_meta.as_bytes(),
shared_secret_hash
], program_id)

This approach leverages Solana's native PDA mechanics for secure, deterministic address derivation.

7.3 Token Support

SPL tokens are supported through Associated Token Accounts (ATAs) derived from stealth PDAs:

stealth_ata = get_associated_token_address(
stealth_pda,
token_mint
)

8. Security Considerations

8.1 Threat Model

Cloak protects against:

  • Passive observers analyzing the public blockchain
  • Correlation attacks linking multiple transactions
  • Timing analysis of transaction patterns

Cloak does NOT protect against:

  • Compromised spending keys
  • Malicious recipients who reveal their viewing keys
  • Off-chain metadata leaks (IP addresses, etc.)

8.2 Compliance

The viewing key architecture enables selective transparency:

  • Users can share viewing keys with auditors or regulators
  • Businesses can prove payment flows without exposing spending keys
  • Institutions can implement internal compliance while maintaining external privacy

9. Conclusion

Cloak brings practical privacy to Solana without sacrificing the network's core advantages of speed, low cost, and ecosystem compatibility. By combining stealth addresses for unlinkable receiving with a decentralized relayer network for unlinkable spending, Cloak provides comprehensive transaction privacy that works within existing infrastructure.

The protocol is designed with regulatory flexibility in mind, allowing users to maintain privacy from the public while enabling selective disclosure to authorized parties through viewing key sharing.

Privacy is not about hiding wrongdoing—it's about maintaining financial sovereignty in an increasingly surveilled world. Cloak makes this possible on Solana.

References

  • [1] Buterin, V. (2023). "An Incomplete Guide to Stealth Addresses"
  • [2] Todd, P. (2014). "Stealth Addresses" - Bitcoin Forum
  • [3] Solana Documentation - Program Derived Addresses
  • [4] EIP-5564: Stealth Addresses (Ethereum)
Back to home