Eyni 0x ünvanı eyni şəbəkə demək deyil: Ethereum və BSC

Bir açar, eyni ünvan, ayrı tarixçə

Ethereum və BNB Smart Chain kimi EVM şəbəkələrində eyni məxfi açardan eyni 20 baytlıq hesab ünvanı yarana bilər. Pulqabıda chain dəyişdikdə 0x... sətrinin dəyişməməsi buna görə normaldır.

Lakin hər chain öz bloklarını və hesab vəziyyətini saxlayır. Ethereum-da token alan ünvanın BSC balansı avtomatik artmır. Bu, eyni mənzil nömrəsinin iki ayrı şəhərdə olmasına bənzəyir: yazılış uyğun gəlir, yerləşmə uyğun gəlmir.

Eyni ünvan niyə eyni balans demək deyil?

EVM uyğun şəbəkələr eyni private key-dən eyni görünən 0x ünvanı yarada bilər. Kriptoqrafik nəzarət eyni olsa da, Ethereum, BSC və digər chain-lər ayrıca nonce, native balans, müqavilə və token vəziyyəti saxlayır. BSC-dəki USDT Ethereum balansında görünməyəcək.

Aktiv hansı şəbəkədədir?

Göndərən tərəfin tam network adı və TxID-si ilə başlayın. Namizəd explorer-lərdə hash, vaxt, from, to, müqavilə və məbləği tutuşdurun. 0x formatı chain seçmir. Wallet tokeni göstərmirsə, əvvəl ünvanı və rəsmi müqaviləni read-only yoxlayın; naməlum DApp-a qoşulmaq lazım deyil.

Çoxşəbəkəli address book necə qurulur?

Bir qeyd yalnız 0x... ünvanından ibarət olmamalıdır. Chain adı və ID-si, aktiv müqaviləsi, recipient, address mənbəyi, son təsdiq tarixi və lazım olan native fee aktivi əlavə olunmalıdır. Platforma address-i üçün hesab daxilindəki depozit səhifəsi mənbə kimi yazılır. Bu cədvəl private key saxlamır. Hər göndərişdə cari qəbul səhifəsi yenə yoxlanılır; address book köməkçidir, daimi zəmanət deyil. Eyni ünvanın müxtəlif chain-lərdə eyni sahibi ola bilməsi platformanın hər chain-i qəbul etməsinə dəlil deyil.

Asset-i başqa chain-ə aparmaq üçün hansı suallar verilir?

Əvvəl aktivin faktiki chain-də sizin nəzarətinizdə olduğu sübut olunur. Sonra məqsəd chain-də qəbul edilən token versiyası, bridge və ya platforma route-u, native fee aktivləri, minimum, slippage və contract riskləri araşdırılır. Eyni 0x recipient-ə birbaşa göndərmək chain-i dəyişmir. Bridge istifadə edilirsə, rəsmi mənbədən daxil olun, source/destination chain və token-i yoxlayın, kiçik sınaq edin. Platforma address-indəki aktivə siz nəzarət etmirsinizsə, bridge imzalaya bilməzsiniz; əvvəl rəsmi support qərarı lazımdır.

Gas-ı hansı chain-ə göndərmək lazımdır?

Yalnız aktivin faktiki yerləşdiyi chain-in native aktivini, öz nəzarət etdiyiniz eyni address-ə göndərin. Ethereum üçün ETH, BSC üçün BNB kimi. Başqa chain-də eyni 0x address-ə native aktiv göndərmək səhv ledger-dəki tokeni hərəkətə gətirmir.

Chain ID və RPC niyə vacibdir?

Wallet adı dəyişdirilə bilər, chain ID isə imza kontekstinin əsas hissəsidir. Custom şəbəkəni yalnız rəsmi sənəddən əlavə edin. “Ethereum” adlı saxta şəbəkə başqa chain ID və zərərli RPC istifadə edə bilər. RPC sizdən seed istəməməlidir.

