Пытанні і адказы

Рэжым платформы - адзіны даступны рэжым: усе сумы віртуальныя. Заяўка на выплату рэзервуе суму ўнутры ўліку і не выходзіць у сетку: у заяўкі стаіць executionMode: 'sandbox'. У бягучым рэжыме папаўнення і выплаты ў блокчейн не выконваюцца - рэальныя пераклады адпраўляць не варта. Запуск рэальных аперацый не "хутка", а зачынены па ўмовах: 41 пункт гатоўнасці ў payments/config/gates.cjs, ні ў аднаго няма done: true, таму функцыя canGoLive() вяртае адмову. Пакуль гэта так, рэжым платформы - адзіны даступны рэжым.

Праверыць: payments/config/gates.cjs:20-70,87 · payments/pyramid/engine.cjs:1389 · GET /api/public/stats → environment: sandbox

3 000 віртуальных USDT адзін раз на профіль. Нарочваюцца кнопкай «Атрымаць стартавы баланс» у кабінеце: да націску баланс пусты. Папаўненне не патрэбнае, вывесці гэтыя USDT нельга.

Сума зададзена як Math.min(DEMO_GRANT_LIMIT, 300_000) — гэта 300 000 цэнтаў; ліміт выдачы DEMO_GRANT_LIMIT = 1 000 000 цэнтаў (10 000 USDT). Паўторны запыт атрымлівае памылку demo_grant_used.

Праверыць: payments/pyramid/engine.cjs:1003-1020 · POST /api/me/demo-grant · картка «Пачатак працы» ў кабінеце

Адзінаццаць ступеняў T1–T11. Мяжы замкнёныя: верхняя мяжа папярэдняй ступені плюс адзін цэнт роўная ніжняй мяжы наступнай — дзірак і перасячэнняў няма. Стаўка залежыць ад сумы і тэрміну: на 30 дзён — ад 1,2 % у дзень (T1) да 2,6 % (T11); на 90 дзён +0,2 п.п.; на 180 дзён +0,4 п.п., але не вышэй за 3,0 % у дзень. Чым даўжэйшы тэрмін — тым вышэйшая стаўка. Тэрмін выбіраецца пры адкрыцці дэпазіту: 30, 90 або 180 дзён, уваход — ад 10 да 250 000 USDT.

Спроба адкрыць ступень ніжэй за мінімум або вышэй за максімум адхіляецца кодамі below_tier_min / above_tier_max — «амаль хапае» не працуе: 9,99 USDT на T1 не прымуць.

Праверыць: payments/pyramid/plans.cjs:300,447-453 · GET /api/plans (тыя ж лікі машынна) · укладка «Дэпазіты» ў кабінеце

Формула адна: налічэнне за D дзён = floor(цела × дзённая стаўка × D ÷ 10 000), а даход канкрэтнага дня — розніца двух такіх значэнняў: floor(P × bp × d ÷ 10 000) − floor(P × bp × (d−1) ÷ 10 000). Кумулятыўны floor не губляе капейкі: сума дзённых прыростаў роўная налічэнню за ўвесь тэрмін.

Прыклад (арыфметыка мадэлі, не абяцанне): T3, 100 USDT — гэта 10 000 × 160 ÷ 10 000 = 160 цэнтаў = 1,60 USDT у дзень; за 30 дзён — 48,00 USDT. На мінімальных 10 USDT ступені T1 дзень дае 12 цэнтаў, за 30 дзён — 3,60 USDT.

Капіталізацыі няма: налічаныя працэнты не дадаюцца да цела і не павялічваюць наступны дзень. Дні ідуць каляндарна, без выхадных.

Праверыць: payments/pyramid/plans.cjs:418-434,458-461 · dist/plan-math.js:50-55 · GET /api/plans → accrualMethod: tier_daily_cumulative_floor_cents

Не. Гэта два контуры на адным капітале, і ў кожны дзень працуе роўна адзін з іх; складаць іх нельга. Плоскі контур — налічэнне па стаўцы ступені і календары, гэта ўмова плана. Эпохавы — доля пула ад выручкі, абвешчанай аператарам за суткі, па вазе пазіцыі. Таму 48,00 USDT за 30 дзён на T3 100 USDT — гэта або плоская сума, або сума эпох.

