Kripto səhv şəbəkəyə göndərilibsə ilk yoxlama nədir?

Kriptoaktiv səhv şəbəkəyə göndərilibsə, ilk məqsəd “geri qaytarma xidməti” tapmaq deyil. Əvvəl əməliyyatın həqiqətən hansı blokçeyndə baş verdiyini, uğurlu olub-olmadığını və qəbul ünvanının açarını kimin idarə etdiyini müəyyən etmək lazımdır. Bu üç fakt olmadan verilən hər hansı uğur faizi və ya bərpa vədi təxmindən ibarətdir.

Yeni köçürmə etməyin, “hesabı aktivləşdirmək” üçün əlavə token göndərməyin və Telegram, WhatsApp və ya Instagram-da sizə ilk yazan “dəstək əməkdaşına” ödəniş etməyin. Bu bələdçi yalnız açıq blokçeyn sübutlarını toplamağa və düzgün rəsmi kanala təqdim etməyə kömək edir. Heç bir mərhələdə seed phrase, private key, birdəfəlik giriş kodu və ya uzaqdan cihaz idarəsi tələb olunmur; sayt vəsaitin mütləq qaytarılacağını iddia etmir.

İlk on dəqiqədə nə etmək lazımdır?

Panikada edilən ikinci əməliyyat hadisəni daha da çətinləşdirə bilər. Aşağıdakı məlumatları bir sənəddə toplayın və orijinal ekranları silməyin:

1. aktivin adı və miqdarı;
2. göndərən pulqabı və ya platforma;
3. çıxarışda seçilmiş tam şəbəkə adı;
4. qəbul tərəfinin gözlədiyi şəbəkə;
5. qəbul ünvanı;
6. tam TxID və ya Solana signature;
7. tarix, saat və platforma əməliyyat nömrəsi;
8. göndərən və qəbul edən interfeysdə görünən status.

Hadisəni hansı dörd kateqoriyaya bölmək olar?

Kateqoriya	Açıq zəncir nəticəsi	Növbəti əsas sual
Hələ yayımlanmayıb	Etibarlı TxID yoxdur	Göndərən xidmət əməliyyatı zəncirə veribmi?
Uğursuz əməliyyat	Failed, reverted və ya uyğun xəta görünür	Aktiv ilkin ünvanın nəzarətindədirmi?
Şəxsi açarla idarə olunan ünvana uğurlu köçürmə	Faktiki şəbəkədə success	Pulqabı həmin şəbəkəni təhlükəsiz aça bilirmi?
Platforma və ya naməlum ünvana uğurlu köçürmə	Faktiki şəbəkədə success	Ünvan sahibi bu şəbəkəni dəstəkləyir və araşdıra bilirmi?

“Balansımda görünmür” ayrıca kateqoriya deyil. Bu, pulqabı interfeysinin tokeni göstərməməsi, platformanın kreditləşməni gecikdirməsi, minimum depozit, çatışmayan Memo/Tag və ya həqiqətən səhv şəbəkə kimi müxtəlif səbəblərin əlamətidir.

Azərbaycandilli istifadəçiləri hədəfləyən fırıldaq siqnalları hansılardır?

Fırıldaqçı sizin TxID-nizi blokçeyn brauzerindən oxuyaraq məbləği, vaxtı və ünvanı düzgün deyə bilər. Bu məlumat açıqdır və onun platformada işlədiyini sübut etmir. “Bakı ofisi”, yerli telefon nömrəsi, Azərbaycan dilində səlis yazı və bank kartı hesabı da texniki nəzarətin sübutu deyil.

Aşağıdakı ifadələr yüksək risk siqnalıdır: “100% geri qaytarırıq”, “validator vergisi”, “unlock fee”, “sığorta depoziti”, “wallet synchronization”, “node-a seed yazın”, “bu gün ödəməsəniz əməliyyat silinəcək”. Blokçeyn brauzerinin ekran görüntüsü və saxta admin paneli heç bir açarı idarə etməyə imkan vermir.

Rəsmi platforma işçisi adətən sosial şəbəkədə ilk olaraq şəxsi mesajla yazmır və aktivin qaytarılması üçün başqa şəxsi ünvana kripto tələb etmir. Şübhə varsa söhbəti bağlayın, rəsmi tətbiqi ayrıca açın və ticket nömrəsini orada yoxlayın.

Faktiki şəbəkə necə müəyyən edilir?

Çıxarış tarixçəsindəki tam şəbəkə adı və TxID əsas başlanğıcdır. Eyni token loqosu bir neçə şəbəkədə göstərilə bilər. “USDT göndərmişəm” demək hansı ledger-dən istifadə edildiyini açıqlamır. TRON, Ethereum, BNB Smart Chain, Bitcoin və Solana hərəsi öz açıq məlumat mənbəyinə sahibdir.

EVM uyğun şəbəkələrdə ünvanlar və hash-lər oxşar görünür. 0x ilə başlayan ünvanı görüb avtomatik Ethereum nəticəsinə gəlməyin. Eyni TxID-ni ehtimal olunan brauzerlərdə yoxlayın və yalnız aşağıdakılar birlikdə uyğun gəldikdə nəticəni qəbul edin:

• göndərən və qəbul ünvanı;
• aktivin token müqaviləsi;
• miqdar və decimal çevirməsi;
• əməliyyat vaxtı;
• status və blok nömrəsi.

TRON ünvanının T ilə başlaması və Solana ünvanının base58 simvollardan ibarət olması faydalı işarədir, lakin göndərmə qeydi olmadan yekun sübut deyil. Ünvan formatı şəbəkəni daralda bilər, əməliyyat səhifəsi isə konkret hadisəni göstərir.

Ən mühüm sual: qəbul ünvanını kim idarə edir?

Blokçeyndə uğurlu əməliyyatı miner, validator və ya brauzer geri çevirmir. Praktik imkan qəbul ünvanının açarına nəzarətdən asılıdır. Ünvan üç qrupdan birinə düşür:

Ünvan sizin şəxsi pulqabınızdadır