Hər chain-in nonce-u ayrıdır. Ethereum nonce problemi BSC transaction-unu bloklamır; birində speed up digərini əvəz etmir.

ERC-55 checksum chain-i kodlaşdırmır

Böyük və kiçik hərflərin xüsusi düzülüşü ünvan yazısında bəzi səhvləri tapmağa kömək edir. Checksum-un düzgün olması Ethereum seçildiyini göstərmir. Eyni checksum-lu ünvan BSC görünüşündə də istifadə oluna bilər.

Ona görə ünvan validatorunun “valid” nəticəsini “doğru şəbəkə” kimi təqdim etmək yanlışdır. Validator yalnız sintaksis barədə məhdud cavab verir; qəbul platformasının siyasətini və ünvan sahibini bilmir.

Ünvan şəxsi pulqabınızdadırsa

Etibarlı wallet-də faktiki şəbəkəni açın, eyni ünvanı və rəsmi token müqaviləsini yoxlayın. Sonra hərəkət üçün həmin chain-in native fee aktivini hazırlayın. Bu yeni transaction-dur, köhnə transaction-un şəbəkəsini dəyişmir.

Hardware wallet seed-ini software wallet-a daxil etməyin. Rəsmi multi-network interfeys və cihaz ekranında ünvan yoxlaması daha təhlükəsizdir.

Platforma ünvanı şəxsi pulqabı kimi işləməyə bilər

Şəxsi pulqabıda açara siz nəzarət edirsiniz. Etibar etdiyiniz tətbiqdə doğru chain-i əlavə edib həmin zəncirdəki aktivə baxmaq mümkündür. Bu əməliyyat seed-i başqa sayta daxil etməyi tələb etmir.

Depozit ünvanı platformaya aiddirsə, açarlara və monitorinq sisteminə platforma nəzarət edir. O, bir chain-dəki eyni ünvanı izləyə, digərində isə heç skan etməyə bilər. Hətta texniki olaraq açara malik olsa belə, konkret tokeni qaytarmaq üçün əməliyyat, təhlükəsizlik və uyğunluq proseduru olmaya bilər.

Ünvan platformanındırsa

İstifadəçi platforma backend-inə chain əlavə edə bilməz. Faktiki network, TxID, müqavilə, ünvan, məbləğ və vaxtla rəsmi ticket açın. Platforma eyni görünən ünvanı başqa chain-də də idarə etsə belə, həmin chain-i indeksləməyə və kreditləşdirməyə bilər.

Heç bir üçüncü tərəf platformanın qərarını zəmanətlə deyə bilməz. Yanlış depozit ünvanına əlavə Gas göndərmək nəzarəti sizə vermir.

Artıq yanlış chain-ə göndərmisinizsə

Transaction hash-i doğru zəncirdə tapın. Sonra ünvanın nəzarət növünü müəyyən edin. Şəxsi pulqabıdırsa, etibarlı proqramla faktiki şəbəkəni açın və token contract-ı yoxlayın. Platformadırsa, həmin platformanın girişli rəsmi dəstəyinə müraciət edin.

Bu mərhələlərin heç biri bərpa zəmanəti deyil. Smart contract davranışı, token likvidliyi, ünvan nəzarəti və xidmət qaydası nəticəni dəyişir. “0x eynidir, yüz faiz qaytarılır” ifadəsi texniki faktı yanlış vədə çevirir.

Azərbaycandilli istifadəçi ünvan kitabında yalnız “USDT” və ya şəxsin adını yazmamalıdır. Şəbəkə, aktiv, ünvanın ilk və son simvolları, ünvanın şəxsi pulqabıya yoxsa platformaya aid olması və son yoxlama tarixi birlikdə saxlanmalıdır. Xaricdən ödəniş alanda bu qeyd qarşı tərəfin fərqli EVM şəbəkəsini avtomatik seçməsi riskini azaldır.

Eyni adlı tokenlər necə ayrılır?

