Вопросы и ответы

Сейчас доступен только режим платформы: все суммы виртуальные. Заявка на выплату резервирует сумму внутри учёта и не выходит в сеть: у заявки стоит executionMode: 'sandbox'. В текущем режиме пополнения и выплаты в блокчейн не выполняются — реальные переводы отправлять не следует.

Запуск реальных операций не «скоро»: 41 пункт готовности в payments/config/gates.cjs не выполнен, поэтому 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), заявка уходит на проверку и исполняется только решением оператора. Решение — до 24 часов.

Статус — в кабинете, «Выплаты» → «Мои заявки»: на проверке → одобрена → отправлена → исполнена (или отклонена). Адрес получателя фиксируется в момент оформления заявки.

Проверить: 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 часов. Почтовой доставки на платформе нет — этот экран её не обещает. Пароли и коды в переписке не передавайте.

Что делать, если код не пришёл: откройте раздел «Поддержка» в кабинете — обращение попадёт в ту же очередь. Пароль, коды и seed-фразы в переписке передавать нельзя.

Проверить: 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