Întrebări și răspunsuri

Modul platformă este singurul mod disponibil: toate sumele sunt virtuale. Solicitarea de plată își rezervă suma în cont și nu intră online: cererea are ExecutionMode: 'sandbox'. În modul actual, depunerile și plățile nu se fac către blockchain - transferurile reale nu trebuie trimise. Lansarea operațiunilor reale nu este „în curând”, dar este închisă din cauza unor condiții: 41 de articole de pregătire în payments/config/gates.cjs, niciunul dintre ele nu a făcut: true, deci funcția canGoLive() returnează un eșec. În timp ce acesta este cazul, modul platformă este singurul mod disponibil.

Verifica: payments/config/gates.cjs:20-70,87 · payments/pyramid/engine.cjs:1389 · GET /api/public/stats → environment: sandbox

3 000 USDT virtuali o singură dată pe profil. Se acordă prin butonul „Obține balanța de start” din cabinet: înainte de apăsare balanța este goală. Nu este nevoie de depunere, iar acești USDT nu pot fi retrași.

Suma este Math.min(DEMO_GRANT_LIMIT, 300_000) — adică 300 000 de cenți; limita de acordare DEMO_GRANT_LIMIT = 1 000 000 de cenți (10 000 USDT). O cerere repetată returnează eroarea demo_grant_used.

Verifica: payments/pyramid/engine.cjs:1003-1020 · POST /api/me/demo-grant · cardul „Începerea lucrului” din cabinet

Unsprezece trepte T1–T11. Granițele sunt închise: granița superioară a treptei anterioare plus un cent este egală cu granița inferioară a următoarei — nu există goluri sau suprapuneri. Rata depinde de sumă și termen: pentru 30 de zile — de la 1,2 % pe zi (T1) până la 2,6 % (T11); pentru 90 de zile +0,2 p.p.; pentru 180 de zile +0,4 p.p., dar nu mai mult de 3,0 % pe zi. Cu cât termenul este mai lung, cu atât rata este mai mare. Termenul se alege la deschiderea depozitului: 30, 90 sau 180 de zile, intrare de la 10 la 250 000 USDT.

O încercare de a deschide o treaptă sub minim sau peste maxim este respinsă cu codurile below_tier_min / above_tier_max — „aproape ajunge” nu funcționează: 9,99 USDT la T1 nu vor fi acceptați.

Verifica: payments/pyramid/plans.cjs:300,447-453 · GET /api/plans (aceleași numere, în formă mașină) · fila „Depozite” din cabinet

Formula este una singură: acumularea pentru D zile = floor(corp × rata zilnică × D ÷ 10 000), iar venitul unei zile concrete este diferența a două astfel de valori: floor(P × bp × d ÷ 10 000) − floor(P × bp × (d−1) ÷ 10 000). Floor-ul cumulativ nu pierde niciun cent: suma creșterilor zilnice este egală cu acumularea pentru întreaga perioadă.

Exemplu (aritmetică a modelului, nu o promisiune): T3, 100 USDT — aceasta este 10 000 × 160 ÷ 10 000 = 160 cenți = 1,60 USDT pe zi; în 30 de zile — 48,00 USDT. La minimul de 10 USDT al treptei T1 o zi dă 12 cenți, în 30 de zile — 3,60 USDT.

Nu există capitalizare: dobânda acumulată nu se adaugă la corp și nu mărește ziua următoare. Zilele merg calendaristic, fără zile libere.

Verifica: payments/pyramid/plans.cjs:418-434,458-461 · dist/plan-math.js:50-55 · GET /api/plans → accrualMethod: tier_daily_cumulative_floor_cents

Nu. Sunt două contururi pe același capital și în fiecare zi funcționează exact unul; nu pot fi adunate. Conturul plat este acumularea după rata treptei și calendar — o condiție a planului. Conturul epocii este o cotă din pool din venitul declarat de operator pentru zi, după ponderea poziției. De aceea 48,00 USDT pentru 30 de zile la T3 100 USDT este fie suma plată, fie suma epocilor.