Qeyddə “chain + contract + issuer/bridge source” yazın. Bir versiya emitentin native dəstəyi, digəri bridge wrapped token, üçüncüsü saxta ola bilər. Simvol və loqo iqtisadi ekvivalentlik sübutu deyil.

Təhlükəsizlik hadisəsində çoxşəbəkəli risk

Seed sızıbsa, hücumçu eyni açarın bütün EVM chain-lərini yoxlaya bilər. Təhlükəsiz cihazda yeni seed yaradın, chain üzrə native aktiv, token, NFT və allowance inventarı çıxarın. Yalnız hazırda wallet ana səhifəsində görünən aktivi daşımaq kifayət deyil. İnventar cədvəlində private key saxlamayın.

Qeyd

Hər chain üçün explorer linkini və yoxlama tarixini saxlayın. Wallet ekranında token görünmədikdə belə public address inventarı aktivin harada olduğunu sübut edə bilər. İnventar yalnız oxuma mərhələsidir; nəticə tamamlanmadan heç bir bridge və approval imzalanmır.

Hadisə cədvəli hansı sübutları bir yerdə saxlamalıdır?

Əvvəl göndərən platformanın seçdiyi tam şəbəkə adını, withdrawal order nömrəsini və verdiyi TxID-ni yazın. Sonra etibarlı explorer-dən chain ID, block, status, from, to, token müqaviləsi və Transfer məbləğini əlavə edin. Qəbul hissəsində ünvanın haradan götürüldüyünü, ünvanı kimin idarə etdiyini, platformanın hansı şəbəkəni göstərdiyini və Memo tələbinin olub-olmadığını qeyd edin. Bu üç hissə eyni hadisəni müxtəlif səviyyələrdə təsvir edir.

“Ünvan eynidir” ayrıca nəticə deyil. Cədvəl aktivin hansı zəncirdə olduğunu və həmin zəncirdə ünvanı kimin idarə etdiyini göstərməlidir. Bir sətir yalnız ehtimala əsaslanırsa, onu fakt kimi işarələməyin. Məsələn, wallet hazırda Ethereum seçibsə, bu, keçmiş withdrawal-un Ethereum-da aparıldığını sübut etmir. Sübut göndərən tərəfin qeydi və public transaction-dur.

Screenshot yanında mətn dəyərlərini də saxlayın. Şəkildə hash qısaldıla, chain adı görünməyə və tarix sonradan qarışa bilər. Məxfi məlumatları gizlədin, lakin public address və TxID tam qalsın.

Ünvan şəxsi pulqabınıza aiddirsə, addımlar hansı ardıcıllıqla gedir?

Birinci addım eyni private key-in faktiki zəncirdə həmin address-i idarə etdiyini təsdiqləməkdir. Bunun üçün tanıdığınız wallet-in rəsmi multi-chain funksiyasından istifadə edin. Naməlum “recovery wallet” səhifəsinə seed yazmayın. İkinci addım etibarlı RPC və explorer vasitəsilə düzgün chain-i açmaqdır. Üçüncü addım token müqaviləsini rəsmi mənbədən yoxlayıb wallet-da göstərməkdir. Bu mərhələlər yalnız görünüşü və oxuma imkanını dəyişir.

Aktivi köçürmək istəyirsinizsə, faktiki chain-in yerli haqq aktivini hazırlayın. BSC-dəki token üçün BNB, Ethereum-dakı token üçün ETH lazımdır. Eyni 0x address-ə başqa chain-də göndərilmiş yerli aktiv həmin əməliyyatın haqqını ödəmir. Kiçik, əsaslandırılmış məbləğ istifadə edin və platformada withdrawal network-i yenidən yoxlayın.

Son transfer yeni transaction olacaq. Köhnə səhv transaction dəyişmir və tarixçədən silinmir. Həm ilkin TxID-ni, həm fee əlavəsini, həm də son köçürməni uçotda ayrı saxlayın.

