Memo və ya Tag unudulub: dəstək üçün sübutlar

Ünvan platformanı, Memo isə hesabı göstərə bilər

Bəzi xidmətlər bütün müştərilər üçün ortaq depozit ünvanından istifadə edir. XRP Ledger-də Destination Tag, Stellar-da Memo və digər sistemlərdə bənzər istinad sahəsi platformanın daxilində vəsaitin hansı hesaba aid olduğunu göstərir.

Bu sahə hər chain-də tələb olunmur. Şəxsi pulqabıya köçürmədə lazım olmayan Memo, platformanın depozit səhifəsində məcburi ola bilər. Qaydanı ümumi internet məqaləsindən deyil, qəbul edən tərəfin cari ekranından götürün.

Ünvan və Memo hansı ayrı işi görür?

Ünvan aktivi xidmətin zəncir hesabına çatdırır. Memo, Destination Tag və oxşar identifikator isə ortaq ünvan daxilində konkret istifadəçi hesabını seçə bilər. Doğru şəbəkə və ünvana success transaction, Memo yoxdursa, zəncirdə uğurlu, platformada kreditsiz qala bilər.

Bu, wrong network hadisəsi deyil. Birində ledger düzgündür, daxili hesab identifikatoru çatmır; digərində aktiv platformanın gözləmədiyi chain-dədir.

“Memo problemi” deməzdən əvvəl zənciri yoxlayın

TxID-ni doğru şəbəkədə açın və aşağıdakıları təsdiqləyin:

• status uğurludurmu;
• qəbul ünvanı platformanın verdiyi ünvanla eynidirmi;
• token müqaviləsi və məbləğ dəstəklənirmi;
• tələb olunan təsdiq səviyyəsi tamamlanıbmı;
• Memo/Tag sahəsi boşdur, yoxsa yanlış dəyər daşıyır.

Şəbəkə də səhvdirsə, məsələ yalnız Memo deyil. Sorğunu düzgün kateqoriyaya yönəltmək üçün faktiki chain-i ayrıca qeyd edin.

Müxtəlif dil istifadə edən support-a məlumat necə verilir?

Əvvəl dəyişməyən fakt cədvəli hazırlayın: chain, TxID, address, asset contract, amount, faktiki Memo, düzgün Memo, account ID və vaxt. Sonra izahı Azərbaycan, türk, rus və ya ingilis dilinə çevirsəniz belə rəqəmlər eyni qalır. “Wrong network”, “missing memo” və “not credited” terminlərini qarışdırmayın. Support başqa şöbəyə ötürəndə eyni ticket-i saxlayın və yalnız yeni confirmation və sənədi əlavə edin. Tərcümə zamanı “geri qaytarma zəmanəti” kimi mövcud olmayan nəticə yazmayın. Bu üsul regional istifadəçinin dil maneəsi üzündən texniki kateqoriyanı səhv seçməsinin və saxta tərcüməçi/admin-ə şəxsi məlumat verməsinin qarşısını alır.

Əməliyyat emal olunandan sonra necə bağlanır?

Platforma manual credit edibsə, gross məbləğ, tutulan xidmət haqqı, net balans və tarix yoxlanılır. Refund edibsə, yeni refund TxID, şəbəkə və recipient saxlanılır; “həll edildi” mesajı təkbaşına kifayət deyil. Refund address-i original from kimi kor-koranə seçməyin, çünki göndərən platforma batch hot wallet istifadə edə bilər. Rəsmi qəbul yolu göndərən tərəfdən alınmalıdır. Original TxID, ticket və nəticə bir qovluqda saxlananda sonradan iki əməliyyatın gəlir və ya xərc kimi iki dəfə yazılması qarşısı alınır.

Support gec cavab verirsə nə etmək olar?

Platformanın elan etdiyi cavab müddətini gözləyin, sonra eyni ticket-də TxID və cari confirmation ilə follow-up edin. Yeni ticket-lər açmaq və müxtəlif sosial media “admin”lərinə yazmaq sübutları parçalayır. Rəsmi escalation və complaint kanalı varsa, əvvəlki ticket nömrəsini əlavə edin. İctimai paylaşımda account ID, e-poçt, telefon və şəxsiyyət sənədini gizlədin. Heç bir gecikmə seed və SMS kodunu paylaşmağa əsas yaratmır. Platformanın mümkün manual credit qərarı yalnız onun address nəzarəti və siyasətindən asılıdır.

Təsdiqlənmiş əməliyyata sonradan sətir əlavə edilmir

