Token müqavilə ünvanına göndərilib: nəzarəti və bərpanı yoxlayın

Əvvəl receipt və Transfer hadisəsi arasında fərqi görün

ERC-20 tokeni səhv müqavilə ünvanına göndəriləndə explorer transaction üçün success göstərə bilər. Bu nəticə token müqaviləsinin çağırışı icra etdiyini bildirir. Transfer hadisəsi də token balansının göstərilən recipient address-ə yazıldığını sübut edir. Lakin həmin recipient-in adi pulqabı kimi tokeni geri imzalaya bildiyini sübut etmir.

Transaction səhifəsində iki ayrı to sahəsi qarışdırılır. Xarici transaction-un to dəyəri çox vaxt token contract olur, çünki istifadəçi onun transfer funksiyasını çağırır. Event log-dakı Transfer to dəyəri isə faktiki token recipient-dir. İstifadəçi yalnız yuxarıdakı contract address-ə baxsa, tokenin harada qaldığını yanlış müəyyən edə bilər.

ERC-20 standartı transfer zamanı recipient contract-ın xüsusi qəbul funksiyasını çağırmağı məcburi etmir. Buna görə token düzgün qaydada hərəkət edir, amma qəbul edən contract həmin gözlənilməyən balansla nə edəcəyini bilməyə bilər. Uğurlu receipt texniki execution cavabıdır; geri qaytarma imkanı barədə ayrıca kod və nəzarət araşdırması tələb olunur.

Sübut cədvəlini tam məlumatla doldurun

Orijinal wallet və ya platforma səhifəsindən tam TxID-ni götürün. Düzgün şəbəkənin etibarlı explorer-ində açın və dəyişdirilməyən qeyd yaradın. Ekran şəklində qısaldılmış ünvan kifayət deyil. Şəbəkə, block, status, sender, transaction to, input method, token contract, event recipient, raw amount, decimals və UTC vaxtını yazın.

Token adı və simvolu kifayət etmir. Eyni adlı saxta və ya başqa buraxılış token ola bilər. Contract address əsas identifikatordur. Amount-a baxarkən decimals tətbiq edin; raw integer-i istifadəçi məbləği kimi yazmaq ticket-də ciddi səhv yaradır.

Əgər göndərmə mərkəzləşdirilmiş platformadan edilibsə, order ID on-chain TxID deyil. Platformadan faktiki transaction hash və hansı sender address-dən yayımlandığını istəyin. Sonrakı ownership sübutu lazım olanda həmin sender sizin private key ilə idarə etdiyiniz ünvan olmaya bilər.

Ünvanın hesab növünü müəyyən edin

Ethereum tipli şəbəkədə xaricdən idarə olunan hesab məxfi açar ilə, contract account isə code ilə idarə olunur. Explorer address səhifəsində bytecode, Contract nişanı, verified source, creator və proxy məlumatı yoxlanılır. Contract address üçün istifadəçinin və ya layihə əməkdaşının ixrac edə biləcəyi gizli açar yoxdur.

Əvvəl recipient-in həqiqətən contract olub-olmadığını təsdiqləyin. Eyni address başqa EVM şəbəkəsində EOA kimi görünə, seçilmiş chain-də isə code ola bilər; hər ledger ayrıca yoxlanılır. Address-in 0x ilə başlaması account növünü və doğru şəbəkəni göstərmir.

Sonra contract rolunu müəyyən edin. Token contract aktiv proqramıdır və depozit wallet deyil. DEX router yalnız düzgün function call və parametrlərlə swap edə bilər. Bridge vault protokolun gözlədiyi mesaj olmadan adi transferi kredit saymaya bilər. Multisig və smart account isə signer və modul qaydaları varsa token çıxara bilər. Proxy contract-da görünən address-in arxasındakı implementation ayrıca oxunmalıdır.

Kodda bərpa yolu necə axtarılır