Ünvan platformaya aiddirsə, istifadəçi nəyi edə bilməz?

Platforma deposit address-in private key-inə istifadəçi sahib deyil. Address başqa EVM zəncirində eyni görünürsə belə, onu öz wallet-ınıza import etmək olmaz. Yalnız platforma həmin chain-də açara çıxışı, token müqaviləsinin dəstəyini və manual recovery imkanını qiymətləndirə bilər. Buna görə ticket-də konkret sual verin: “Platforma bu address-i faktiki chain-də idarə edirmi və həmin token üçün manual credit qaydası varmı?”

Ticket-ə TxID, chain, address, müqavilə, məbləğ, deposit səhifəsinin seçilmiş network-i, hesab identifikatoru və hadisə vaxtını əlavə edin. “USDT itdi” cümləsi texniki qovluq deyil. Platforma əlavə ownership yoxlaması və ya rəsmi emal haqqı tələb edə bilər; qaydanı yalnız hesab daxilindəki rəsmi kanal təsdiqləməlidir.

Sosial şəbəkədə özünü platforma əməkdaşı kimi təqdim edən şəxs private key istəyə, “cross-chain node” üçün ödəniş tələb edə və ya remote desktop açdıra bilməz. Public TxID-ni bilməsi onun əməkdaş olduğunu sübut etmir, çünki bu məlumat explorer-də hamıya açıqdır.

Gas əlavə edərkən üçüncü səhv necə yaranır?

İstifadəçi tokenin BSC-də olduğunu müəyyən edir, lakin exchange withdrawal-da Ethereum seçib ETH göndərir. Sonra eyni address-də ETH görünsə də, BSC transaction-u üçün BNB yoxdur. Bu səhvin səbəbi address formatına həddindən artıq etibar etməkdir. Gas planında address ilə yanaşı chain adı, yerli aktiv və withdrawal network ayrıca yazılmalıdır.

Wallet estimasiyasını oxuyun, bir transfer üçün kifayət edən və itirilməsi qəbul edilən kiçik məbləğ planlayın. “Aktivləşdirmə paketi” adı ilə böyük məbləğ almaq lazım deyil. Yerli aktiv öz address-inizdə olmalı və transaction imzalandıqda public receipt-də xərc görünməlidir.

Əgər wallet naməlum contract approval tələb edirsə, bu sadə Gas əlavəsi deyil. Əməliyyatı dayandırın, spender, token, allowance və calldata-nı yoxlayın. Fee problemini həll etmək üçün aktivinizi idarə edən üçüncü tərəfə limitsiz icazə vermək məntiqli deyil.

Bridge nə vaxt həll deyil?

Bridge köhnə transaction-u başqa chain-ə çevirmir. Aktiv artıq mənbə chain-də sizin nəzarətinizdədirsə və məqsəd həqiqətən başqa chain tələb edirsə, bridge ayrıca yeni qərar ola bilər. Bu qərarda rəsmi domain, mənbə və təyinat chain, token, minimum məbləğ, destination Gas, claim addımı və contract riski yoxlanılır.

Qəbul platforması aktivin hazırkı chain-ni birbaşa dəstəkləyirsə, əlavə bridge mərhələsi lazım olmaya bilər. Əksinə, platforma address-i sizə aid deyilsə, həmin address-dəki aktivi siz bridge edə bilməzsiniz. İmza hüququ platformadadır.

Bridge pending olarsa, mənbə transaction, cross-chain mesajı və destination icrası ayrı araşdırılır. Eyni məbləği təkrar göndərmək ilkin mesajı sürətləndirmir və iki transfer riski yaradır.

Son təsdiqdən əvvəl iki şəbəkəni yanaşı yazın

Qərar verməzdən əvvəl mənbə və təyinat üçün ayrıca sətir yaradın: chain adı, chain ID, explorer domeni, token contract, aktivin yerləşdiyi ünvan və həmin ünvanın imza sahibi. Eyni 0x mətninin iki sətirdə görünməsi aktivin avtomatik olaraq eyni yerdə olması demək deyil. Balans yalnız sorğunun göndərildiyi şəbəkənin state məlumatıdır.