Pulqabını əvvəldən siz yaratmısınız və açar sizin nəzarətinizdədir. Faktiki şəbəkəni etibarlı pulqabıda açmaq, eyni ünvanı görmək və rəsmi token müqaviləsini əlavə etmək mümkün ola bilər. Bu, “geri qaytarma” deyil; aktiv əvvəldən həmin ledger-də sizin ünvanınızdadır, sadəcə interfeys onu göstərməyə bilər.

Ünvan platforma və ya xidmətə məxsusdur

Private key sizdə deyil. Platformanın şəbəkəni texniki olaraq oxuya bilməsi, həmin tokeni dəstəkləməsi və əl ilə kreditləşdirmə siyasəti yalnız onun rəsmi komandası tərəfindən qiymətləndirilir. İstifadəçi platforma backend-ində şəbəkə əlavə edə bilməz.

Ünvanın sahibi bilinmir və ya səhv yazılıb

Əməliyyat uğurludursa və ünvanı idarə edən məlum şəxs yoxdursa, üçüncü tərəfin onu geri çəkməsi üçün normal funksiya yoxdur. “Validatorla danışacağam” və ya “daxili panelim var” deyən şəxsin ünvanı imzalamaq səlahiyyəti sübut olunmur.

Nəzarəti sübut etmək üçün seed phrase paylaşmaq lazım deyil. Şəxsi pulqabıda eyni ünvanı görmək, rəsmi tətbiqdə təhlükəsiz mesaj imzalama üsulu və ya platformanın rəsmi hesab təsdiqi kifayət edə bilər.

Platforma ünvanına göndərilibsə rəsmi sorğu necə yazılır?

Yalnız platformanın tətbiqi daxilindən və ya ünvanını özünüz yazdığınız rəsmi domendən support bölməsini açın. Azərbaycan, türk, rus və ya ingilis dilində cavab verən sosial media hesabının loqosu onun rəsmi olduğunu sübut etmir. Platformanın profilindəki istifadəçi adını kopyalayan saxta hesablar xüsusilə “səhv şəbəkə” sözlərini axtaran istifadəçilərə yaza bilər.

Sorğunun mövzusunu konkret edin: “Unsupported network deposit review” və ya platformanın istifadə etdiyi uyğun kateqoriya. Mətnə bunları əlavə edin:

• hesab identifikatoru və rəsmi ticket nömrəsi;
• aktiv, məbləğ və token müqaviləsi;
• faktiki göndərmə şəbəkəsi;
• depozit üçün seçilməli olan şəbəkə;
• tam ünvan və TxID;
• blok vaxtı və success nəticəsi;
• göndərən platformanın çıxarış qeydi;
• əvvəl etdiyiniz əlavə əməliyyatlar varsa onların TxID-ləri.

“Pulumu qaytarın” kimi ümumi mesaj əvəzinə bu faktlar texniki komandaya ünvan nəzarətini və dəstəyi qiymətləndirməyə imkan verir. Platforma xidmət haqqı, minimum məbləğ, uzun emal müddəti və ya ümumiyyətlə imtina tətbiq edə bilər. Bu sayt həmin qərarın nə olacağını qabaqcadan vəd etmir.

Dörd praktik ssenaridə nəticə necə yazılır?

TxID yoxdur, platforma “completed” göstərir

Nəticə: açıq zəncir yayımı hələ sübut olunmayıb. Göndərən platformadan tam TxID və faktiki şəbəkə tələb olunur. Alıcıya təkrar ödəniş etmək üçün əsas yoxdur.

BSC-də success görünür, ünvan şəxsi EVM pulqabısıdır

Nəticə: eyni ünvanı etibarlı pulqabıda BNB Smart Chain üzərində açmaq və rəsmi token müqaviləsini yoxlamaq lazımdır. Yeni hərəkət üçün BNB tələb oluna bilər. Seed heç kimə verilmir.

TRON-da success görünür, ünvan platforma depozitidir

Nəticə: ünvanın açarı platformadadır. TxID, TRC20 müqaviləsi və hesab məlumatı rəsmi ticket-ə verilir. Kreditləşdirmənin mümkünlüyünü yalnız platforma qiymətləndirə bilər.

Ünvan bir simvol səhvdir və sahibi bilinmir

Nəticə: əməliyyat uğurlu olduqda validator onu geri çevirmir. Clipboard zərərvericisi ehtimalı yoxlanır, sübutlar saxlanılır və zəmanətli bərpa vədinə pul verilmir.

Hadisə bağlanmazdan əvvəl yoxlama siyahısı

• Faktiki şəbəkə və tam TxID müəyyən edilib.
• Blokçeyn statusu, from, to, müqavilə və məbləğ tutuşdurulub.
• Ünvanın şəxsi pulqabı, platforma və ya naməlum nəzarətdə olduğu müəyyən edilib.
• Memo/Tag məsələsi şəbəkə səhvindən ayrılıb.
• Yalnız rəsmi support kanalında ticket açılıb.
• Heç bir məxfi açar, giriş kodu və uzaqdan idarə icazəsi paylaşılmayıb.
• Hadisədən sonra göndərilən hər əlavə əməliyyat ayrıca qeydə alınıb.
• “Mümkündür”, “yalnız platforma qiymətləndirə bilər” və “normal texniki yol görünmür” nəticələri bir-birindən ayrılıb.

Yaxşı diaqnostikanın sonu vəd deyil, yoxlanıla bilən cümlədir: “Əməliyyat Ethereum-da uğurludur, ünvan mənim nəzarətimdədir və tokeni həmin şəbəkədə görə bilirəm” və ya “Əməliyyat Solana-da uğurludur, ünvan platformanındır və rəsmi ticket araşdırılır.” Bu cümləni yaza bilmirsinizsə, hələ hərəkət yox, məlumat toplama mərhələsindəsiniz.

Rəsmi dəstəyə nə vermək olar, nəyi vermək olmaz?

Açıq TxID, ünvan, şəbəkə, token müqaviləsi, məbləğ, tarix, platforma order ID-si və ticket nömrəsi araşdırma üçün verilə bilər. Şəxsiyyət yoxlaması tələb olunursa, sənədi yalnız hesab daxilindəki rəsmi yükləmə kanalına təqdim edin. Ekran görüntüsündə hadisə ilə əlaqəsiz e-poçt, telefon, şəxsiyyət nömrəsi və digər balansları gizlədin.

Heç vaxt bunları paylaşmayın:

