Chain-də uğurlu, balansda yox: iki mərhələ

Blokçeyn və platforma iki ayrı uçot aparır

Explorer-də success göründükdə konkret chain əməliyyatın icrasını qəbul edib. Platforma balansı isə onun node monitorinqi, token tanınması, təsdiq həddi və daxili müştəri uçotu tamamlandıqdan sonra yenilənir.

Bu iki nəticə eyni anda fərqli ola bilər: zəncir uğurlu, depozit isə processing. Zəncir qeydi platformanın daxili hesabına birbaşa yazmır.

Success nəyi sübut edir?

Success yalnız həmin chain-də göstərilən instruction-un tamamlandığını bildirir. Platforma krediti üçün recipient address hesabınıza aid olmalı, network və token müqaviləsi dəstəklənməli, məbləğ minimumdan yuxarı, Memo/Tag doğru və confirmation həddi tamam olmalıdır. Yaşıl ekran bu şərtlərin hamısını avtomatik sübut etmir.

Token transfer həqiqətən varmı?

EVM/TRON tokenində Transfer hadisəsi, Solana-da mint və token account balans dəyişməsi yoxlanır. Outer transaction success olub yalnız approval və ya başqa method işləmiş ola bilər. Token adı və loqosu saxta müqavilədə də görünür; contract/mint rəsmi mənbə ilə uyğunlaşmalıdır.

AZN və fiat sübutu necə ayrılır?

Bank kartı ödənişi, P2P sifarişi, platforma daxili alış və on-chain deposit ayrı hadisələrdir. AZN qəbzi blokçeyndə transferi sübut etmir. Hər mərhələnin order ID/TxID, vaxt, məbləğ və məzənnəsini ayrıca saxlayın.

Platforma credit monitorinqi üçün şəxsi zaman xətti

Birinci sətir withdrawal/deposit vaxtı və order ID, ikinci sətir on-chain success və blok, üçüncü sətir confirmation həddinə çatma, dördüncü sətir platforma pending/credit, beşinci sətir ticket cavabıdır. Hər sətirdə URL və screenshot saxlanılır. Bu zaman xətti support “hələ confirmation gözləyin” deyəndə həddin nə vaxt keçdiyini göstərir.

Əgər platforma maintenance elan edib, başlanğıc və bitmə vaxtı qeyd olunur. Maintenance bitdikdən sonra köhnə transaction-un avtomatik indekslənib-indekslənmədiyi yoxlanılır. Yenə credit yoxdursa, eyni ticket yenilənir. Sosial mediada public TxID paylaşmaq mümkündür, amma account e-poçtu, telefon, ID və başqa balanslar gizlədilir.

Manual credit nəticəsinin audit edilməsi

Gross amount, service fee, net credit, asset, account və credit time müqayisə olunur. Nəticə original TxID və ticket-lə bağlanır. Platforma refund edibsə, refund chain, address və TxID ayrıca yazılır. Bu audit eyni aktivin həm depozit, həm refund kimi iki dəfə uçota düşməsinin qarşısını alır və gələcək oxşar hadisə üçün real siyasət nümunəsi yaradır; yenə də növbəti hadisəyə zəmanət deyil.

Yaşıl statusdan daha çox sahə oxuyun

Əvvəl success əməliyyatının həqiqətən sizin depozitiniz olduğunu sübut edin. Chain, qəbul ünvanı, məbləğ, token müqaviləsi və vaxt uyğun gəlməlidir.

EVM token transferində xarici to çox vaxt token contract-dır; faktiki alıcı event log-da görünür. Bitcoin-də düzgün çıxışı, Solana-da owner, mint və token balance dəyişməsini, TRON-da isə TRC20 hadisəsini yoxlayın. Sadəcə hash səhifəsinin yaşıl rəngi kifayət deyil.

Platforma hansı mərhələdə dayana bilər?

Chain dəstəyi yoxdur

