Listen. If you're building something that needs private payments — a mixer, a swap, a marketplace, a darknet gateway, a dead-drop wallet, anything that can't phone home to Coinbase — you've been stuck with two bad options:

1. Monero. Brilliant privacy. Ed25519 keys that die the instant Shor's algorithm hits a production QPU. Explorer still leaks exact timestamps, exact fees, exact block heights. Chainalysis built an empire on those breadcrumbs.
2. Roll your own. You know how that ends.

There's a third option now. This API gives you:

• Shadow transactions — from, to, amount, block height are null. Not masked. Not ring-signed. Gone.
• Amount-only proof keys — The SYNX Node generates a quantum-sealed proof key using Kyber-768 lattice encryption when a private transaction is sent. This proof key — unforgeable, quantum-resistant — is the only way to decode the exact amount. No sender address. No receiver address. Not in the proof, not in the API, not anywhere. The amount is the only thing that surfaces. Everything else stays drowned.
• Zero address disclosure — there is no view key endpoint, no disclose endpoint, no audit endpoint that reveals addresses. Sender and receiver identities are permanently sealed. Not even the wallet owner can unseal them through the API. The only thing provable is the amount.
• Post-quantum everything — Kyber-768 lattice KEM, SPHINCS+-SHAKE256-128f signatures, SHAKE256 XOF, Argon2id wallet encryption. When Shor wakes up, this chain doesn't flinch.

No migration roadmap. No "we'll add PQ later." Born this way. Genesis block zero.

🌊 Why We Never Disclose Sender or Receiver

This is the core principle. Open-source transparency and user privacy are natural enemies — unless you architect the boundary correctly. SynergyX solves this by making the protocol transparent (anyone can audit the code) while keeping identity permanently opaque (no mechanism exists to reveal sender or receiver). The proof key is a puzzle key — it unlocks the amount, and only the amount. The identities behind the transaction dissolved into the Synergy Sea the moment the block was sealed.

The SYNX Node generates the proof key using quantum Kyber-768 lattice encryption. The key is mathematically bound to the transaction amount. It cannot be forged, cannot be reverse-engineered, and expires in 30 minutes. The sender shares the proof key with the recipient off-chain — Signal, PGP, Tor, a napkin. The recipient verifies via this API. That's the entire trust model. No custody. No intermediary. No metadata trail.

⛨ What The Server Knows (Jack)

Let's be honest about trust boundaries. You're hitting an API. The server is a machine, and machines can be seized. Here's exactly what an attacker gets if they root the box:

Timing is mitigated. Every single API response — GET, POST, success, failure, 404, everything — is padded to a 500ms constant ceiling. The server measures actual processing time, then sleeps exactly 500ms - elapsed. Every response takes exactly 500ms. Not random. Constant. Cohen's d between valid and invalid paths: 0.015 (tested by GhostReaper — statistically invisible). Chainalysis's timing oracle playbook? Dead on arrival.

🌊 The Synergy Sea — Two Depth Layers

Think of the chain as an ocean. Public transactions float on the surface. Private ones sink. The deeper you go, the more you need proof keys to see anything. And even at maximum depth, only the amount surfaces — never addresses.

No deeper layer exists. There is no view key disclosure, no address audit, no mechanism to reveal who sent or received. The proof key — generated by the SYNX Node using quantum Kyber-768 encryption — decodes the exact amount. That's the deepest anyone can go. Sender and receiver addresses are permanently drowned in the Sea.

Anti-correlation armor: Timestamps fuzzed ±120s. Fees bucketed into 5 tiers (micro/low/standard/high/premium — never the raw sat amount). Block heights nulled. Response times padded to 500ms constant ceiling. "TX not found" and "TX is private" return the identical shape. Proof keys expire in 30 minutes — limiting replay windows to near zero. You can't even enumerate which hashes are real. Every surface query returns the same amount of information whether the TX exists, doesn't exist, or is shielded. Good luck, Chainalysis.

—͟͟͞͞★ Vendor Proof Verification — 3 Minutes, Zero Trust

You're a vendor. A buyer just paid you in private SYNX. You need to verify the payment without seeing their address, their balance, or trusting any third party. Here's how. No KYC. No custody. Prove payments blind.

# What the buyer sends you (encrypted channel only)
tx_hash:    "a1b2c3d4e5f6789012345678901234567890123456789012345678901234abcd"
proof_key:  "PT-f7e8d9c0b1a23456789012345678901234567890123456789012345678901234"