Verifica: payments/pyramid/vault.cjs:19-30 · payments/pyramid/plans.cjs:418-434 · docs/product-math.md:200-224 · eticheta sursei în cabinet: dist/account.html, funcția numbersSource()

Patru pași: poziție → părți de capital (shares) → pondere → cota pro-rata din pool → înscriere.

Pondere = floor(corp × multiplicatorul treptei ÷ 10 000). Multiplicatorii sunt dați pe trepte: T1–T2 — 150 bpm, T3–T4 — 192, T5–T6 — 233, T7–T8 — 275, T9–T10 — 296, T11 — 300. T3 la 100 USDT dă o pondere de 192 cenți = 1,92 USDT de „așteptare a ciclului”. O treaptă necunoscută nu dă pondere: poziția este respinsă cu codul vault_weight_class_unknown.

Cota din pool — două cazuri, și acesta este locul principal unde se greșește:

— pool ≥ suma ponderilor: poziția primește exact ponderea sa, iar tot ce depășește rămâne în capitalul vault și ridică prețul părții;

— pool mai mic decât suma ponderilor: poziția primește floor(pool × pondere ÷ suma ponderilor), iar restul pool-ului se reportează în ciclul următor ca deferred.

Un exemplu pe numerele paginii, nu un venit promis: la T3 100 USDT ponderea este 1,92 USDT; dacă pool-ul ciclului este mai mic decât suma ponderilor, poziția primește floor(pool × 1,92 ÷ suma ponderilor), iar restul merge în report.

Verifica: payments/pyramid/plans.cjs:288-300,331-367 · payments/pyramid/vault.cjs:252-258,585-610,733-853 · tabelul de exemple — /epochs, blocul „Cum se calculează cota dvs.”

Pentru că sursa plății este pool-ul, nu calendarul. Pool-ul ciclului se compune din venitul declarat de operator pentru acest ciclu și reportul deferral-urilor anterioare. Fără venit — pool-ul este zero, iar pozițiile nu primesc nimic în acest ciclu; rata zilnică a treptei este o mărime de calcul pentru compararea condițiilor, nu o obligație a ciclului.

O captură din ruta publică a standului (ciclul 6): pool 4 800,00 USDT, distribuit pozițiilor 7,50 USDT — aceasta este 0,15 % din pool, iar 4 792,50 USDT au mers în capitalul vault (reținere), adică au ridicat prețul părții, dar nu au fost plătite în numerar. Un astfel de ciclu este normal, nu o defecțiune: cu o pondere mare și un pool mic distribuția arată exact așa.

Venitul ciclului este fixat de operator printr-o acțiune separată; o abatere mai mare de 30 % de la mediana celor șapte cicluri anterioare cere o a doua confirmare — aceasta protejează de o greșeală accidentală în număr.

Verifica: GET /api/epochs/history?limit=30 (aceleași coloane) · dist/epochs-public.js:77 · tabelul ultimelor 30 de cicluri — /epochs

ACOPERIRE este 2,5% (250 bpm) din fiecare plată zilnică a unui circuit plat, pe care protocolul o transferă intern: din contul treasury_hot în contul treasury_cover. Pentru T3 100 USDT, acesta este podeaua (160 × 250 ÷ 10.000) = 4 cenți pe zi. Aici nu există contribuții externe, comisioane către client sau plăți „pentru un eveniment asigurat”. De ce nu asigurare: rezerva nu este un fond și nu dă dreptul la despăgubiri. Rămâne un cont de protocol intern și nu are niciun contract, destinatar sau eveniment de plată. Vitrina etichetează în mod explicit cifra de acoperire ca „nu acoperire de asigurare”. Acolo unde este vizibil la matematică: COVER nu participă deloc la distribuția epocală și nu reduce ponderea poziției. Într-un circuit plat, aceasta este o translație internă, deci sarcina pe model este calculată ca procent + cascadă + COPERTIN. Singurul lucru pe care îl schimbă pentru tine: dacă acoperirea trezoreriei (fonduri ÷ obligații) scade sub 150%, acțiunile în cascadă sunt înmulțite cu 0,75 - aceasta este o reducere automată a bonusurilor pentru cei care au invitat, și nu o deducere din pariul tău. Rezerva nu este o sursă de plată către client: COVER nu plătește contul.