• 12/24 sözlük seed phrase;
• private key və ya keystore parolu;
• hardware wallet PIN-i;
• SMS, e-poçt və authenticator kodu;
• API secret;
• ekran paylaşımı və uzaqdan idarəetmə icazəsi;
• izahını anlamadığınız token approval imzası.

Ünvan nəzarətinin sübutu lazım olsa, platforma konkret mesaj imzası və ya kiçik doğrulama əməliyyatı barədə rəsmi təlimat verə bilər. Bu, açarın mətnini göndərməkdən tamamilə fərqlidir.

İlk 15 dəqiqədə dəyişməz sübutları saxlayın

Withdrawal order ID, göndərən platformanın seçdiyi network, recipient, aktiv, gross məbləğ, fee, net məbləğ, vaxt və göstərilən TxID screenshot və mətn kimi saxlanır. Qəbul edən tərəfin həmin anda göstərdiyi deposit network, ünvan, Memo və minimum qaydası da qeyd edilir.

Heç nəyi “düzəltmək” üçün ikinci transfer göndərməyin. İlk transaction-un public vəziyyəti, recipient nəzarəti və platformaların recovery imkanları bilinmədən yeni əməliyyat sübut zəncirini qarışdırır və itkini ikiqat edə bilər.

TxID ilə faktiki mənbə chain-i müəyyən edin

Hash formatı ipucu versə də qəti chain deyil. Withdrawal detail-də explorer keçidi, network etiketi, fee aktivi və platforma support cavabı birlikdə istifadə olunur. Eyni 0x recipient Ethereum, BSC və başqa EVM chain-lərdə görünə bilər.

Transaction doğru explorer-də tapıldıqda block, status, sender, recipient event-i, token contract və amount yazılır. Tapılmırsa order ID-ni TxID kimi istifadə edib-etmədiyinizi və platformanın hələ broadcast edib-etmədiyini yoxlayın.

Gözlənilən destination chain-i sübut edin

Recipient platformanın depozit səhifəsində seçilən network əsasdır. İstifadəçi sadəcə token adını görüb hansı şəbəkəni seçdiyini unuda bilər. Screenshot, address prefix, Memo qaydası və platformanın hesab daxilindəki məlumatı bu seçimi bərpa edir.

Köhnə address book və ya başqa istifadəçinin depozit ünvanı sübut deyil. Platforma eyni ünvanı bir neçə EVM chain üçün göstərə bilər, amma hər chain və token üçün ayrı dəstək siyasəti saxlayır.

Ünvan private key-i sizdədirsə

Şəxsi EVM wallet-ə yanlış EVM chain-də göndərişdə eyni private key çox vaxt eyni 0x ünvanı idarə edir. Əvvəl wallet-in həmin chain-i təhlükəsiz şəkildə göstərib-göstərmədiyini və token contract-ı yoxlayın. Aktiv “itmiş” deyil, başqa ledger-də ola bilər.

Tokeni hərəkət etdirmək üçün həmin chain-də native Gas lazımdır. Etibarlı mənbədən kiçik fee aktivi təmin edilir, recipient və contract yenidən yoxlanır. Seed-i naməlum multi-chain saytına import etmək lazım deyil.

Ünvan custodial platformaya aiddirsə

İstifadəçi platformanın depozit ünvanının private key-inə sahib deyil. Eyni address səhv chain-də aktiv göstərsə belə onu özü bridge və ya geri göndərə bilməz. Recovery yalnız platforma həmin chain-də açara nəzarət edirsə və əməliyyat siyasəti icazə verirsə mümkündür.

Ticket-ə source chain TxID-si, event recipient, contract, amount, nəzərdə tutulan deposit network və hesab ownership sübutu verilir. Platformanın “dəstəklənməyən chain” cavabı texniki və siyasət səbəblərini əhatə edə bilər; kənar validator bunu ləğv etmir.

EVM-dən EVM-ə səhv göndəriş

Ethereum əvəzinə BSC, Polygon, Arbitrum və ya başqa EVM chain seçilibsə, chain ID, token contract və native fee ayrı yoxlanır. Eyni address formatı recovery ehtimalını artıra bilər, amma platformanın hər chain-də eyni wallet infrastrukturu istifadə etdiyinə zəmanət vermir.

Şəxsi wallet ssenarisində aktiv doğru contract ilə görünürsə rəsmi bridge və ya dəstəklənən deposit network seçilə bilər. Hər yeni bridge əməliyyatı ayrıca risk, fee və destination Gas tələb edir; köhnə transferi dəyişmir.

EVM-dən qeyri-EVM ünvana cəhd

Bir çox wallet uyğun olmayan address formatını qəbul etməz. Lakin platforma address-i çevrilmiş, contract və ya memo sahəsində təqdim edibsə mürəkkəb ssenari yarana bilər. Public transaction-un faktiki recipient və calldata-sı decoded şəkildə yoxlanır.

Yanlış format UI tərəfindən bloklanıbsa TxID yaranmaya bilər və aktiv hesabdan çıxmamalıdır. Lokal failed bildirişini explorer və balansla təsdiqləyin. “Səhv ünvanı aktivləşdirmək” üçün kənara ödəniş etməyin.

TRON və EVM ünvan çevrilməsi barədə ehtiyat

TRON və Ethereum ünvanlarının bəzi daxili hexadecimal təsvirləri texniki əlaqə göstərə bilər, amma istifadəçi səviyyəsində avtomatik cross-chain recovery qaydası deyil. T ünvanını təsadüfi converter-də 0x mətninə çevirmək platforma dəstəyini yaratmır.

Private key sizdədirsə belə token hər chain-də ayrıca contract və fee tələb edir. Custodial platforma ssenarisində converter nəticəsi ownership sübutu deyil. Yalnız rəsmi support və public transaction state əsas götürülür.

Memo və network səhvini ayırmaq

Aktiv doğru chain və platforma ünvanına gedib, yalnız Memo boşdursa bu account mapping problemidir. Aktiv yanlış chain-dədirsə Memo düz olsa belə destination ledger səhvdir. Ticket-də bu iki problemi qarışdırmamaq operatorun düzgün recovery prosesini seçməsinə kömək edir.