# cURL — verify the proof key (recommended endpoint)
curl -X POST https://explorer.synxcrypto.com/explorer/api/verify_proof.php \
  -H "Content-Type: application/json" \
  -d '{"tx_hash":"a1b2c3d4e5f6...64hex","proof_key":"f7e8d9c0...64hex"}'

# Through Tor (you should be doing this)
torsocks curl -X POST http://synxexplorer.onion/explorer/api/verify_proof.php \
  -H "Content-Type: application/json" \
  -d '{"tx_hash":"a1b2c3d4...","proof_key":"f7e8d9c0..."}'

# GET also works — quick terminal checks
curl "https://explorer.synxcrypto.com/explorer/api/verify_proof.php?tx_hash=a1b2c3d4...&proof_key=f7e8d9c0..."

{
  "valid": true,              // ← that's your money, ghost
  "tx_hash": "a1b2c3d4...",  // ← echoed back for confirmation
  "amount": "183.00",        // ← exact amount decoded from quantum lattice seal
  "currency": "SYNX",
  "confirmed_at": 1735689600,  // ← UNIX epoch when TX was inscribed on-chain
  "message": "Payment proof verified — this proof key is valid for the specified transaction"
}

𖣐 Full Verification Rite

Step ④ is the critical link. The proof key must travel sender→receiver through a channel the API never sees. Signal disappearing messages. PGP-encrypted email. Tor hidden service. A QR code shown across a table. A note taped under a park bench. The API doesn't care how the secret gets there — it only verifies the math when the receiver asks.

POST /verify_proof — Verify a Proof Key (Recommended)

POST GET PUBLIC — The simplest way to verify a payment. Send tx_hash + proof_key in the body (or as GET params). Returns the exact amount. No auth. No API key. No account. Start here.

// POST Request (JSON body) — recommended
{
  "tx_hash": "a1b2c3d4e5f6...64hex",
  "proof_key": "f7e8d9c0b1a2...64hex"
}
// "proof_token" also accepted as an alias for "proof_key"
// PT- prefix accepted: "PT-f7e8d9c0..." → server strips it automatically
// Also accepts form-encoded POST data or GET query parameters

// ✓ Response — seal broken, exact amount decoded
{
  "valid": true,
  "tx_hash": "a1b2c3d4...",
  "amount": "183.00",
  "currency": "SYNX",
  "confirmed_at": 1735689600,
  "message": "Payment proof verified — this proof key is valid for the specified transaction"
}

// ✗ Response — wrong proof key
{
  "valid": false,
  "tx_hash": "a1b2c3d4...",
  "error": "Proof key does not match this transaction",
  "hint": "The proof_key provided does not match this transaction. Ensure you received the correct proof key from the payment sender."
}

// ✗ Response — missing or malformed inputs
{
  "valid": false,
  "error": "Missing required parameters: tx_hash and proof_key",
  "hint": "Send tx_hash (64 hex chars) and proof_key (64 hex chars) as GET params, POST form data, or JSON body.",
  "example": {
    "GET": "/explorer/api/verify_proof.php?tx_hash=abc123...&proof_key=def456...",
    "POST": "{\"tx_hash\": \"abc123...\", \"proof_key\": \"def456...\"}"
  }
}

Complete Error Reference — verify_proof.php

POST /privacy/tx/{hash}/rune-verify — Runic Envelope (Rich Metadata)

POST PUBLIC — Same proof key verification with richer metadata: timestamp window (±120s fuzzy), expiry countdown, decryption method. Use this when you need more than just the amount.

Alias: /explorer/api/privacy/tx/{hash}/proof

// Request — proof_token in body, tx_hash in URL path
{ "proof_token": "f7e8d9c0b1a2...64hex" }

// Response — seal broken, rich metadata
{
  "valid": true,
  "confirmed": true,
  "timestamp_range": { "earliest": 1735689480, "latest": 1735689720 },
  "amount_decoded": "183.00",
  "rune_lattice": "encrypted",
  "decrypted_by": "runic_proof_token",
  "expires_in_minutes": 24,
  "proof_algorithm": "Kyber-768 quantum lattice seal — addresses never disclosed"
}

// Response — invalid
{ "valid": false, "reason": "Proof token does not match any registered runic proof" }

// Response — expired
{ "valid": false, "reason": "Runic proof has expired" }

What the verifier learns vs. what stays drowned