Ünvan formatı uyğun olsa da platforma faktiki şəbəkəni monitorinq etməyə bilər. Bu halda əlavə təsdiq gözləmək problemi həll etmir; yanlış şəbəkə sorğusu açılmalıdır.

Token müqaviləsi tanınmır

Eyni simvollu token başqa contract və ya mint ola bilər. Platforma chain-i dəstəkləsə də, həmin aktivi kreditləşdirməyə bilər.

Memo və ya Tag yoxdur

Vəsait ortaq platforma ünvanına çatıb, amma müştəri hesabı müəyyən edilməyib. Əməliyyata sonradan Memo əlavə olunmur; rəsmi support prosesi lazımdır.

Təsdiq həddi tamamlanmayıb

Bir blok və ya confirmed etiketi platformanın daxili həddi ilə eyni olmaya bilər. Cari depozit qaydasını yoxlayın.

Minimum və texniki xidmət

Minimumdan aşağı məbləğ, node sinxronizasiya problemi və depozit baxımı zəncir uğurlu olsa da balansı gecikdirə bilər.

Platforma kredit mərhələləri

Xidmət transaction-u görür, müqavilə və məbləği yoxlayır, confirmation/finality gözləyir, risk və address ownership nəzarəti edir, sonra internal ledger-i yeniləyir. Maintenance bu mərhələlərdən birini dayandıra bilər. Eyni depoziti təkrar göndərmək prosesi sürətləndirmir.

Minimum məbləğ problemi

Minimumdan aşağı transfer platforma address-inə success çata bilər, amma avtomatik kredit olmaya bilər. İkinci transaction-un məbləğləri toplanacağına özbaşına ümid etməyin. Cari siyasəti yoxlayın və TxID ilə soruşun; platforma manual fee və ya imtina tətbiq edə bilər.

Address mapping necə işləyir?

Bəzi platformalar hər user-ə ayrı address, bəziləri ortaq address + Memo, bəziləri smart contract deposit method verir. Address platforma nəzarətində olsa da internal user mapping ayrıca sübut tələb edir. O vaxt hesabınızda yaranan depozit səhifəsini və account ID-ni saxlayın.

Hot wallet-in aktivi sonradan başqa ünvana toplaması sizin credit-in tamamlandığını göstərmir. On-chain treasury movement və internal ledger iki sistemdir.

Köhnə və ya səhv deposit address

Keçmiş uğurlu address cari dəstəyi zəmanət vermir. Platforma şəbəkəni dayandıra, contract dəyişə və address-i yeniləyə bilər. Köhnə ekran və history həmin address-in o vaxt hesabınıza aid olduğunu sübut etməyə kömək edir. Explorer label-i təkbaşına ownership sübutu deyil.

Contract deposit ilə sadə transfer

Bəzi xidmətlər xüsusi contract method çağırmağı tələb edir. Tokeni sadəcə contract address-inə transfer etmək order identifikatorunu yaratmaya bilər. Transaction input, events və order məlumatını support-a verin. “Gizli withdraw function” çağırmaq üçün naməlum DApp-a imza verməyin.

Vaxt xətti qurun

Sorğu açmazdan əvvəl üç vaxtı yazın: göndərən platformanın çıxarışı tamamladığı vaxt, zəncir blokunun vaxtı və qəbul platformasında gözləmənin başladığı vaxt. Bu, “çoxdan gözləyirəm” ifadəsindən daha faydalıdır.

Chain təsdiq həddi tamamlanıb və platformanın göstərdiyi müddət keçibsə, qəbul tərəfinə rəsmi sorğu göndərin. Hash, chain, contract/mint, ünvan, məbləğ, vaxt və depozit ekranındakı məlumatı əlavə edin.

Eskalasiya zaman xətti

