Verifiera privata SynX-betalningar
Med bevisnycklar för endast belopp.
Den här guiden dokumenterar samma privata transaktionsprovnyckelflöde som används av timeline.php för betalningar för tidslinjeåtkomst. Den är designad för utvecklare som behöver acceptera privata SynX-betalningar, verifiera det exakta beloppet och hålla adressdata borta från sin applikation.
- Vad du får från betalaren: en 64-tecken
tx_hashoch en provnyckel. Provnyckeln kan vara rå 64-hex eller ha prefix somPT-plus 64 hex. - Vad API bevisar: om den bevisnyckeln är giltig för den transaktionen och det exakta SynX-beloppet.
- Vad API inte avslöjar: avsändaradress, mottagaradress, plånbokssaldo eller en offentlig betalningsväg för privata transaktioner.
- Primär slutpunkt:
POST /explorer/api/verify_proof.phpmed JSON-kropp{"tx_hash":"...","proof_key":"..."}.
Rekommenderad integrationsväg: bygga en verifierare på serversidan som accepterar tx_hash och proof_key, samtal /explorer/api/verify_proof.php, checkar valid === true, jämför sedan den returnerade amount till ditt önskade orderbelopp. Detta är den väg som Timeline använder för privata betalningar.
Implementering av provnycklar som tidslinje
Tidslinjen accepterar synliga marknadsplatsbetalningar automatiskt. När en transaktion är privat eller dold, växlar den till verifiering med korrekturnyckel. Bevisnyckeln bekräftar betalningsbeloppet medan adressfälten förblir förseglade.
PHP-verifierare i tidslinjestil
function normalize_synx_proof_key(string $proofKey): string {
$proofKey = preg_replace('/\s+/', '', trim($proofKey));
return $proofKey ?? '';
}
function verify_private_synx_payment(string $txHash, string $proofKey, float $requiredAmount): array {
$txHash = strtolower(trim($txHash));
$proofKey = normalize_synx_proof_key($proofKey);
if (!preg_match('/^[a-f0-9]{64}$/', $txHash)) {
return ['ok' => false, 'reason' => 'tx_hash must be exactly 64 hex characters'];
}
if (!preg_match('/^(PT-)?[a-fA-F0-9]{64}$/', $proofKey)) {
return ['ok' => false, 'reason' => 'proof_key must be 64 hex characters, with optional PT- prefix'];
}
$response = file_get_contents('https://synxcrypto.com/explorer/api/verify_proof.php', false, stream_context_create([
'http' => [
'method' => 'POST',
'header' => "Content-Type: application/json\r\nAccept: application/json\r\n",
'content' => json_encode(['tx_hash' => $txHash, 'proof_key' => $proofKey]),
'timeout' => 15,
'ignore_errors' => true,
]
]));
$data = json_decode($response ?: '', true);
if (!is_array($data) || empty($data['valid'])) {
return ['ok' => false, 'reason' => $data['hint'] ?? $data['error'] ?? 'proof could not be verified'];
}
$paid = is_numeric($data['amount'] ?? null) ? (float)$data['amount'] : 0.0;
if (abs($paid - $requiredAmount) > 0.0001) {
return ['ok' => false, 'reason' => "amount mismatch: paid {$paid}, required {$requiredAmount}"];
}
return ['ok' => true, 'amount' => $paid, 'currency' => $data['currency'] ?? 'SYNX'];
}
Svarsfält att bero på
| Fält | Slutpunkt | Använda |
|---|---|---|
valid | verify_proof.php | Primär boolean. Bevilja ingenting om inte detta är true. |
amount | verify_proof.php | Exakt SynX-belopp för beviset. Jämför med ditt önskade belopp. |
currency | verify_proof.php | Förväntat värde är SYNX. |
error + hint | verify_proof.php | Visa ett enkelt nytt försök eller korrigeringsmeddelande för användaren. |
amount_decoded | /privacy/tx/{hash}/rune-verify | Samma koncept som amount, men returneras av den rikare metadataslutpunkten. |
Verifieringskompatibilitet i kö: Den enkla slutpunkten svarar vanligtvis synkront. Om en integration någonsin tar emot {"status":"pending","request_id":"...","retry_after":3}, omröstning /explorer/api/index.php?endpoint=verify_proof&request_id=... efter retry_after sekunder och analysera den slutliga JSON på samma sätt. Tidslinjen inkluderar denna kompatibilitetsväg.
Implementeringsnotering: För webbläsarapplikationer ringer du verifieraren från din backend om inte ditt ursprung redan är tillåtet av explorers CORS-policy. Verifiering på serversidan låter dig också redigera korrekturnycklar från klientloggar och jämföra belopp mot din orderdatabas på ett ställe.
🌊 Varför vi aldrig avslöjar avsändare eller mottagare
Detta är kärnprincipen. Öppen källkodstransparens och användarintegritet är naturliga fiender – såvida du inte utformar gränsen korrekt. SynergyX löser detta genom att göra protokoll transparent (vem som helst kan granska koden) samtidigt som den behålls identitet permanent ogenomskinlig (ingen mekanism finns för att avslöja sändare eller mottagare). Bevisnyckeln är en pusselnyckel — den låser upp beloppet, och endast beloppet. Identiteterna bakom transaktionen upplöstes i Synergy Sea i samma ögonblick som blocket förseglades.
SynX Node genererar bevisnyckeln med hjälp av kvant Kyber-768 gitterkryptering. Nyckeln är matematiskt bunden till transaktionsbeloppet. Det kan inte smidas, kan inte omvändas, och går ut om 30 minuter. Avsändaren delar provnyckeln med mottagaren utanför kedjan — Signal, PGP, Tor, en servett. Mottagaren verifierar via denna API. Det är hela tillitsmodellen. Ingen vårdnad. Ingen mellanhand. Inget metadataspår.
Endast belopp enligt permanent design. Bevisnyckeln avkodar det exakta betalningsbeloppet. Det finns ingen mekanism - ingen slutpunkt, ingen nyckel, ingen parameter, ingen flagga - som avslöjar avsändar- eller mottagaradresser. Detta är inte ett konfigurationsval. Det är en arkitektonisk omöjlighet. Adresserna lagras inte i någon form som vilken nyckel som helst kan låsa upp. De sjönk i havet.
⛨ Vad servern vet (Jack)
Låt oss vara ärliga om förtroendegränser. Du slår en API. Servern är en maskin och maskiner kan beslagtas. Här är exakt vad en angripare får om de rootar rutan:
Den ärliga varningen: Under demonsynkronisering ser skannern kortfattat råadresser innan de hashas och originalen slängs. Detta är samma förtroendemodell som Moneros fjärrnod — demonen skickar klartext till skannern. Vad vi garanterar: lagrad data och API-svar läcker aldrig råadresser eller belopp. Det finns ingen API-slutpunkt som returnerar adresser — inte med en vynyckel, inte med en korrekturnyckel, aldrig någonsin. Hashningen är omedelbar. Fönstret är mikrosekunder. En blinkning, inte en läcka.
Tidpunkten är mildrad. Varje enskilt API-svar — GET, POST, framgång, misslyckande, 404, allt — är vadderat till en 500ms konstant tak. Servern mäter den faktiska bearbetningstiden och sover sedan exakt 500ms - elapsed. Varje svar tar exakt 500ms. Inte slumpmässigt. Konstant. Cohens d mellan giltiga och ogiltiga sökvägar: 0.015 (testad av GhostReaper — statistiskt osynlig). Chainalysis's timing oracle playbook? Död vid ankomst.
🌊 Synergy Sea — Två djuplager
Tänk på kedjan som ett hav. Offentliga transaktioner flyter på ytan. Privata sjunker. Ju djupare du går, desto mer behöver du provnycklar för att se någonting. Och även på maximalt djup är det bara belopp ytor — adresserar aldrig.
| Djup | Vem ser | Vilka läckor | Skydda |
|---|---|---|---|
| YTA | Någon | Hash, existens, fuzzy time, avgiftsnivå, konf | Kryptografiska åtaganden |
| DJUP | Bevisnyckelhållare | Över + exakt belopp (avkodad från kvantgitterförsegling) + tidsfönster | Kyber-768 kvantgitterkryptering, AES-256-GCM |
Det finns inget djupare lager. Det finns ingen visningsnyckel, ingen adressgranskning, ingen mekanism för att avslöja vem som skickade eller tog emot. Bevisnyckeln – genererad av SynX-noden med hjälp av kvant-Kyber-768-kryptering – avkodar den exakta mängden. Det är det djupaste någon kan gå. Avsändar- och mottagaradresser drunknar permanent i havet.
Anti-korrelationsrustning: Tidsstämplar fuzzed ±120s. Avgifterna fördelade på 5 nivåer (mikro/låg/standard/hög/premium – aldrig det råa beloppet). Blockhöjder nollställda. Svarstider vadderade till 500ms konstant tak. "TX not found" och "TX is private" returnerar identisk form. Bevisnycklar löper ut om 30 minuter — begränsa uppspelningsfönster till nära noll. Du kan inte ens räkna upp vilka hash som är riktiga. Varje ytfråga returnerar samma mängd information oavsett om TX existerar, inte existerar eller är avskärmad. Lycka till, Chainalysis.
—͟͟͞͞★ Verifiering av leverantörsbevis — 3 minuter, noll förtroende
Du är en försäljare. En köpare har precis betalat dig i privat SynX. Du måste verifiera betalningen utan att se deras adress, deras saldo eller lita på någon tredje part. Så här gör du. Ingen KYC. Ingen vårdnad. Bevisa betalningar blinda.
Hur korrekturnycklar fungerar: När en köpare skickar privata SynX, SynX Nod genererar automatiskt en kvantförseglad provnyckel med hjälp av Kyber-768 gitterkryptering. Denna provnyckel är en pusselnyckel — det är det enda som kan avkoda transaktionsbeloppet. Nyckeln är matematiskt oförglömlig: utan Nodens interna kvantgitterparametrar kan ingen angripare - klassisk eller kvant - tillverka en. Noden returnerar provnyckeln till avsändarens plånbok. Avsändaren delar den med dig utanför kedjan. Du kopplar in den i API. Belopp verifierat. Inga adresser avslöjade. Någonsin.
Köparen skickar dig tx_hash + proof_key (utanför kedjan)
Efter den privata sändningen genererar SynX-noden korrekturnyckeln automatiskt. Köparens plånbok tar emot den och skickar den till dig via DM – tillsammans med transaktionshashen. Signal, PGP, Tor-chatt, skrivet på en servett - vad som helst. Noll metadatakanal. API ser aldrig denna handoff.
# What the buyer sends you (encrypted channel only)
tx_hash: "a1b2c3d4e5f6789012345678901234567890123456789012345678901234abcd"
proof_key: "PT-f7e8d9c0b1a23456789012345678901234567890123456789012345678901234"
30-minutersfönster: Bevisnycklar löper ut om 30 minuter från generation. Köparen bör dela provnyckeln omedelbart efter sändningen. Du bör verifiera omedelbart efter mottagandet. Det här snäva fönstret eliminerar långvariga reprisattacker – nyckeln är tillfällig till sin design. Om den löper ut kan avsändaren begära en ny från SynX-noden.
PT-prefix: Alla korrekturnycklar börjar med PT- — förhindrar inklistringsfel (du kommer aldrig av misstag att klistra in en TX-hash i ett korrekturfält eller vice versa). API accepterar båda PT-f7e8... och rå f7e8... — servern tar bort prefixet automatiskt. Båda formaten fungerar.
Inmatningstak — hårt påtvingat: tx_hash måste vara exakt 64 hexadecken [a-fA-F0-9]{64}. proof_token max 67 tecken (PT-prefix + 64 hex). Allt utanför dessa gränser → omedelbart 400 Bad Request. API avvisar överdimensionerade ingångar före all bearbetning - skicka inte en hash på 200 tecken i hopp om att den ska trimmas. Det gör det inte. Det tappas.
Träffa en slutpunkt - matematiken talar
# 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..."
Läs oraklet
{
"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"
}
"valid": true — Betalning bekräftad. Du vet exakt belopp (avkodad från kvantgittrets tätning) och currency. Du vet inte avsändaren, mottagaren eller blockeringen. Ingen gör det. Inte vi. Inte servern. Inte någon stämning. Det finns ingen API-slutpunkt för att avslöja adresser — inte med en vynyckel, inte med en korrekturnyckel, aldrig någonsin. Nyckeln låste upp beloppet och inget annat. Den sjönk i havet.
Fältnamn spelar roll: Den enkla slutpunkten återkommer "amount" (inte "amount_decoded"). Runic Envelope endpoint returns "amount_decoded". Kontrollera vilken slutpunkt du träffar och läs det högra fältet. Båda ändpunkterna återkommer "valid": true/false.
Det är allt. Tre steg. Ett POST. Noll konton, noll API-nycklar, noll KYC. Bevisnyckeln är aut. Quantum Kyber-768-kryptering är domaren. Skicka varorna.
Elda och glömma: SynX-noden genererar automatiskt bevisnyckeln och skickar den till utforskaren direkt efter att transaktionen har skickats. Detta är en bakgrundsprocess - om pushen misslyckas (nätverkshicka, server nere) lyckas sändningen fortfarande. Bevisnyckeln genereras av Nodens interna kvantgitterparametrar. Registreringen görs bäst. Sändningsflödet blockerar aldrig API-tillgänglighet.
𖣐 Fullständig verifieringsrit
| AVSÄNDARE | SynX NOD + HAV | 🖣 MOTTAGARE |
|
① Privat skicka (plånbok) Kyber-768 inkapslad SPHINCS+ signerad | ||
|
② SynX Node genererar kvantförseglad provnyckel Kyber-768 gitterkryptering oförglömlig — löper ut 30 min | ||
|
③ Plånboken får provnyckel PT- prefix (nyckeln återlämnas en gång - lagra den) | ◄──────────────────── | |
|
④ Dela bevis nyckel utanför kedjan Signal / PGP / Tor medd ═══════════════════════════════════════════► | (noll metadatasökväg) | ══► |
|
⑤ Verifiera förseglingen POST /verify_proof.php ◄──────────────────── | ||
|
← {"valid":true,"amount":"183.00"} ────────────────────► | ||
| ✓ BETALAT. SKIPPA DET. |
Steg ④ är den kritiska länken. Bevisnyckeln måste färdas avsändare→mottagare genom en kanal som API aldrig ser. Signalera meddelanden som försvinner. PGP-krypterad e-post. Tor dold tjänst. En QR-kod visas över en tabell. En lapp tejpad under en parkbänk. API bryr sig inte om hur hemligheten kommer dit - den verifierar bara matematiken när mottagaren frågar.
Klockan tickar. Bevisnycklar löper ut om 30 minuter. Dela omedelbart. Verifiera omedelbart. Genom design - bevisnycklar är tillfälliga pusselnycklar, inte långlivade referenser. Detta täta fönster innebär att även om en nyckel fångas upp är angriparens fönster för att använda den mikroskopiskt. Efter 30 minuter är nyckeln kryptografiskt damm.
POST /verify_proof — Verifiera en korrekturnyckel (rekommenderas)
POSTA FÅ OFFENTLIG — Det enklaste sättet att verifiera en betalning. Skicka tx_hash + proof_key i kroppen (eller som GET params). Returnerar det exakta beloppet. Ingen autentisering. Ingen API-nyckel. Inget konto. Börja här.
// 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...\"}"
}
}
Detta är slutpunkten att börja med. Det är den enklaste och mest pålitliga vägen för att verifiera en betalning. Ett POST med två fält → exakt belopp. Runic Envelope endpoint nedan (/rune-verify) returnerar rikare metadata (tidsstämpelintervall, utgångsnedräkning) men kräver TX-hash i URL-sökvägen. Använda verify_proof.php om du inte specifikt behöver de extra fälten.
Komplett felreferens — verify_proof.php
| HTTP | error fält | Vad gick fel | Fixera |
|---|---|---|---|
| 400 | Missing required parameters: tx_hash and proof_key | Tom kropp eller saknade fält | Skicka båda tx_hash och proof_key i JSON, formulärdata eller frågeparametrar |
| 400 | Invalid tx_hash format | Inte 64 hexadecken | Måste vara exakt 64 hexadecimala tecken [a-fA-F0-9]{64} |
| 400 | Invalid proof_key format | Inte 64 hexadecken (efter strippning av PT-) | 64 hex, med eller utan PT- prefix |
| 400 | tx_hash exceeds maximum length (64 chars) | Inmatningen är för lång – hård lock påtvingad | Skicka inte överdimensionerade ingångar i hopp om att de ska trimmas. Det gör de inte. |
| 400 | proof_key exceeds maximum length (67 chars) | Inmatningen är för lång – hård lock påtvingad | Max 67 tecken: PT- + 64 hex |
| 429 | Rate limit exceeded — maximum 30 verification requests per minute | Havet strypt | Backa tillbaka. Cacheresultat på klientsidan – ett verifierat sigill ändras inte. |
| 503 | Verification service temporarily unavailable | Daemon synkroniserar eller startar om | Försök igen om några ögonblick. SynX-noden kan komma ikapp. |
| 200 | Proof key does not match this transaction | Fel nyckel för denna TX | Dubbelkolla att du har rätt proof_key från avsändaren |
Felsvar inkluderar alltid hint. De hint fältet ger utvecklarvänlig vägledning om vad som ska åtgärdas. Analysera valid först (alltid närvarande), kolla sedan error + hint på misslyckande. Om framgång, läs amount och currency.
POST /privacy/tx/{hash}/rune-verify — Runic Envelope (Rich Metadata)
POSTA OFFENTLIG — Samma bevisnyckelverifiering med rikare metadata: tidsstämpelfönster (±120s fuzzy), utgångsnedräkning, dekrypteringsmetod. Använd detta när du behöver mer än bara mängden.
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" }
Viktig skillnad från verify_proof.php: Denna slutpunkt återkommer amount_decoded (inte amount), reason vid misslyckande (inte error + hint), och inkluderar timestamp_range, expires_in_minutes, rune_lattice. TX-hash går i URL-sökvägen, inte JSON-kroppen. Välj den slutpunkt som passar dina behov – båda verifierar samma korrekturnyckel.
Vad verifieraren lär sig kontra vad som förblir drunknat
| Datapunkt | Avslöjat? | Varför |
|---|---|---|
| Betalning skedde | ✅ | valid: true |
| TX på kedjan | ✅ | confirmed: true |
| Tidsfönster | ✅ | ±120s luddigt — inte exakt |
| Exakt belopp | ✅ | Avkodad från kvantgitterförsegling via bevisnyckel — inte ett intervall, det verkliga talet |
| Avsändarens adress | ❌ | Dränkte i havet |
| Mottagarens adress | ❌ | Dränkte i havet |
| Blockhöjd | ❌ | null för alla privata TX |
Kvantgitteravkodning: Bevisnyckeln genereras av SynX-noden med Kyber-768-gitterkryptering — samma postkvantstandard (FIPS 203) som hela kedjan bygger på. Nyckeln är matematiskt bunden till transaktionens exakta belopp. Fel nyckel? Avkodningen misslyckas helt - ingen delinformation, inga sidokanalläckor. Gitterkodningen är vadderad till en fast längd - en transaktion på 0,01 SynX och en transaktion på 77 000 000 SynX producerar förseglade gitter av identisk storlek. Mängdens storlek är osynlig utan nyckel.
Bevis upphör att gälla efter 30 minuter. Efter utgången kommer servern tillbaka "reason": "Runic proof has expired". Detta snäva fönster ger mottagarna tillräckligt med tid att verifiera samtidigt som risken för omspelning på lång sikt elimineras. Om fönstret stängs kan avsändarens plånbok begära en ny korrekturnyckel från SynX-noden (upp till gränsen per TX).
GET /privacy/tx/{hash}/verify — Existens Oracle
FÅ OFFENTLIG — Finns denna TX? Returnerar ett kryptografiskt existensåtagande. Avslöjar inget annat.
{
"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
FÅ OFFENTLIG — Slå upp vilken TX som helst. Privata ger tillbaka skuggan - hash synlig, allt annat 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
}
Anti-uppräkningsavdelning: Fråga en hash som inte finns? Du får {"status":"not_found_or_private","transaction":null,"message":"Transaction not found or may be shielded"} — identisk svarsform till en privat TX (samma nycklar, samma struktur). Chainalysis, Elliptic, CipherTrace: de kan inte ens avgöra vilka hash som är riktiga. Det är inget fel. Det är arkitekturen.
GET /privacy/recent — Surface Ripples
Senaste TX. Privata dyker upp som skuggor (nollfält). Offentliga visar transparenta data. Bra för instrumentpaneler. Fråga param limit (1-50, standard 20).
GET /privacy/stats — Havsdjupsavläsningar
Mätvärden för antagande av sekretess: totala TX, privata TX, adoptionsprocent, funktionsflaggor. Ingen autentisering krävs. Övervaka havets djup från din egen infrastruktur.
POST /privacy/batch-proof — Batchverifiera flera bevis
POSTA OFFENTLIG — Verifiera upp till 50 provnycklar i en enda begäran. Samma demonverifiering som de enkelsäkra slutpunkterna, men batchad för effektivitet. Idealisk för marknadsplatser som behandlar flera beställningar eller plånböcker som verifierar flera inkommande betalningar samtidigt.
// 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
}
Batchgränser och felreferens
| Tvång | Begränsa | Fel vid överträdelse |
|---|---|---|
| Max provtryck per sats | 50 | 400 — "Maximum 50 proofs per batch, got N" |
| Max förfrågningstext | 256 KB | 400 — "Request body too large for batch endpoint" |
| Tom array | Min 1 | 400 — "Proofs array is empty" |
| Ogiltig tx_hash i objektet | 64 hex | Hoppade över — {"valid":false,"reason":"Invalid tx_hash"} i resultat |
| Ogiltig proof_token i objektet | 67 tecken max | Hoppade över — {"valid":false,"reason":"Invalid proof_token (max 67 chars, 64 hex)"} |
Batch användningar amount_decoded (som Runekuvertet), inte amount. Varje resultat har en index fält som matchar indatamatrispositionen. Misslyckade artiklar kraschar inte partiet – de kommer tillbaka valid: false med en reason medan andra bevis fortsätter att verifiera. Batch-slutpunkten delar integritets-API:s havsgasreglage (100 req/min baseline + inkrementella förbud).
DDoS-port: Om din hashade IP är nära sjögasgränsen (60 %+ av 100 req/min budget), nekar batchslutpunkten alla daemon RPC-anrop för att förhindra förstärkning – en batchbegäran på 50 prov skulle annars träffa demonen 50 gånger. Du får {"error": "Proof verification service temporarily unavailable"}. Backa och försök igen.
🧅 Tor / .onion — Led allt genom dimman
API är statslös REST över HTTPS. Inga kakor. Inga sessioner. Inget JS-fingeravtryck. Inga WebSocket-uppgraderingar. Ren begäran→svar över TLS. Det fungerar över Tor inbyggt eftersom vi byggde det på det sättet. Inte som en eftertanke. Om du bygger något privat och du gör det inte routing genom .onion, läcker du din IP till alla DNS-lösare mellan dig och servern. Gör det inte.
.onion status: Den hängivna synxexplorer.onion dold tjänst är kommer snart. Webbadresser nedan använder en platshållare. Tills .onion är live, dirigera clearnet-förfrågningar genom Tor via torsocks eller SOCKS5 proxy. Din IP förblir dold i båda fallen. Vi kommer att uppdatera detta dokument i samma ögonblick som den dolda tjänsten går live.
cURL genom 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 genom 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 genom 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);
Varför socks5h inte socks5? De h betyder att DNS-upplösning också sker genom Tor. Utan det ser din lokala DNS-resolver "synxexplorer.onion" - en metadataläcka. Alltid socks5h. Alltid.
📡 Dela bevisnycklar via signal — noll metadata
Bevisnyckeln måste färdas avsändare → mottagare utan att vidröra API. Här är OPSEC-hierarkin för den överlämnandet:
| Kanal | Metadata läckt | Dom |
|---|---|---|
| Signal (försvinner, förseglad avsändare) | Telefonnummer känd för Signal, meddelandeinnehåll E2EE | BRA för de flesta hot |
| PGP över Tor e-post (ProtonMail/Tutanota) | E-postmetadata (leverantören ser från/till/tid), brödtext E2EE | BRA |
| Tor dold tjänst direktmeddelande | Ingenting. Båda parter bakom .onion. | BÄST |
| Telegram (även "hemliga chattar") | Telefonnummer, molnmetadata, Telegram har din IP | MEH |
| Discord / Slack / E-post (klartext) | Allt. Loggad för alltid. Stämningsbar. | NO |
Tid spelar roll: Korrekturnycklar går ut om 30 minuter. Använd försvinnande meddelanden inställda på 5 minuter eller mindre. Köparen bör skicka provnyckeln omedelbart efter att plånboken bekräftat den privata sändningen. Säljaren bör verifiera omedelbart efter mottagandet. Efemära kanaler för efemära nycklar.
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...")
Kanalen är inte API:s problem. Det är skönheten. API verifierar bara provnycklar - den vet aldrig hur de reste. Du kan skriva ut nyckeln på ett kvitto och lämna över en disk. Matematiken fungerar fortfarande. Verifieringen är statslös. Nyckeln går ut om 30 minuter oavsett kanal.
⚓ Marketplace Payment Rite
Du bygger en suverän marknadsplats. Ingen Stripe. Ingen PayPal. Ingen KYC mellanprogram. Bara Synergy Sea och kvantförseglade proof-nycklar. Så här verifierar du betalningar med exakta belopp med endast en korrekturnyckel — inga adresser avslöjas någonsin.
Provnycklar avkodar exakta belopp – inget annat. SynX-noden genererar en kvantförseglad provnyckel med hjälp av Kyber-768-gitterkryptering som avkodar till exakt betalningsbelopp — inga adresser, inga blockhöjder, ingen avsändare/mottagare info. En 300 SynX beställning? Nyckeln avkodar till "300.00". En betalning på 100 SynX? "100.00". Ingen oklarhet om belopp. Total oklarhet om identitet. Nyckeln går ut om 30 minuter.
# 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
Endast belopp enligt design. Bevisnyckeln avkodar kvantgitterförseglingen till den exakta mängden - och så är det alla det gör det. Det finns ingen slutpunkt, ingen vynyckel, ingen mekanism i denna API för att avslöja avsändar- eller mottagaradresser. Marknaden ser "300,00 SynX betalades" — aldrig WHO betalt eller varifrån. Det är integritetsavtalet. Det är permanent.
✗∑🗡 Code Grimoire — Varje språk, varje mönster
Python — Verifiera en korrekturnyckel
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 – Betalningsverifierare (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 — Komplett fuskblad
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 — Den ärliga jämförelsen
Monero var pionjär. Ringsignaturer, RingCT, stealth-adresser – allt briljant. Men de byggdes för en pre-kvantvärld där Ed25519 var okrossbar och exakta tidsstämplar på en utforskare var "bra". Den eran är över. Här är de två kedjorna när du sätter dem sida vid sida:
| Förmåga | Monero (XMR) | SynergyX (SynX) |
|---|---|---|
| Betalningsbevis | check_tx_proof (läckage adresser) | POST /verify_proof.php (endast belopp) |
| Adressavslöjande i bevis | ❌ adresser synliga i bevis | ✅ INGA adresser - någonsin |
| Belopp dolda (utforskare) | ✅ RingCT | ✅ null i alla butiker + kvantsäkra nycklar |
| Belopp i bevis | ❌ exakt belopp + adresser exponerade | ✅ Exakt belopp avkodad, noll adresser |
| Bevis utgång | ❌ bevis lever för evigt | ✅ 30-minuters fönster — flyktigt till sin design |
| Bevisgenerering | Klientsidan (angripare kan reverse-engineera) | SynX Node (quantum Kyber-768 — oförglömlig) |
| Tidsstämpel integritet | ❌ exakt till den andra | ✅ ±120s flummigt |
| Avgift integritet | ❌ exakt sat/byte synlig | ✅ 5-vånings hinkar |
| Blockhöjd dold | ❌ synlig i utforskaren | ✅ null för privata TX |
| Anti-timing orakel | ❌ inget API-jitter | ✅ 500ms konstant tak |
| Oskiljbar 404:or | ❌ annan form | ✅ not_found == privat |
| Post-quantum signaturer | ❌ Ed25519 (Shor-dead) | ✅ SPHINCS+-SHAKE256-128f |
| Post-kvantnyckelutbyte | ❌ x25519 (Shor-dead) | ✅ Kyber-768 (FIPS 203) |
| Plånbok diskkryptering | ChaCha20 | ✅ Argon2id (2GB, 4 pass) |
| Tor-native API | ✅ RPC | ✅ Statslös VILA |
| Behövs kvantmigrering? | ❌ JA — total omskrivning | ✅ Född på det här sättet. Genesis block. |
Om du fortfarande använder Monero 2026 är du redan död: du har bara inte märkt det.
Dina ringsignaturer? Kedjeanalys samlar dem som boskap. Exakta tidsstämplar? NSA tidsstämplar ditt kaffe. Ed25519? Shor kommer: dina nycklar är damm. Bevisgenerering på klientsidan? Dekompilera plånboken och förfalska korrektur hela dagen. Det är arkeologi, inte säkerhet.
SynergyX proof-nycklar genereras av SynX Nod använder kvant Kyber-768 gitterkryptering. Genereringsmetoden är förseglad inuti nodens kärna — ingen klient, ingen dekompilator, ingen angripare kan komma åt de interna kvantgitterparametrarna. Även en sofistikerad motståndare som helt dekompilerar plånboken får ingenting: plånboken tar emot provnyckeln från noden. Det genererar det inte. Hemligheten lämnar aldrig noden.
Skuggtransaktioner: avsändare, mottagare, belopp, block: null. Inte obfuscerad. Raderad.
Kvantsäkra nycklar: Kyber-768 gitterförseglade pusselnycklar: bevisa den exakta mängden utan att läcka vem som skickade, vem tog emot, när (±120s fuzz) eller var. Nyckeln avkodar exakta belopp — 183,00, inte "medium". Inga adresser i beviset. Inga adresser i API. Inga adresser någonstans. Går ut om 30 minuter.
Ingen adressupplysning: Det finns ingen vynyckelslutpunkt. Ingen revisionsändpunkt. Ingen mekanism för att avslöja sändare eller mottagare genom denna API. Mängden är allt som dyker upp. Identitet förblir drunknade — permanent.
Postkvantum: Kyber-768, SPHINCS+, SHAKE256 — Shor kan kyssa ditt genesisblock. Ingen färdplan. Inga "senare kommer att lägga till kvant-sig." Vi föddes immuna.
Vill du ha integritet? Sluta tigga om skrot. Med Synergy får du quantum stealth och fart i havet av skuggor. Ta bladet.
Kvantelefanten: Monero:s Ed25519-nycklar är Shor-sårbara. Deras "migreringsplan" innebär att varje plånbok återhämtar nycklar under ett nytt system - medan kedjan är live, medan pengar är i riskzonen, medan tidslinjen är okänd. SynergyX har ingen migreringsplan eftersom det inte finns något att migrera från. Kyber-768 + SPHINCS+ från block noll. När Shor vaknar rycker den här kedjan inte. Äldre kedjor faller sönder. Det är skillnaden mellan "vi fixar det senare" och "vi fixade det först."
Felkoder
Två slutpunkter, två felformer. verify_proof.php returnerar "error" + "hint" fält. Runekuvertet (/rune-verify) returnerar "reason". Båda inkluderar alltid "valid": false. Analysera valid först, kontrollera sedan felfältet som matchar din slutpunkt.
verify_proof.php — HTTP-statuskoder
| Koda | Menande | Svaret inkluderar |
|---|---|---|
| 200 | Framgång — bevisnyckel verifierad, exakt belopp avkodad | valid, tx_hash, amount, currency, confirmed_at, message |
| 200 | Ogiltigt bevis – fel nyckel för denna TX (inte ett HTTP-fel) | valid: false, tx_hash, error, hint |
| 400 | Felaktig begäran — saknade fält, felformat hash, ogiltigt format, överdimensionerad inmatning | valid: false, error, hint, ibland example |
| 429 | Havet strypt - 30 req/min per IP. Backa och cache-resultat. | valid: false, error, hint |
| 503 | SynX-noden är inte tillgänglig — demonsynkronisering eller omstart. Försök igen om några ögonblick. | valid: false, error, hint |
Runiskt kuvert (/rune-verify) — HTTP-statuskoder
| Koda | Menande |
|---|---|
| 200 | Framgång — bevisnyckel verifierad, mängd avkodad med rik metadata |
| 200 | Ogiltigt bevis - "reason": "Proof token does not match any registered runic proof" |
| 200 | Utgått - "reason": "Runic proof has expired" |
| 404 | TX hittades inte or TX är privat (du kommer aldrig att veta vilket - av design) |
| 429 | Strypt till sjöss — stegvis förbudsnivåer (100→gas, 500→5 min förbud, 1500→1 timme förbud) |
| 500 | Intern störning — kontrollera serverloggar |
429 Sea Throttle — Response Body
Alla 429 svar (båda endpoints) inkluderar en Retry-After HTTP-huvud (RFC 7231) och en strukturerad JSON-kropp med nivå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."
}
Analysera retry_after eller den Retry-After rubrik — båda ger samma värde i sekunder. De throttle_tier fältet talar om vilken eskaleringsnivå du har nått. Om du ser "active_ban", du har redan eskalerats — den message talar om hur länge du drunknar. verify_proof.php har sin egen enklare 30 req/min rate limiter som returnerar ett vanligt felmeddelande utan nivåinformation.
Indataformat (båda slutpunkter): TX-hash = exakt 64 hexadecken [a-fA-F0-9]{64}. Bevisnyckel = max 67 tecken (med PT- prefix) eller exakt 64 hex (rå). API accepterar båda formaten - serverremsor PT- automatiskt. verify_proof.php accepterar fältnamnet proof_key or proof_token (alias). Allt utanför dessa gränser får en hård 400. Ingen trimning. Ingen nåd.
Prisgränserna skiljer sig åt beroende på slutpunkt. verify_proof.php upprätthåller 30 req/min per IP. Runic Envelope använder integritet APIs havsgasreglage: 100 req/min baslinje med inkrementell förbudsupptrappning (500→5min, 1500→1h). Cachesäkra resultat på klientsidan under 30-minutersfönstret – en verifierad försegling ändras inte när den är aktiv. En gång valid: true, beloppet är beloppet.
🕳 Noll metadata-garantier – vad utvecklare måste veta
Om du integrerar denna API, här är det hårda beviset på det inga metadataläckor. Alla påståenden nedan är GhostReaper-reviderade (100+ attackvektorer, 0 opatchade fynd).
Säkerhetsegenskaper — Utvecklarchecklista
| Egendom | Garanti | Hur |
|---|---|---|
| Provnycklar oförglömliga | ✅ | Genereras av SynX Node med hjälp av kvant Kyber-768 gitterkryptering. Interna parametrar lämnar aldrig nodprocessen. Kan inte förfalskas ens genom att dekompilera plånboken. |
| Bevisnycklar förgängliga | ✅ | Varje provnyckel upphör att gälla 30 minuter. Efter utgången är förseglingen permanent bruten. Inga "för alltid tokens" – minimerar risken för uppspelning och avlyssning. |
| Belopp aldrig på tråden | ✅ | Servern lagrar quantum-sealed lattice-kodning. Råbelopp har aldrig skickats, tagits emot eller lagrats i klartext. Endast korrekturnyckeln kan avkoda den. |
| Gitterstorlek = konstant | ✅ | Alla gallertätningar vadderade till en fast längd. En 0,01 SynX TX och en 777 000 000 SynX TX producerar tätningar av identisk storlek. Mängden är osynlig. |
| Timing oracle dött | ✅ | 500ms konstant tak för varje svar. Cohens d = 0,015 mellan giltiga/ogiltiga sökvägar (GhostReaper bekräftad). Statistiskt osynligt. |
| Provnyckel har aldrig lagrats rå | ✅ | Serverbutiker SHA256(proof_key) endast. Om DB läcker → hash + förseglat gallerljud. Beräkningsmässigt värdelös utan nyckel. |
| Avsändare/mottagare har aldrig skickats | ✅ | Det finns ingen slutpunkt som accepterar eller returnerar adresser. Inga vynycklar. Inga identitetsuppgifter. Enbart beloppsarkitektur. |
| Ingen svarsdifferentiering | ✅ | "TX not found" och "TX is private" returnerar identiska svarsformer. Ingen informationsläcka. |
| Sjögasreglaget håller under samtidighet | ✅ | Filbaserad sjögasbegränsare med LOCK_EX serialisering. 200 samtidiga förfrågningar → 0 gick igenom (GhostReaper). TOCTOU-fönstret är stängt. Inkrementella bannivåer (500 → 5 min, 1 500 → 1 timme) eskalerar även under aktiva bans - räknaren stannar aldrig. Utöver 60 % av budgeten nekas daemon RPC-anrop för att förhindra DDoS-förstärkning. IP-adresser lagrade som SHA-256-hashar. |
Vad du MÅSTE göra som integratör
1. Logga aldrig proof-nycklar. Bevisnyckeln är pusselnyckeln till beloppet. Om din applikation loggar den har du brutit mot sekretessmodellen. Behandla det som en privat nyckel.
2. PT-prefix accepterat — men validera dina inmatningar. API accepterar båda PT-f7e8... och rå f7e8... format — servern strippar det automatiskt. Men tx_hash måste vara exakt 64 hexadecken och proof_token max 67 tecken. Överdimensionerade ingångar får en hård 400.
3. Verifiera inom 30 minuter. Bevisnycklar upphör att gälla. Bygg ditt verifieringsflöde så att det är omedelbart – inte batchbearbetning nästa dag.
4. Dela endast korrekturnycklar över noll-metadatakanaler. Signal (försvinner), PGP över Tor, .onion DMs. Aldrig discord. Aldrig Slack. Maila aldrig utan PGP.
5. Cache-verifierade bevis på klientsidan. En gång "valid": true, lagra resultatet. Verifiera inte igen – du läcker timingmönster och nyckeln kan löpa ut mellan kontrollerna.
6. Installera nginx-härdning i produktionen. API levereras med nginx_privacy_hardening.conf — 5s timeouts, 20 anslutningar/IP, 100 req/min havsgasbegränsning, blockering av vägtraversering. Aktivt slow-loris-försvar.
𖣐 Koda det. Testa det. Äga mörkret.
Bara ett huvudnät idag. Ingen förköp. Ingen VC-dump. Ingen influencer allokering. Ingen stiftelsekassa där 6 personer kontrollerar 40% av utbudet. Inga "strategiskt partnerskap" pressmeddelanden. Bara en kedja, en gemenskap och matematik som inte böjer sig.
Nu har du allt. Sex slutpunkter. Riktig kod. Tor routing. Signalkrokar. En hotmodell som är ärlig om vad som läcker och inte. Quantum Kyber-768 proof-nycklar genererade av SynX Node — oförglömliga pusselnycklar som avkodar exakta mängder och inget annat. Ingen adressupplysning – inte med en vynyckel, inte med en korrekturnyckel, aldrig någonsin. Tidsstämpel fuzzing som gör timing analys statistiskt meningslös. Och under allt, gitterkryptografi som överlever alla kända kvantattacker - inte för att vi migrerade, utan för att vi började där.
Synergy Sea är postkvanthavet där skuggor aldrig kommer upp till ytan. Inget datacenter kan vara kung när SynergyX detroniserar dem och tronar användaren. Varje privat transaktion sjunker in i Kyber-768-inkapsling, förseglad av SPHINCS+-hyperträd, indexerad av kvantnätsåtaganden. Belopp viskar genom korrekturnycklar - snålhet till observatörer, exakta decimaler till nyckelinnehavare. Utforskaren ser krusningar. API returnerar null där det är viktigt. Korrekturnyckeln är den enda tråden tillbaka till beloppet - och beloppet är det alla som dyker upp. Avsändare och mottagare? Dränkte. Permanent. Ingen slutpunkt, ingen nyckel, ingen stämning tar dem tillbaka.
Ingen KYC. Ingen vårdnad. Ingen kedjeanalys. Ingen adressupplysning. Ingen central punkt för misslyckande. Ingen migreringsfärdplan eftersom det inte finns något att migrera från. First mover i quantum slutspelet.
Det här är inte dokumentation. Det här är ett vapen. Använd den.
𝓢𝔁
Koda den. Testa det. Äg det mörka tidvattnet.
SynergyX Privacy API v2.0 — Quantum Proof Keys — Synergy Sea
Postkvanthavet där skuggor aldrig kommer upp till ytan.