Հարցեր ու պատասխաններ

Պլատֆորմի ռեժիմը միակ հասանելի ռեժիմն է. բոլոր գումարները վիրտուալ են: Վճարման հարցումը պահում է գումարը հաշվում և չի անցնում առցանց. հարցումն ունի կատարման եղանակ՝ «ավազարկղ»: Ընթացիկ ռեժիմում ավանդներ և վճարումներ չեն կատարվում բլոկչեյնին. իրական փոխանցումները չպետք է ուղարկվեն: Իրական գործառնությունների մեկնարկը «շուտով» չէ, այլ փակված է պայմանների պատճառով. 41 պատրաստի տարր pays/config/gates.cjs-ում, որոնցից ոչ մեկը չի արել. 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-ի համար սա հարկ է (160 × 250 ÷ 10,000) = 4 ցենտ օրական: Այստեղ չկան արտաքին վճարումներ, միջնորդավճարներ հաճախորդին կամ վճարումներ «ապահովագրված իրադարձության համար»: Ինչու ոչ ապահովագրություն. պահուստը ֆոնդ չէ և փոխհատուցման իրավունք չի տալիս։ Այն մնում է ներքին արձանագրային հաշիվ և չունի պայմանագիր, ստացող կամ վճարման իրադարձություն: Խանութի ցուցափեղկը բացահայտորեն նշում է ծածկույթի ցուցանիշը որպես «ոչ ապահովագրական ծածկույթ»: Որտեղ դա տեսանելի է մաթեմատիկայում՝ COVER-ը ընդհանրապես չի մասնակցում դարաշրջանային բաշխմանը և չի նվազեցնում դիրքի բաժինը։ Հարթ միացումում սա ներքին թարգմանություն է, ուստի մոդելի բեռը հաշվարկվում է որպես տոկոս + կասկադ + COVER: Միակ բանը, որ փոխվում է ձեզ համար. եթե գանձապետական ​​ծածկույթը (միջոցներ ÷ պարտավորություններ) ընկնում է 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 · «Հետգնման պայմաններ» կոճակը ավանդների ցանկում