Əməliyyat zəncirdə təsdiqlənibsə, onun məzmununu redaktə edib itkin Tag yazmaq üçün universal funksiya yoxdur. Vəsait platformanın idarə etdiyi ünvana çatmış ola bilər, lakin daxili sistem onu müştəri hesabına bağlamayıb.

Mümkün həll yalnız qəbul xidmətinin əməliyyatı əl ilə tanımasıdır. Bu, hüquq və ya protokol zəmanəti deyil. Platforma minimum məbləğ, emal haqqı, şəxsiyyət yoxlaması və ya ümumiyyətlə dəstəyin olmaması qaydasını tətbiq edə bilər.

İkinci əməliyyat köhnə Memo-nu düzəldirmi?

Xeyr. Yeni transaction əvvəlkinin sahəsini dəyişmir. Platforma konkret doğrulama transferi istəməyibsə, “düzgün Memo ilə eyni məbləği yenidən göndərmək” ikinci kredit problemi yarada bilər. Rəsmi təlimat varsa, məqsəd, məbləğ, ünvan və ticket nömrəsini təsdiqləyin.

Səhv Memo başqa hesaba uyğun gəlirsə nə baş verir?

Platforma təhlükəsizlik və məxfilik qaydalarına görə iki hesabın məlumatını sadəcə dəyişə bilməz. Əl ilə araşdırma, mənbə sübutu və əlavə doğrulama lazım ola bilər. Digər istifadəçini sosial mediada tapıb pul tələb etməyin; daxili uçotu platforma həll etməlidir.

Rəsmi sorğu üçün məlumat paketi

Ekran görüntüsü tələb edilərsə, yalnız hadisəyə aid hissəni saxlayın. Başqa balansları, ad-soyadı və əlaqəsiz əməliyyatları gizlətmək olar; TxID və chain kimi əsas sahələri dəyişdirmək olmaz.

Dörd sübut necə toplanır?

TxID doğru şəbəkədə success olmalı, qəbul ünvanı platformanın verdiyi ünvanla eyni, aktiv/müqavilə və məbləğ doğru, Memo isə boş və ya səhv görünməlidir. Depozit səhifəsinin o vaxt göstərdiyi Memo tələbinin ekran qeydini saxlayın.

Transaction failed-dirsə, missing Memo kreditləşmənin səbəbi deyil. Ünvan da səhvdirsə, nəzarət araşdırmasına keçin.

Ticket necə hazırlanır?

TxID, şəbəkə, ünvan, məbləğ, blok vaxtı, faktiki Memo, düzgün Memo, hesab ID-si və göndərən tərəfin çıxarış sübutunu bir sorğuda verin. Rəsmi tətbiq və ya özünüz yazdığınız domeni istifadə edin. Platforma məbləğ, haqq və emal müddəti üçün xüsusi siyasət tətbiq edə bilər.

Şəxsiyyət sənədi lazımdırsa, yalnız rəsmi yükləmə kanalına verin. Seed phrase, private key, SMS kodu və remote access heç vaxt Memo araşdırması üçün lazım deyil.

Növbəti dəfə iki dəfə kopyalayın

Köhnə qeyd faylından ünvan götürməyin. Depozit səhifəsini yenidən açın, əvvəl ünvanı, sonra Memo/Tag-i ayrı kopyalayın və göndərmə ekranında hər ikisini yoxlayın. Tətbiq rəqəmdə ön sıfırı və ya simvolu dəyişirsə, imzalamadan əvvəl platforma təlimatı ilə müqayisə edin.

Sınaq məbləği platformanın minimumundan aşağı olmamalıdır. Əks halda Memo düzgün olsa belə, test görünməyə bilər və yanlış diaqnoz yaradar.

Gələcəkdə necə qarşısı alınır?

Hər dəfə ünvan və Memo-nu eyni cari qəbul səhifəsindən kopyalayın. Address book yalnız ünvan saxlayırsa, onu natamam hesab edin. İlk marşrutda minimumdan yuxarı sınaq edin və hesab kreditini gözləyin. Son yoxlama tarixini qeyd edin; köhnə məlumat cari qaydanı əvəz etmir.

Memo-nu necə paylaşmaq daha təhlükəsizdir?

Recipient aktiv, tam şəbəkə adı, address və Memo-nu eyni mesajda verir; göndərən isə hər sahəni öz etiketinə yapışdırır. Şəkil ilə yanaşı kopyalana bilən mətn də saxlanılır. Memo-nun əvvəlində və sonunda boşluq qalmadığını, rəqəm sırasının tam olduğunu yoxlayın.