Verified source-da recoverERC20, rescueTokens, sweep, withdrawToken və oxşar funksiyalar ola bilər. Adın görünməsi kifayət deyil. Funksiyanın hansı tokenləri qəbul etdiyi, destination address-i kimin seçdiyi, kimlərin çağırmağa icazəsi olduğu və hansı hadisəni yaratdığı oxunmalıdır.

Araşdırma ardıcıllığı:

1. Contract istənilən ERC-20 üçün outgoing transfer yarada bilirmi?
2. Bu funksiya sizin token contract-ı istisna etmir ki?
3. Funksiyanı public istifadəçi, original sender, owner, role, multisig və ya governance çağırır?
4. Həmin owner və ya role hazırda aktivdirmi, yoxsa renounce edilib?
5. Proxy varsa, cari implementation və admin address doğrudurmu?
6. Pause, timelock, vote və ya accounting invariant əməliyyata mane olurmu?

Kodda bərpa yolu varsa, bu yalnız texniki imkan deməkdir. Layihənin fərdi müraciətləri qəbul etməsi, ownership sübutu, minimum məbləğ, hüquqi yoxlama və əməliyyat haqqı ayrıca siyasətdir. Əksinə, heç bir outgoing yol yoxdursa, yaxşı niyyətli support da code qaydasını keçə bilməz.

Dörd mümkün nəticə üçün qərar verin

Recipient əslində sizin nəzarət etdiyiniz EOA-dırsa, düzgün chain-i wallet-ə əlavə etmək və həmin şəbəkənin native gas aktivini əldə etmək kifayət edə bilər. Bu nəticə yalnız eyni address üçün həqiqətən private key və ya hardware wallet nəzarətiniz olduqda keçərlidir. Birja depozit ünvanının başqa chain-də eyni görünməsi sizin nəzarətiniz demək deyil.

Contract-da uyğun rescue funksiya və aktiv admin varsa, rəsmi layihə kanalından sorğu verilir. Contract upgradeable-dır, amma rescue yoxdur deyə bir istifadəçi üçün upgrade tələb etmək yüksək riskli ola bilər; governance digər istifadəçilərin vəsaitini və protokol qaydasını qorumaq məcburiyyətindədir. Contract immutable-dır və tokeni çıxaran heç bir kod yolu yoxdur isə texniki nəticə sərtdir: geri qaytarılacağına zəmanət yoxdur və praktik bərpa mümkün olmaya bilər.

Dəstək ticket-i konkret suallarla yazın

Başlıqda şəbəkəni, tokeni və “ordinary ERC-20 transfer to contract address” ifadəsini göstərin. Mətndə TxID, token contract, event recipient, amount, vaxt, sender və səhv ünvanı haradan götürdüyünüz yazılsın. Explorer permalink əlavə edin. Bütün məlumat copy edilə bilən mətn olsun; yalnız screenshot göndərməyin.

Layihədən bu suallara cavab istəyin:

• Recipient address həmin layihənin hansı contract-ıdır?
• Cari implementation gözlənilməyən ERC-20 balansını çıxaran funksiya saxlayırmı?
• Hansı owner, role, multisig və ya governance bu funksiyanı çağırır?
• Funksiya konkret tokeni və original sender-ə qaytarmağı dəstəkləyirmi?
• Ownership və compliance üçün hansı açıq və hesab məlumatı lazımdır?
• Müraciət qəbul olunmursa, səbəb code məhdudiyyəti, itmiş səlahiyyət, yoxsa siyasətdir?

Original sender sizə məxsusdursa, support adi message imzası ilə nəzarəti sübut etməyi istəyə bilər. Domeni və imzalanan mətni oxuyun. Permit, approval, token transfer və anlaşılmayan hexadecimal əməliyyatı “ownership signature” kimi təsdiqləməyin. Sender birjaya aiddirsə, özünüz imza verə bilməzsiniz; çıxaran platforma rəsmi qeyd təqdim etməlidir.