Confirmation həddi çatanda ilk ticket, platformanın cavab müddəti keçəndə eyni ticket-də follow-up, varsa formal complaint kanalı növbəti addımdır. Hər yeniləmədə cari confirmation və yeni sübut verin. Emosional təkrar mesaj yeni texniki məlumatı əvəz etmir.

Platforma imtina edərsə nə etmək olar?

Rəsmi cavabdan tətbiq olunan siyasəti, texniki səbəbi və varsa formal appeal yolunu soruşun. Ünvan platforma nəzarətində olsa belə, unsupported contract, çox kiçik məbləğ və ya təhlükəsizlik xərci manual bərpanı mümkünsüz edə bilər. İmtina cavabını saxlayın, lakin onu sosial mediada “daxili əməkdaş” axtarmaq üçün paylaşmayın. TxID-ni görən üçüncü şəxs platforma ledger-inə giriş əldə etmir. Normal növbəti addım yalnız rəsmi appeal, yerli peşəkar məsləhət və sübutların qorunmasıdır; seed və qabaqcadan “zəmanət haqqı” deyil.

“İkinci əməliyyatla açmaq” fikrini yoxlayın

Başqa ünvana qaz və ya “doğrulama ödənişi” göndərmək platformanın köhnə depozitini tanıtmır. Bəzi xidmətlər minimum məbləğ üçün toplama qaydası yaza bilər, lakin bunu yalnız rəsmi sənəd təsdiqləməlidir. Təxminlə ikinci ödəniş etməyin.

TxID araşdırması açıq məlumatla aparılır. Məxfi açar, bərpa sözləri, parol və birdəfəlik kod təqdim etmək zəncir uğurunu sübut etmir, yalnız hesab təhlükəsini artırır.

Ticket necə yazılır?

Mövzuya asset, network və “on-chain success, not credited” yazın. Account ID, TxID, recipient, contract/mint, amount, block time, confirmation, platform rule və depozit screenshot əlavə edin. Wrong network və ya missing Memo varsa açıq deyin. Bir əsas ticket saxlayın, müxtəlif sosial media hesablarında təkrar sorğu açmayın.

Dürüst yekun necə səslənir?

“Transaction doğru chain-də success, rəsmi müqavilə və platformanın o vaxt verdiyi address-ə doğru məbləğ çatıb, confirmation həddi keçib, Memo düzgündür; ticket X daxili ledger yoxlamasındadır.” Bu cümlə sübut ilə naməlum nəticəni ayırır. “Platforma mütləq qaytaracaq” və ya “aktiv oğurlanıb” ifadələri mövcud on-chain məlumatdan artıq iddiadır.

Nəyi paylaşmaq olmaz?

Seed phrase, private key, hardware PIN, SMS/authenticator kodu, API secret və remote desktop lazım deyil. Platforma identity proof istəyirsə, yalnız rəsmi upload kanalına verin. “Recovery fee” şəxsi kripto ünvana istənirsə, rəsmi ticket-də təsdiqləmədən ödəməyin.

“Success” sözünü üç ayrı nəticəyə bölün

Birinci nəticə transaction receipt-in protokol səviyyəsində uğurlu olmasıdır. İkinci nəticə gözlənilən aktivin doğru token contract və ya native transfer yolu ilə doğru recipient-ə çatmasıdır. Üçüncü nəticə platformanın həmin on-chain hadisəni sizin daxili hesabınıza kredit etməsidir. Bu üçü eyni vaxtda baş verməyə bilər və birinin sübutu avtomatik olaraq digərini sübut etmir.

Məsələn, EVM receipt success ola bilər, amma göndərilən token platformanın dəstəklədiyi contract deyil. TRON event düzgün ünvana gedə bilər, amma məbləğ minimum depozitdən aşağı qala bilər. Solana transferi doğru mint ilə bitə bilər, lakin Memo tələb olunan custodial hesabda identifikator çatışmaya bilər. Problemi dəqiq mərhələyə ayırmaq support cavabını sürətləndirir.