Memo sonradan on-chain transaction-a əlavə edilə bilməz. Platforma manual credit edə bilər, amma üçüncü tərəfə verification payment göndərmək orijinal event-i dəyişmir. Düzgün Memo və hesab məlumatı yalnız rəsmi kanal vasitəsilə verilir.

Yanlış token contract ssenarisi

Network doğru, recipient doğru ola bilər, lakin saxta və ya dəstəklənməyən contract göndərilib. Bu wrong-network deyil, asset identity problemidir. Explorer event-ində contract, decimals və amount yoxlanır. Eyni simvol və logo etibarlılıq yaratmır.

Platforma həmin contract-ı indeksləmirsə manual sweep mümkünlüyünü qiymətləndirə bilər. Token zərərli transfer məntiqinə malikdirsə platforma təhlükəsizlik səbəbindən recovery etməyə bilər. “Real USDT-yə çevirmə haqqı” istəyən naməlum şəxsə inanmayın.

Bridge istifadə etməzdən əvvəl ownership qərarı

Yalnız source chain-dəki aktivə imza səlahiyyətiniz varsa bridge əməliyyatı edə bilərsiniz. Platforma address-ində görünən tokeni öz wallet-inizdən bridge etmək mümkün deyil. Private key kimdədirsə source transaction-u yalnız o imzalaya bilər.

Şəxsi wallet-də rəsmi bridge domain, source və destination chain, token, minimum, fee, message statusu və claim addımı yoxlanır. Saxta bridge allowance oğurlaya bilər. Kiçik sınaq və hardware wallet ekranı riski azaldır.

Platforma manual recovery qiymətləndirməsi

Platforma açar nəzarəti, node dəstəyi, token contract, sweep xərci, compliance və minimum recovery məbləğini nəzərə alır. Cavab “mümkün”, “mümkün deyil” və ya “gələcəkdə dəstək açılsa baxılacaq” ola bilər. Heç biri əvvəlcədən zəmanət deyil.

Fee və müddət hesab daxilindəki ticket-də yazılı olmalıdır. Sosial mediada rəsmi logo istifadə edən hesabın şəxsi ünvana ödəniş istəməsi etibarlı recovery prosesi deyil. Domain və ticket nömrəsi ayrıca yoxlanır.

Recovery üçün ownership sübutu

Şəxsi wallet göndərişində address-dən konkret mesaj imzası tələb oluna bilər. İmzalanan mətn domain, məqsəd və vaxt baxımından oxunur; transaction və ya approval olmamalıdır. Seed phrase və private key heç vaxt mətn kimi ötürülmür.

Custodial göndərən tərəfdə withdrawal order, hesab tarixçəsi və rəsmi platforma ticket-i ownership sübutudur. Hot wallet private key-i istifadəçidə olmadığı üçün message signature verə bilməməsi normaldır.

Native fee aktivi çatışmırsa

Səhv chain-də şəxsi wallet-ə çatan tokeni hərəkət etdirmək üçün həmin chain-in native coin-i lazımdır. EVM chain-də müvafiq ETH, BNB və ya başqa coin, TRON-da TRX, Solana-da SOL tələb oluna bilər. Başqa chain-dəki eyni adlı aktiv fee ödəmir.

Fee mənbəyi etibarlı və məbləği estimate-ə uyğun kiçik olmalıdır. “Gas açmaq” üçün token approval, owner permission və seed istəyən xidmət dayandırılır. Public address estimate üçün kifayətdir.

Kiçik məbləğdə iqtisadi recovery

Texniki recovery mümkün olsa da Gas, bridge fee, platforma manual haqqı və operator vaxtı aktivdən çox ola bilər. Qərarda tokenin real likvidliyi, contract etibarlılığı və net bərpa məbləği hesablanır. Saxta tokenin ekranda yüksək qiyməti iqtisadi dəyər sübutu deyil.

Platformanın minimum recovery həddi varsa yazılı qayda saxlanır. İstifadəçi kənar agentə əvvəlcədən daha çox pul göndərməklə bu həddi dəyişə bilməz. Risk artımı emosional qərarla deyil, net nəticə ilə ölçülür.

Böyük məbləğdə eskalasiya

Yüksək dəyərli hadisədə ticket fakt cədvəli, hüquqi ownership sənədi və daxili təhlükəsizlik eskalasiyası tələb oluna bilər. Eyni məlumatı çox açıq kanalda paylaşmaq əvəzinə platformanın təhlükəsiz upload yolu istifadə edilir. TxID və public address açıq qala bilər, şəxsiyyət məlumatı məhdud saxlanır.

Şirkət əməliyyatında iki nəfərlik yoxlama və hüquqi məsləhət nəzərdən keçirilə bilər. Heç kimə seed ötürülmür. Recovery transaction-u yaradılarsa yeni hash və authorization qeydi audit sənədinə əlavə olunur.

Saxta support ssenarisini tanımaq

Fırıldaqçı public TxID-dən məbləğ və recipient-i görüb ekspert kimi çıxış edə bilər. “Validator ilə danışırıq”, “chain sync fee”, “AML unlock” və “refund contract” kimi terminlərlə şəxsi ünvana ödəniş istəyə bilər. Public məlumatı bilməsi platforma səlahiyyəti deyil.

Rəsmi support yalnız hesab daxilindəki ticket, doğrulanmış domain və platformanın elan etdiyi kanaldan təsdiqlənir. Remote desktop, seed, 2FA və anlaşılmayan approval tələbi rədd edilir.

Polis və hüquqi bildiriş üçün faktlar

Oğurluq, saxta support və ya clipboard malware ehtimalında TxID, address, domain, mesajlar, ödəniş tələbləri və timestamp-lər dəyişdirilmədən saxlanır. Screenshot-la yanaşı mümkün olduqda original URL və message export qorunur. Məxfi açar sübut paketinə daxil edilmir.

Yerli qaydalara uyğun platforma fraud kanalı və hüquq-mühafizə müraciəti istifadə edilə bilər. Heç bir hüquqi müraciət confirmed transaction-u texniki olaraq geri çevirmir, amma custodial freeze və identifikasiya imkanları vaxtdan asılı ola bilər.

Hadisə jurnalının statusları