Праверыць: payments/pyramid/vault.cjs:19-30 · payments/pyramid/plans.cjs:418-434 · docs/product-math.md:200-224 · пазнака крыніцы ў кабінеце: dist/account.html, функцыя numbersSource()

Чатыры крокі: пазіцыя → долі капіталу (shares) → вага → pro-rata доля пула → залічэнне.

Вага = floor(цела × множнік ступені ÷ 10 000). Множнікі зададзеныя па ступенях: T1–T2 — 150 bpm, T3–T4 — 192, T5–T6 — 233, T7–T8 — 275, T9–T10 — 296, T11 — 300. T3 на 100 USDT дае вагу 192 цэнты = 1,92 USDT «чакання цыкла». Невядомая ступень вагі не дае: пазіцыя адхіляецца кодам vault_weight_class_unknown.

Доля пула — два выпадкі, і гэта галоўнае месца, дзе памыляюцца:

— пул ≥ сумы ваг: пазіцыя атрымлівае роўна сваю вагу, а ўсё звыш застаецца ў капітале vault і паднімае цану долі;

— пул меншы за суму ваг: пазіцыя атрымлівае floor(пул × вага ÷ суму ваг), а рэшта пула пераносіцца ў наступны цыкл як deferred.

Прыклад на ліках старонкі, а не абяцаны даход: у T3 100 USDT вага 1,92 USDT; калі пул цыкла меншы за суму ваг, пазіцыя атрымлівае floor(пул × 1,92 ÷ суму ваг), а рэшта ідзе пераносам.

Праверыць: payments/pyramid/plans.cjs:288-300,331-367 · payments/pyramid/vault.cjs:252-258,585-610,733-853 · табліца прыкладаў — /epochs, блок «Як лічыцца твая доля»

Таму што крыніца выплаты — пул, а не каляндар. Пул цыкла складаецца з абвешчанай аператарам выручкі гэтага цыкла і пераносу мінулых дэферралаў. Няма выручкі — пул нулявы, і пазіцыі ў гэты цыкл не атрымліваюць нічога; дзённая стаўка ступені — разліковая велічыня для параўнання ўмоў, а не абавязацельства цыкла.

Здымак з публічнага маршруту стэнда (цыкл 6): пул 4 800,00 USDT, размеркавана пазіцыям 7,50 USDT — гэта 0,15 % пула, а 4 792,50 USDT пайшло ў капітал vault (утрыманне), гэта значыць падняло цану долі, але не выплачана ў кэш. Такі цыкл — норма, а не збой: пры адной буйной вазе і невялікім пуле размеркаванне выглядае менавіта так.

Выручку цыкла фіксуе аператар асобным дзеяннем; адхіленне больш за 30 % ад медыяны сямі мінулых цыклаў патрабуе другога пацверджання — гэта абарона ад выпадковай памылкі ў ліку.

Праверыць: GET /api/epochs/history?limit=30 (тыя ж калонкі) · dist/epochs-public.js:77 · табліца апошніх 30 цыклаў — /epochs

COVER - гэта 2,5% (250 bpm) кожнай дзённай выплаты плоскага контуру, якія пратакол пераводзіць унутры ўліку: з рахунку treasury_hot на рахунак treasury_cover. Для T3 100 USDT гэта floor(160 × 250 ÷ 10 000) = 4 цэнты ў дзень. Ніякіх знешніх узносаў, камісій кліенту або выплат "па страхавым выпадку" тут няма. Чаму не страхаванне: рэзерв не з'яўляецца фондам і не дае права на кампенсацыю. Ён застаецца унутраным уліковым лікам пратаколу, у яго няма дамовы, атрымальніка і падзеі выплаты. Вітрына прама падпісвае паказчык пакрыцця як "не страхавое пакрыццё". Дзе ён бачны ў матэматыцы: у эпохавым размеркаванні COVER не ўдзельнічае зусім і дзель пазіцыі не памяншае. У плоскім контуры гэта ўнутраны пераклад, таму нагрузка на мадэль лічыцца як працэнты + каскад + COVER. Адзінае, што ён мяняе для вас: калі пакрыццё казны (funds ÷ obligations) падае ніжэй за 150%, долі каскаду памнажаюцца на 0,75 - гэта аўтаматычнае зніжэнне бонусаў запрасілі, а не вылік з вашай стаўкі. Рэзерв не з'яўляецца крыніцай выплат кліенту: рахунак COVER не плаціць.

