Запитання та відповіді

Режим платформи – єдиний доступний режим: усі суми віртуальні. Заявка на виплату резервує суму всередині обліку і не виходить у мережу: заявка має 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