Unknown, broadcast, pending, success, failed, wrong chain confirmed, recovery review, recovery approved, swept və credited ayrı statuslardır. Hər dəyişiklik UTC vaxtı və mənbə ilə yazılır. Köhnə status silinmir.

Bu tarixçə platforma cavabı gecikəndə nə vaxt eskalasiya etməli olduğunuzu göstərir. Eyni zamanda ikinci transferin niyə edilmədiyini və hansı sübutun çatışmadığını izah edir.

Recovery nəticəsini yoxlamaq

Platforma aktivin bərpa olunduğunu bildirdikdə yeni sweep hash, hesab kredit ID-si, gross məbləğ, fee və net məbləğ tutuşdurulur. Başqa token və ya yanlış chain balansı nəticə sayılmır. İstifadə edilə bilən status ayrıca təsdiqlənir.

Şəxsi wallet bridge nəticəsində destination hash və doğru token contract yoxlanır. Source tokenin azalması təkbaşına destination uğurunu sübut etmir. Claim tələb olunursa rəsmi status səhifəsində tamamlanır.

Hadisədən sonra proses dəyişikliyi

Address book-da recipient ilə yanaşı chain və aktiv contract qeyd edilir. Platforma deposit səhifəsi hər dəfə yenidən açılır, withdrawal və deposit network-ləri yanaşı yoxlanır. Böyük məbləğdən əvvəl minimuma uyğun sınaq edilir.

Komanda işində ikinci şəxs network, Memo, contract və net məbləği yoxlayır. Hadisə səbəbi təlim nümunəsinə çevrilir, lakin şəxsi hesab və məxfi məlumat çıxarılır. Məqsəd günahlandırma deyil, eyni uyğunsuzluğun təkrarını azaltmaqdır.

Bağlanma qərarı

Aktiv doğru nəzarətə qayıdıb və ya platforma son yazılı qərarı verib, bütün hash-lər və məbləğlər uzlaşdırılıbsa hadisə bağlana bilər. “Araşdırılır” cavabı bağlanma deyil. Texniki mümkünsüzlük qərarı varsa səbəb və tarix saxlanır.

Nəticə recovery uğurlu, iqtisadi cəhətdən məqsədəuyğun deyil, platforma siyasətinə görə rədd və ya ownership mümkün deyil kimi dəqiq kateqoriya alır. Bu qeyd növbəti qərarda yanlış ümid və təkrar riskli ödənişin qarşısını alır.

Hadisəni source, custody və asset oxlarına bölün

Source oxu transaction-un hansı chain-də yarandığını, custody oxu recipient private key-inə kimin nəzarət etdiyini, asset oxu isə hansı contract və ya mint-in köçdüyünü göstərir. Wrong-network diaqnostikası bu üç cavab olmadan tamamlanmır. Eyni recipient mətni custody-ni, eyni simvol asset-i sübut etmir.

Qərar cədvəlində hər ox üçün sübut linki saxlanır: withdrawal detail və explorer source-u, platforma ticket-i custody-ni, issuer və event contract-ı asset-i göstərir. Qeyri-müəyyən sahə recovery addımından əvvəl bağlanır.

Şəxsi EOA üçün təhlükəsiz chain əlavə etmə

Wallet-ə yeni EVM chain əlavə edilirsə chain ID, RPC və explorer rəsmi sənəddən alınır. Axtarış reklamındakı “recovery RPC” istifadə olunmur. Public RPC balansı göstərə bilər, lakin naməlum RPC transaction məlumatını manipulyasiya edə və privacy riski yarada bilər.

Token custom asset kimi contract və decimals ilə read-only əlavə olunur. Balansı görmək üçün seed import tələb olunmur; mövcud wallet həmin hesabı idarə edirsə chain dəyişimi kifayətdir. Sonra kiçik Gas və təhlükəsiz destination planlanır.

Contract wallet destination chain-də deploy edilməyibsə

Safe və başqa smart account address-i deterministic görünə bilər, amma contract hər chain-də deploy edilməmiş ola bilər. Aktiv deploy olunmamış counterfactual address-ə çata bilər. Recovery factory, salt, owner və deployment metodundan asılı mürəkkəb texniki məsələdir.

Naməlum şəxsə initializer imzası verməyin. Wallet vendor-un rəsmi sənədi və support-u ilə address derivation yoxlanır. Custodial və multisig owner-lər birlikdə qərar verir; sadə EOA qaydası tətbiq edilmir.

Proxy və bridge contract ünvanına səhv transfer

Token şəxsi recipient əvəzinə bridge, router və ya proxy contract-a birbaşa göndərilə bilər. Contract-ın arbitrary token rescue funksiyası yoxdursa aktiv kilidlənə bilər. Explorer-də contract verified source, admin modeli və token event-i araşdırılır.

Contract deployer və ya DAO yalnız rəsmi governance prosesində recovery edə bilər. Sosial mediada özünü developer adlandıran şəxsə əlavə payment və approval verilməz. Ticket və proposal linkləri public sübutla bağlanır.

Token contract-ın öz ünvanına göndəriş

ERC20 tokeni token contract-ın öz ünvanına göndərmək burn ilə eyni olmaya bilər, amma istifadəçinin onu geri çəkmək səlahiyyəti adətən yoxdur. Contract kodunda rescue mexanizmi və admin governance araşdırılır. Recipient contract-ın private key-i olmur.

Issuer support-a hash, event, amount və sender verilir. “Contract açma Gas-ı” adı ilə üçüncü tərəfə pul göndərmək funksiyanı yaratmır. Recovery mümkün deyilsə qərar texniki səbəblə sənədləşdirilir.

Burn address və əlçatmaz recipient

Recipient tanınan burn address, sıfır ünvan və ya private key-i məlum olmayan təsadüfi ünvan ola bilər. Chain success bu halda da mümkündür. Ünvan formatının valid olması onun kimsə tərəfindən idarə edildiyini göstərmir.

Heç bir miner və explorer confirmed state-i başqa recipient-ə dəyişə bilməz. Qarşı tərəf private key-ə nəzarət etmirsə refund imzalana bilməz. Saxta “key generator” və brute-force vədləri qəbul edilmir.

Exchange-in eyni address-i çox chain-də istifadə etməsi

