Questions and answers

Platform mode is the only mode available: all amounts are virtual. The payment request reserves the amount within the account and does not go online: the request has executionMode: 'sandbox'. In the current mode, deposits and payments are not made to the blockchain - real transfers should not be sent. The launch of real operations is not “coming soon”, but is closed due to conditions: 41 readiness items in payments/config/gates.cjs, none of them have done: true, so the canGoLive() function returns a failure. While this is the case, platform mode is the only mode available.

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

3,000 virtual USDT once per profile. They are credited by the “Get starting balance” button in the account: before that the balance is empty. No top-up is required, and these USDT cannot be withdrawn.

The amount is Math.min(DEMO_GRANT_LIMIT, 300_000) — 300,000 cents; the grant cap DEMO_GRANT_LIMIT = 1,000,000 cents (10,000 USDT). A repeated request returns demo_grant_used.

Check: payments/pyramid/engine.cjs:1003-1020 · POST /api/me/demo-grant · the “Getting started” card in the cabinet

Eleven tiers T1–T11. The boundaries are closed: the upper boundary of the previous tier plus one cent equals the lower boundary of the next one — there are no gaps or overlaps. The rate depends on the amount and the term: for 30 days — from 1.2% per day (T1) to 2.6% (T11); for 90 days +0.2 pp; for 180 days +0.4 pp, capped at 3.0% per day. The longer the term, the higher the rate. The term is chosen when the deposit is opened: 30, 90 or 180 days, entry from 10 to 250,000 USDT.

An attempt to open a tier below the minimum or above the maximum is rejected with the codes below_tier_min / above_tier_max — “almost enough” does not work: 9.99 USDT on T1 will not be accepted.

Check: payments/pyramid/plans.cjs:300,447-453 · GET /api/plans (the same numbers, machine-readable) · the “Deposits” tab in the cabinet

The formula is the same: accrual for D days = floor(principal × daily rate × D ÷ 10,000), and the income of a particular day is the difference of two such values: floor(P × bp × d ÷ 10,000) − floor(P × bp × (d−1) ÷ 10,000). The cumulative floor loses no cents: the sum of daily increments equals the accrual for the whole term.

Example (model arithmetic, not a promise): T3, 100 USDT is 10,000 × 160 ÷ 10,000 = 160 cents = 1.60 USDT per day; over 30 days — 48.00 USDT. At the minimum 10 USDT of tier T1 a day gives 12 cents, over 30 days — 3.60 USDT.

There is no compounding: accrued interest is not added to the principal and does not increase the next day. Days run by calendar, without weekends.

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

No. These are two contours on the same capital, and exactly one of them is active on any given day; they cannot be added together. The flat contour is accrual at the tier rate by calendar — a plan condition. The epoch contour is a pool share from revenue declared by the operator for the day, by position weight. So 48.00 USDT over 30 days on T3 100 USDT is either the flat amount or the sum of epochs.

Check: payments/pyramid/vault.cjs:19-30 · payments/pyramid/plans.cjs:418-434 · docs/product-math.md:200-224 · source label in the cabinet: dist/account.html, function numbersSource()

Four steps: position → capital shares → weight → pro-rata pool share → credit.

Weight = floor(principal × tier multiplier ÷ 10,000). Multipliers are set by tier: T1–T2 — 150 bpm, T3–T4 — 192, T5–T6 — 233, T7–T8 — 275, T9–T10 — 296, T11 — 300. T3 on 100 USDT gives a weight of 192 cents = 1.92 USDT of “cycle expectation”. An unknown tier gives no weight: the position is rejected with the code vault_weight_class_unknown.

Pool share — two cases, and this is the main place where people make mistakes:

— pool ≥ the sum of weights: the position receives exactly its weight, and everything above stays in the vault capital and raises the share price;

— pool less than the sum of weights: the position receives floor(pool × weight ÷ the sum of weights), and the remainder of the pool is carried to the next cycle as deferred.

An example on the numbers of this page, not a promised income: for T3 100 USDT the weight is 1.92 USDT; if the cycle pool is less than the sum of weights, the position receives floor(pool × 1.92 ÷ the sum of weights), and the remainder is carried over.

