Relayers

Relayers provide an IP privacy layer and gas abstraction for Veil transactions. They act as intermediaries that submit transactions to Solana on behalf of users, breaking the link between the user's IP address and their on-chain activity.

Even with perfect cryptographic privacy, metadata can reveal your identity:

Without Relayers:

1. You generate a private transfer proof locally
2. You submit the transaction to a Solana RPC node
3. The RPC node sees your IP address and the transaction data
4. Network observers can correlate:
   • Your IP → Transaction submission time → On-chain transaction
   • Multiple transactions from the same IP (linking your activity)
   • Geographic location and timing patterns

Impact:

• Your ISP can see you're using Veil
• RPC providers can log your IP with transaction details
• Governments or adversaries can correlate IP with on-chain activity
• Even if amounts are hidden, your participation pattern is visible

Relayers provide a privacy-preserving submission service:

[User's Computer]
    |
    | 1. Generate zkSNARK proof (locally, ~5-10s)
    | 2. Sign transaction with proof + nullifier
    |
    v
[Relayer Network]
    |
    | 3. Relayer validates transaction format
    | 4. Estimates fee and adds it to transaction
    | 5. Submits to Solana RPC (from relayer's IP)
    |
    v
[Solana Blockchain]
    |
    | 6. On-chain verification
    | 7. Relayer fee paid from transaction
    |
    v
[Transaction Confirmed]

Step-by-Step Process

1. User Preparation (Off-Chain):

• Generate zkSNARK proof for private transfer
• Construct transaction with proof, nullifier, and new commitment
• Sign transaction with user's keypair
• Contact relayer and request fee estimate

2. Fee Negotiation:

• Relayer examines transaction size and complexity
• Calculates fee: typically 30 basis points (0.3%) of transaction value
• User confirms fee or tries another relayer

3. Transaction Submission:

• User sends signed transaction to relayer over HTTPS (optionally via Tor)
• Relayer validates transaction structure
• Relayer submits to Solana RPC from their infrastructure
• User's IP address is never exposed to the blockchain network

4. Fee Collection:

• On-chain program verifies the transaction
• If valid, relayer's fee is deducted from the transaction
• Relayer receives payment automatically
• User receives transaction confirmation

Relayers charge fees to cover infrastructure costs and provide economic incentive:

Default Fee Rates

Basis Points (bps): 1 bp = 0.01% = 0.0001

Examples:

• Transfer 10 SOL: Fee = 10 × 0.003 = 0.03 SOL (~$3 at$100/SOL)
• Transfer 100 USDC: Fee = 100 × 0.003 = 0.30 USDC
• Maximum fee capped at 5% to prevent abuse

Fee Calculation

def calculate_relayer_fee(amount, fee_rate=0.003):
    """
    Calculate relayer fee for transaction.
 
    Args:
        amount: Transaction amount in base units
        fee_rate: Fee as decimal (0.003 = 0.3%)
 
    Returns:
        Fee amount in base units
    """
    fee = amount * fee_rate
    max_fee = amount * 0.05  # 5% cap
    return min(fee, max_fee)
 
# Example
amount = 1_000_000_000  # 1 SOL in lamports
fee = calculate_relayer_fee(amount)
print(f"Fee: {fee} lamports = {fee / 1e9} SOL")
# Output: Fee: 3000000 lamports = 0.003 SOL

Users can choose from multiple relayers based on their preferences:

Selection Criteria

1. Fee Rate:

• Lowest fee (cost-sensitive users)
• Relayers compete on fees, creating a market

2. Reliability:

• Uptime percentage (99.9%+ for production relayers)
• Historical success rate
• Response time

3. Geographic Distribution:

• Select relayers in different countries
• Reduces correlation risk
• Improves censorship resistance

4. Reputation:

• Community-vetted relayers
• On-chain performance metrics
• Slashing for misbehavior (future)

Selection Algorithm

Veil SDK implements a smart relayer selection algorithm:

def select_relayer(relayers, strategy="balanced"):
    """
    Select optimal relayer based on strategy.
 
    Strategies:
    - "lowest_fee": Minimize cost
    - "fastest": Minimize latency
    - "balanced": Optimize fee + reliability
    - "random": Random selection (max privacy)
    """
    if strategy == "lowest_fee":
        return min(relayers, key=lambda r: r.fee_rate)
 
    elif strategy == "fastest":
        return min(relayers, key=lambda r: r.avg_response_time)
 
    elif strategy == "balanced":
        # Score = fee_weight * fee + reliability_weight * (1 - uptime)
        scores = [
            (r, 0.4 * r.fee_rate + 0.6 * (1 - r.uptime))
            for r in relayers
        ]
        return min(scores, key=lambda x: x[1])[0]
 
    elif strategy == "random":
        # Maximum privacy: no preferential selection pattern
        return random.choice(relayers)

What Relayers CAN Do:

• See transaction metadata (proof size, nullifier, commitment)
• See transaction timing
• Refuse to submit transactions (denial of service)
• Charge fees within the maximum cap

What Relayers CANNOT Do:

• Steal your funds (transaction is signed by you)
• Modify transaction data (would invalidate zkSNARK proof)
• See amounts or recipient information (cryptographically hidden)
• Link you to your transaction (if you use Tor/VPN)
• Spend your notes (requires your secret key)

Security Guarantees

Cryptographic Protection:

• zkSNARK proof is generated on your device
• Transaction is signed with your keypair
• Relayer sees only the final, signed transaction
• Tampering would invalidate the proof

Economic Incentives:

• Relayers earn fees for honest service
• Misbehavior risks reputation and future revenue
• On-chain slashing for provable fraud (future)

Redundancy:

• Multiple relayer options
• If one fails or censors, try another
• Decentralized relayer network prevents single point of failure

Relayer Knowledge

What a Single Relayer Knows:

• Your IP address (if not using Tor/VPN)
• Transaction submission time
• Transaction size and structure
• Cannot: Link to other transactions or determine amounts

Mitigation:

• Use different relayers for each transaction
• Connect via Tor/VPN to hide IP
• Random delays before submission

Relayer Collusion

Risk: Multiple relayers collaborate to correlate users.

• If relayers share data, they could build correlation databases
• Timing analysis across relayers could link transactions

Mitigation:

• Choose reputable, independent relayers
• Avoid relayers operated by the same entity
• Use Tor/VPN to prevent IP-based correlation
• Protocol-level mixing with delays (future)

Censorship Resistance

Risk: Relayers could selectively censor transactions.

• Relayer refuses to submit your transaction
• Government pressure on relayers in certain jurisdictions

Mitigation:

• Run your own relayer (ultimate censorship resistance)
• Use decentralized relayer network with many options
• Fallback to direct submission (sacrificing IP privacy)
• Geographic diversity of relayer selection

For maximum privacy and censorship resistance, run your own relayer:

Requirements:

• Solana RPC access (can use public nodes or run your own)
• Server with static IP and HTTPS
• ~100 SOL for operational liquidity (paying gas fees)

Steps:

1. Deploy relayer software (open-source, provided by Veil)
2. Configure fee rate (0.3% default)
3. Advertise relayer endpoint (HTTP API)
4. Monitor for submissions and process transactions
5. Collect fees automatically on-chain

Benefits:

• No trust required in third parties
• Complete control over transaction submission
• Can serve as relayer for friends/community
• Earn fees for providing infrastructure

Implementation Status: ✅ Implemented (Phase 3G complete)

Network Status: 🔄 Coming in v0.2.0

• Relayer protocol fully implemented
• Public relayer network planned for v0.2.0
• Currently available for self-hosting

Roadmap:

• Phase 4: Public relayer directory and reputation system
• Phase 5: Economic incentives and slashing mechanism
• Phase 6: Decentralized relayer discovery (DHT-based)

Using a Relayer for Private Transfer

from veil import VeilClient, RelayerClient
 
# Initialize clients
veil_client = VeilClient()
relayer_client = RelayerClient()
 
# Add relayers to pool
relayer_client.add_relayer("https://relayer1.veil.network", priority=1)
relayer_client.add_relayer("https://relayer2.veil.network", priority=2)
relayer_client.add_default_relayers()  # Adds known public relayers
 
# Generate private transfer proof (locally)
proof = veil_client.generate_transfer_proof(
    input_note=my_note,
    recipient_pubkey=recipient,
    amount=1_000_000_000  # 1 SOL
)
 
# Estimate fee
fee_estimate = relayer_client.estimate_fee(proof)
print(f"Relayer fee: {fee_estimate.fee / 1e9} SOL")
print(f"Fee rate: {fee_estimate.rate * 100}%")
 
# Submit via relayer (IP privacy preserved)
result = relayer_client.submit_private_transfer(
    proof=proof,
    max_fee=fee_estimate.fee,
    strategy="balanced"  # or "lowest_fee", "fastest", "random"
)
 
print(f"Transaction: {result.transaction_signature}")
print(f"Relayer used: {result.relayer_url}")
print(f"Fee paid: {result.fee_paid / 1e9} SOL")

Direct Submission (No Relayer)

# If privacy from IP exposure is not a concern,
# you can submit directly (no relayer fee)
 
tx_signature = veil_client.private_transfer_async(
    input_note=my_note,
    recipient_pubkey=recipient,
    amount=1_000_000_000
)
 
# Your IP is visible to RPC provider, but no relayer fee

Best Practice: Combine relayers + Tor/VPN for maximum privacy.

1. Payment Channels: Open channels with relayers for frequent, low-fee transactions
2. Reputation Staking: Relayers stake tokens, slashed for misbehavior
3. Anonymous Payments: Pay relayer fees using privacy-preserving mechanisms
4. Distributed Relayer Network: DHT-based discovery without central directory
5. MEV Protection: Relayers provide front-running protection as a service

See also:

• Privacy Model - Overall privacy guarantees and limitations
• Note Encryption - How recipients discover their notes
• RelayerClient API - Technical API documentation