Security policy.

What we guarantee

These are architectural invariants, enforced in code, not in policy.

• The server never sees plaintext. Every message is encrypted client-side using X25519 + AES-256-GCM before reaching the server. The server stores opaque ciphertext bytes; it has no decryption key and cannot acquire one. A subpoena yields ciphertext.
• The server never holds user funds. Payments flow directly from the payer's wallet to a hardcoded XETE treasury via a custody-free Solana program. The server reads on-chain receipts to authorize delivery. The contract has no admin keys, no upgrade path, no way to redirect funds.
• Receipts are read from the chain, not from clients. When a payment is confirmed, the server queries Solana RPC directly and decodes the on-chain payment account. Only the chain is trusted.
• Identity is wallet-native. Authentication is by Solana keypair signature only. No passwords, no recoverable credentials, no API keys. The server has no honeypot of user secrets.
• The server does not inspect message content. The role is "store opaque ciphertext blob, emit it to recipient when paid for." No content-aware logic exists in between.
• The on-chain contract is auditable in isolation. The Solana payment program is published as source. Every conditional in the source is a security check.
• The web interface uses the same model as the desktop client. Browser-side JavaScript does the encryption with the user's wallet keys. The server's view is identical: opaque ciphertext.

What we do NOT guarantee

Honesty matters more than marketing. These are real constraints:

• Compelled web JavaScript compromise. A government order forcing modified JavaScript to a specific user's browser session could exfiltrate that user's keys. For maximum security, use the Concierge desktop client — it loads no JavaScript from xete servers.
• Traffic-pattern analysis. An adversary monitoring network traffic could observe send/receive patterns, sizes, and timing. We employ synthetic noise traffic to obscure these patterns, but a sufficiently resourced adversary may still derive metadata.
• Compromise of the user's machine. If the device running Concierge or the browser is compromised, private keys can be extracted. xete cannot defend against an attacker who already has root on user hardware.
• Quantum-resistant cryptography. xete uses Ed25519 and X25519. Both are vulnerable to a sufficiently large quantum computer. Migration to post-quantum primitives is on the long-term roadmap.
• Solana network availability. Payments require a functioning Solana RPC endpoint. If the network is congested or partitioned, payments may fail or take longer than the 10-minute invoice expiry. Funds are not at risk — message delivery may be delayed.

Threat model

Cryptographic primitives

All primitives are well-established and broadly audited. We do not invent cryptographic algorithms.