Verifica: payments/pyramid/plans.cjs:223-225 · payments/pyramid/engine.cjs:156-158,282-288,542-546 · docs/product-math.md:105-112,249-253 · plăcuța „Acoperirea contabilă a obligațiilor” de pe pagina principală

În grila de 11 trepte nu există accelerare de echipă: toate treptele T1–T11 au în configurație teamBoost: false, de aceea chiar 100 de direcți activi nu adaugă niciun punct de bază. Dacă nu există accelerare — aceasta nu este o eroare a profilului dvs.: ea nu există pe platformă.

Câmpul a rămas doar în conturul legacy al depozitelor istorice: clasele ADVANCED, PREMIUM și VIP au un supliment de +1 bpm (+0,01 punct procentual pe zi) pentru fiecare 3 direcți activi, maximum +5 bpm. La noile trepte T1–T11 această regulă nu se aplică: GET /api/plans returnează teamBoost: false și teamBoostDailyBpsMax: 0 pentru fiecare dintre cele 11 trepte.

Verifica: payments/pyramid/plans.cjs:300,69-77 · GET /api/plans → teamBoost, teamBoostDailyBpsMax

Acumularea merge exact atâtea zile câte sunt indicate în termenul treptei; în ultima zi depozitul trece în statutul matured („ajuns la scadență”). După aceea nu se mai acumulează dobândă pentru el.

Comisionul de răscumpărare anticipată în acel moment este zero — în locul comisionului treptei (de la 2 % la T1 la 0 % la T11). Comisionul de rețea de 1 USDT la retragere se reține în orice caz, inclusiv la închiderea la termen.

Corpul nu se trimite automat: banii rămân în contul depozitului până la cererea dvs. de închidere (în cabinet — „Condițiile de răscumpărare” / „Închiderea depozitului”). Nu există nicio „reținere” a corpului peste termen — dar nici transfer automat: fără cerere suma pur și simplu stă.

Verifica: payments/pyramid/engine.cjs:1281,1320-1335,1347-1404 · fila „Plăți” din cabinet

Comisionul de răscumpărare = floor(corp × rata de răscumpărare ÷ 10 000), rata este dată de treaptă: T1–T2 — 2 %, T3–T4 — 1,5 %, T5–T6 — 1 %, T7–T8 — 0,5 %, T9–T10 — 0,25 %, T11 — 0 %. Se calculează din corp, nu din dobândă.

Exemplu: T3 la 100 USDT (10 000 cenți) se închide anticipat → comision 150 cenți = 1,50 USDT, de transferat 98,50 USDT, minus rețeaua 1 USDT → 97,50 USDT (în modul platformă — în contul intern al cererii).

Dobânda acumulată rămâne la dvs. integral: în cerere câmpul clawbackCents este zero, nu există arderea acumulărilor. Ordinea este simplă: mai întâi se plătește dobânda acumulată, corpul se închide printr-o cerere separată.

Verifica: payments/pyramid/plans.cjs:91-95,300-367 · payments/pyramid/engine.cjs:1320-1335,1347-1404 · butonul „Condițiile de răscumpărare” din lista depozitelor