Check: payments/pyramid/plans.cjs:288-300,331-367 · payments/pyramid/vault.cjs:252-258,585-610,733-853 · examples table — /epochs, the “How your share is calculated” block

Because the source of the payout is the pool, not the calendar. The cycle pool consists of the revenue declared by the operator for this cycle and the carry-over of previous deferrals. No revenue — the pool is zero, and positions receive nothing in that cycle; the daily tier rate is a calculated value for comparing terms, not an obligation of the cycle.

A snapshot from the public route of the stand (cycle 6): pool 4,800.00 USDT, distributed to positions 7.50 USDT — that is 0.15 % of the pool, while 4,792.50 USDT went into vault capital (retention), that is, it raised the share price but was not paid out in cash. Such a cycle is normal, not a failure: with one large weight and a small pool the distribution looks exactly like this.

The revenue of a cycle is recorded by the operator as a separate action; a deviation of more than 30 % from the median of the seven previous cycles requires a second confirmation — this protects against an accidental typo in the number.

Check: GET /api/epochs/history?limit=30 (the same columns) · dist/epochs-public.js:77 · table of the last 30 cycles — /epochs

COVER is 2.5% (250 bpm) of each daily payment of a flat circuit, which the protocol transfers internally: from the treasury_hot account to the treasury_cover account. For T3 100 USDT this is floor(160 × 250 ÷ 10,000) = 4 cents per day. There are no external contributions, commissions to the client or payments “for an insured event” here. Why not insurance: the reserve is not a fund and does not give the right to compensation. It remains an internal protocol account and has no contract, recipient, or payout event. The storefront explicitly labels the coverage figure as “not insurance coverage.” Where it is visible in mathematics: COVER does not participate at all in the epochal distribution and does not reduce the share of the position. In a flat circuit this is an internal translation, so the load on the model is calculated as percentage + cascade + COVER. The only thing it changes for you: if the treasury coverage (funds ÷ obligations) falls below 150%, the cascade shares are multiplied by 0.75 - this is an automatic reduction of bonuses for those who invited, and not a deduction from your bet. The reserve is not a source of payment to the client: COVER does not pay the account.

Check: payments/pyramid/plans.cjs:223-225 · payments/pyramid/engine.cjs:156-158,282-288,542-546 · docs/product-math.md:105-112,249-253 · the “Accounting coverage of obligations” tile on the home page

In the grid of 11 tiers there is no team acceleration: all tiers T1–T11 have teamBoost: false in the configuration, so even 100 active direct referrals add not a single basis point. If there is no acceleration, this is not an error in your profile: it does not exist on the platform.

The field remains only in the legacy circuit of historical deposits: the ADVANCED, PREMIUM and VIP classes have a bonus of +1 bpm (+0.01 percentage point per day) for every 3 active direct referrals, maximum +5 bpm. This rule does not apply to the new tiers T1–T11: GET /api/plans returns teamBoost: false and teamBoostDailyBpsMax: 0 for each of the 11 tiers.

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

Accrual runs for exactly as many days as the tier term states; on the last day the deposit is moved to the status matured. After that no interest is accrued on it.

The early redemption fee at that moment is zero — instead of the tier fee (from 2 % on T1 to 0 % on T11). The network fee of 1 USDT on withdrawal is withheld in any case, including closing by term.

The principal is not sent automatically: the money stays on the deposit account until your closing request (in the cabinet — “Redemption terms” / “Close deposit”). There is no “retention” of the principal beyond the term — but there is no automatic transfer either: without a request the amount simply sits there.

Check: payments/pyramid/engine.cjs:1281,1320-1335,1347-1404 · the “Payouts” tab in the cabinet

Redemption fee = floor(principal × redemption rate ÷ 10,000), the rate is set by the tier: T1–T2 — 2 %, T3–T4 — 1.5 %, T5–T6 — 1 %, T7–T8 — 0.5 %, T9–T10 — 0.25 %, T11 — 0 %. It is calculated from the principal, not from the interest.