Explorer-də Write Contract düyməsini sınaq etməyin

Write Contract səhifəsi recovery wizard deyil. Funksiya adı rescue görünsə belə, yalnız admin üçün ola, tokeni treasury-yə göndərə və ya başqa state dəyişikliyi yarada bilər. Səhv parametr haqq xərcləyər və yeni problemi artırar. Kod, proxy, role və transaction simulation anlaşılmadan təsadüfi çağırış edilməməlidir.

Contract-a əlavə ETH və ya başqa native aktiv göndərmək də onu avtomatik “oyatmır”. Contract transaction yaratmaq üçün özbaşına qərar verən EOA deyil. Mövcud kod xarici çağırış tələb edir və bu çağırışın səlahiyyət qaydası olur. Gas çatışmazlığı admin transaction-u üçün problem ola bilər, amma contract balance-ına pul atmaq ümumi həll deyil.

Kiçik ikinci token transferi, memo yazılmış transfer və ya saxta token yaratmaq əvvəlki event-i dəyişmir. Bu əməliyyatlar sübut qovluğunu qarışdırır. Yalnız layihənin rəsmi sənədi və dəstək əməkdaşı eyni message üçün müəyyən təhlükəsiz çağırış göstərirsə, onu ayrıca qiymətləndirin.

Təhlükəsizlik: bərpa adı ilə wallet nəzarətini verməyin

Contract code və açıq transaction araşdırması bərpa sözləri, private key, wallet backup, remote desktop və ya əvvəlcədən “validator fee” tələb etmir. Həqiqi məhdudiyyət contract-ın proqramı və role nəzarətidir. Kənar şəxs sizin seed məlumatınızı bilsə, contract-a sehrli çıxış qazanmayacaq; əvəzində qalan wallet aktivlərinizi oğurlaya bilər.

Sosial mediada yardım istədikdən sonra gələn şəxsi mesajlar yüksək risklidir. Özünü developer, white-hat və ya explorer əməkdaşı kimi təqdim edən şəxsin göndərdiyi DApp-a wallet qoşmayın. Zəmanətli recovery, əvvəlcədən faiz və “liquidity verification” üçün başqa ünvana transfer istəyi ikinci fırıldaq əlamətidir.

Əgər səhv address phishing səhifəsindən götürülübsə, ayrıca approval və cihaz təhlükəsini yoxlayın. Etibarlı cihazdan spender allowance-ları araşdırın, naməlum icazələri düzgün chain-də revoke edin və domen sübutunu saxlayın. Approval ləğvi contract-a artıq göndərilmiş tokeni qaytarmır; yalnız gələcək transferFrom riskini azalda bilər.

Azərbaycan ödənişində biznes qeydi

Azərbaycandakı biznes xarici təchizatçıya və ya frilans əməkdaşa token göndərərkən recipient məlumatını hesab-faktura və təsdiqlənmiş vendor qeydindən götürməlidir. Explorer token səhifəsindəki contract address ödəniş rekviziti deyil. Ünvan dəyişikliyi iki əməkdaşın yoxlaması və əvvəlki rabitə kanalı ilə geri zəng tələb edə bilər.

Səhv köçürmə baş veribsə, orijinal ödəniş öhdəliyi, itkin aktiv və sonradan edilən əvəz ödənişi ayrı qeydə alınmalıdır. AZN ilə razılaşdırılmış dəyər, token amount, məzənnə vaxtı, fee, TxID, ticket və nəticə ayrı sahələrdə saxlanılsın. Project sonradan rescue transaction göndərərsə, onun yeni TxID-si original transaction-la əlaqələndirilsin; əvvəlki sübut silinməsin.

Məbləğin maliyyə hesabatı, vergi və hüquqi təsnifatı texniki statusdan fərqli mövzudur. Yerli ixtisaslı mühasib və hüquqşünasla sənədləşmə qaydasını dəqiqləşdirin. Explorer-də tokenin contract balance-da görünməsi avtomatik olaraq hüquqi olaraq geri alına bilən debitor borcu yaratmır.