Dəstək adından gələn təhlükəli tələblər

Platforma açıq TxID-ni öz node-u ilə yoxlaya bilər. Hesabınızı isə girişli support sorğusu ilə tanıyır. Buna görə bərpa sözləri, məxfi açar, parol, API secret və SMS kodu Memo araşdırmasına lazım deyil.

“Tag bərpası üçün əvvəl qaz göndərin” ifadəsi də məntiqsizdir. Problem platformanın daxili xəritələnməsidir; üçüncü şəxsin ünvanına ödəniş orijinal əməliyyata Tag əlavə etmir.

Qeyd

Platforma nəticə verdikdən sonra address book-u düzəldin, lakin Memo-nu daimi və dəyişməz saymayın. Növbəti depozitdə cari səhifəni yenidən açın. Bu vərdiş köhnə identifikatorun başqa hesab və ya yeni şəbəkə qaydasına düşməsinin qarşısını alır.

Dəstək sorğusunu hansı ardıcıllıqla hazırlamaq olar?

Birinci hissədə hesabın rəsmi ticket nömrəsini və depozit məhsulunun adını yazın. İkinci hissədə şəbəkə, aktiv, məbləğ, göndərən ünvan, platformanın depozit ünvanı, TxID, block vaxtı və confirmation sayını verin. Üçüncü hissədə Memo və ya Tag sahəsinin boş, səhv, köhnə və ya başqa hesaba aid olduğunu dürüst qeyd edin. Uyğunsuzluğu gizlətmək recovery yoxlamasını sürətləndirmir.

Explorer linkini platformanın qəbul etdiyi şəbəkəyə uyğun seçin. Eyni simvollu aktiv başqa chain-də də mövcud ola bilər; yanlış explorer sübutu operatoru başqa ledger-ə aparır. Screenshot əlavə edilirsə, domen, TxID və status oxunaqlı qalsın, amma e-poçt, telefon, şəxsiyyət sənədi və balansın əlaqəsiz hissələri örtülsün.

Platforma ownership təsdiqi istəyərsə, yalnız rəsmi tətbiq və rəsmi domen daxilində göstərilən proseduru izləyin. Public address-dən təhlükəsiz mesaj imzası tələb oluna bilər, lakin seed phrase, private key, SMS kodu və uzaqdan ekran nəzarəti heç vaxt tələb olunmamalıdır. Tələbin mahiyyətini anlamırsınızsa, imzalamadan əvvəl ticket-də izah istəyin.

Manual credit prosesində vaxt xəttini necə saxlamaq lazımdır?

TxID-nin ilk confirmation vaxtını, ticket-in açıldığı vaxtı, dəstəyin hər cavabını və status dəyişikliklərini ardıcıl cədvəldə saxlayın. “Araşdırılır”, “manual review”, “recovery approved” və “credited” eyni mərhələ deyil. Təxmini müddəti zəmanət kimi şərh etməyin; fərqli aktiv və şəbəkələrdə compliance, wallet maintenance və minimum məbləğ qaydaları dəyişir.

Operator əlavə transaction tələb edirsə, onun nə üçün lazım olduğunu soruşun. Bəzi platformalar kiçik ownership deposit-i yalnız öz rəsmi təlimatında tətbiq edə bilər, amma sosial şəbəkədə yazan şəxsin ünvanına “verification fee” göndərilməsi etibarlı sübut deyil. Yeni ödəniş orijinal Memo-nu dəyişdirmir və geri qaytarılma zəmanəti yaratmır.

Kredit tamamlandıqda hesab tarixçəsində aktiv, məbləğ və timestamp-i explorer nəticəsi ilə tutuşdurun. Recovery haqqı tutulubsa, ticket-də göstərilən siyasətlə uyğunluğunu yoxlayın. Nəticəni qeyd etdikdən sonra köhnə depozit ünvanı və Tag kombinasiyasını address book-dan silin və yeni transferdən əvvəl cari məlumatı yenidən alın.

Göndərən platforma hansı məlumatı verə bilər?

Çıxarış başqa birja və ya custodial wallet-dən edilibsə, istifadəçi mənbə ünvanın private key-inə sahib olmaya bilər. Bu halda göndərən platformanın withdrawal ID-si, status səhifəsi, TxID-si və hesab tarixçəsi əsas sübutdur. Dəstək ticket-ində “ünvan mənim şəxsi wallet-imdir” demək əvəzinə custodial mənbəni düzgün göstərin.