Recipient sübutunu chain modelinə uyğun çıxarın

Native coin transferində əsas recipient transaction detail-də görünür. ERC20, BEP20 və TRC20 tokenində contract çağırışının to sahəsi token contract ola bilər; faktiki recipient Transfer event-ində yoxlanır. Solana SPL tokenində destination token account-un owner-i əsas wallet ünvanı olmalıdır. Bitcoin-də isə recipient konkret output və output index ilə müəyyən edilir.

Support paketində “ünvana göndərdim” cümləsi əvəzinə chain-ə uyğun sübut göstərin. Event index, token account owner və ya Bitcoin output index səhv recipient mübahisəsini obyektivləşdirir. Explorer screenshot-u domen, hash və lazım olan sahələri göstərsin, lakin hesabın əlaqəsiz şəxsi məlumatlarını açmasın.

Aktiv kimliyini platforma siyahısı ilə tutuşdurun

Token adı və simvolu təkbaşına kimlik deyil. Contract və ya mint address qəbul edən platformanın cari depozit səhifəsindəki aktivlə eyni olmalıdır. Wrapped, bridged, legacy və saxta token eyni simvolu daşıya bilər. Platforma yalnız müəyyən issuer contract-ını indeksləyirsə, başqa contract-dan gələn success event avtomatik kredit olunmayacaq.

Decimals və transfer fee davranışı da yoxlanır. Raw amount düzgün çevrilmədikdə istifadəçi gözlədiyindən fərqli məbləğ görür. Fee-on-transfer tokenində recipient event-i withdrawal ekranındakı gross məbləğdən aşağı ola bilər. Ticket-ə həm raw dəyəri, həm görünən net məbləği yazmaq operatora düzgün reconciliation aparmağa kömək edir.

Minimum depozit və confirmation həddini vaxtla bağlayın

Minimum və tələb olunan confirmation sayı dəyişə bilər. Transfer anındakı platforma səhifəsi, aktiv, şəbəkə və mümkün maintenance bildirişi saxlanmalıdır. Köhnə FAQ və ya başqa istifadəçinin screenshot-u cari şərti sübut etmir. Minimumdan aşağı depozit chain-də itməsə də avtomatik credit və ya recovery siyasətindən kənarda qala bilər.

Confirmation sayını ticket açılan andakı block height ilə qeyd edin. Platforma daha çox blok gözləyirsə, “success” olmasına baxmayaraq gözləmə normal ola bilər. Bitcoin və bəzi digər şəbəkələrdə risk modeli məbləğə görə dəyişə bilər. Sonradan hədd tamamlandıqda yeni timestamp və count əlavə edin, köhnə qeydi silməyin.

Maintenance və indexer gecikməsini fərqləndirin

Maintenance şəbəkənin dayanması demək deyil. Platforma wallet service, node, indexer və ya hot-wallet sweep sistemini müvəqqəti saxlaya bilər. Public chain normal block istehsal etsə də daxili kredit növbəsi gecikə bilər. Rəsmi status səhifəsində başlanğıc vaxtı, təsir edən şəbəkə və bərpa elanını yoxlayın.

Indexer gecikməsində başqa istifadəçilərin transferləri də gecikə bilər, lakin sosial mediada yayılan şayiə sübut deyil. Öz TxID-nizi və platformanın rəsmi bildirişini əsas götürün. Maintenance bitdikdən sonra avtomatik kredit üçün ağlabatan müddət verin; nəticə yoxdursa əvvəlki ticket-ə yeni confirmation və status əlavə edin.

Memo, Tag və daxili hesab xəritələnməsi

Custodial platforma çox istifadəçi üçün eyni chain ünvanından istifadə edib Memo və ya Tag ilə hesabı seçə bilər. Aktiv doğru ünvana çatsa da identifikator boş və ya yanlış olduqda vəsait platformanın nəzarətində, amma istifadəçi ledger-indən kənarda qala bilər. Bu, chain rollback problemi deyil; manual xəritələnmə tələb edir.