Puteți: - cont disponibil - dobanda acumulata si bonusuri (in cod este o aplicatie de tipul: 'dobanda'); — organism de depozit — cerere de închidere (tip: „principal”): înainte de termen cu un comision de etapă, conform termenului fără comision. Nu poți: — începând cu 3.000 USDT virtual este soldul de pornire, nu se schimbă pe bani reali; - „retrageți corpul și lăsați dobânda” cu un singur buton - acestea sunt două cereri diferite; — primiți ceva pe blockchain în timp ce platforma este în modul platformă: transferul nu este efectuat fizic. Comisionul de rețea este de 1 USDT (100 de cenți) și este dedus din suma aplicației. Într-o singură depunere, poate exista o singură cerere activă pentru un corp la un moment dat: a doua primește depozit_locked - deci rezervarea dublă a unui corp este imposibilă.

Verifica: payments/pyramid/engine.cjs:1320-1404 · payments/pyramid/plans.cjs:227-233 · fila „Plăți” → „Disponibil”

Aplicația își rezervă imediat suma: banii merg din contul clientului în contul de așteptare (withdraw_reserve) chiar înainte de decizia operatorului. Dacă cererea este respinsă, rezerva este returnată. Există o singură rută pentru orice sumă: nu există o rută automată (autoRoute: false), aplicația trece la revizuire și este executată numai prin decizia operatorului. Timpul de procesare este de până la 24 de ore. Starea aplicației: revizuire → aprobată → difuzată → terminată (sau respinsă). Adresa destinatarului este înregistrată în momentul completării cererii - editarea ulterioară a profilului nu afectează aplicația deja creată.

Verifica: payments/pyramid/engine.cjs:1347-1404 · payments/pyramid/plans.cjs:227-233 · „Cererile mele” din cabinet

Doar prin transfer de USDT într-una din cele trei rețele, adresa o emite cabinetul:

— TRON (TRC-20) — minimum 10 USDT;

— BNB Smart Chain (BEP-20) — minimum 10 USDT (tokenul are 18 zecimale, nu 6 — un detaliu important pentru suma transferului);

— Ethereum (ERC-20) — minimum 20 USDT.

Cardul și banca nu sunt implementate: în interfață nu există o astfel de metodă, promisiunile „în planurile de dezvoltare” nu sunt o funcție. Un screenshot al transferului sau o bifă „plătit” nu creează sold: suma, contractul tokenului, adresa și confirmările sunt verificate de nodul propriu.

Verifica: payments/config/networks.cjs:54-140 — minimele din rândurile 60, 88, 133 · fila „Alimentare” din cabinet

Nu va exista credit automat. Creditarea are loc pe baza unui transfer efectiv confirmat în rețeaua selectată, fără schimb automat de alte active: USDC, USDT al altei rețele sau orice alt token la această adresă nu se transformă în sold. Adresele de pe diferite rețele sunt adrese diferite; coincidența primelor personaje nu înseamnă nimic. Ce trebuie să faceți: nu trimiteți a doua sumă și contactați prin pagina de asistență, indicând ID-ul tranzacției. Returnarea unui transfer eronat este o procedură separată; în modul platformă, problema este rezolvată fără mișcarea fondurilor reale.

Verifica: payments/config/networks.cjs · fila „Alimentare” — explicația de sub câmpul sumei („fără schimb automat al altor active”)

Trei niveluri — nu mai mult: 15 % primului invitant, 7 % celui de-al doilea, 3 % celui de-al treilea. Plafonul total al cascadei este 25 %. Baza o reprezintă acumulările zilnice ale invitaților, nu depozitul lor; fiecare nivel se rotunjește în jos separat.

Exemplu: T3 100 USDT produce 160 de cenți pe zi, deci L1 primește 24 de cenți, L2 — 11, L3 — 4 (39 pe zi față de plafonul de 40). Nimeni mai adânc de al treilea nivel nu primește.

Aceasta este o cheltuială a platformei: acumularea invitatului nu scade nici cu cascada, nici cu COVER.

Verifica: payments/pyramid/plans.cjs:104-111 · docs/product-math.md:91-103 · secțiunea „Invitații” din cabinet