Platforma bir EVM deposit address-i bir neçə chain üçün göstərə bilər. Bu, recovery ehtimalını artıra bilər, amma yalnız platformanın həmin chain node-u, token parser-i və əməliyyat proseduru varsa. İstifadəçi platformanın private key-ni idarə etmir.

Ticket-də dəstəklənən və faktiki chain yanaşı göstərilir. Platforma gələcəkdə həmin chain-i dəstəkləsə avtomatik credit verib-verməyəcəyini yazılı soruşun. Qeyri-rəsmi “gözləyin, özü gələcək” vədi sübut deyil.

UTXO şəbəkələrində səhv ünvan

Bitcoin və fork şəbəkələrində oxşar address formatları tarixən qarışıqlıq yaradıb. Address encoding və script eyni görünə bilər, amma hər chain UTXO ledger-i ayrıdır. Recipient wallet-in digər chain açarına nəzarəti bəzən recovery imkanı yarada bilər.

Private key export risklidir və yalnız wallet vendor-un rəsmi, offline proseduru ilə qiymətləndirilir. Custodial recipient üçün platforma support-u lazımdır. Seed-i online converter-ə daxil etmək düzgün recovery yolu deyil.

Solana token account yanlışlığı

SPL token əsas wallet əvəzinə yanlış token account-a gedibsə account owner və mint yoxlanır. Owner istifadəçinin wallet-idirsə token etibarlı wallet UI-də görünməyə bilər, amma idarə edilə bilər. Owner platformadırsa manual credit siyasəti tələb olunur.

Yanlış mint üçün eyni simvol heç nəyi dəyişmir. Destination account həmin mint üçün uyğun olsa da platforma onu qəbul etməyə bilər. Signature, owner, token account, mint və balance dəyişiklikləri ticket-ə əlavə olunur.

Memo başqa istifadəçiyə aiddirsə

Doğru platforma ünvanına, amma başqa hesabın Memo-su ilə göndəriş mümkün mübahisə yaradır. Vəsait başqa istifadəçinin ledger-inə düşə bilər. Dərhal rəsmi ticket açın, TxID və withdrawal ownership-i verin. Qarşı istifadəçi ilə kənar kanalda əlaqə qurmaq privacy və fraud riski yarada bilər.

Platforma daxili audit və reversal siyasətini tətbiq edir. Seed və əlavə verification payment lazım deyil. Nəticə həm yanlış kreditin düzəldilməsini, həm doğru hesabın net məbləğini göstərməlidir.

Transaction failed görünürsə wrong-network deyil

Receipt failed və token event-i yoxdursa aktiv recipient-ə keçməyib. Gas xərclənə bilər, əsas balans isə sender-də qala bilər. Bu halda recovery yox, revert səbəbi və yenidən göndərmə təhlükəsizliyi araşdırılır.

Platforma withdrawal failed order-i balansı qaytara bilər. Public hash və daxili refund statusu uzlaşdırılır. Eyni məbləği chain nəticəsi bilinmədən ikinci dəfə göndərmək lazım deyil.

Pending transaction zamanı qərar

Pending transaction hələ final yanlış-chain hadisəsi deyil. EVM-də RBF və cancel, Bitcoin-də RBF/CPFP kimi imkanlar ola bilər, amma yalnız signer nəzarəti varsa. Custodial withdrawal-u istifadəçi özü əvəzləyə bilməz.

Müdaxilə recipient və network səhvini düzəltmək məqsədi daşıyırsa replacement mined olmadan zəmanət yoxdur. Köhnə və yeni hash-lər izlənir. Naməlum accelerator seed tələb etməməlidir.

Destination platforma artıq aktivi sweep edibsə

Yanlış chain-də platforma address-inə gələn token sonradan başqa platforma wallet-inə sweep olunubsa bu, platformanın texniki nəzarətini göstərə bilər. Inbound və sweep hash-ləri ticket-ə əlavə edin. Yenə də istifadəçi hesabına credit siyasət qərarı tələb edir.

Sweep-i görüb kənar şəxsin recovery etdiyini düşünməyin. Platformalar avtomatik wallet management istifadə edir. Rəsmi ticket nəticəsi olmadan əlavə ödəniş etməyin.

Recovery transaction-un destination seçimi

Platforma refund təklif edirsə source address hot wallet ola bilər və uyğun recipient sayılmaya bilər. İstifadəçi cari, nəzarət etdiyi, düzgün chain ünvanı təqdim edir və ikinci kanal ilə təsdiqləyir. Refund aktivin mövcud chain-ində və ya platformanın müəyyən etdiyi dəstəklənən yolla edilə bilər.

Yeni transaction fee-si, net məbləğ və hash əvvəlcədən və ya nəticədə yazılı göstərilir. Original TxID ilə əlaqə saxlanır. Refund screenshot-u deyil, public event və faktiki balans əsasdır.

Bridge recovery-də destination Gas

Bridge source əməliyyatı üçün native fee-dən başqa destination claim üçün də Gas tələb edə bilər. İstifadəçi destination chain-də heç native balans saxlamırsa aktiv mesaj tamamlandıqdan sonra da claim gözləyə bilər. Rəsmi bridge relayer modelini əvvəlcədən oxuyun.

Gas almaq üçün naməlum faucet-də wallet approval verməyin. Etibarlı mənbədən yalnız lazım olan kiçik native məbləğ alınır. Claim calldata və recipient imzadan əvvəl yoxlanır.

Wrapped aktivlə native aktivin fərqi

Recovery bridge nəticəsində wrapped token yarada bilər. Platforma isə native issuer contract-ını tələb edə bilər. Destination-də görünən simvol eyni olsa da contract və likvidlik yoxlanır. Lazım gələrsə rəsmi unwrap və ya issuer-supported route ayrıca əməliyyatdır.

Hər əlavə swap və bridge yeni riskdir. Birbaşa platformanın dəstəklədiyi recovery destination mümkün olarsa daha sadədir. Net nəticə bütün fee-lərdən sonra hesablanır.

Vergi və audit izi

Yanlış-chain transfer iqtisadi disposal, loss və ya self-transfer kimi yerli qaydalarda fərqli qiymətləndirilə bilər. Texniki sənəd source amount, timestamp, asset contract, recipient custody, recovery fee və final amount-u dəqiq saxlayır. Hüquqi təsnifat üçün yerli mütəxəssisə müraciət olunur.