Göndərən tərəf transaction-u batch şəklində qurubsa, bir TxID daxilində çoxlu output və ya token transfer event-i ola bilər. Yalnız ümumi transaction məbləğini deyil, məhz depozit ünvanına gedən event və məbləği qeyd edin. Bu fərq manual operatorun doğru hesablamanı tapmasına kömək edir.

Çıxarış statusu hələ processing-dirsə və public TxID yoxdursa, qəbul edən platformada Memo bərpası başlatmaq tezdir. Əvvəl göndərən xidmətin broadcast edib-etmədiyini müəyyən edin. Public chain-də əməliyyat yaranmadan recipient tərəfin credit edə biləcəyi aktiv yoxdur.

Mühasibat nəticəsini necə təsdiqləmək olar?

Manual kredit verildikdən sonra hesab tarixçəsində görünən gross məbləği, recovery haqqını və net krediti ayrı qeyd edin. Bunların cəmi chain-dəki depozit event-i və platformanın yazılı qərarı ilə uyğunlaşmalıdır. Başqa aktiv, başqa Memo və ya başqa tarixdəki kreditlə səhv bağlanma görsəniz, ticket-i bağlamadan düzəliş istəyin.

Nəticə sənədində TxID, platforma ticket nömrəsi və kredit vaxtı birlikdə saxlanır. Bu məlumat gələcək audit üçün kifayətdir; hesab parolu, 2FA ehtiyat kodu və şəxsiyyət sənədinin tam surətini şəxsi qeydə əlavə etmək lazım deyil.

Yekun yoxlamada növbəti depozit üçün cari ünvan və Memo yenidən açılır. Köhnə Tag address book-dan silinir, yeni qeyd şəbəkə və aktiv adı ilə etiketlənir. Beləliklə manual recovery nəticəsi gələcək transferdə köhnə identifikatoru təkrar istifadə etmək üçün yanlış əsas yaratmır.

Memo hadisəsini başlanğıcdan sona necə idarə etmək olar?

Memo və ya Destination Tag buraxıldıqda məqsəd transaction-u dəyişdirmək deyil; zəncirdə artıq qəbul olunmuş depozitin platformadakı doğru hesaba aid olduğunu sübut etməkdir. Bunun üçün əvvəlcə hadisəni düzgün təsnif edin. Doğru chain, doğru ümumi depozit ünvanı və doğru aktiv varsa, problem çox vaxt daxili identifikasiya qatındadır. Wrong network, yanlış token contract və ya səhv recipient hadisəsi isə başqa araşdırma tələb edir.

Depozit səhifəsinin hadisə vaxtındakı vəziyyətini qoruyun

Platformalar ünvanı, Memo formatını, minimum məbləği və confirmation tələbini dəyişə bilər. Ticket açmazdan əvvəl cari depozit ekranını saxlayın, lakin hadisə vaxtında istifadə edilən məlumatı da ayrıca qeyd edin. Köhnə screenshot varsa domen, aktiv, network, address və Tag oxunaqlı olmalıdır. Screenshot yoxdursa, əməliyyatdan əvvəl kopyalanmış address book qeydi və withdrawal detail kömək edə bilər; bunları sonradan hazırlanmış “sübut” kimi təqdim etməyin.

Eyni aktiv üçün bir neçə depozit şəbəkəsi varsa, Memo tələbinin hər şəbəkədə eyni olduğunu fərz etməyin. XRP Ledger Destination Tag, Stellar Memo və başqa sistemlərdəki identifikatorlar texniki olaraq fərqlidir. Platformanın UI-də göstərilən adı və formatı olduğu kimi ticket-ə yazın. 0, boş sahə və səhv rəqəm də “Memo yoxdur” hadisəsindən fərqli ola bilər.

TxID daxilində doğru köçürməni seçin

Explorer-də transaction success görünəndə recipient ünvan, aktiv və məbləğ yoxlanılır. Batch çıxarışda bir neçə transfer eyni transaction-da ola bilər; buna görə yalnız ümumi məbləği deyil, sizin depozit ünvanınıza gedən output və ya token event-i seçin. Token contract platformanın dəstəklədiyi rəsmi contract ilə uyğun gəlməlidir. Saxta eyni simvollu tokenin ümumi ünvana çatması manual kredit hüququ yaratmır.