Əgər qəbul edən xidmət yalnız bir şəbəkə göstərirsə, depozit səhifəsinin vaxtını və ekran görüntüsünü saxlayın. Dəstəkdən cavab gələnədək tokeni başqa contract-a, naməlum bridge-ə və ya “sinxronizasiya ünvanı”na köçürməyin. Belə köçürmə ilkin səhvi düzəltmir, sübut zəncirini isə mürəkkəbləşdirir.

Eyni ünvan hadisəsi üçün təhlükəsiz bərpa planı

EVM ünvanının bir neçə şəbəkədə eyni görünməsi bəzi hallarda aktivə çıxışı asanlaşdıra bilər, amma nəticə yalnız ünvanın kim tərəfindən idarə edildiyindən asılıdır. Şəxsi wallet, hardware wallet, multisig, smart account və platforma depozit ünvanı eyni bərpa qaydasına malik deyil. İlk addım yeni transaction imzalamaq yox, nəzarət modelini sənədləşdirməkdir. Public address-i idarə etmək private key-i paylaşmaq demək deyil; wallet daxilində düzgün chain-i seçərək ownership yoxlanılır.

Şəxsi wallet-da read-only inventar yaradın

İstifadəçi seed və ya hardware cihazı ilə ünvanı özü idarə edirsə, əvvəl hər ehtimal olunan chain-də public balansı yoxlayır. Şəbəkə adı, chain ID, RPC mənbəyi, native balans, token contract və token balansı ayrıca sətirdə yazılır. Wallet UI-si tokeni göstərmirsə, bu aktivin yox olması demək deyil. Etibarlı explorer-də address və contract üzrə balans görünə bilər; wallet-a custom token əlavə etmək yalnız görünüşü dəyişir, aktivin yerini dəyişmir.

Read-only mərhələdə DApp-a qoşulmaq, approval vermək və ya “recovery contract” çağırmaq lazım deyil. Public address və TxID zəncir vəziyyətini görmək üçün kifayətdir. Token contract-ın rəsmi mənbədən götürüldüyünü yoxlayın; eyni simvol və loqo ilə saxta contract yaradıla bilər. Explorer-də contract verification nişanı faydalı ipucudur, amma rəsmi issuer məlumatı ilə müqayisəni əvəz etmir.

Aktiv tapıldıqda həmin chain-in native fee aktivi də yoxlanır. Ethereum-da ETH, BSC-də BNB və başqa EVM şəbəkələrində öz yerli aktivləri tələb olunur. Gas almaq üçün istifadə edilən çıxarış network-i aktivin olduğu chain ilə eyni olmalıdır. Eyni 0x address-ə başqa chain-də coin göndərmək lazım olan Gas balansını yaratmır.

Hardware wallet və derivation path fərqini nəzərə alın

Hardware wallet istifadəçisi eyni seed altında bir neçə hesab görə bilər. Ünvanın cihazda həqiqətən idarə olunduğunu wallet ekranında və cihazın özündə yoxlayın. Sadəcə eyni seed ifadəsini başqa tətbiqə daxil etmək təhlükəsiz həll deyil. Rəsmi wallet inteqrasiyası ilə düzgün account index və derivation path seçilir; naməlum veb-sayta seed yazılmır.

Bir tətbiqdə görünən birinci hesab başqa tətbiqdə avtomatik eyni sıra ilə açılmaya bilər. Bərpa zamanı transferin recipient ünvanı cihazda göstərilən ünvanla tam müqayisə olunur. Uyğun gəlmirsə, “EVM-də ünvanlar eynidir” arqumenti yetərli deyil; doğru account tapılmadan transaction imzalanmır. Bu xüsusilə birdən çox Ledger, multisig və ya köhnə wallet proqramı istifadə olunan hallarda vacibdir.