Праверыць: payments/pyramid/plans.cjs:223-225 · payments/pyramid/engine.cjs:156-158,282-288,542-546 · docs/product-math.md:105-112,249-253 · плітка «Уліковае пакрыццё абавязацельстваў» на галоўнай

У сетцы з 11 ступень каманднага паскарэння няма: ва ўсіх ступень T1–T11 у канфігурацыі стаіць teamBoost: false, таму нават 100 актыўных прамых не дадаюць ніводнага базавага пункта. Калі паскарэння няма — гэта не памылка вашага профілю: яго няма на платформе.

Поле засталося толькі ў легасі-контуры гістарычных дэпазітаў: у класаў ADVANCED, PREMIUM і VIP надбаўка +1 bpm (+0,01 працэнтнага пункта ў дзень) за кожныя 3 актыўныя прамыя, максімум +5 bpm. Да новых ступень T1–T11 гэтае правіла не адносіцца: GET /api/plans аддае teamBoost: false і teamBoostDailyBpsMax: 0 для кожнай з 11 ступень.

Праверыць: payments/pyramid/plans.cjs:300,69-77 · GET /api/plans → teamBoost, teamBoostDailyBpsMax

Налічэнне ідзе роўна столькі дзён, колькі пазначана ў тэрміне ступені; у апошні дзень дэпазіт пераводзіцца ў статус matured («паспеў»). Далей працэнты па ім не налічваюцца.

Камісія датэрміновага выкупу ў гэты момант роўная нулю — замест камісіі ступені (ад 2 % на T1 да 0 % на T11). Сеткавая камісія 1 USDT пры вывадзе ўтрымліваецца ў любым выпадку, уключаючы закрыццё па тэрміне.

Цела не адпраўляецца аўтаматычна: грошы застаюцца на рахунку дэпазіту да вашай заяўкі на закрыццё (у кабінеце — «Умовы выкупу» / «Закрыццё дэпазіту»). Ніякага «ўтрымання» цела звыш тэрміну няма — але і аўтапераводу таксама: без заяўкі сума проста ляжыць.

Праверыць: payments/pyramid/engine.cjs:1281,1320-1335,1347-1404 · укладка «Выплаты» ў кабінеце

Камісія выкупу = floor(цела × стаўка выкупу ÷ 10 000), стаўка зададзена ступенню: T1–T2 — 2 %, T3–T4 — 1,5 %, T5–T6 — 1 %, T7–T8 — 0,5 %, T9–T10 — 0,25 %, T11 — 0 %. Лічыцца ад цела, а не ад працэнтаў.

Прыклад: T3 на 100 USDT (10 000 цэнтаў) закрываецца датэрмінова → камісія 150 цэнтаў = 1,50 USDT, да пераводу 98,50 USDT, мінус сеткавыя 1 USDT → 97,50 USDT (у рэжыме платформы — на ўнутраны рахунак заяўкі).

Налічаныя працэнты застаюцца ў вас цалкам: у заяўцы поле clawbackCents роўнае нулю, згарання налічанага няма. Парадак просты: спачатку выплачваюцца назапашаныя працэнты, цела закрываецца асобнай заяўкай.

Праверыць: payments/pyramid/plans.cjs:91-95,300-367 · payments/pyramid/engine.cjs:1320-1335,1347-1404 · кнопка «Умовы выкупу» у спісе дэпазітаў