Transaction fee, platforma withdrawal haqqı və faktiki depozit məbləğini qarışdırmayın. Ticket-də göndərilən gross məbləğ, chain-də recipient-ə çatan məbləğ və platformanın gözlədiyi net məbləğ ayrı göstərilir. Explorer-in saat qurşağını da qeyd edin; yerli vaxtla UTC arasındakı fərq operatorun başqa depoziti seçməsinə səbəb ola bilər.

Hesab aidiyyətini təhlükəsiz şəkildə necə göstərmək olar?

Platforma adətən istifadəçinin artıq daxil olduğu hesab, ticket nömrəsi və depozit məlumatı vasitəsilə aidiyyəti yoxlayır. Göndərən şəxsi wallet-dırsa, public address və lazım olduqda təhlükəsiz mesaj imzası ownership sübutu ola bilər. Ancaq mesajın mətni, domain və məqsədi aydın olmalıdır. Token köçürən, approval verən və ya naməlum contract çağıran imza “sadə mesaj imzası” deyil.

Göndərən custodial platformadırsa, istifadəçi mənbə address-in açarına sahib deyil. Bu halda withdrawal order, hesab tarixçəsi, platformanın verdiyi TxID və rəsmi support cavabı istifadə olunur. Başqasının private key-i ilə ownership sübutu yaratmağa çalışmayın. Seed phrase və 2FA kodu heç bir manual credit prosesinin sübut tələbi ola bilməz.

Recovery haqqı və minimum məbləğ necə qiymətləndirilir?

Bəzi platformalar manual araşdırma üçün haqq, minimum bərpa məbləği və ya müəyyən aktivlər üçün dəstək məhdudiyyəti tətbiq edə bilər. Bu qaydalar yalnız platformanın rəsmi yardım səhifəsi və hesab daxilindəki ticket ilə təsdiqlənir. Sosial şəbəkədə göndərilən şəxsi ünvana “node fee” ödəmək manual credit deyil. Haqq varsa məbləğ, tutulma üsulu və nəticə yazılı şəkildə aydın olmalıdır.

İqtisadi qərar verərkən ehtimal olunan net kredit, rəsmi haqq, gözləmə müddəti və əlavə sənəd tələbi müqayisə olunur. Kiçik depozit üçün recovery texniki olaraq mümkün, amma net nəticə mənfi ola bilər. Bununla belə qərar verməzdən əvvəl platformanın faktiki siyasətini öyrənin; təxmin edilən haqqı real qayda kimi yazmayın.

Ticket statusları hansı ardıcıllıqla izlənir?

Ticket açıldı, sübut qəbul edildi, araşdırma başladı, recovery təsdiqləndi və hesab kreditləşdirildi ayrı mərhələlərdir. Hər cavabın vaxtını və tələb olunan növbəti addımı saxlayın. Operator əlavə məlumat istəyirsə, yalnız çatışmayan sahəni verin və əvvəl göndərilən TxID-ni dəyişməyin. Yeni ticket açmaq əvvəlkinin növbəsini sürətləndirməyə bilər, əksinə eyni hadisə üçün zidd qeydlər yarada bilər.

Platforma planlaşdırılmış maintenance və ya wallet yeniləməsi bildirirsə, status səhifəsinin tarixini saxlayın. Maintenance bitdikdən sonra ticket nömrəsi ilə follow-up edin. “Tezliklə” ifadəsini zəmanətli tarix kimi biznes tərəfinə ötürməyin; ödəniş öhdəliyi varsa qarşı tərəfə zəncirdə success, platformada isə manual review olduğunu ayrı izah edin.

Kreditdən sonra nəyi yenidən yoxlamaq lazımdır?

Hesaba məbləğ gəldikdə aktiv kodu, gross məbləğ, tutulan recovery haqqı, net məbləğ və kredit vaxtı chain sübutu ilə tutuşdurulur. Yanlış aktiv və ya yanlış hesab krediti görünürsə, vəsaiti hərəkət etdirmədən ticket-i yenidən açın. Nəticənin screenshot-u saxlanıla bilər, amma hesab balansının əlaqəsiz hissəsi və şəxsi məlumat örtülür.

Son addım köhnə depozit qeydlərini kor-koranə təkrar istifadə etməməkdir. Address book sətirində network və Memo ayrıca yazılır, dəyişiklik tarixi əlavə olunur və növbəti transferdə cari depozit səhifəsi yenidən açılır. Kiçik sınaq əməliyyatı belə Memo tələbini ləğv etmir. Uğurlu manual recovery yalnız keçmiş hadisəni bağlayır; gələcək köçürmənin şərtlərinə zəmanət vermir.