GET /privacy/tx/{hash}/verify — Existence Oracle

GET PUBLIC — Does this TX exist? Returns a cryptographic existence commitment. Reveals nothing else.

{
  "exists": true,
  "hash": "a1b2c3d4...",
  "confirmed": true,
  "confirmations": 142,
  "block_height": null,   // sealed — private TXs don't surface block info
  "is_private": true,
  "verified_at": 1735689600,
  "existence_proof": "9d4997cb84efc492...",
  "proof_algorithm": "HMAC-SHA256(tx_hash || block_height || date, server_key)"
}

GET /privacy/tx/{hash} — Shadow Transaction Lookup

GET PUBLIC — Look up any TX. Private ones return the shadow — hash visible, everything else null.

// Response — TX found (private shadow)
{
  "status": "found",
  "hash": "a1b2c3d4...",
  "message": "Transaction located",
  "transaction": {
    "hash": "a1b2c3d4...",
    "block_height": null,       // hidden
    "timestamp": 1735689600,   // fuzzy ±120s
    "from": null,               // drowned
    "to": null,                 // drowned
    "amount": null,             // drowned
    "fee_tier": "redacted",     // private TXs: fee tier sealed
    "is_private": true,
    "privacy_tier": "shadow",
    "status": "confirmed",
    "confirmations": 142,
    "existence_commitment": "7833cd43..."
  }
}

// Response — TX not found or shielded (identical shape prevents enumeration)
{
  "status": "not_found_or_private",
  "hash": "a1b2c3d4...",
  "message": "Transaction not found or may be shielded",
  "transaction": null
}

GET /privacy/recent — Surface Ripples

Recent TXs. Private ones surface as shadows (null fields). Public ones show transparent data. Good for dashboards. Query param limit (1-50, default 20).

GET /privacy/stats — Sea Depth Readings

Privacy adoption metrics: total TXs, private TXs, adoption %, feature flags. No auth required. Monitor the Sea's depth from your own infrastructure.

POST /privacy/batch-proof — Batch Verify Multiple Proofs

POST PUBLIC — Verify up to 50 proof keys in a single request. Same daemon verification as the single-proof endpoints, but batched for efficiency. Ideal for marketplaces processing multiple orders or wallets verifying several incoming payments at once.

// Request — array of proof pairs (max 50)
{
  "proofs": [
    { "tx_hash": "a1b2c3d4...64hex", "proof_token": "f7e8d9c0...64hex" },
    { "tx_hash": "b2c3d4e5...64hex", "proof_token": "PT-e8d9c0b1...67chars" }
  ]
}

// Response — per-proof results with summary
{
  "batch_size": 2,
  "results": [
    {
      "index": 0,
      "valid": true,
      "tx_hash": "a1b2c3d4...",
      "confirmed": true,
      "amount_decoded": "183.00",
      "rune_lattice": "encrypted"
    },
    {
      "index": 1,
      "valid": false,
      "tx_hash": "b2c3d4e5...",
      "reason": "Proof token mismatch"
    }
  ],
  "valid_count": 1,
  "invalid_count": 1
}

Batch Limits & Error Reference

🧅 Tor / .onion — Route Everything Through the Fog

The API is stateless REST over HTTPS. No cookies. No sessions. No JS fingerprinting. No WebSocket upgrades. Pure request→response over TLS. It works over Tor natively because we built it that way. Not as an afterthought. If you're building anything private and you're not routing through .onion, you're leaking your IP to every DNS resolver between you and the server. Don't.

cURL through Tor

# Install torsocks (Debian/Ubuntu)
sudo apt install torsocks

# Verify a payment — sovereign style
torsocks curl -X POST http://synxexplorer.onion/explorer/api/verify_proof.php \
  -H "Content-Type: application/json" \
  -d '{"tx_hash":"a1b2c3d4...","proof_key":"f7e8d9c0..."}'

Python through Tor (SOCKS5)

import requests

# pip install requests[socks] PySocks
session = requests.Session()
session.proxies = {
    'http':  'socks5h://127.0.0.1:9050',
    'https': 'socks5h://127.0.0.1:9050',
}

# socks5h = DNS resolution through Tor too (no DNS leak)
API = "http://synxexplorer.onion/explorer/api"

result = session.post(f"{API}/verify_proof.php",
                      json={"tx_hash": "a1b2c3d4...", "proof_key": "f7e8d9c0..."},
                      timeout=30).json()