Можна: - Даступны рахунак - налічаныя працэнты і бонусы (у кодзе гэта заяўка выгляду kind: 'interest'); - Цела дэпазіту - заяўкай на закрыццё (kind: 'principal'): датэрмінова з камісіяй ступені, па тэрміне без камісіі. Нельга: - стартавыя 3 000 віртуальных USDT - гэта стартавы баланс, ён не абменьваецца на рэальныя грошы; - "Вывесці цела і пакінуць працэнты" адной кнопкай - гэта дзве розныя заяўкі; - атрымаць штосьці ў блокчейн, пакуль платформа ў рэжыме платформы: пераклад не выконваецца фізічна. Сеткавая камісія - 1 USDT (100 цэнтаў) і ўтрымліваецца з сумы заяўкі. Унутры аднаго дэпазіту адначасова можа быць толькі адна актыўная заяўка на цела: другая атрымлівае deposit_locked - так падвойнае рэзерваванне цела немагчыма.

Праверыць: payments/pyramid/engine.cjs:1320-1404 · payments/pyramid/plans.cjs:227-233 · укладка «Выплаты» → «Даступна»

Заяўка адразу рэзервуе суму: грошы сыходзяць з рахунку кліента ў лік чакання (withdraw_reserve) яшчэ да рашэння аператара. Калі заяўку адхіляюць, рэзерв вяртаецца. Маршрут адзін для любой сумы: аўтаматычнага маршруту няма (autoRoute: false), заяўка сыходзіць у review і выконваецца толькі рашэннем аператара. Арыентыр апрацоўкі - да 24 гадзін. Статусы заяўкі: review approved broadcast done (або rejected). Адрас атрымальніка фіксуецца ў момант афармлення заяўкі - праўка профілю потым на ўжо створаную заяўку не ўплывае.

Праверыць: payments/pyramid/engine.cjs:1347-1404 · payments/pyramid/plans.cjs:227-233 · «Мае заяўкі» ў кабінеце

Толькі пераводам USDT у адной з трох сетак, адрас выдае кабінет:

— TRON (TRC-20) — мінімум 10 USDT;

— BNB Smart Chain (BEP-20) — мінімум 10 USDT (у токена 18 знакаў, а не 6 — гэта важная дэталь для сумы пераводу);

— Ethereum (ERC-20) — мінімум 20 USDT.

Картка і банк не рэалізаваныя: у інтэрфейсе няма такога спосабу, абяцанні «у планах развіцця» — не функцыя. Скрыншот пераводу або адзнака «аплачана» баланс не ствараюць: суму, кантракт токена, адрас і пацверджанні правярае свая нода.

Праверыць: payments/config/networks.cjs:54-140 — мінімумы ў радках 60, 88, 133 · укладка «Папоўніць» у кабінеце

Аўтаматычнага заліку не будзе. Залічэнне адбываецца па фактычным пацверджаным перакладзе ў абранай сетцы, без аўтаматычнага абмену іншых актываў: USDC, USDT іншай сеткі або любы іншы токен па гэтым адрасе ў баланс не ператвараюцца. Адрасы ў розных сетках - розныя адрасы, супадзенне першых сімвалаў нічога не значыць. Што рабіць: не адпраўляць другую суму і звярнуцца праз старонку суправаджэння, указаўшы ідэнтыфікатар транзакцыі. Зварот памылковага перакладу - асобная працэдура, у рэжыме платформы пытанне разбіраецца без руху рэальных сродкаў.

Праверыць: payments/config/networks.cjs · укладка «Папоўніць» — тлумачэнне пад полем сумы («без аўтаматычнага абмену іншых актываў»)

Тры ўзроўні — не больш: 15 % першаму запросіўшаму, 7 % другому, 3 % трэцяму. Сумарны ліміт каскаду — 25 %. База — дзённыя налічэнні запрошаных, а не сума іх укладу; кожны ўзровень акругляецца ўніз асобна.

Прыклад: T3 100 USDT дае 160 цэнтаў у дзень, значыць L1 атрымлівае 24 цэнты, L2 — 11, L3 — 4 (усяго 39 у дзень супраць ліміту 40). Глыбей за трэці ўзровень не атрымлівае ніхто.

Гэта выдатак платформы: налічэнне запрошанага не змяншаецца ні на каскад, ні на COVER.

Праверыць: payments/pyramid/plans.cjs:104-111 · docs/product-math.md:91-103 · раздзел «Запрашэнні» ў кабінеце

Узровень каманды LV1–LV6 прысвойваецца па колькасці актыўных прамых: 1, 3, 8, 20, 45 і 100. Лічацца менавіта прамыя, а не глыбіня: дзесяць запрошаных другога ўзроўню не заменяць аднаго прамога.