Memo formatındakı xırda fərqlər niyə vacibdir?

Memo, Tag və payment ID yalnız “bir əlavə rəqəm” deyil. Platforma rəqəm, mətn, müəyyən uzunluq və ya xüsusi kod tələb edə bilər. Başdakı sıfır, böyük-kiçik hərf və boşluq bəzi sistemlərdə nəticəni dəyişə bilər. İstifadəçi sahəni əl ilə yenidən yazmaq əvəzinə cari depozit səhifəsindən kopyalayır və göndərən tətbiqin tam dəyəri qəbul etdiyini yoxlayır.

Göndərən platforma Memo sahəsini rəqəm kimi saxlayıb başdakı sıfırı silirsə, preview-də görünən nəticə dayandırma siqnalıdır. Recipient support-dan tələb olunan formatı yazılı şəkildə təsdiqləyin. Sahə uzun görünürsə “qısaltmaq” olmaz. QR code istifadə edilirsə address və Memo-nun hər ikisinin daxil olduğunu preview-də ayrılıqda yoxlayın.

Bəzi wallet-lar Memo, Tag, Destination Tag, Reference və Payment ID üçün ayrı ad istifadə edir. Ad uyğunluğu məna uyğunluğunu avtomatik sübut etmir. Qəbul platformasının help səhifəsi və göndərən tətbiqin network-specific izahı müqayisə olunur. Naməlum “conversion tool”a hesab məlumatı daxil etməyin.

Bir TxID-də çoxlu depozit olduqda uyğunlaşdırma

Batch transaction bir neçə recipient və ya bir neçə token event-i daşıya bilər. Operator ümumi transaction məbləğindən istifadəçi depozitini təxmin etmir. Dəqiq recipient address, event amount, asset contract və transaction vaxtı seçilir. Memo transaction səviyyəsindədirsə onun hansı output və ya hesab üçün istifadə olunduğu chain qaydasına uyğun şərh edilir.

Eyni ümumi depozit address-ə yaxın vaxtda bir neçə eyni məbləğ gəlibsə yalnız məbləğ və timestamp hesab aidiyyətini sübut etməyə bilər. Göndərən address, withdrawal order və platformanın hesab içindəki sübutu əlavə olunur. Support-a başqa istifadəçinin public transaction-unu öz depozitiniz kimi təqdim etmək həm araşdırmanı gecikdirir, həm də yanlış kredit riski yaradır.

Platforma operatoru gross və net məbləği ayırmalıdır. Göndərən xidmət fee-ni məbləğdən çıxarıbsa chain-dəki event order məbləğindən fərqli ola bilər. Ticket-də bu hesab aydın göstərilir. Recovery haqqı sonradan ayrıca tutulursa ilkin depozit event-i dəyişdirilmir.

Yanlış Memo yazılıbsa boş Memo-dan nə fərqi var?

Boş Memo platformaya hesab seçmək üçün heç bir daxili identifikator verməyə bilər. Yanlış Memo isə başqa mövcud hesabı göstərə və daha ciddi ownership yoxlaması tələb edə bilər. İstifadəçi yanlış Tag-in kimə aid olduğunu təxmin etməməli və həmin şəxslə public kanalda əlaqə yaratmamalıdır. Hadisə dərhal rəsmi platforma support-u vasitəsilə bildirilir.

Explorer-də Memo görünürsə tam dəyər ticket-ə daxil edilir. Hesab ekranında nəzərdə tutulan dəyər ayrıca göstərilir. “Bir rəqəm səhvdir” demək əvəzinə sent value və expected value fərqləndirilir. Şəxsi hesab identifikatorunu public forumda paylaşmayın; yalnız rəsmi ticket-də lazım olan hissəni verin.

Platforma yanlış kredit baş verib-vermədiyini daxili sistemdə yoxlayır. İstifadəçi əlavə kiçik transaction göndərib əvvəlkini “düzəldə” bilməz. Yeni Memo ilə yeni transfer yalnız ayrıca depozit yaradar, köhnə transaction-un metadata-sını dəyişməz.

Travel rule və compliance sorğularını texniki recovery-dən ayırın

Bəzi platformalar mənbə xidmət, göndərən şəxs və əməliyyat məqsədi barədə əlavə məlumat istəyə bilər. Bu, Memo-nun on-chain funksiyasından ayrı compliance mərhələsidir. İstənilən sənədin səbəbi, təqdim ediləcəyi rəsmi kanal və saxlanma qaydası anlaşılır. Sosial şəbəkə əməkdaşına şəxsiyyət sənədi göndərilmir.