if result.get("valid"):
    print(f"ᛣ Sealed — amount: {result['amount']} {result['currency']}")

Node.js through Tor

const { SocksProxyAgent } = require('socks-proxy-agent');
const fetch = require('node-fetch');

const agent = new SocksProxyAgent('socks5h://127.0.0.1:9050');
const API = 'http://synxexplorer.onion/explorer/api';

const r = await fetch(`${API}/verify_proof.php`, {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({tx_hash: 'a1b2c3d4...', proof_key: 'f7e8d9c0...'}),
  agent,
});
const data = await r.json();
if (data.valid) console.log('𖣐 Sovereign verified', data.amount, data.currency);

📡 Share Proof Keys via Signal — Zero Metadata

The proof key must travel sender → receiver without touching the API. Here's the OPSEC hierarchy for that handoff:

Signal Integration Hook (Python bot)

# signal-cli or signal-bot framework — send proof key after payment
import subprocess, json

def send_proof_via_signal(recipient_phone, tx_hash, proof_key):
    """Send proof key through Signal. Disappearing message. Verify within 30 min."""
    msg = json.dumps({
        "tx_hash": tx_hash,
        "proof_key": proof_key,
        "verify_at": f"POST /verify_proof.php with tx_hash + proof_key",
        "expires": "30 minutes from generation — verify NOW",
    })
    subprocess.run([
        "signal-cli", "-u", "+1YOUR_NUMBER",
        "send", "-m", msg, recipient_phone,
        "--expire", "300",  # 5-min disappearing message
    ])

# After private SYNX send:
send_proof_via_signal("+1BUYER_PHONE", "a1b2c3d4...", "PT-f7e8d9c0...")

⚓ Marketplace Payment Rite

You're building a sovereign marketplace. No Stripe. No PayPal. No KYC middleware. Just the Synergy Sea and quantum-sealed proof keys. Here's how you verify payments with exact amounts using only a proof key — no addresses ever revealed.

# Flask marketplace backend: amount-only verification via proof key
import requests

API = "https://explorer.synxcrypto.com/explorer/api"

@app.route('/verify-payment', methods=['POST'])
def verify():
    tx_hash   = request.json['tx_hash']
    proof_key = request.json['proof_key']  # raw 64-hex or PT- prefixed (API accepts both)
    order     = Order.query.filter_by(tx_hash=tx_hash).first()
    if not order:
        return {'status': 'unknown_order'}, 404

    # Step 1: confirm TX exists on-chain
    existence = requests.get(f"{API}/privacy/tx/{tx_hash}/verify", timeout=20).json()
    if not existence.get('exists') or not existence.get('confirmed'):
        return {'status': 'not_confirmed'}, 402

    # Step 2: decode exact amount using proof key (30-min window)
    # Uses verify_proof.php — returns "amount" (not "amount_decoded")
    result = requests.post(f"{API}/verify_proof.php",
                           json={"tx_hash": tx_hash, "proof_key": proof_key}, timeout=20).json()

    if result.get('valid'):
        paid = float(result['amount'])  # ← "amount" not "amount_decoded"
        if paid >= order.total:
            order.status = 'paid'
            db.session.commit()
            return {'status': 'sovereign_paid', 'exact_amount': paid}
        return {'status': 'underpaid', 'sent': paid, 'required': order.total}, 402

    # Error responses include "error" + "hint" — check both
    error = result.get('error', '')
    if 'expired' in error.lower():
        return {'status': 'proof_expired', 'message': 'Proof key expired — ask buyer for a fresh key'}, 410

    return {'status': 'invalid_proof', 'hint': result.get('hint', '')}, 402

✗∑🗡 Code Grimoire — Every Language, Every Pattern

Python — Verify a Proof Key

import requests

API  = "https://explorer.synxcrypto.com/explorer/api"
SOCKS = {'http': 'socks5h://127.0.0.1:9050', 'https': 'socks5h://127.0.0.1:9050'}

def verify(tx_hash, proof_key, tor=False):
    """Verify a SYNX proof key — decodes exact amount, reveals nothing else.
    
    The SYNX Node generates proof keys using quantum Kyber-768 lattice encryption.
    Keys expire in 30 minutes. Verify immediately upon receipt.
    Uses verify_proof.php — the recommended endpoint.
    """
    s = requests.Session()
    if tor: s.proxies = SOCKS
    return s.post(f"{API}/verify_proof.php",
                  json={"tx_hash": tx_hash, "proof_key": proof_key},
                  timeout=20).json()