Ticket-ə TxID, deposit address, düzgün hesabın cari Memo-su, faktiki yazılmış Memo, məbləğ və göndərən məlumatı əlavə edin. Heç bir üçüncü tərəf yeni ödənişlə köhnə transaction-a Memo əlavə edə bilməz. Recovery haqqı varsa, yalnız platformanın hesab daxilindəki yazılı siyasətindən təsdiqlənməlidir.

Contract vasitəsilə gələn depozitlər

Bəzi platformalar yalnız sadə wallet transferini indeksləyir, smart contract payout, batch transfer və internal transaction formatını avtomatik tanımaya bilər. Explorer event-i doğru recipient göstərirsə, aktiv yenə platformanın ünvanındadır, amma parser gözlənilən modeli görməmiş ola bilər. Ticket-də contract call, event və faktiki recipient məbləği açıq göstərilir.

Platformanın “contract deposit dəstəklənmir” qaydası recovery-nin mümkünsüz olduğu anlamına gəlməyə də bilər, zəmanət verdiyi anlamına da gəlməz. Qərar private key nəzarəti, təhlükəsizlik prosesi və əməliyyat xərcindən asılıdır. İstifadəçi contract-a yenidən çağırış etməzdən əvvəl rəsmi cavabı gözləməlidir.

Hot-wallet sweep-i depozit kimi səhv oxumayın

Platforma daxil olan aktivləri depozit ünvanından mərkəzi hot wallet-ə köçürə bilər. Explorer-də balansın depozit ünvanından çıxması vəsaitin oğurlandığını göstərmir; bu, normal sweep ola bilər. İlk inbound event, sonrakı sweep və daxili credit ayrı zaman xəttində saxlanır.

Support üçün əsas sübut platformanın nəzarət etdiyi depozit ünvanına inbound transferdir. Sonrakı sweep hash-i varsa əlavə etmək faydalıdır, çünki platformanın aktivə çıxış etdiyini göstərə bilər. Bununla belə, yalnız sweep faktına əsasən konkret istifadəçi hesabına kredit hüququ müəyyən edilmir; Memo və hesab ownership-i də yoxlanır.

Yanlış şəbəkə ssenarisi

Eyni 0x ünvan Ethereum, BSC və başqa EVM chain-lərdə eyni açarla idarə oluna bilər, amma platforma bütün chain-lərdə həmin açarı və tokeni dəstəkləməyə bilər. Withdrawal network ilə deposit network fərqlidirsə, doğru recipient mətni success olsa belə avtomatik kredit yaranmır. Chain ID və explorer domeni ticket-də açıq göstərilir.

Platforma səhv chain-də eyni address açarına nəzarət edirsə manual recovery texniki olaraq mümkün ola bilər, lakin əməliyyat siyasət və təhlükəsizlik review tələb edir. İstifadəçi özü platforma ünvanından bridge edə bilməz. “Validator köçürməsi” təklif edən naməlum şəxs platformanın private key nəzarətinə malik deyil.

Compliance review əlamətləri

On-chain transfer düzgün olduqda belə platforma risk, source-of-funds və hesab doğrulaması səbəbindən kredit və ya çıxarışı saxlaya bilər. Bu halda texniki support ilə compliance sorğusu fərqli ola bilər. Hesab daxilində hansı sənəd və məlumatın istəndiyini dəqiq oxuyun, yalnız rəsmi upload kanalından istifadə edin.

Public ticket-ə şəxsiyyət sənədi, tam bank məlumatı və təhlükəsizlik kodu yerləşdirməyin. Compliance nəticəsinin ticket nömrəsi və qərar vaxtı texniki hadisə cədvəlinə əlavə olunur. On-chain success compliance qərarını ləğv etmir, compliance review də transaction receipt-i dəyişdirmir.