Yeni transferdən əvvəl contract yoxlama siyahısı

Yeni recipient-i yoxlayarkən üç ayrı sətri bir-birinə qarışdırmayın: token contract aktivin özünü tanıdır, recipient address ödənişi alan hesabdır, spender isə yalnız təsdiqlənmiş allowance-dan istifadə edə bilən ünvandır. Explorer səhifəsində bunların hamısı hexadecimal görünə bilər, lakin hüquqları və məqsədləri fərqlidir. Ödəniş təlimatında “USDT contract” göstərilməsi həmin contract-ın to sahəsinə yazılmalı olduğu mənasına gəlmir. Qarşı tərəfdən məhz qəbul edən address-i və dəstəklənən chain-i yazılı təsdiqləməsini istəyin.

Yoxlama qeydində ən azı aşağıdakı sahələr olsun:

1. Recipient məlumatının ilkin mənbəyi: rəsmi depozit səhifəsi, imzalanmış hesab-faktura və ya əvvəlcədən təsdiqlənmiş address book qeydi.
2. Chain ID və şəbəkə adı; eyni formatlı address-in başqa EVM zəncirində işləməsi düzgün marşrut demək deyil.
3. Aktiv simvolu ilə yanaşı token contract və decimals; eyni ticker saxta və ya bridged variantı gizlədə bilər.
4. Memo, Tag, reference və minimum depozit tələbi; bunlar contract səhvindən ayrı olsa da kredit nəticəsinə təsir edir.
5. Explorer-in address təsnifatı: EOA, verified contract, proxy, multisig və ya naməlum bytecode.
6. Dəyişiklik təsdiqi: recipient əvvəlki qeyddən fərqlidirsə, köhnə və etibarlı rabitə kanalından geri yoxlama.
7. Test məbləği, test TxID-si və qarşı tərəfin faktiki balans təsdiqi; yalnız transaction success olması daxili kreditə zəmanət vermir.
8. Əsas köçürməni təsdiqləyən şəxs, UTC vaxtı və hardware ekranında müqayisə edilən tam ünvan.

Address explorer-də contract kimi işarələnirsə, avtomatik olaraq bütün müqavilələrə köçürməni qadağan etmək də düzgün deyil. Bəzi rəsmi depozit sistemləri smart account, vault və ya payment contract istifadə edə bilər. Fərq ondadır ki, recipient sənədi adi token transferini məhz həmin contract-a qəbul etdiyini açıq göstərməli, contract code-u gözlənilən token üçün qəbul və çıxış davranışına sahib olmalı və layihənin rəsmi kanalı bunu təsdiqləməlidir. Bu sübutlar yoxdursa, təcili ödəniş təzyiqinə görə contract address-i recipient kimi qəbul etməyin.

Kiçik test riskin hamısını aradan qaldırmır. Upgrade edilə bilən contract testdən sonra dəyişə, depozit ünvanı yalnız bir dəfəlik ola və platforma minimumdan aşağı testə kredit verməyə bilər. Testin məqsədi chain, recipient və qəbul qatının real işlədiyini yoxlamaqdır; o, sonrakı transaction üçün limitsiz zəmanət deyil. Əsas məbləğ göndərilən anda rəsmi səhifə, chain və tam ünvan yenidən açılmalıdır.

Simulation aləti tokenin hansı address-ə gedəcəyini və hansı event-lərin yaranacağını göstərə bilər, amma nəticəni şərh etmədən yaşıl işarəyə güvənməyin. Simulyasiya cari state, RPC və məlum code əsasında işləyir; front-end-in kimliyini və qarşı tərəfin business məqsədini təsdiqləmir. Gözlənilən sadə transfer əvəzinə naməlum approval, multicall, delegatecall və ya limitsiz allowance görünürsə, imzanı dayandırın və tətbiqin rəsmi sənədini araşdırın.