def check_exists(tx_hash, tor=False):
    """Check if a TX exists on-chain. Reveals nothing about amounts or addresses."""
    s = requests.Session()
    if tor: s.proxies = SOCKS
    return s.get(f"{API}/privacy/tx/{tx_hash}/verify", timeout=20).json()

# Usage — the whole rite (amount-only verification)
# Buyer sends you: tx_hash + proof_key (off-chain, via Signal/PGP/Tor)
result = verify("a1b2c3d4...", "f7e8d9c0...", tor=True)  # raw or PT- prefixed
if result.get("valid"):
    print(f"𖣐 Payment confirmed — exact amount: {result['amount']} {result['currency']}")
    # No addresses revealed — ever. Only the amount surfaces.
elif result.get('error'):
    print(f"⚠ {result['error']}")
    if result.get('hint'): print(f"  Hint: {result['hint']}")

# The SYNX Node generates the proof key. You just verify it.
# Proof key = quantum puzzle key. Amount = the only answer.
# Sender? Drowned. Receiver? Drowned. That's the deal.

Node.js — Payment Verifier (Express Middleware)

const fetch = require('node-fetch');
const API = 'https://explorer.synxcrypto.com/explorer/api';

async function verifyPayment(txHash, proofKey) {
  // Proof key generated by SYNX Node — quantum Kyber-768 sealed
  // Expires in 30 minutes — verify immediately
  const r = await fetch(`${API}/verify_proof.php`, {
    method: 'POST',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({ tx_hash: txHash, proof_key: proofKey }),
  });
  return r.json();
}

// Express middleware — drop into any route
async function requirePayment(req, res, next) {
  const { tx_hash, proof_key } = req.body;
  const result = await verifyPayment(tx_hash, proof_key);
  if (!result.valid) {
    // Error responses include "error" + "hint" fields
    return res.status(result.error?.includes('expired') ? 410 : 402).json({
      error: result.error,
      hint: result.hint,
    });
  }
  req.paymentAmount = result.amount;  // ← "amount" (not "amount_decoded")
  req.paymentCurrency = result.currency;
  next();
}

cURL — Complete Cheat Sheet

BASE="https://explorer.synxcrypto.com/explorer/api"

# Sea depth readings
curl $BASE/privacy/stats

# Recent shadow transactions
curl "$BASE/privacy/recent?limit=10"

# Shadow lookup (private TX)
curl $BASE/privacy/tx/a1b2c3d4e5f6...

# Existence oracle
curl $BASE/privacy/tx/a1b2c3d4e5f6.../verify

# Verify a proof key — RECOMMENDED (simple endpoint)
# Returns: {"valid":true, "amount":"183.00", "currency":"SYNX", ...}
curl -X POST $BASE/verify_proof.php \
  -H "Content-Type: application/json" \
  -d '{"tx_hash":"a1b2c3d4...","proof_key":"f7e8d9c0..."}'

# GET also works (quick terminal check):
curl "$BASE/verify_proof.php?tx_hash=a1b2c3d4...&proof_key=f7e8d9c0..."

# PT- prefix also works in proof_key:
# "proof_key":"PT-f7e8d9c0..." or "proof_token":"f7e8d9c0..."

# Runic Envelope (richer metadata: timestamp range, expiry)
curl -X POST $BASE/privacy/tx/a1b2c3d4.../rune-verify \
  -H "Content-Type: application/json" \
  -d '{"proof_token":"f7e8d9c0..."}'

# All of the above, through Tor:
torsocks curl http://synxexplorer.onion/explorer/api/verify_proof.php \
  -d '{"tx_hash":"a1b2...","proof_key":"f7e8..."}'

⚔ SynergyX vs Monero — The Honest Comparison

Monero pioneered. Ring signatures, RingCT, stealth addresses — all brilliant. But they were built for a pre-quantum world where Ed25519 was unbreakable and exact timestamps on an explorer were "fine." That era's ending. Here's where the two chains stand when you put them side by side:

If you're still using Monero in 2026, you're already dead: you just haven't noticed.

Your ring signatures? Chainalysis clusters them like cattle. Exact timestamps? NSA timestamps your coffee. Ed25519? Shor's coming: your keys are dust. Client-side proof generation? Decompile the wallet and forge proofs all day. That's archaeology, not security.