Example: T3 on 100 USDT (10,000 cents) is closed early → fee 150 cents = 1.50 USDT, to transfer 98.50 USDT, minus the network 1 USDT → 97.50 USDT (in platform mode — to the internal account of the request).

Accrued interest stays with you in full: in the request the field clawbackCents is zero, there is no burning of accrued amounts. The order is simple: first the accumulated interest is paid out, the principal is closed by a separate request.

Check: payments/pyramid/plans.cjs:91-95,300-367 · payments/pyramid/engine.cjs:1320-1335,1347-1404 · the “Redemption terms” button in the deposit list

You can: - available account - accrued interest and bonuses (in the code this is an application of the form kind: 'interest'); — deposit body — application for closing (kind: 'principal'): ahead of schedule with a stage commission, according to the term without commission. You can't: — starting 3,000 virtual USDT is the starting balance, it is not exchanged for real money; - “withdraw the body and leave the interest” with one button - these are two different requests; — receive something on the blockchain while the platform is in platform mode: the transfer is not physically performed. The network commission is 1 USDT (100 cents) and is deducted from the application amount. Within one deposit, there can be only one active request for a body at a time: the second one receives deposit_locked - so double reservation of a body is impossible.

Check: payments/pyramid/engine.cjs:1320-1404 · payments/pyramid/plans.cjs:227-233 · the “Payouts” tab → “Available”

The application immediately reserves the amount: the money goes from the client’s account to the waiting account (withdraw_reserve) even before the operator’s decision. If the application is rejected, the reserve is returned. There is one route for any amount: there is no automatic route (autoRoute: false), the application goes to review and is executed only by the operator’s decision. The processing time is up to 24 hours. Application statuses: review → approved → broadcast → done (or rejected). The recipient's address is recorded at the time of filling out the application - editing the profile later does not affect the already created application.

Check: payments/pyramid/engine.cjs:1347-1404 · payments/pyramid/plans.cjs:227-233 · “My requests” in the cabinet

Only by transferring USDT in one of the three networks, the address is issued by the cabinet:

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

— BNB Smart Chain (BEP-20) — minimum 10 USDT (the token has 18 decimals, not 6 — an important detail for the transfer amount);

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

Card and bank are not implemented: there is no such method in the interface, promises of “planned features” are not a feature. A transfer screenshot or a “paid” mark does not create a balance: the amount, token contract, address and confirmations are verified by our own node.

Check: payments/config/networks.cjs:54-140 — minimums on lines 60, 88, 133 · the “Top up” tab in the cabinet

There will be no automatic credit. Crediting occurs based on an actual confirmed transfer in the selected network, without automatic exchange of other assets: USDC, USDT of another network or any other token at this address does not turn into balance. Addresses on different networks are different addresses; the coincidence of the first characters means nothing. What to do: do not send the second amount and contact through the support page, indicating the transaction ID. Returning an erroneous transfer is a separate procedure; in platform mode, the issue is dealt with without the movement of real funds.

Check: payments/config/networks.cjs · the “Top up” tab — the note under the amount field (“without automatic exchange of other assets”)

Three levels, no more: 15% to the first inviter, 7% to the second, 3% to the third. The total cascade cap is 25%. The base is the invitees’ daily accruals, not their deposit; each level is rounded down separately.

Example: T3 100 USDT yields 160 cents a day, so L1 receives 24 cents, L2 — 11, L3 — 4 (39 a day against the 40 cap). Nobody deeper than the third level receives anything.

This is a platform expense: the invitee’s accrual is reduced by neither the cascade nor COVER.

Check: payments/pyramid/plans.cjs:104-111 · docs/product-math.md:91-103 · the “Invitations” section in the cabinet

Team level LV1–LV6 is assigned by the number of active direct referrals: 1, 3, 8, 20, 45 and 100. Only direct referrals count, not depth: ten second-level invites will not replace one direct one.