Multisig ödəniş prosesində proposer və signer rollarını ayırın. Proposal yaradan şəxs destination, token, amount və calldata-nı original hesab-faktura ilə əlaqələndirsin; signer-lər isə yalnız qısaldılmış UI xülasəsini deyil, decoded əməliyyatı yoxlasın. Threshold imzalarının toplanması yanlış recipient-i düzəltmir. İmza siyasətində yeni vendor, yeni chain və contract recipient üçün daha yüksək təsdiq həddi müəyyən edilə bilər.

Təcili vendor dəyişiklikləri ayrıca risk siqnalıdır. E-poçt hesabı ələ keçiriləndə hücum edən əvvəlki yazışma daxilində yeni address göndərə bilər. Buna görə “eyni e-poçt zənciri” həmişə müstəqil təsdiq deyil. Mövcud müqavilədəki telefon, satınalma portalı və ya əvvəlcədən qeyd olunmuş şəxs vasitəsilə geri əlaqə saxlayın; cavab verən şəxsdən tam address və chain-i yenidən söyləməsini istəyin. Təsdiqin kimdən və nə vaxt alındığını audit qeydinə yazın.

Son qərar dörd mümkün nəticədən biri ilə bitməlidir. Birincisi, EOA recipient və bütün sahələr uyğundur: testdən sonra əsas transfer mümkündür. İkincisi, contract recipient rəsmi sənədlə təsdiqlənib: qəbul funksiyası və marşrut əlavə yoxlanılır. Üçüncüsü, address contract-dır, lakin qəbul sübutu yoxdur: transfer dayandırılır və yeni rekvizit tələb olunur. Dördüncüsü, mənbələr bir-birinə ziddir: heç bir məbləğ göndərilmir, dəyişiklik request-i təhlükəsizlik və maliyyə komandasına yönləndirilir. “Bəlkə işləyər” texniki qərar deyil.

Ödəniş forması address-i avtomatik doldurursa, sahənin kilidli görünməsini təhlükəsizlik zəmanəti saymayın. QR kod, deep link və browser storage köhnə və ya dəyişdirilmiş məlumat daşıya bilər. Tam recipient-i müstəqil mənbədə açın, QR-dən çıxarılan sətri müqayisə edin və tətbiqin hansı chain-i seçdiyini yoxlayın. QR kodun altında düzgün şirkət adı yazılması kodun daxilindəki address-i təsdiqləmir.

Məbləğ böyükdürsə, transferdən əvvəl yazılı “dayanma şərti” müəyyən edin. Məsələn, explorer recipient-i naməlum contract kimi göstərirsə, verified source mövcud deyilsə, platforma həmin marşrutu rəsmi siyahıda göstərmirsə və ya hardware ekranı tam məlumatı göstərmirsə, əməliyyat əlavə araşdırmaya keçir. Bu şərt əvvəlcədən yazıldıqda son dəqiqə təzyiqi texniki yoxlamanı ləğv etmir.

İki nəfərin yoxlaması yalnız hər ikisinin eyni screenshot-a baxması demək deyil. Birinci şəxs ödəniş məlumatını hazırlaya, ikinci şəxs isə recipient-i ilkin mənbədən müstəqil götürüb chain, token və tam address-i yenidən müqayisə edə bilər. Hər iki şəxs address-i yalnız əvvəl və son simvollarla yoxlayırsa, address poisoning riskinə qarşı real müstəqillik yaranmır. Yoxlama nəticəsinə istifadə olunan mənbənin permalink-i əlavə olunsun.

Əməliyyat imzalanmamışdan əvvəl son xülasə sadə və oxunaqlı olmalıdır: hansı aktiv, hansı chain, hansı tam recipient, hansı məbləğ və hansı biznes sənədi. Bu xülasə transaction data ilə uyğun gəlmirsə, əvvəl formanı bağlayıb fərqin səbəbini tapın. Sonradan ticket açmaq mümkün olsa da, smart contract-ın tokeni qaytarmaq imkanı olmaya bilər; ən etibarlı bərpa addımı yanlış to sahəsinin ümumiyyətlə imzalanmamasıdır.

