Overview
SecurePay enables users to request and send cryptocurrency (Solana and Zcash) through encrypted chat messages, without exposing transaction metadata to third parties. Every payment request, acceptance, and confirmation travels through Tor's anonymity network, encrypted end-to-end using keys derived from Solana Ed25519 keypairs.
Cross-Chain Support
Send and receive both SOL (Solana) and ZEC (Zcash)
End-to-End Encrypted
All payment messages encrypted with XChaCha20-Poly1305
Tor-Routed
All communication flows through Tor hidden services
No Central Server
True peer-to-peer architecture
Cryptographic Proof
NLx402 payment quotes provide verifiable payment requests
Replay Protection
Transaction signatures tracked to prevent double-claiming
Supported Currencies
Solana
Fast & Low-Fee
Zcash
Maximum Privacy
How It Works
The complete payment flow from request to confirmation
Create Payment Request
Alice creates a payment request for 0.5 ZEC. An NLx402 quote is generated with a unique hash that will identify this specific payment request.
Encrypted Transmission
The payment request is encrypted with XChaCha20-Poly1305 and sent through the Tor network using the Ping-Pong Wake Protocol to Bob's .onion address.
Review & Approve
Bob receives the encrypted request in his chat. He sees "Alice requests 0.5 ZEC" and can review the details before deciding to pay.
Send Payment
Bob clicks "Pay" and signs the blockchain transaction. The transaction includes a memo in the format "NLx402:<quote_hash>" that cryptographically links it to Alice's request.
Confirmation & Verification
Bob sends an encrypted payment confirmation message with the transaction signature. Alice verifies the transaction on the blockchain, checks the NLx402 memo matches her quote, and marks the payment as PAID.
Ping-Pong Wake Protocol
Messages are delivered instantly when both parties are online, with automatic retries for offline recipients
PING (Wake Signal)
Encrypted wake signal sent to recipient's .onion:8080 to check if they're online
PING_ACK
Acknowledges ping receipt, sender knows recipient is awake
PONG
Encrypted response with same Ping ID to prove authenticity
MESSAGE BLOB
Full encrypted payment request payload delivered to recipient
MESSAGE_ACK
Confirms message delivered, UI shows checkmark
Why Ping-Pong?
No Central Server
Messages don't sit on a server waiting for pickup. True peer-to-peer delivery.
Instant Delivery
When both parties are online, delivery is immediate with no delays.
Offline Support
Pings are automatically retried until the recipient comes online.
Privacy
No metadata about when/if messages were read leaks to third parties.
Cross-Chain Cryptography
One master keypair for all operations - messaging, payments, and Tor identity
Why Solana Keys for Everything?
SecureLegion uses Ed25519 keypairs (the same as Solana wallets) as the master identity for all cryptographic operations. This creates a unified security model:
Your Solana wallet address, encryption keys, and Tor hidden service address are all mathematically linked
Creates a provable identity across all operations - messaging, payments, and network routing
One seed phrase backs up everything - no separate keys to manage
Key Derivation
Ed25519 Signing Key
Used for digital signatures and identity verification
X25519 Encryption Key
Derived from Ed25519 for ECDH key exchange and message encryption
Tor .onion Address
Generated from Ed25519 public key (Tor v3 specification)
Message Encryption Flow
1. Prepare
Payment request JSON + message type byte
2. Key Exchange
X25519 ECDH creates shared secret
3. Encrypt
XChaCha20-Poly1305 with auth tag
4. Transmit
Send through Tor network
NLx402 Payment Protocol
Cryptographic payment quotes inspired by HTTP 402 (Payment Required)
Payment Quote Structure
{
"quote_id": "a1b2c3d4...",
"recipient": "zs1abc...xyz",
"amount": 50000000,
"token": "ZEC",
"description": "Payment request",
"created_at": 1701234567,
"expires_at": 1701320967,
"sender_handle": "alice",
"recipient_handle": "bob"
}Quote Hash & Memo
When paying a quote, the blockchain transaction includes a memo that cryptographically links the payment to the specific request:
NLx402:<sha256_hash_of_quote>This format enables verification, replay protection, and creates an audit trail for payments.
Verification
Recipient can verify payment matches their request
Replay Protection
Each quote hash can only be claimed once
Auditability
Clear proof of what payment was for
Payment Message Types
| Byte | Type | Description |
|---|---|---|
| 0x0A | PAYMENT_REQUEST | NLx402 payment quote |
| 0x0B | PAYMENT_SENT | Payment confirmation with TX signature |
| 0x0C | PAYMENT_ACCEPTED | Receiver accepts incoming payment |
Security Properties
Comprehensive protection across all layers of the payment system
| Property | Protection |
|---|---|
| Content Privacy | All messages encrypted end-to-end |
| Metadata Privacy | Communication routed through Tor |
| Identity Privacy | No central account system |
| Transaction Privacy | ZEC shielded transactions supported |
| Replay Attacks | Quote hashes tracked in local database |
| Man-in-the-Middle | Ed25519 signatures verify identity |
Technical Specifications
What Users Should Know
Device Security
Keys are stored in Android Keystore / encrypted database. Your device security is critical to protecting your funds.
Seed Phrase
Your BIP39 mnemonic is the master backup for all keys. Store it safely - anyone with your seed phrase can access your funds.
Tor Requirement
Active Tor connection required for all payments. Ensure Tor is running before sending or receiving payment requests.
Getting Started with SecurePay
Create Account
Add Contact
Send Request
Receive Payment
Verify