Fiat qiymətləri ayrıca mənbə və vaxtla qeyd edilir. Public hash-lər dəyişməz sübutdur, platforma ticket-i custody qərarını tamamlayır. Məxfi açarlar audit əlavəsinə daxil edilmir.

Komanda eskalasiya matrisi

Kiçik və şəxsi EOA ssenarisini texniki operator idarə edə bilər. Custodial recipient, böyük məbləğ, compliance hold, contract wallet və ya fraud əlaməti varsa təhlükəsizlik, hüquq və maliyyə rolları qoşulur. Hər rol yalnız lazım olan məlumatı alır.

Bir nəfər həm recipient-i dəyişib, həm imza verib, həm nəticəni təsdiqləməməlidir. İki nəfərlik nəzarət böyük recovery transaction-da səhv destination riskini azaldır.

Məlumat məxfiliyi

TxID, public address və contract açıqdır. Hesab e-poçtu, şəxsiyyət sənədi, telefon, API key, 2FA və cihaz məlumatı məhdud kanalda saxlanır. Screenshot paylaşmazdan əvvəl browser tab-ları və balansın əlaqəsiz hissələri örtülür.

Platforma identity proof istəyirsə rəsmi upload kanalını doğrulayın. Sosial media DM-i və naməlum bulud linki istifadə edilmir. Public texniki diaqnostika məxfi açar tələb etmir.

24 saatlıq monitorinq planı

İlk saatda source status, confirmation və platforma ticket qəbulu izlənir. Sonra platformanın verdiyi SLA və chain vəziyyətinə uyğun interval seçilir. Hər dəyişiklik timestamp ilə yazılır, eyni sual üçün çoxlu ticket açılmır.

Yeni saxta support mesajları ayrıca təhlükəsizlik hadisəsi kimi saxlanır. Recovery qərarı geciksə də tələsik ikinci transaction və ya şəxsi ünvana fee göndərilmir.

Son owner checkpoint

Hadisə sahibi fakt cədvəlini, custody nəticəsini, texniki variantları, net recovery məbləğini və təhlükəsizlik riskini oxuyur. Seçilən variant yazılı təsdiqlənir. “Heç nə etməmək” də fee aktivdən yüksək və ya risk qeyri-məqbul olduqda əsaslandırılmış qərar ola bilər.

İcraçı yalnız təsdiqlənmiş chain, contract, recipient və limit daxilində əməliyyat edir. Nəticə sahibi tərəfindən ikinci dəfə yoxlanır. Beləliklə texniki recovery yeni yanlış-network hadisəsinə çevrilmir.

Bir səhifəlik yekun checklist

Source chain və TxID məlumdur; status finaldır; token contract doğrudur; recipient custody müəyyən edilib; Memo ayrıca qiymətləndirilib; platforma ticket-i rəsmi kanaldadır; private məlumat paylaşılmayıb; variantın fee və net nəticəsi hesablanıb; owner təsdiqi var; yeni destination ikinci kanalla yoxlanıb.

Bu maddələrdən biri cavabsızdırsa proses müşahidə və araşdırma mərhələsində qalır. Yalnız bütün kritik faktlar bağlandıqda bridge, refund, manual sweep və ya təhlükəsiz şəxsi wallet köçürməsi icra olunur.

Vendor support cavabını texniki yoxlamaq

Wallet və ya platforma support-u “address bizə aid deyil” deyirsə, hansı chain və hansı tarix üçün danışdıqlarını soruşun. Platforma address rotasiyası, sub-account və legacy wallet səbəbindən ümumi cavab natamam ola bilər. TxID, recipient və hesab deposit səhifəsi ilə konkret sorğu verilir.

“Recovery mümkün deyil” cavabında private key nəzarəti, dəstəklənməyən token, compliance və ya siyasət səbəbi ayrılmaya bilər. Əlavə məlumat tələb etmək olar, lakin eyni faktla çoxlu ticket açıb növbəni pozmaq lazım deyil. Son qərar tarix və ticket nömrəsi ilə saxlanır.

Dəstək gələcəkdə açıla bilərsə

Platforma hazırda source chain-i indeksləməsə, gələcək inteqrasiya zamanı köhnə depozitləri avtomatik credit edəcəyinə zəmanət yoxdur. İstifadəçi TxID, account ownership və ticket-i uzunmüddətli saxlayır. Platformanın yazılı təlimatı olmadan vaxtaşırı kiçik “oyatma” ödənişi göndərilmir.

Aktivin contract state-i və platforma address balansı read-only izlənə bilər. Token sweep olunarsa ticket yenilənir. Monitoring private key və wallet connection tələb etmir.

Miras və təşkilati açar nəzarəti

Recipient şəxsi wallet olsa da sahibi vəfat edib, açar itirilib və ya şirkət signer-i ayrılıbsa wrong-network recovery açar idarəçiliyi problemi ilə birləşir. Ünvanın eyni chain-də idarə oluna bilməsi üçün qanuni və texniki səlahiyyət tələb olunur.

Seed axtarışı adı ilə naməlum “mütəxəssis”ə cihaz verməyin. Təşkilat multisig, backup və hüquqi prosedurdan istifadə edir. Public balance ownership yaratmır.

Açar kompromisi recovery zamanı

Yanlış chain-də aktivə nəzarət edən şəxsi key artıq sızıbsa, Gas əlavə etmək hücumçunun tokeni aparmasına imkan verə bilər. Təhlükəsiz köçürmə private transaction, yeni wallet və koordinasiya tələb edə bilər. Sadə “BNB göndər, sonra tokeni köçür” addımı risklidir.

Hadisə təhlükəsizlik mütəxəssisi ilə planlanır, lakin seed yenə paylaşılmır. Hücumçu monitorinqi, nonce və bundle variantları chain-ə görə qiymətləndirilir. Net məbləğ və risk owner tərəfindən qəbul edilir.

Saxta token recovery tələsi

Wallet yüksək dollar dəyəri göstərən saxta token ala bilər. Hücumçu onu “yanlış şəbəkədə qalan USDT” kimi təqdim edib swap və ya claim saytına yönləndirə bilər. Contract, holder, liquidity və issuer məlumatı yoxlanmadan Gas və approval verilməz.