Proxy, multisig və admin məlumatını səhv oxumayın

Proxy address-də saxlanan balance ilə implementation code-u ayrı yerlərdə ola bilər. Explorer “Read as Proxy” göstərirsə, cari implementation slot-u və upgrade tarixçəsini yoxlayın. Köhnə verified implementation-da rescue funksiyası görünməsi hazırkı proxy-nin eyni funksiyanı təhlükəsiz istifadə edə bildiyini sübut etmir. Upgrade-dən sonra storage layout, role və selector dəyişmiş ola bilər.

Admin address bir EOA, multisig və ya governance executor ola bilər. Multisig səhifəsində signer sayı və threshold görünürsə, bu üzvlərin fərdi olaraq token qaytara bilməsi demək deyil. Lazımi sayda imza, daxili policy, compliance yoxlaması və bəzən timelock tələb olunur. Signer-lərə şəxsi mesaj göndərmək rəsmi müraciət kanalını əvəz etmir və sosial engineering riski yaradır.

Owner-in renounce edilməsi admin funksiyalarının daha çağırıla bilmədiyini göstərə bilər, amma bunu yalnız bir owner() cavabı ilə ümumiləşdirməyin. AccessControl rolları, ayrı guardian, proxy admin və governance contract qala bilər. Əksinə, owner address mövcuddur deyə onun private key-nin hələ əlçatan olduğunu qəbul etmək olmaz. Son uğurlu idarəetmə transaction-ları və layihənin rəsmi governance sənədi kontekst verir.

Contract source verified deyilsə, bytecode və açıq call tarixçəsi ilə məhdud nəticə çıxarmaq olar, lakin “mütləq bərpa yoxdur” demək üçün peşəkar analiz lazım ola bilər. Naməlum analitikə wallet qoşmaq əvəzinə yalnız TxID, address və code kimi açıq məlumat verin. Təhlil texniki imkan taparsa belə, icra qərarı yenə səlahiyyət sahibinə aiddir.

Multisig proposal yaradılarsa, onun destination, token, amount və calldata məlumatı original səhv transferlə tutuşdurulmalıdır. Sadəcə proposal başlığında istifadəçi adının yazılması kifayət deyil. İmzalanmadan əvvəl simulation və decoded call yoxlanmalı, çıxış recipient-i sübut edilmiş sender və ya rəsmi refund address olmalıdır. İdarəetmə əməliyyatının öz TxID-si sonradan ticket-ə əlavə edilir.

Timelock olan sistemdə proposal qəbul edilsə də icra dərhal baş verməyə bilər. Gözləmə müddəti, queue transaction-u və execute transaction-u ayrı sübutlardır. İstifadəçi bunu gecikmə kimi görə bilər, amma governance təhlükəsizliyinin bir hissəsidir. Bu mərhələdə başqa “sürətli recovery” xidmətinə pul ödəmək rəsmi prosesi sürətləndirmir.

Project migration və ya köhnə contract vəziyyətində cari komandanın əvvəlki admin key-lərinə çıxışı olmaya bilər. Domen və brend davam etsə belə, on-chain role başqa və ya istifadəsiz address-də qala bilər. Rəsmi support-dan texniki nəzarətin həqiqətən mövcud olduğunu təsdiqləyən governance keçidi və ya son admin transaction-u istəmək əsaslıdır.

Gələcəkdə səhvin təkrarlanmaması üçün token contract və recipient address anlayışlarını interfeysdə ayrı saxlayın. Explorer-də “Contract” sahəsindən götürülən sətr tokeni tanıyır; pulqabının “Send to” sahəsi üçün yalnız recipient-in rəsmi depozit və ya ödəniş ünvanı istifadə olunur.