One-time milestone bonuses for active direct referrals: caps 3 → 10 USDT, 10 → 50, 25 → 150, 50 → 400, 100 → 1,000. These are exactly caps: the tier payout = min(cap, 1 % of the deposits of direct referrals), so the sum of caps 1,610 USDT is an upper bound, not a promised amount. For the tier to trigger, the deposit of the invited must survive the tier hold: 14, 30, 60, 90 and 120 days respectively. The payout is idempotent: a repeated run for the same tier does not pay twice.

The welcome bonus is declared two-sided: to the inviter 2 % of the first deposit (the deposit itself — from 50 USDT, the bonus cap is 100 USDT), to the invited +0.1 % to the rate for 3 days. Honestly: it is not paid now — it is launched only by a separate operator action, and the boost window of the invited is deployed incorrectly in the code. This amount cannot be promised.

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

The steps are described, but cashback does not have a money engine. The configuration specifies four levels according to the number of active lines: 0 → 20%, 5 → 30%, 15 → 50%, 30 → 60% (the latter has 50% of its lines plus 10% of the second level), in the historical configuration the T+1 calculation was mentioned. There are no entries in the code that pay this interest, which means cashback as a payment does not exist now, and you should not wait for it.

Check: payments/pyramid/plans.cjs:196-208 · docs/product-math.md:140-154 (directly: “there is no cashback money engine in the code”) · the “Team” section in the cabinet

2.5 % of the month's revenue (250 bpm) goes to the monthly budget, and it is distributed among DIAMOND rank participants in proportion to the subtree volume (BV). BV is not a currency but a conditional volume for ranks: it is calculated from the sum of entries and the tier multiplier. Residual cents are distributed by the largest shares. A month without recipients remains entirely undistributed.

The rank threshold: 2,000,000 BV of the subtree. A scale reference (example): the top tier T11 on 100,000 USDT gives 250,000 BV — eight such entries close the threshold.

Check: payments/pyramid/global-pool.cjs (POOL_BPS = 250) · payments/pyramid/plans.cjs:581-599 (RANK_VOLUME_BV.diamond, BV_FACTOR_HUNDREDTHS.vip) · the “Global Pool · DIAMOND” block in the “Team” section

Third parties have nothing. Verified by the browser, not as promised: crawling 13 pages over the network resulted in 0 requests to foreign hosts; There are no third-party cookies, analytics, pixels or external captcha; fonts and libraries are in the repository; captcha - its own, on the HMAC token. Referer is not sent when following an external link. In the browser: nine localStorage entries - language selection, theme, animation pause, hidden “Getting Started” block, saved calculator scripts (data entered by the person himself) and a local outline portfolio. No key is a visitor identifier. The only record associated with a person is the session cookie velar_session: HttpOnly (not available to scripts), SameSite=Lax, lasts 30 minutes of downtime and no longer than 14 days. On the server: the platform server does not keep an access log at all - neither the method, nor the path, nor the address, nor the User-Agent are written; in the nginx combat circuit, it was switched to access_log off. The raw IP is not stored: the only place where the address is involved is the HMAC registration fingerprint with the key in the file with rights 0600 (without the key, the digest is not searched). The HMAC fingerprint now expires indefinitely - this is a recognized flaw, recorded as REQUEST S3. The only device feature included in the profile: time zone. The page reads the browser zone and substitutes it into the required profile field, the value is stored on the server and used for “quiet hours”. The visitor is not asked about this - the audit suggests making the choice explicit (find F12, REQUEST S11).

Check: docs/privacy-audit.md §1 (browser), §2 (server), §3 (external requests — “domain list: empty”), §6 (fingerprint) · machine check — node --test tests/ds-privacy-traces.test.cjs

Three layers, all active now.

— Withdrawal password: a separate secret, not the login password. Minimum 8 characters. Without it no request is created: the server returns withdraw_password_required (403).

— Address lock: the wallet address is taken from the profile when the request is created and frozen in it; changing the address in settings does not alter an existing request.

— Session limits: 30 minutes idle and 14 days absolute for the customer; 8 and 12 hours for the operator.

Passwords are stored as salted scrypt hashes, the session token only as a sha256 digest. TOTP 2FA exists in the API but not in the interface.

Check: payments/pyramid/engine.cjs:1293,1320-1404 · payments/auth/service.cjs:25 · docs/privacy-audit.md §2.5 · the “Settings” section → “Withdrawal security”