Hardware cihazında “blind signing” və ya anlaşılmayan calldata tələb edən əməliyyatı bərpa addımı kimi qəbul etməyin. Sadə token transferində recipient, amount, contract və chain məlumatı mümkün qədər aydın görünməlidir. Cihaz təsdiqi private key-i göstərmədən imza verir; support əməkdaşı cihaz ekranını uzaqdan idarə etməməlidir.

Smart account və multisig-də nəzarət necə sübut olunur?

Recipient smart contract wallet və ya multisig ola bilər. Belə ünvanın digər chain-də eyni görünməsi həmin chain-də eyni contract kodunun yerləşdirildiyini sübut etmir. Counterfactual address, factory və deployment qaydası nəzərə alınmalıdır. Explorer-də recipient address-in code vəziyyətini yoxlayın. Bir chain-də contract, digərində boş hesab görünürsə, recovery səlahiyyəti və deployment yolu ayrıca araşdırılır.

Multisig üçün signer-lər, threshold və chain üzrə deployment təsdiqlənir. Bir signer-in private key-ə sahib olması təkbaşına aktiv köçürməyə kifayət etməyə bilər. Naməlum şəxsin “digər chain-də multisig-i aktivləşdirəcəyəm” vədi ilə əlavə signer və ya module quraşdırmaq hesab nəzarətini dəyişə bilər. Rəsmi wallet sənədlərində göstərilən təhlükəsiz prosedurdan kənara çıxmayın.

Smart account-da sponsorlu Gas və account abstraction istifadə oluna bilər, amma bunlar yanlış chain-dəki aktivin avtomatik daşınması deyil. Paymaster yalnız konkret əməliyyatın haqqını ödəyə bilər; token contract, recipient və imza qaydası yenə yoxlanır. “Gasless recovery” ifadəsi limitsiz approval və ya naməlum bundler imzasını təhlükəsiz etmir.

Platforma ünvanında qərarı platforma verir

Recipient birja və ya başqa custodial xidmətin depozit ünvanıdırsa, istifadəçinin eyni address-in private key-inə çıxışı yoxdur. Platforma bəzi EVM chain-lərdə eyni açarı texniki olaraq idarə edə bilər, amma bu, hər token və chain üçün manual recovery öhdəliyi yaratmır. Dəstəklənən network, token contract, sweep infrastrukturu, compliance və minimum məbləğ siyasəti qərara təsir edə bilər.

Rəsmi ticket-də “ünvan hər iki chain-də eynidir” deməklə kifayətlənməyin. Faktiki chain, chain ID, TxID, block, recipient, token contract, məbləğ, deposit ekranında seçilmiş network və hesab identifikatoru verilir. Platformadan recipient address-i həmin chain-də idarə edib-etmədiyini və konkret contract üçün recovery prosesinin olub-olmadığını soruşun. Cavab gələnədək əlavə token və ya Gas göndərməyin.

Platforma ownership və ya emal haqqı tələb edərsə, prosedur yalnız hesab daxilindəki rəsmi kanal və help center qaydası ilə təsdiqlənir. Telegram-da verilən fərdi address-ə “wallet sync fee” göndərilməsi chain üzərində platforma nəzarətini sübut etmir. Public TxID-ni bilən hər kəs hadisəni explorer-də görə bilər; bu məlumat support şəxsiyyətinin sübutu deyil.

Token contract və decimal fərqi səhv nəticə yarada bilər

Eyni token adı müxtəlif chain-lərdə fərqli contract və decimal dəyərinə malik ola bilər. Explorer-də balansın rəqəmi wallet UI-sindən fərqli görünürsə, raw amount və decimal birlikdə oxunur. Məsələn, event-də böyük tam ədəd görmək istifadəçinin milyonlarla token aldığı demək olmaya bilər. Contract metadata-sı rəsmi issuer və qəbul platformasının siyahısı ilə yoxlanır.