Compliance review gecikməsi transaction-un chain statusunu dəyişdirmir. Yekun vaxt xəttində “on-chain success”, “Memo matching review” və “compliance review” ayrı göstərilir. Qarşı tərəfə gecikmə izah ediləndə bu mərhələlər qarışdırılmır. Platformanın qərarı əvvəlcədən zəmanət kimi verilməz.

Göndərən custodial xidmət əlavə originator məlumatı təqdim etməlidirsə, iki platforma rəsmi ticket nömrələri ilə koordinasiya edə bilər. İstifadəçi özü saxta bank qəbzi və ya dəyişdirilmiş screenshot hazırlamamalıdır. Yoxlanıla bilən withdrawal detail və public TxID əsasdır.

Komanda üçün Memo nəzarət nöqtələri

Müntəzəm ödəniş prosesində address book qeydi aktiv, network, address, Memo növü, tam dəyər, recipient sahibi və son yoxlama tarixini saxlayır. Operator məlumatı cari depozit səhifəsindən açır; ikinci reviewer address və Memo-nu ayrı müqayisə edir. Kopyala düyməsi yalnız UI rahatlığı deyil, nəticə preview-də yenə yoxlanır.

API çıxarışında Memo ayrıca məcburi parametrdirsə boş dəyər üçün texniki blok qoyulur. Lakin bütün şəbəkələrdə Memo tələb olunmadığına görə qayda recipient konfiqurasiyasına bağlıdır. Avtomatlaşdırma köhnə Tag-i yeni address-ə avtomatik daşımaq əvəzinə dəyişiklik üçün approval tələb edir.

Sınaq əməliyyatı istifadə edilirsə recipient hesabında məhz həmin Memo ilə credit olunduğu təsdiqlənir. Sonra əsas əməliyyat üçün address və Memo yenidən açılır. Sınağın uğuru məlumatın heç vaxt dəyişməyəcəyini sübut etmir. Nəticə TxID və platforma credit vaxtı ilə saxlanır.

Recovery fırıldağını hansı cümlələr tanıdır?

“Memo-nu zəncirdə yenidən yaza bilərik”, “validatora vergi ödə” və “seed ilə hesabı tapacağıq” kimi iddialar texniki reallıqla uyğun deyil. Təsdiqlənmiş transaction-un metadata-sı üçüncü tərəf tərəfindən dəyişdirilmir. Recovery platformanın artıq idarə etdiyi depozit ünvanında daxili hesab uyğunlaşdırmasıdır; private key verməyi tələb etmir.

Saxta support real TxID-ni və məbləği deyə bilər, çünki bunlar public explorer-də görünür. Şəxsiyyətin sübutu rəsmi domain, hesab daxilindəki ticket və əvvəlcədən məlum support kanalıdır. Təcili ödəniş, remote desktop və birdəfəlik kod tələbi dayandırma səbəbidir.

Şübhəli şəxslə əlaqə olubsa message, username, domain və payment address təhlükəsiz saxlanır. Wallet imzası və ya hesab login-i verilibsə platformanın rəsmi təhlükəsizlik prosesi işə salınır. Bu incident manual credit ticket-indən ayrı idarə olunur ki, maliyyə recovery-si hesab kompromisini gizlətməsin.

Recovery qərarının ikinci yoxlaması

Ticket bağlanmazdan əvvəl başqa reviewer TxID, network, recipient, asset contract, sent Memo, expected Memo, gross məbləğ, rəsmi haqq və net credit-i müqayisə edir. Məqsəd support qərarını dəyişmək deyil, başqa depozitin səhvən bu case-ə bağlanmadığını görməkdir. Reviewer platforma hesabına öz səlahiyyəti ilə daxil olur; istifadəçinin parolu paylaşılmır.

Kredit hələ verilməyibsə status “recovery approved” ilə “credited” arasında saxlanır. Biznes uçotunda məbləğ istifadə edilə bilən balans yaranmadan tamamlanmış ödəniş kimi göstərilmir. Eyni zamanda chain-də success nəticəsi də itki kimi dəyişdirilmir; iki qat ayrı qeyd olunur.