Custodial göndərənlə ownership sübutu

Çıxarış başqa birjadan edilibsə, göndərən address platformanın hot wallet-i ola bilər və istifadəçi onun private key-inə sahib deyil. Ownership sübutu withdrawal order ID, hesab tarixçəsi, TxID və rəsmi ticket ilə verilir. “Göndərən ünvan mənimdir” kimi yanlış bəyanat araşdırmanı çətinləşdirir.

Batch çıxarışda eyni TxID bir neçə istifadəçini əhatə edə bilər. Sizin recipient event və məbləğiniz ayrılıqda göstərilməlidir. Göndərən platforma transaction-u yenidən qurub ikinci hash veribsə, hər iki order-hash əlaqəsi saxlanır və yalnız canonical success event əsas götürülür.

Ticket eskalasiyası üçün fakt cədvəli

Bir sətirdə hesab və order, ikinci sətirdə chain və aktiv, üçüncü sətirdə TxID və block, sonra sender, event recipient, contract, amount, confirmation, Memo və platforma statusu yazın. Hər fakta mənbə linki və müşahidə vaxtı əlavə edin. Qısa, yoxlana bilən cədvəl uzun emosional izahdan daha işləkdir.

İlk cavab avtomatikdirsə, eyni məlumatı təkrar yeni ticket-lərə bölməyin. Mövcud ticket-də konkret uyğunsuzluğu göstərin: məsələn, “15 confirmation tamamdır, event recipient depozit ünvanıdır, contract dəstək siyahısı ilə eynidir, credit hələ yoxdur.” Bu forma operatorun növbəti qərarını daraldır.

Recovery təklifini qiymətləndirmək

Rəsmi platforma manual recovery üçün müddət, mümkün fee, dəstəklənməyən hallar və tələb olunan ownership sübutunu yazılı bildirməlidir. “Yüz faiz qaytarırıq” deyən sosial media hesabı, əvvəlcədən şəxsi ünvana ödəniş və seed tələbi ciddi təhlükədir. Domain, ticket və hesab daxilindəki bildirişi yoxlamadan heç nə göndərməyin.

Recovery əməliyyatı yeni on-chain sweep yarada bilər. Yeni hash, net məbləğ, fee və hansı hesaba kredit verildiyi nəticə sənədinə əlavə olunur. Orijinal transaction silinmir; yeni əməliyyat onunla əlaqəli ayrıca sübutdur.

Hadisəni bağlama meyarı

Məsələ yalnız balans UI-də rəqəm görünəndə deyil, doğru aktiv, doğru net məbləğ və istifadə edilə bilən status hesab tarixçəsində təsdiqlənəndə bağlanır. Platforma “credited” yazsa, lakin başqa token və ya yanlış məbləğ göstərsə, ticket açıq qalmalıdır. Mühasibat qeydi TxID və credit ID ilə bağlanır.

Son qeyd əsas səbəbi kateqoriyaya ayırır: confirmation gözləməsi, maintenance, yanlış Memo, minimum məbləğ, dəstəklənməyən contract, səhv chain, parser problemi və ya compliance review. Qarşısını alan addım da konkret yazılır. Bu yanaşma növbəti transferdə eyni səhvi daha tez tanımağa imkan verir.

Çoxsaylı ticket-ləri bir hadisədə birləşdirmək

Göndərən platforma, qəbul edən platforma və chain məlumatı üç ayrı yerdədirsə, hər ticket-in nömrəsini vahid hadisə cədvəlinə daxil edin. Göndərən tərəf broadcast və withdrawal ownership-i, explorer public nəticəni, qəbul edən tərəf isə depozit xəritələnməsi və krediti sübut edir. Bir tərəfin daxili order nömrəsi digər tərəfdə avtomatik tanınmaya bilər.