Göndərmədən əvvəl:

• Recipient ünvanı rəsmi qəbul səhifəsindən və ya yoxlanmış address book-dan alınır.
• Aktiv, chain, token contract, Memo və ya Tag tələbi birlikdə yoxlanılır.
• Explorer address-i contract kimi göstərirsə, recipient sənədi məhz həmin contract-a adi transfer tələb etməlidir.
• Yeni marşrut platforma minimumuna uyğun kiçik məbləğlə sınanır.
• Qarşı tərəf testin faktiki balansda kredit olduğunu təsdiqləyir.
• Əsas məbləğ üçün tam ünvan hardware ekranında yenidən oxunur.
• Test və əsas köçürmənin TxID-ləri ayrıca saxlanılır.

Son nəticəni receipt-dən başlayıb code-a qədər qurun. Success tokenin hərəkət etdiyini, account növü onu kimin idarə etdiyini, contract funksiyası isə geri çıxışın olub-olmadığını göstərir. Heç biri təkbaşına refund vədi deyil. Sübutu rəsmi səlahiyyət sahibinə verin, qalan wallet təhlükəsizliyini qoruyun və mümkün olmayan bərpa üçün məxfi məlumat ödəməyin.

Hadisə sübutunu dəyişmədən necə saxlamalısınız?

Bərpa müraciətində ən güclü material original transaction-un dəyişməyən açıq qeydidir. TxID-ni mətn kimi saxlayın və düzgün chain explorer-ində permalink yaradın. Receipt statusu, block nömrəsi, UTC vaxtı, sender, to sahəsi, token contract, amount və Transfer event recipient-i eyni qeyddə olsun. Token decimals nəzərə alınmadan explorer-də görünən xam rəqəmi əllə çevirməyin; həm raw value, həm də interfeysin göstərdiyi məbləği saxlayın.

Contract sonradan upgrade edilə bildiyi üçün yalnız cari source görünüşü hadisə vaxtındakı vəziyyəti tam sübut etməyə bilər. Proxy implementation address-i, həmin block-da implementation dəyişiklikləri və varsa admin event-ləri qeyd edin. Explorer tarixi state oxumağı dəstəkləmirsə, RPC block nömrəsi və istifadə olunan mənbə yazılsın. Məqsəd özbaşına nəticə çıxarmaq deyil; support və ya müstəqil auditorun eyni vəziyyəti yenidən qura bilməsidir.

Screenshot köməkçi materialdır, əsas sübut deyil. Şəkildə chain adı, TxID və address görünə bilər, lakin link, mətn sahələri və block nömrəsi ayrıca verilməlidir. Browser profili, hesab adı, e-poçt, qalan balans və digər şəxsi məlumatlar kəsilir. Screenshot-u redaktə etdikdən sonra original həssas faylı public ticket-ə yükləməyin.

Outgoing transfer görünsə belə refund olduğunu fərz etməyin

Contract balansından token çıxdıqda onun sizin hadisənizlə bağlı olub-olmadığını yoxlayın. Eyni token contract-da başqa istifadəçilərdən, reward mexanizmindən və ya liquidity əməliyyatından qala bilər. Outgoing Transfer event-in amount və destination məlumatını original transferlə müqayisə edin; yaxın vaxt və eyni məbləğ yalnız ipucudur. Ticket ID-si, governance proposal və ya rəsmi support cavabı əlaqəni təsdiqləməlidir.

Rescue funksiyası bütün balansı treasury-yə köçürə bilər, sonra maliyyə komandası ayrıca refund göndərə bilər. Bu halda iki on-chain addım və daxili approval olur. İkinci transaction fərqli sender və məbləğlə gələ bilər; fee və compliance çıxılması siyasətdə izah olunmalıdır. Naməlum address-dən gələn kiçik tokeni “verification refund” kimi qəbul edib ona cavab transferi etməyin.