Разовыя milestone-бонусы за актыўных прамых: столі 3 → 10 USDT, 10 → 50, 25 → 150, 50 → 400, 100 → 1 000. Гэта менавіта столі: выплата ступені = min(столя, 1 % укладаў прамых), таму сума столей 1 610 USDT — верхняя мяжа, а не абяцаная сума. Каб ступень спрацавала, уклад запрошанага павінен пражыць холд ступені: 14, 30, 60, 90 і 120 дзён адпаведна. Выплата ідэмпатэнтная: паўторны запуск па той жа ступені не плаціць другі раз.

Welcome-бонус абвешчаны двухбаковым: запрашальніку 2 % ад першага дэпазіту (сам дэпазіт — ад 50 USDT, столя бонусу 100 USDT), запрошанаму +0,1 % да стаўкі на 3 дні. Шчыра: сам ён зараз не выплачваецца — яго запускае толькі асобнае дзеянне аператара, а акно бусту запрошанага ў кодзе разгорнута няправільна. Абяцаць гэтую суму нельга.

Праверыць: payments/pyramid/plans.cjs:120-149 · docs/product-math.md:114-138,289-302 · payments/pyramid/engine.cjs:838-843

Прыступкі апісаны, але валютнага рухавічка ў кэшбэка няма. У канфігурацыі зададзены чатыры ступені па колькасці актыўных прамых: 0 → 20%, 5 → 30%, 15 → 50%, 30 → 60% (у апошняй 50% сваіх прамых плюс 10% другога ўзроўню), у гістарычнай канфігурацыі згадваўся разлік T+1. У кодзе няма праводак, якія гэтыя працэнты плацяць, - значыць кэшбэка як выплаты цяпер не існуе, і чакаць яго не варта.

Праверыць: payments/pyramid/plans.cjs:196-208 · docs/product-math.md:140-154 (прама: «грашовага рухавіка кэшбэку ў кодзе няма») · раздзел «Каманда» ў кабінеце

У бюджэт месяца ідзе 2,5 % выручкі месяца (250 bpm), і размяркоўваецца ён сярод удзельнікаў рангу DIAMOND прапарцыйна аб'ёму паддрэва (BV). BV — не валюта, а ўмоўны аб'ём для рангаў: ён лічыцца з сумы ўваходаў і множніка ступені. Рэшткавыя цэнты размяркоўваюцца па найбольшых долях. Месяц без атрымальнікаў застаецца неразмеркаваным цалкам.

Парог рангу: 2 000 000 BV паддрэва. Арыенцір маштабу (прыклад): верхняя ступень T11 на 100 000 USDT дае 250 000 BV — парог закрываюць восем такіх уваходаў.

Праверыць: payments/pyramid/global-pool.cjs (POOL_BPS = 250) · payments/pyramid/plans.cjs:581-599 (RANK_VOLUME_BV.diamond, BV_FACTOR_HUNDREDTHS.vip) · блок «Global Pool · DIAMOND» у раздзеле «Каманда»

У трэціх бакоў - нічога. Праверана браўзэрам, а не па абяцанні: абыход 13 старонак па сетцы даў 0 запытаў на чужыя хасты; іншых cookie, аналітыкі, пікселяў і вонкавай капчы няма; шрыфты і бібліятэкі ляжаць у рэпазітары; капча - свая, на HMAC-токене. Referer пры пераходзе па вонкавай спасылцы не адпраўляецца. У браўзэры: дзевяць запісаў localStorage - выбар мовы, тэма, паўза анімацыі, схаваны блок "Пачатак працы", захаваныя сцэнары калькулятара (дадзеныя ўводзіць сам чалавек) і партфель лакальнага контуру. Ніводны ключ не з'яўляецца ідэнтыфікатарам наведвальніка. Адзіная запіс, прывязаная да чалавека, - сесійная cookie velar_session: HttpOnly (скрыптам недаступная), SameSite = Lax, жыве 30 хвілін прастою і не даўжэй 14 сутак. На серверы: сервер прадукта наогул не вядзе часопіс доступу - ні метад, ні шлях, ні адрас, ні User-Agent не пішуцца; у баявым контуры nginx пераведзены ў access_log off. Сырой IP не захоўваецца: адзінае месца, дзе адрас удзельнічае, - HMAC-адбітак рэгістрацыі з ключом у файле з правамі 0600 (без ключа дайджэст не перабіраецца). Тэрмін HMAC-адбітка зараз бестэрміновы – гэта прызнаны недахоп, зафіксаваны як REQUEST S3. Адзіная прыкмета прылады, які трапляе ў профіль: гадзінны пояс. Старонка чытае зону браўзэра і падстаўляе яе ў абавязковае поле профіля, значэнне захоўваецца на серверы і выкарыстоўваецца для «ціхіх гадзін». Наведвальніка пра гэта не пытаюцца – аўдыт прапануе зрабіць выбар відавочным (знаходка F12, REQUEST S11).