Yeni cavab gəldikcə əvvəlki faktları dəyişməyin; əlavə sətir yazın. Məsələn, ilkin processing, sonrakı TxID, sonra success event və nəhayət manual credit. Bu ardıcıllıq iki platformanın timestamp fərqini və hansı mərhələdə gecikmə olduğunu göstərir.

Qiymət dəyişməsi ilə token miqdarını qarışdırmamaq

Platforma fiat ekvivalentini cari bazar qiyməti ilə göstərə bilər. On-chain sübut isə token unit və decimals əsasında aparılır. Qiymət düşdüyünə görə balansın dollar dəyərinin azalması token kreditinin əskik olduğu demək deyil. Eyni şəkildə dollar məbləğinin uyğun görünməsi doğru token contract-ını sübut etmir.

Reconciliation zamanı gross token amount, on-chain transfer fee davranışı, recovery haqqı və net token credit ayrıca yazılır. Fiat dəyəri yalnız əlavə məlumat kimi timestamp ilə qeyd olunur. Bu üsul dəyişkən qiyməti texniki çatışmazlıqdan ayırır.

Mobil tətbiq və veb hesab zidd görünürsə

Eyni hesabın mobil və veb interfeysi fərqli cache və refresh vaxtı istifadə edə bilər. Hesab ID, sub-account, wallet növü və seçilmiş aktiv filtri uyğunlaşdırılır. UI-də görünməyən, lakin statement və ya API-də olan kredit front-end gecikməsinə işarə edə bilər.

Refresh üçün seed və ya yenidən wallet import tələb olunmur. Logout etməzdən əvvəl ticket və hesab identifikatorunu saxlayın, sonra rəsmi tətbiqin son versiyasını və status səhifəsini yoxlayın. Naməlum APK və brauzer əlavəsi quraşdırmayın.

Sub-account və şəbəkə hesabını yoxlamaq

Bəzi platformalarda spot, funding, futures, earn və sub-account balansları ayrıdır. Depozit əvvəlcə funding wallet-ə düşə, istifadəçi isə spot səhifəsinə baxa bilər. Hesab tarixçəsində transfer növü, destination wallet və daxili transfer ID-si yoxlanır.

Bu daxili hərəkətin public TxID-si olmaya bilər. On-chain depozit bir dəfə baş verir, sonra platforma ledger-i daxilində balans bölmələri dəyişir. Eyni hash-i ikinci dəfə kredit gözləmək əvəzinə doğru account bölməsini seçin.

Hüquqi və mühasibat sübutunu ayırmaq

Texniki paket chain nəticəsini və platforma hərəkətini göstərir. Mühasibat sənədi isə invoice, order, qarşı tərəf və exchange rate kimi əlavə kontekstə malik ola bilər. Bu iki sənədi eyni faylda saxlasanız belə, private məlumatın support screenshot-una düşməməsinə diqqət edin.

Mübahisə üçün hash və public recipient açıq sübutdur, hesab ownership-i isə platformanın təhlükəsiz kanalında təsdiqlənir. Public forumda şəxsiyyət sənədi paylaşmaq transaction-u sürətləndirmir. Lazım olan minimum məlumat prinsipi qorunur.

Növbəti transfer üçün preflight kartı

Kartda aktiv contract və ya mint, chain, cari depozit ünvanı, Memo ehtiyacı, minimum məbləğ, confirmation həddi, maintenance statusu və kiçik sınaq nəticəsi olur. Recipient clipboard-dan sonra ikinci kanal ilə müqayisə edilir. Platformanın səhifəsi transfer anında yenidən açılır.

Sınaq kredit olunmadan əsas məbləği göndərməyin. Sınaq minimumdan aşağıdırsa onun nəticəsiz qalması sistemin işləmədiyini sübut etmir; məbləğ qaydaya uyğun seçilməlidir. Preflight qeydi gələcək ticket üçün vaxtlı sübut da yaradır.