Wrapped və bridged tokenlər də eyni simvolu daşıya bilər. Aktiv destination chain-də olsa belə, platforma yalnız native issuer contract-ını qəbul edə bilər. “USDT yazılır” nəticəsi kifayət deyil; contract address ticket-in əsas hissəsidir. Saxta token və ya dəstəklənməyən bridged variantın düzgün address-ə gəlməsi manual credit-i zəmanətli etmir.

Token transfer event-ində recipient düzgün görünür, amma əsas transaction to sahəsi token contract ola bilər. Buna görə yalnız transaction başlığını yox, event log-u da oxuyun. Əksinə, failed receipt içində hazırlanmış event cəhdi yekun state-ə yazılmır. Status, logs və post-transaction balans birlikdə qiymətləndirilir.

Bridge qərarı üçün ayrıca risk kartı hazırlayın

Aktiv şəxsi nəzarətinizdədirsə və həqiqətən başqa chain-ə keçməlidirsə, bridge yeni əməliyyat kimi qiymətləndirilir. Mənbə chain, destination chain, token contract, rəsmi bridge domain-i, min/max məbləğ, fee, destination Gas, claim addımı və mümkün gözləmə müddəti yazılır. Köhnə səhv transaction bridge tərəfindən “geri çevrilmir”; bridge yalnız hazırda idarə etdiyiniz aktivi yeni marşrutla daşıyır.

Kiçik sınaq mümkün olsa da, destination-də yalnız token görünüşünü yox, faktiki istifadə imkanını yoxlayın. Alıcı platforma bridged contract-ı dəstəkləmirsə, sınağın wallet-da görünməsi biznes məqsədini yerinə yetirmir. Destination-də swap və ya transfer üçün Gas lazım ola bilər. Ümumi xərcə mənbə Gas, bridge haqqı, destination claim və son transfer əlavə olunur.

Bridge adı ilə wallet permission, limitsiz token approval və ya naməlum message signature tələb olunursa, hər birinin məqsədini anlayın. Rəsmi domain-i bookmark və layihənin rəsmi sənədləri ilə təsdiqləyin. Axtarış reklamı və sosial şəbəkə linki tək mənbə deyil. Approval məbləği lazım olandan çoxdursa, azaltmaq və əməliyyatdan sonra ləğv etmək imkanını qiymətləndirin.

Hadisəni maliyyə və audit qeydi ilə bağlayın

Yekun sənəddə ilkin transaction, aktivin tapıldığı chain, ownership modeli, recovery əməliyyatları, bütün fee-lər və son recipient nəticəsi ayrı göstərilir. AZN və ya başqa hesabat valyutası istifadə edilirsə, hər əməliyyatın vaxtındakı məzənnə mənbəyi yazılır. Token başqa chain-də tapıldığı üçün onu ilkin tarixdə “itki” və sonradan “gəlir” kimi iki dəfə qeyd etməyin; mühasibat siyasəti ilə uyğun təsnifat seçin.

Recovery mümkün olmayıbsa, səbəb texniki və inzibati hissələrə ayrılır: address idarə olunmur, contract dəstəklənmir, Gas yoxdur, platforma siyasəti imkan vermir və ya iqtisadi xərc məbləğdən böyükdür. Bu nəticə gələcəkdə saxta “yeni node açıldı” vədlərinə qarşı müqayisə nöqtəsi olur. Yeni rəsmi imkan yaranarsa, köhnə seed və ya hesab məlumatını üçüncü tərəfə vermədən ayrıca risk yoxlaması aparılır.

Növbəti transfer üçün address book-da təkcə 0x sətri saxlanmır. Chain adı, chain ID, token contract, recipient sahibi, əlavə Memo tələbi və son yoxlama tarixi eyni qeydə daxil edilir. Göndərmə vaxtında məlumat yenə cari mənbədən açılır. Beləliklə eyni ünvanın rahatlığı şəbəkə fərqini gizlədən riskə çevrilmir.