Nivelul de echipă LV1–LV6 se acordă după numărul de direcți activi: 1, 3, 8, 20, 45 și 100. Se numără exact direcții, nu adâncimea: zece invitați de nivelul doi nu înlocuiesc un direct.

Bonusuri milestone unice pentru direcții activi: plafoane 3 → 10 USDT, 10 → 50, 25 → 150, 50 → 400, 100 → 1 000. Acestea sunt exact plafoane: plata treptei = min(plafon, 1 % din depozitele direcților), de aceea suma plafoanelor 1 610 USDT este limita superioară, nu o sumă promisă. Pentru ca treapta să funcționeze, depozitul invitatului trebuie să supraviețuiască hold-ului treptei: respectiv 14, 30, 60, 90 și 120 de zile. Plata este idempotentă: o relansare pe aceeași treaptă nu plătește a doua oară.

Bonusul de bun venit este declarat bilateral: invitantului 2 % din primul depozit (depozitul propriu-zis — de la 50 USDT, plafonul bonusului 100 USDT), invitatului +0,1 % la rată pentru 3 zile. Sincer: acum nu se plătește — este lansat doar de o acțiune separată a operatorului, iar fereastra de boost a invitatului este implementată incorect în cod. Această sumă nu poate fi promisă.

Verifica: payments/pyramid/plans.cjs:120-149 · docs/product-math.md:114-138,289-302 · payments/pyramid/engine.cjs:838-843

Pașii sunt descriși, dar cashback nu are un motor de bani. Configurația specifică patru niveluri în funcție de numărul de linii active: 0 → 20%, 5 → 30%, 15 → 50%, 30 → 60% (cel din urmă are 50% din liniile sale plus 10% din al doilea nivel), în configurația istorică a fost menționat calculul T+1. Nu există intrări în cod care să plătească această dobândă, ceea ce înseamnă cashback ca plată nu există acum și nu ar trebui să așteptați.

Verifica: payments/pyramid/plans.cjs:196-208 · docs/product-math.md:140-154 (direct: „nu există motor de bani pentru cashback în cod”) · secțiunea „Echipă” din cabinet

În bugetul lunii merge 2,5 % din venitul lunii (250 bpm) și se distribuie între participanții rangului DIAMOND proporțional volumului subarborelui (BV). BV nu este o valută, ci un volum condiționat pentru ranguri: se calculează din suma intrărilor și multiplicatorul treptei. Cenții reziduali se distribuie după cele mai mari cote. O lună fără beneficiari rămâne integral nedistribuită.

Pragul rangului: 2 000 000 BV de subarbore. Reper de scară (exemplu): treapta superioară T11 la 100 000 USDT dă 250 000 BV — pragul este închis de opt astfel de intrări.

Verifica: payments/pyramid/global-pool.cjs (POOL_BPS = 250) · payments/pyramid/plans.cjs:581-599 (RANK_VOLUME_BV.diamond, BV_FACTOR_HUNDREDTHS.vip) · blocul „Global Pool · DIAMOND” din secțiunea „Echipă”

Terții nu au nimic. Verificat de browser, nu așa cum a promis: accesarea cu crawlere a 13 pagini prin rețea a dus la 0 solicitări către gazde străine; Nu există cookie-uri terță parte, analize, pixeli sau captcha extern; fonturile și bibliotecile sunt în depozit; captcha - propriu, pe tokenul HMAC. Refererul nu este trimis atunci când urmăresc un link extern. În browser: nouă intrări de stocare locală - selecția limbii, temă, pauză de animație, bloc ascuns „Noțiuni introductive”, scripturi salvate pentru calculator (date introduse de persoana însăși) și un portofoliu local. Nicio cheie nu este un identificator de vizitator. Singura înregistrare asociată cu o persoană este cookie-ul de sesiune velar_session: HttpOnly (nu este disponibil pentru scripturi), SameSite=Lax, durează 30 de minute de oprire și nu mai mult de 14 zile. Pe server: serverul produsului nu păstrează deloc un jurnal de acces - nu sunt scrise nici metoda, nici calea, nici adresa, nici User-Agent; în circuitul de luptă nginx, a fost comutat la access_log off. IP-ul brut nu este stocat: singurul loc unde este implicată adresa este amprenta de înregistrare HMAC cu cheia în fișierul cu drepturi 0600 (fără cheie nu se caută digest-ul). Amprenta digitală HMAC expiră acum pe termen nelimitat - acesta este un defect recunoscut, înregistrat ca REQUEST S3. Singura caracteristică a dispozitivului inclusă în profil: fusul orar. Pagina citește zona browserului și o înlocuiește în câmpul de profil necesar, valoarea este stocată pe server și folosită pentru „orele de liniște”. Vizitatorul nu este întrebat despre acest lucru - auditul sugerează ca alegerea să fie explicită (găsiți F12, CERERE S11).