Праверыць: docs/privacy-audit.md §1 (браўзер), §2 (сервер), §3 (знешнія запыты — «спіс даменаў: пусты»), §6 (адбітак) · машынная праверка — node --test tests/ds-privacy-traces.test.cjs

Тры ўзроўні, усе працуюць зараз.

— Пароль вываду — асобны сакрэт, не роўны паролю ўваходу. Мінімум 8 сімвалаў. Без яго заяўка не ствараецца: сервер адказвае withdraw_password_required (403).

— Фіксацыя адрасу — адрас кашалька бярэцца з профілю ў момант афармлення заяўкі і замарожваецца ў ёй; змена адрасу ў наладах не мяняе ўжо створаную заяўку.

— Тэрміны сесіі — у кліента 30 хвілін прастою і 14 сутак абсалютны тэрмін; у аператара 8 і 12 гадзін.

Паролі захоўваюцца як scrypt-хэшы з соллю, токен сесіі — толькі як sha256-дайджэст. 2FA па TOTP ёсць у API, але ў інтэрфейсе яе няма.

Праверыць: payments/pyramid/engine.cjs:1293,1320-1404 · payments/auth/service.cjs:25 · docs/privacy-audit.md §2.5 · раздзел «Налады» → «Бяспека вываду»

Аднаўленне працуе без пошты. Укажыце email на экране «Забылі пароль?»: калі да акаўнта прывязаны Telegram, код прыйдзе туды; калі не — ствараецца заяўка аператару, адказ на працягу 4 гадзін. Паштовай дастаўкі на платформе няма, таму «ліст адпраўлены» вы не ўбачыце. Паролі і коды ў перапісцы не перадавайце.

Праверыць: payments/auth/recovery.cjs:1-32 · payments/server.cjs:1004-1040 (чарга зваротаў, адказы, аўдыт дзеянняў) · dist/support.html

2FA па TOTP ёсць у API, але ў інтэрфейсе яе няма: уключыць самастойна нельга. Уваход абараняюць пароль, пароль вываду і кароткая сесія.

Модуль TOTP/HOTP напісаны і правяраецца тэстамі, але кліенцкага маршруту ўключэння няма. Код з праграмы пры аднаўленні доступу не дапаможа: аднаўленне ідзе праз Telegram або аператара.

Праверыць: payments/auth/totp.cjs · payments/server.cjs:1496-1519 (уваход прымае totp; маршруту ўключэння для кліента няма)

У прадукце няма ні аракула курса, ні каэфіцыента пераліку: усе сумы і разлікі вядуцца ў USDT як у адзінцы ўліку 1:1. Асобнага правіла на адхіленне курсу не апублікавана - ні як платформа пералічвае абавязацельствы, ні як кампенсуе разыходжанне. Гэта значыць, што курсавая розніца застаецца на вас, і абяцаць "у USDT заўсёды столькі ж даляраў" ніхто не можа. Раскрыццё рызыкі прывязкі вынесена на старонку рызык і абапіраецца на знешнюю крыніцу - палітыку казначэйства Ethereum Foundation.

Праверыць: dist/legal-risk.html (раздзел пра прывязку, спасылка на знешнюю крыніцу) · payments/config/networks.cjs — адзінка і знакі токенаў