Tokenin satıla bilməyən honeypot olması mümkündür. Recovery iqtisadi hesabı real likvidliyə əsaslanır, UI qiymətinə deyil. Şübhəli tokenlə qarşılıqlı əlaqə etməmək bəzən ən təhlükəsiz qərardır.

Domain və sosial hesab arxivlənməsi

Phishing və saxta support varsa URL, domain registrasiya məlumatının public hissəsi, mesaj user ID-si, payment address və timestamp saxlanır. Linklər təhlükəsiz mətn kimi arxivlənir, yenidən login edilmir. Brauzer session və API key kompromisi də yoxlanır.

Platforma fraud report-u üçün tələb olunan minimum paket hazırlanır. Public paylaşımda şəxsi hesab və hüquqi sənəd örtülür. Məqsəd sübutu qorumaq, hücumçu ilə əlavə danışıqa girmək deyil.

Əməliyyatın iqtisadi sonluğu

Recovery net məbləği platforma haqqı, Gas, bridge fee, qiymət təsiri və mümkün vergi xərci çıxıldıqdan sonra hesablanır. Vaxt və təhlükəsizlik riski də qərara daxildir. Kiçik token üçün texniki mümkün yol iqtisadi cəhətdən düzgün olmaya bilər.

Owner bu hesabı görüb icra, gözləmə və ya zərər kimi bağlama variantını seçir. Qərar emosional “mütləq qaytarmalıyıq” təzyiqinə deyil, yoxlana bilən rəqəm və riskə söykənir.

İkinci səhvin qarşısını alan rehearsal

Real recovery-dən əvvəl komanda read-only şəkildə source hash, destination, contract və addımlar üzrə walkthrough edir. İmza verilmədən hər ekranın gözlənilən sahələri yazılır. Testnet həmişə eyni contract və bridge davranışını göstərməsə də proses təlimi verə bilər.

Kiçik mainnet sınaq mümkündürsə net minimum və fee nəzərə alınır. Sınağın uğuru destination-də doğru contract və istifadə edilə bilən balansla ölçülür. Sonra əsas əməliyyat üçün bütün məlumat yenidən açılır.

Final hesabat nümunəsi

Hesabat “USDT BSC-də platformanın Ethereum depozit ünvanına göndərildi; address platforma nəzarətində idi; BEP20 contract təsdiqləndi; ticket üzrə manual sweep edildi; fee çıxıldıqdan sonra net məbləğ funding hesabına kredit olundu” kimi konkret yazılır. Hər hissəyə hash və vaxt əlavə edilir.

Uğursuz nəticə də dəqiq ola bilər: “recipient şəxsi açarla idarə olunmur, contract-da rescue yoxdur, platforma ownership-i təsdiqləmədi.” Bu cümlə saxta recovery təkliflərinə qarşı aydın sərhəd yaradır.

Sənədin saxlanma qaydası

Public hash-lər, ticket nömrələri, qərar vaxtı və net nəticə təşkilatın hadisə reyestrində saxlanır. Seed, private key, 2FA və sənədlərin əlaqəsiz surətləri bu reyestrə daxil edilmir. Giriş yalnız recovery və audit roluna verilir; saxlanma müddəti yerli qayda və biznes ehtiyacına uyğun müəyyən olunur.

Sonradan platforma siyasəti dəyişsə, köhnə hadisə yeni qayda ilə səssizcə yenidən təsnif edilmir. Yeni recovery imkanı yaranarsa ayrıca owner qərarı, risk yoxlaması və icra qeydi açılır.

Recovery bağlandıqdan sonra nəzarət necə dəyişdirilir?

Hadisə yalnız vəsait qayıtdıqda deyil, səbəb və növbəti nəzarət sahibi yazıldıqda bağlanır. Səhv network seçimi platforma UI-sində oxşar adlardan yaranıbsa, prosedur tam şəbəkə adı və chain ID tələb edəcək şəkildə dəyişdirilir. Köhnə address book qeydi səbəb olubsa, recipient sətirinə network, token contract, Memo və son yoxlama tarixi əlavə olunur. Məqsəd əməkdaşı günahlandırmaq deyil, eyni səhvin eyni şəraitdə təkrarını çətinləşdirməkdir.

Növbəti real əməliyyatdan əvvəl düzəliş kiçik, nəzarətli sınaqda yoxlanır. Reviewer depozit məlumatını müstəqil mənbədən açır və operatorun seçimi ilə tutuşdurur. Sınaq uğurlu olsa belə böyük transfer üçün məlumat yenidən alınır. Bu nəticə hadisə reyestrinə bağlanır ki, “təlim verildi” kimi ölçülməyən qeyd əvəzinə nəzarətin işlədiyi göstərilsin.

Platforma recovery-ni rədd edibsə, rədd səbəbi də prosedura çevrilir. Məsələn, address platformanın nəzarətində deyil, token contract dəstəklənmir və ya net məbləğ minimumdan aşağıdırsa, gələcək preflight həmin riski əvvəlcədən yoxlamalıdır. Naməlum üçüncü tərəfin sonradan verdiyi vəd rəsmi rədd cavabını ləğv etmir; yeni sübut yaranarsa yalnız rəsmi ticket yenidən qiymətləndirilir.

Hadisənin bağlanma meyarı

Case üç yoldan biri ilə bağlanır: aktiv yoxlanıla bilən üsulla bərpa edilib; rəsmi platforma və texniki nəzarət recovery-nin mümkün olmadığını göstərib; yaxud owner iqtisadi xərc və təhlükəsizlik riskinə görə icradan imtina edib. Hər nəticəyə TxID, ticket və qərar vaxtı əlavə olunur.

“Hələ bir nəfər cavab verməyib” bağlanma meyarı deyil. Açıq qalan addımın sahibi və yenidən baxılacağı tarix yazılır. Seed, private key və 2FA hadisə reyestrində saxlanmır.

Bağlanmış case üçün qısa retrospektiv keçirilir: səhv hansı ekranda yarandı, hansı nəzarət onu görmədi və növbəti transferdə hansı konkret blok işləyəcək. Düzəliş owner, tarix və sınaq nəticəsi ilə yazılır. Ümumi “diqqətli olun” qeydi nəzarət sayılmır.