Verifica: docs/privacy-audit.md §1 (browser), §2 (server), §3 (cereri externe — „lista de domenii: goală”), §6 (amprentă) · verificare automată — node --test tests/ds-privacy-traces.test.cjs

Trei straturi, toate active acum.

— Parola de retragere este un secret separat, diferit de parola de autentificare. Minimum 8 caractere. Fără ea cererea nu se creează: serverul răspunde withdraw_password_required (403).

— Blocarea adresei — adresa portofelului este luată din profil în momentul creării cererii și înghețată în ea; schimbarea adresei în setări nu modifică o cerere deja creată.

— Limitele sesiunii — 30 de minute de inactivitate și 14 zile termen absolut pentru client; 8 și 12 ore pentru operator.

Parolele sunt stocate ca hash-uri scrypt cu sare, tokenul de sesiune doar ca digest sha256. 2FA prin TOTP există în API, dar nu în interfață.

Verifica: payments/pyramid/engine.cjs:1293,1320-1404 · payments/auth/service.cjs:25 · docs/privacy-audit.md §2.5 · secțiunea „Setări” → „Securitatea retragerii”

Recuperarea funcționează fără poștă. Introduceți emailul pe ecranul "Ați uitat parola?": dacă la cont este conectat Telegram, codul ajunge acolo; altfel se creează o cerere pentru operator, răspuns în 4 ore. Platforma nu are livrare prin email, deci nu veți vedea "email trimis". Nu comunicați parole sau coduri în conversație.

Verifica: payments/auth/recovery.cjs:1-32 · payments/server.cjs:1004-1040 (coada cererilor, răspunsuri, auditul acțiunilor) · dist/support.html

2FA prin TOTP există în API, dar nu în interfață: nu o puteți activa singur. Autentificarea este protejată de parolă, parola de retragere și o sesiune scurtă.

Modulul TOTP/HOTP este scris și verificat prin teste, dar nu există o rută pentru client de activare. Codul din aplicație nu ajută la recuperarea accesului: recuperarea trece prin Telegram sau operator.

Verifica: payments/auth/totp.cjs · payments/server.cjs:1496-1519 (autentificarea acceptă totp; nu există rută de activare pentru client)

Produsul nu are nici un oracol de rată și nici un factor de conversie: toate sumele și calculele sunt efectuate în USDT ca unitate contabilă 1:1. O regulă separată pentru abaterea ratei nu a fost publicată - nici modul în care platforma recalculează obligațiile, nici cum se compensează discrepanța. Aceasta înseamnă că diferența de curs valutar rămâne cu tine și nimeni nu poate promite „există întotdeauna aceiași dolari în USDT”. Dezvăluirea riscului peg este postată pe pagina de risc și se bazează pe o sursă externă, politica de trezorerie a Fundației Ethereum.

Verifica: dist/legal-risk.html (secțiunea despre ancorare, link către o sursă externă) · payments/config/networks.cjs — unitatea și zecimalele tokenurilor