SynergyX proof keys are generated by the SYNX Node using quantum Kyber-768 lattice encryption. The generation method is sealed inside the Node's core — no client, no decompiler, no attacker can access the internal quantum lattice parameters. Even a sophisticated adversary who fully decompiles the wallet gets nothing: the wallet receives the proof key from the Node. It doesn't generate it. The secret never leaves the Node.

Shadow transactions: sender, receiver, amount, block: null. Not obfuscated. Erased.

Quantum proof keys: Kyber-768 lattice-sealed puzzle keys: prove the exact amount without leaking who sent, who received, when (±120s fuzz), or where. The key decodes exact amounts — 183.00, not "medium". No addresses in the proof. No addresses in the API. No addresses anywhere. Expires in 30 minutes.

No address disclosure: There is no view key endpoint. No audit endpoint. No mechanism to reveal sender or receiver through this API. The amount is all that surfaces. Identity stays drowned — permanently.

Post-quantum: Kyber-768, SPHINCS+, SHAKE256 — Shor can kiss your genesis block. No roadmap. No "later will add quantum sigs." We were born immune.

You want privacy? Stop begging for scraps. With Synergy you get quantum stealth and speed in the sea of shadows. Take the blade.

Error Codes

verify_proof.php — HTTP Status Codes

Runic Envelope (/rune-verify) — HTTP Status Codes

429 Sea Throttle — Response Body

All 429 responses (both endpoints) include a Retry-After HTTP header (RFC 7231) and a structured JSON body with tier information:

// 429 Response — sea throttle or ban active
// Retry-After: 60  (HTTP header — seconds until retry)
{
  "error": "Sea throttled — incremental ban tiers protect the Sea",
  "throttle_tier": "standard",     // "standard" | "tier1" | "tier2" | "active_ban"
  "retry_after": 60,              // seconds until you can retry
  "message": "100 req/min exceeded — exponential backoff (60s). Cool down and come back.",
  "tiers": {
    "standard": "100 req/min — exponential backoff",
    "tier1":    "500 req/min — 5-minute ban",
    "tier2":    "1500 req/min — 1-hour ban"
  }
}

// Example: active ban (hit 500+ req/min earlier)
// Retry-After: 253
{
  "throttle_tier": "active_ban",
  "retry_after": 253,
  "message": "Active ban — 253s remaining. Keep pushing and the Sea pushes back harder."
}

Input formats (both endpoints): TX hash = exactly 64 hex chars [a-fA-F0-9]{64}. Proof key = max 67 chars (with PT- prefix) or exactly 64 hex (raw). The API accepts both formats — server strips PT- automatically. verify_proof.php accepts the field name proof_key or proof_token (alias). Anything outside these bounds gets a hard 400. No trimming. No mercy.

🕳 Zero Metadata Guarantees — What Devs Must Know

If you're integrating this API, here's the hard proof that no metadata leaks. Every claim below is GhostReaper-audited (100+ attack vectors, 0 unpatched findings).

Security Properties — Developer Checklist

What You MUST Do as an Integrator

𖣐 Code It. Test It. Own the Dark.

You now have everything. Six endpoints. Real code. Tor routing. Signal hooks. A threat model that's honest about what leaks and what doesn't. Quantum Kyber-768 proof keys generated by the SYNX Node — unforgeable puzzle keys that decode exact amounts and nothing else. No address disclosure — not with a view key, not with a proof key, not ever. Timestamp fuzzing that makes timing analysis statistically meaningless. And underneath all of it, lattice cryptography that survives every known quantum attack — not because we migrated, but because we started there.

The Synergy Sea is the post-quantum ocean where shadows never surface. No data center can be king when SynergyX dethrones them and thrones the user. Every private transaction sinks into Kyber-768 encapsulation, sealed by SPHINCS+ hypertrees, indexed by quantum lattice commitments. Amounts whisper through proof keys — gibberish to observers, exact decimals to key holders. The explorer sees ripples. The API returns null where it matters. The proof key is the only thread back to the amount — and the amount is all that surfaces. Sender and receiver? Drowned. Permanently. No endpoint, no key, no subpoena brings them back.

No KYC. No custody. No chain analysis. No address disclosure. No central point of failure. No migration roadmap because there's nothing to migrate from. First mover in the quantum endgame.

This isn't documentation. This is a weapon. Use it.

𝓢𝔁
Code it. Test it. Own the dark tides.

SynergyX Privacy API v2.0 — Quantum Proof Keys — The Synergy Sea
The post-quantum ocean where shadows never surface.