Платформа не публікуе ні падатковага парадку, ні даведак, ні выпісак для падатковай: юрыдычная асоба аператара ў чарнавіку умоў не запоўнена – у тэксце засталася незапоўненая падстаноўка замест рэквізітаў (знаходка F9 у аўдыце прыватнасці), а сам дакумент пазначаны як чарнавік, які не з'яўляецца дзеючым пагадненнем. Разлік падатку залежыць ад вашай юрысдыкцыі і статусу - удакладняйце індывідуальна, платформа тут нічога не ўтрымлівае і не кансультуе.

Праверыць: dist/legal-terms.html (шапка «Чарнавік», §1) · docs/privacy-audit.md §5, F9

Апублікаванага пераліку краін няма: юрысдыкцыя аператара ў чарнавіку ўмоў не вызначана. Па факце абмежавання па рэгіёнах сёння ні на што не ўплываюць, таму што рэальны прыём сродкаў закрыты цалкам: 41 пункт гатоўнасці не закрыты ніводны, рэжым платформы даступны ўсім без плацежных дадзеных.

Праверыць: dist/legal-terms.html (раздзел пра дастасавальнае права) · payments/config/gates.cjs:20-70

Працэдуры выдалення ў інтэрфейсе няма. Чарнавік умоў прама кажа, што парадак аднаўлення доступу і выдаленні акаўнта патрабуе асобнага апісання - гэта значыць абяцаць "выдалім за 30 дзён" няма чым. Тэрміны захоўвання дадзеных у кодзе абвешчаныя арыентыровачна (5 гадоў па фінансавых і AML-запісах) і ва ўсіх варта адзнака "не пацверджана юрыстам". Што можна зрабіць цяпер: выдаліць лакальныя дадзеныя самастойна (наладкі браўзэра - ачыстка дадзеных сайта здыме запісы localStorage гэтага дамена) і напісаць у суправаджэнне з просьбай аб разборы. Змену пароля і водгук усіх сесій дае толькі змена сакрэту акаўнта.

Праверыць: dist/legal-terms.html §2 · payments/compliance/privacy.cjs:126-133 (verified: false) · docs/privacy-audit.md §2.5

Што даступна вам прама зараз: - у кабінеце - «Гісторыя аперацый» (часопіс праводак з тыпамі і сумамі) і «Мая справаздача за перыяд»; - пазіцыі па эпохах персанальна - GET /api/me/epochs (патрэбная сесія); - публічна, без уваходу - GET /api/epochs/history?limit=30 аддае тыя ж агрэгаты эпох, што намаляваныя на старонцы /epochs: пул, выручка, размеркавана, пакрыццё, утрыманне, хэш кожнай эпохі; - зводка рэжыму - GET /api/public/stats (поле environment). Улік усярэдзіне ўладкованы як падвойны запіс: кожная аперацыя — праводка дэбет/крэдыт, у запісаў эпохі ёсць refId выгляду E-index, а часопіс дзеянняў аператара append-only з хэш-ланцужком. Чаго пакуль няма: карыстацкага спосабу зверыць вашыя асабістыя праводкі незалежна - расчыненні ўласнага часопіса ў машынным выглядзе не прадугледжана.

Праверыць: payments/ledger/ledger.cjs · payments/admin/audit.cjs · /epochs, блок «Гісторыя аперацый пратакола і публічныя маршруты»

Зварот — праз кабінет, раздзел «Падтрымка»: ён трапляе ў чаргу супрацоўнікаў, адказ з’яўляецца ў тым жа дыялогу. Першы адказ — да 4 працоўных гадзін; статус — у раздзеле «Мае звароты».

Гэта тэкставая перапіска, а не чат у рэальным часе; тэлефона і знешніх месенджараў няма — на сайце няма ніводнага знешняга запыту.

Прыярытэт адказу не паскарае фінансавае выкананне, і працяг падтрымкі не патрабуе новага папаўнення. Паролі, коды пацверджання, seed-фразы і пашпартныя даныя ў перапісцы не перадавайце.

Праверыць: dist/support.html · payments/ops/service.cjs (чарга зваротаў, адказы, аўдыт дзеянняў) · docs/privacy-audit.md §3