Recovery works without email. Enter your address on the "Forgot password?" screen: if Telegram is linked, the code is sent there; otherwise an operator ticket is created with a 4-hour response target. The platform has no email delivery and this screen never promises one. Never share passwords or codes in chat.

Check: payments/auth/recovery.cjs:1-32 · payments/server.cjs:1004-1040 (request queue, replies, action audit) · dist/support.html

2FA via TOTP exists in the API but not in the interface: you cannot enable it yourself. Login is protected by the password, the withdrawal password and a short session.

The TOTP/HOTP module is written and covered by tests, but there is no customer route to enable it. A code from the app will not help with account recovery: recovery goes through Telegram or an operator.

Check: payments/auth/totp.cjs · payments/server.cjs:1496-1519 (login accepts totp; there is no customer route to enable it)

The platform has neither a rate oracle nor a conversion factor: all amounts and calculations are carried out in USDT as a 1:1 accounting unit. A separate rule for rate deviation has not been published - neither how the platform recalculates obligations, nor how to compensate for the discrepancy. This means that the exchange rate difference remains with you, and no one can promise “there are always the same dollars in USDT.” The peg risk disclosure is posted on the risk page and is based on an external source, the Ethereum Foundation treasury policy.

Check: dist/legal-risk.html (the peg section, a link to an external source) · payments/config/networks.cjs — the unit and decimals of the tokens

The platform does not publish any tax procedures, nor certificates or statements for the tax office: the legal entity of the operator in the draft conditions is not filled in - there is an empty substitution in the text instead of details (find F9 in the privacy audit), and the document itself is marked as a draft, which is not a valid agreement. Tax calculation depends on your jurisdiction and status - please check individually, the platform does not withhold or advise anything here.

Check: dist/legal-terms.html (the “Draft” header, §1) · docs/privacy-audit.md §5, F9

There is no published list of countries: the jurisdiction of the operator is not defined in the draft conditions. In fact, restrictions by region today do not affect anything, because the actual acceptance of funds is completely closed: 41 readiness points are not closed, not a single one is closed, the platform mode is available to everyone without payment data.

Check: dist/legal-terms.html (the applicable law section) · payments/config/gates.cjs:20-70

There is no deletion procedure in the interface. The draft terms directly state that the procedure for restoring access and deleting an account requires a separate description - that is, there is nothing to promise “we will delete in 30 days.” The storage periods for data in the code are announced approximately (5 years for financial and AML records) and all have the “not confirmed by a lawyer” mark. What you can do now: delete local data yourself (browser settings - clearing site data will remove localStorage records for this domain) and write to support with a request for analysis. Changing the password and revoking all sessions is possible only by changing the account secret.

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

What's available to you right now: - in the account - “Transaction history” (a journal of transactions with types and amounts) and “My report for the period”; — positions by epochs personally — GET /api/me/epochs (session required); — publicly, without logging in — GET /api/epochs/history?limit=30 returns the same epoch aggregates as shown on the /epochs page: pool, revenue, distributed, coverage, retention, hash of each epoch; - mode summary - GET /api/public/stats (environment field). Accounting internally is structured as a double entry: each operation is a debit/credit posting, epoch records have a refId of the form E-index, and the operator’s action log is append-only with a hash chain. What is not yet available: a custom way to reconcile your personal transactions independently - there is no provision for opening your own journal in machine form.

Check: payments/ledger/ledger.cjs · payments/admin/audit.cjs · /epochs, the “Protocol operation history and public routes” block

Requests go through the account, in the “Support” section: they enter the staff queue and the answer appears in the same thread. The first response is within 4 business hours; the status is in “My requests”.

This is text correspondence, not a real-time chat; there is no phone line and no external messengers — the site makes no external requests.

Priority of response does not speed up financial execution, and continued support requires no new top-up. Never send passwords, confirmation codes, seed phrases or passport data in the thread.

Check: dist/support.html · payments/ops/service.cjs (request queue, replies, action audit) · docs/privacy-audit.md §3