კითხვები და პასუხები

პლატფორმის რეჟიმი ერთადერთი ხელმისაწვდომი რეჟიმია: ყველა თანხა ვირტუალურია. გადახდის მოთხოვნა იტოვებს თანხას ანგარიშში და არ გადადის ონლაინ: მოთხოვნას აქვს executionMode: 'sandbox'. მიმდინარე რეჟიმში დეპოზიტები და გადახდები არ ხდება ბლოკჩეინში - არ უნდა გაიგზავნოს რეალური გადარიცხვები. რეალური ოპერაციების დაწყება არ არის „მალე“, მაგრამ დახურულია პირობების გამო: 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 ცენტი) და გამოიქვითება განაცხადის თანხიდან. ერთი დეპოზიტის ფარგლებში შეიძლება იყოს მხოლოდ ერთი აქტიური მოთხოვნა სხეულის შესახებ: მეორე იღებს depozit_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 ან ამ მისამართის ნებისმიერი სხვა ნიშანი არ იქცევა ბალანსად. მისამართები სხვადასხვა ქსელში არის სხვადასხვა მისამართები; პირველი პერსონაჟების დამთხვევა არაფერს ნიშნავს. რა უნდა გააკეთოთ: არ გაგზავნოთ მეორე თანხა და დაუკავშირდით მხარდაჭერის გვერდის მეშვეობით, ტრანზაქციის 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

ნაბიჯები აღწერილია, მაგრამ ქეშბექს არ აქვს ფულის ძრავა. კონფიგურაცია განსაზღვრავს ოთხ დონეს აქტიური ხაზების რაოდენობის მიხედვით: 0 → 20%, 5 → 30%, 15 → 50%, 30 → 60% (ამ უკანასკნელს აქვს ხაზების 50% პლუს მეორე დონის 10%), ისტორიულ კონფიგურაციაში იყო ნახსენები T+1 გაანგარიშება. კოდში არ არის ჩანაწერები, რომლებიც იხდიან ამ პროცენტს, რაც ნიშნავს, რომ ქეშბექი, როგორც გადახდა ახლა არ არსებობს და თქვენ არ უნდა დაელოდოთ მას.

შეამოწმეთ: 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 ჩანაწერი - ენის შერჩევა, თემა, ანიმაციის პაუზა, დამალული ბლოკი "დაწყება", შენახული კალკულატორის სკრიპტები (მონაცემები, რომლებიც შეყვანილია თავად პირის მიერ) და ადგილობრივი მონახაზის პორტფოლიო. არცერთი გასაღები არ არის ვიზიტორის იდენტიფიკატორი. ადამიანთან დაკავშირებული ერთადერთი ჩანაწერი არის სესიის ქუქი-ფაილი 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-დაიჯესტად. 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-index ფორმის refId და ოპერატორის ქმედებების ჟურნალი დართულია მხოლოდ ჰეშის ჯაჭვით. რაც ჯერ არ არის ხელმისაწვდომი: თქვენი პირადი ტრანზაქციების დამოუკიდებლად შეჯერების ჩვეული გზა - არ არსებობს დებულება მანქანური სახით საკუთარი ჟურნალის გახსნისთვის.

შეამოწმეთ: payments/ledger/ledger.cjs · payments/admin/audit.cjs · /epochs, ბლოკი „პროტოკოლის ოპერაციების ისტორია და საჯარო მარშრუტები“

მიმართვა — კაბინეტის «მხარდაჭერა» განყოფილებით: ის თანამშრომლების რიგში ხვდება, პასუხი იმავე დიალოგში ჩნდება. პირველი პასუხი — 4 სამუშაო საათამდე; სტატუსი — «ჩემი მიმართვები» განყოფილებაში.

ეს ტექსტური მიმოწერაა და არა რეალურ დროში ჩატი; ტელეფონი და გარე მესენჯერები არ არის — საიტზე არც ერთი გარე მოთხოვნა არ არის.

პასუხის პრიორიტეტი არ აჩქარებს ფინანსურ შესრულებას და მხარდაჭერის გაგრძელება ახალ შევსებას არ მოითხოვს. მიმოწერაში არ გაგზავნოთ პაროლები, დადასტურების კოდები, seed-ფრაზები და პასპორტის მონაცემები.

შეამოწმეთ: dist/support.html · payments/ops/service.cjs (მიმართვების რიგი, პასუხები, ქმედებების აუდიტი) · docs/privacy-audit.md §3