Recovery rədd edilibsə konkret səbəb və istifadə olunan siyasət tarixi saxlanır. Gələcəkdə platforma qaydası dəyişərsə köhnə case avtomatik açılmır. İstifadəçi yeni rəsmi imkan barədə məlumat alarsa əvvəlki ticket nömrəsi ilə yenidən qiymətləndirmə istəyir.

Son hesabatda hansı məlumatın silinəcəyi də yazılır. Müvəqqəti şəxsiyyət sənədi və əlaqəsiz screenshot rəsmi retention qaydasına uyğun qorunur və ya silinir. Hadisə reyestrində public TxID, ticket, qərar və net nəticə qalır; seed, 2FA və tam şəxsi sənəd qalmır.

Növbəti əməliyyat owner-i bu nəticəni oxuyub address book və API konfiqurasiyasının həqiqətən yeniləndiyini təsdiqləyir. Dəyişiklik yalnız sənəddə qalıb istehsal prosesinə keçməyibsə case tam bağlanmır. Kiçik sınağın TxID-si və doğru credit nəticəsi düzəlişin işlədiyinə dair praktik sübut kimi saxlanır.

Hesab bağlanıbsa və ya giriş mümkün deyilsə

Depozit köhnə və ya bağlanmış platforma hesabına aid ola bilər. Bu halda yeni hesab açmaq köhnə Memo-nun aidiyyətini avtomatik daşımır. İstifadəçi əvvəlki hesab identifikatorunu, transaction sübutunu və hesabın bağlanma tarixini rəsmi support-a təqdim edir. Platformanın məlumat saxlama və bərpa siyasəti nəticəni müəyyən edir; kənar şəxs hesabı “yenidən aktivləşdirə” bilməz.

Giriş problemi ilə manual credit problemi ayrı ticket mövzuları ola bilər. Əvvəl hesab ownership-i rəsmi qaydada bərpa edilir, sonra depozit case-i həmin hesaba bağlanır. Parolu, e-poçt kodunu və şəxsiyyət sənədini sosial şəbəkədə yazan “agent”ə vermək olmaz. Platforma sənəd istəyirsə yalnız rəsmi domain və təhlükəsiz upload kanalı istifadə edilir.

Hesab hüquqi və ya region səbəbilə məhdudlaşdırılıbsa chain-də success nəticəsi bu məhdudiyyəti ləğv etmir. Support aktivin qaytarılması, hesabda saxlanması və ya başqa prosedur barədə yazılı qərar verməlidir. İstifadəçi naməlum recipient address-ə “çıxarma haqqı” göndərmədən rəsmi variantları qiymətləndirir.

Köhnə hesabla bağlı nəticə alınanda ticket nömrəsi və qərar vaxtı hadisə reyestrinə əlavə olunur. Yeni platforma hesabının Memo-su köhnə depozit üçün istifadə edilmir. Növbəti əməliyyat yalnız yeni hesabın cari depozit səhifəsindən götürülən address və Memo ilə hazırlanır.

Bir neçə platforma arasında məsuliyyəti necə ayırmaq olar?

Göndərən platforma transaction-un broadcast sübutunu və withdrawal order məlumatını verir. Qəbul platforması depozit address-i, Memo qaydası və manual credit siyasətini idarə edir. Blokçeyn isə yalnız public transaction və metadata-nı göstərir. Bir tərəfin cavabını digərinin səlahiyyəti kimi təqdim etməyin.

Göndərən xidmət “chain-də tamamlandı” deyirsə düzgün TxID və network təqdim etməlidir. Qəbul edən xidmət “Memo yoxdur” deyirsə sent Memo, expected Memo və recipient address-i göstərən nəticəni yoxlamalıdır. İstifadəçi eyni fakt cədvəlini hər iki ticket-ə əlavə edir, amma hesab parollarını və şəxsi sənədləri tərəflər arasında kor-koranə daşımır.

İki platforma bir-birinə yönləndirirsə hər ticket-in konkret cavabını saxlayın. Broadcast mövcuddursa göndərən tərəfin işi zəncir sübutu ilə məhdudlaşa bilər; credit qərarı qəbul edən tərəfdədir. Public transaction ümumiyyətlə yoxdursa Memo recovery-si başlatmaq düzgün deyil.

Yekun nəticə məsul tərəfi günahlandırmaq üçün deyil, istifadəçinin növbəti addımını düzgün yerə yönəltmək üçün yazılır. Bu ayrım saxta üçüncü tərəfin “hər iki platformanın node-una çıxışım var” iddiasını da zəiflədir; rəsmi ticket və public sübutdan kənar xüsusi giriş tələb olunmur.