Refund eyni tokenlə, eyni chain-də və original sender-ə edilmirsə, yeni recipient təlimatının kim tərəfindən təsdiqləndiyi yazılmalıdır. Sender exchange hot wallet-dırsa, tokeni həmin address-ə qaytarmaq istifadəçi hesabına avtomatik kredit verməyə bilər. Exchange support xüsusi recovery deposit address və memo tələb edə bilər. Project və exchange ticket-ləri bir-birinə istinad etməli, lakin login və 2FA məlumatı paylaşılmamalıdır.

Dəstək cavabını texniki nəticəyə çevirin

“Contract-dan token çıxarmaq olmur” cavabı alınarsa, səbəbi dəqiqləşdirin: uyğun funksiya yoxdur, admin səlahiyyəti itirilib, token policy ilə istisna edilir, məbləğ minimumdan aşağıdır, yoxsa layihə fərdi recovery etmir. Bunlar istifadəçi üçün eyni sonluğa gedə bilər, amma texniki və sənəd nəticəsi fərqlidir. Rəsmi cavabın tarixi, ticket nömrəsi və cavab verən kanal saxlanılır.

“Mümkündür” cavabı da tarix və zəmanət deyil. İcraçı role, approval mərhələsi, tələb olunan ownership sübutu, mümkün fee və gözləmə müddəti yazılı olmalıdır. Project wallet qoşmağı tələb edirsə, rəsmi domain və imzalanacaq message yoxlanır. Ownership sübutu üçün plain message kifayətdirsə token approval və ya transfer imzalamayın. Hardware wallet ekranında əməliyyat çağırışı görünürsə, bu sadə message imzasından fərqlidir.

Support cavabı yalnız Telegram və ya sosial media şəxsi mesajındadırsa, onu rəsmi hesab və layihə saytındakı kanalla təsdiqləyin. Admin adı, profil şəkli və qrup üzvlüyü səlahiyyət sübutu deyil. Rəsmi ticket heç bir advance fee tələb etmədiyi halda şəxsi mesajla ayrıca payment address verilməsi prosesi dayandırmaq üçün kifayət edən ziddiyyətdir.

Hadisəni bağlamaq üçün hansı statuslardan istifadə edin?

Araşdırılır statusu transaction və recipient təsnifatı hələ tamamlanmadıqda istifadə olunur. Rəsmi müraciətdə statusu ticket qəbul edilib, lakin texniki və ya siyasət qərarı verilməyibsə uyğundur. Bərpa planı təsdiqlənib yalnız səlahiyyətli tərəf addım, destination və şərtləri yazılı verdikdə seçilir. Bərpa tamamlandı isə yeni TxID və faktiki balans nəticəsi yoxlandıqdan sonra yazılır.

Contract-da çıxış yolu yoxdur və səlahiyyətli layihə bunu təsdiqləyibsə, hadisə texniki bərpa yolu yoxdur kimi bağlana bilər. Bu ifadə tokenin chain-də yox olması demək deyil; aktiv contract address-də qala bilər, amma onu hərəkət etdirəcək icazəli code yolu mövcud olmaya bilər. Qəti nəticənin mənbəyi, baxılan implementation və tarix saxlanılır. Gələcək upgrade nəzəri ehtimaldır, hazırkı refund vədi deyil.

Hadisə bağlandıqdan sonra address-in səhv seçilmə səbəbi ayrıca düzəldilir. Token contract-ın recipient kimi kopyalanması, address book etiketi, QR yaradılması, vendor rekvizit dəyişikliyi və ya UI sahəsinin anlaşılmazlığı fərqli nəzarət tədbirləri tələb edir. Yalnız əməkdaşa “diqqətli ol” demək sistem səhvini aradan qaldırmır. Formada token contract və recipient üçün ayrı etiket, chain məcburiyyəti, tam ünvan müqayisəsi və böyük məbləğ üçün müstəqil təsdiq tətbiq edin.