Դուք կարող եք. - հասանելի հաշիվ - հաշվեգրված տոկոսներ և բոնուսներ (օրենսգրքում սա դիմում է ձևի` «տոկոս»); — ավանդային մարմին — փակման դիմում (տեսակ՝ «հիմնական»)՝ ժամանակացույցից շուտ փուլային հանձնաժողովի հետ՝ առանց միջնորդավճարի ժամկետի: Դուք չեք կարող. — մեկնարկային 3 000 վիրտուալ USDT-ն մեկնարկային մնացորդն է, այն չի փոխանակվում իրական փողի հետ. - «հանեք մարմինը և թողեք տոկոսները» մեկ կոճակով. սրանք երկու տարբեր խնդրանքներ են. — ստանալ ինչ-որ բան բլոկչեյնում, մինչ հարթակը պլատֆորմի ռեժիմում է. փոխանցումը ֆիզիկապես չի կատարվում: Ցանցի միջնորդավճարը կազմում է 1 USDT (100 ցենտ) և հանվում է հայտի գումարից: Մեկ ավանդի ընթացքում մարմնի համար կարող է լինել միայն մեկ ակտիվ հարցում. երկրորդը ստանում է deposit_locked, ուստի մարմնի կրկնակի ամրագրումն անհնար է:

Ստուգեք. payments/pyramid/engine.cjs:1320-1404 · payments/pyramid/plans.cjs:227-233 · «Վճարումներ» ներդիրը → «Հասանելի»

Հավելվածն անմիջապես վերապահում է գումարը. գումարը հաճախորդի հաշվից գնում է սպասող հաշիվ (հեռացում_պահուստ) նույնիսկ մինչև օպերատորի որոշումը: Եթե ​​հայտը մերժվում է, պահուստը հետ է վերադարձվում։ Ցանկացած գումարի համար կա մեկ երթուղի. չկա ավտոմատ երթուղի (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 կամ այս հասցեի որևէ այլ նշան չի վերածվում մնացորդի: Տարբեր ցանցերի հասցեները տարբեր հասցեներ են. առաջին կերպարների համընկնումը ոչինչ չի նշանակում: Ինչ անել. մի ուղարկեք երկրորդ գումարը և կապվեք աջակցության էջի միջոցով՝ նշելով գործարքի ID-ն: Սխալ փոխանցման վերադարձը առանձին ընթացակարգ է. հարթակի ռեժիմում հարցը լուծվում է առանց իրական միջոցների շարժի:

Ստուգեք. 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-ը վերին սահման է, ոչ խոստացված գումար։ Որպեսզի աստիճանը աշխատի, հրավիրվածի ավանդը պետք է ապրի աստիճանի hold-ը՝ համապատասխանաբար 14, 30, 60, 90 և 120 օր։ Վճարումը իդեմպոտենտ է. նույն աստիճանով կրկնակի գործարկումը երկրորդ անգամ չի վճարում։

Welcome-բոնուսը հայտարարված է երկկողմ՝ հրավիրողին՝ առաջին ավանդի 2 %-ը (ավանդն ինքը՝ 50 USDT-ից, բոնուսի առաստաղը՝ 100 USDT), հրավիրվածին՝ +0,1 % դրույքին 3 օրով։ Ազնվորեն՝ այն հիմա չի վճարվում. այն գործարկում է միայն օպերատորի առանձին գործողությունը, իսկ հրավիրվածի boost-պատուհանը կոդում սխալ է բացված։ Այս գումարը խոստանալ չի կարելի։

Ստուգեք. payments/pyramid/plans.cjs:120-149 · docs/product-math.md:114-138,289-302 · payments/pyramid/engine.cjs:838-843

Քայլերը նկարագրված են, բայց cashback-ը փողի շարժիչ չունի։ Կոնֆիգուրացիան ըստ ակտիվ գծերի քանակի սահմանում է չորս մակարդակ՝ 0 → 20%, 5 → 30%, 15 → 50%, 30 → 60% (վերջինս ունի իր տողերի 50%-ը գումարած երկրորդ մակարդակի 10%-ը), պատմական կոնֆիգուրացիայի մեջ նշվել է T+1 հաշվարկը։ Կոդում չկան գրառումներ, որոնք վճարում են այս տոկոսը, ինչը նշանակում է, որ cashback-ը որպես վճարում այժմ գոյություն չունի, և դուք չպետք է սպասեք դրան:

Ստուգեք. payments/pyramid/plans.cjs:196-208 · docs/product-math.md:140-154 (ուղիղ՝ «կոդում cashback-ի դրամական շարժիչ չկա») · «Թիմ» բաժինը կաբինետում

Ամսվա բյուջե գնում է ամսվա հասույթի 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 հարցում օտարերկրյա հոսթներին; Չկան երրորդ կողմի թխուկներ, վերլուծություններ, պիքսելներ կամ արտաքին captcha; տառատեսակները և գրադարանները գտնվում են պահեստում. captcha - իր սեփական, HMAC նշանի վրա: Արտաքին հղմանը հետևելիս հղում չի ուղարկվում: Բրաուզերում՝ ինը localStorage գրառում՝ լեզվի ընտրություն, թեմա, անիմացիայի դադար, թաքնված «Սկսել» բլոկ, պահված հաշվիչի սցենարներ (անձի կողմից մուտքագրված տվյալներ) և տեղական ուրվագծային պորտֆոլիո: Ոչ մի բանալի այցելուի նույնացուցիչ չէ: Անձի հետ կապված միակ գրառումը նիստի cookie-ն է velar_session. HttpOnly (հասանելի չէ սկրիպտների համար), SameSite=Lax, տևում է 30 րոպե ընդմիջում և ոչ ավելի, քան 14 օր: Սերվերի վրա. արտադրանքի սերվերն ընդհանրապես մուտքի մատյան չի պահում. գրված չեն ոչ մեթոդը, ոչ ուղին, ոչ հասցեն, ոչ էլ User-Agent-ը. nginx մարտական ​​սխեմայում այն ​​միացված էր access_log off-ին: Չմշակված IP-ն չի պահվում. միակ վայրը, որտեղ հասցեն ներգրավված է, HMAC գրանցման մատնահետքն է՝ 0600 իրավունքով ֆայլի բանալիով (առանց բանալիի, digest-ը չի որոնվում): 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-դայջեստ։ TOTP-ով 2FA կա 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 հիմնադրամի գանձապետական քաղաքականության վրա:

Ստուգեք. 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 (շրջակա միջավայրի դաշտ): Ներքին հաշվառումը կառուցված է որպես կրկնակի մուտք. յուրաքանչյուր գործողություն դեբետային/վարկային գրառում է, դարաշրջանի գրառումներն ունեն E-ինդեքսի ձևի refId, և օպերատորի գործողությունների մատյանը կցվում է միայն հեշ շղթայով: Այն, ինչ դեռ հասանելի չէ. ձեր անձնական գործարքները ինքնուրույն հաշտեցնելու սովորական եղանակ. չկա ձեր սեփական ամսագիրը մեքենայական ձևով բացելու դրույթ:

Ստուգեք. payments/ledger/ledger.cjs · payments/admin/audit.cjs · /epochs, «Պրոտոկոլի գործողությունների պատմություն և հանրային երթուղիներ» բլոկը

Դիմումը՝ կաբինետի «Աջակցություն» բաժնով. այն ընկնում է աշխատակիցների հերթը, պատասխանը հայտնվում է նույն երկխոսության մեջ։ Առաջին պատասխանը՝ մինչև 4 աշխատանքային ժամ. կարգավիճակը՝ «Իմ դիմումները» բաժնում։

Սա տեքստային նամակագրություն է, ոչ իրական ժամանակի չատ. հեռախոս և արտաքին մեսենջերներ չկան — կայքում ոչ մի արտաքին հարցում չկա։

Պատասխանի առաջնահերթությունը չի արագացնում ֆինանսական կատարումը, և աջակցության շարունակությունը նոր համալրում չի պահանջում։ Նամակագրության մեջ մի՛ ուղարկեք գաղտնաբառեր, հաստատման կոդեր, seed-արտահայտություններ և անձնագրային տվյալներ։

Ստուգեք. dist/support.html · payments/ops/service.cjs (դիմումների հերթ, պատասխաններ, գործողությունների աուդիտ) · docs/privacy-audit.md §3