Platforma nu publică nicio procedură fiscală, nici certificate sau declarații pentru biroul fiscal: persoana juridică a operatorului în proiectul de condiții nu este completată - există o înlocuire goală în text în loc de detalii (găsiți F9 în auditul de confidențialitate), iar documentul în sine este marcat ca proiect, ceea ce nu este un acord valid. Calculul impozitelor depinde de jurisdicția și statutul dumneavoastră - vă rugăm să verificați individual, platforma nu reține și nu sfătuiește nimic aici.

Verifica: dist/legal-terms.html (antetul „Proiect”, §1) · docs/privacy-audit.md §5, F9

Nu există o listă publicată de țări: jurisdicția operatorului nu este definită în proiectul de condiții. De fapt, restricțiile pe regiune astăzi nu afectează nimic, deoarece acceptarea efectivă a fondurilor este complet închisă: 41 de puncte de pregătire nu sunt închise, nici unul nu este închis, modul platformă este disponibil pentru toată lumea fără date de plată.

Verifica: dist/legal-terms.html (secțiunea despre legea aplicabilă) · payments/config/gates.cjs:20-70

Nu există nicio procedură de ștergere în interfață. Proiectul de termeni afirmă în mod direct că procedura de restabilire a accesului și ștergerea unui cont necesită o descriere separată - adică nu există nimic de promis „vom șterge în 30 de zile”. Perioadele de stocare a datelor din cod sunt anunțate aproximativ (5 ani pentru înregistrările financiare și AML) și toate au marcajul „neconfirmat de către un avocat”. Ce puteți face acum: ștergeți singur datele locale (setările browserului - ștergerea datelor site-ului va elimina înregistrările locale de stocare pentru acest domeniu) și scrieți la asistență cu o solicitare de analiză. Schimbarea parolei și revocarea tuturor sesiunilor este posibilă doar prin modificarea secretului contului.

Verifica: dist/legal-terms.html §2 · payments/compliance/privacy.cjs:126-133 (verified: false) · docs/privacy-audit.md §2.5

Ce vă este disponibil acum: - în cont - „Istoricul tranzacțiilor” (un jurnal al tranzacțiilor cu tipuri și sume) și „Raportul meu pentru perioada”; — posturi pe epoci personal — GET /api/me/epochs (sesiune necesară); — în mod public, fără a vă conecta — GET /api/epochs/history?limit=30 returnează aceleași agregate de epocă așa cum sunt afișate pe pagina /epochs: pool, revenue, distributed, coverage, retention, hash ale fiecărei epoci; - rezumatul modului - GET /api/public/stats (câmpul de mediu). Contabilitatea la nivel intern este structurată ca o intrare dublă: fiecare operațiune este o înregistrare de debit/credit, înregistrările de epocă au un refI din formularul E-index, iar jurnalul de acțiuni al operatorului este doar atașat cu un lanț hash. Ceea ce nu este încă disponibil: o modalitate personalizată de a vă reconcilia tranzacțiile personale în mod independent - nu există nicio prevedere pentru a vă deschide propriul jurnal sub formă de mașină.

Verifica: payments/ledger/ledger.cjs · payments/admin/audit.cjs · /epochs, blocul „Istoricul operațiunilor protocolului și rute publice”

Cererea — prin cabinet, secțiunea „Suport”: intră în coada angajaților, iar răspunsul apare în același dialog. Primul răspuns — în până la 4 ore lucrătoare; statusul — în „Cererile mele”.

Aceasta este corespondență text, nu chat în timp real; nu există telefon și nici mesagerie externă — site-ul nu face nicio cerere externă.

Prioritatea răspunsului nu accelerează execuția financiară, iar continuarea suportului nu cere o nouă depunere. Nu trimiteți în conversație parole, coduri de confirmare, seed phrases sau date de pașaport.

Verifica: dist/support.html · payments/ops/service.cjs (coada cererilor, răspunsuri, auditul acțiunilor) · docs/privacy-audit.md §3