Solana köçürməsi: ünvan, imza və SOL haqqı

Solana-da bir neçə “ünvan” görə bilərsiniz

Pulqabının əsas ünvanı adətən Base58 ilə göstərilən açıq açardır. Token balansı isə mint və owner ilə əlaqəli token account-da saxlanılır. Blokçeyn məlumatında owner, token account, proqram hesabı və mint ayrıca sətirlər kimi görünə bilər.

Bu səbəbdən əməliyyatdakı hər Base58 sətrini alıcı ünvanı saymaq olmaz. Pulqabının transfer xülasəsində owner və tokeni, daha detallı görünüşdə isə token balance dəyişikliklərini yoxlayın.

Simvol yox, mint dəstəyi vacibdir

Solana-da müxtəlif mint-lər eyni ad və simvoldan istifadə edə bilər. Platforma “USDT on Solana” qəbul edirsə, bu, yalnız onun müəyyən etdiyi mint və depozit axınına aiddir. Axtarış nəticəsində tapılan token loqosu dəstək sübutu deyil.

Göndərməzdən əvvəl üç məlumatı birləşdirin: qəbul səhifəsində Solana şəbəkəsi, dəstəklənən aktiv və ya mint, tam ünvan. Yeni istiqamət üçün kiçik sınaq edin, lakin platformanın minimum depozitindən aşağı məbləğ seçməyin.

SOL və SPL Token arasında əsas fərq

SOL native aktivdir. SPL Token adətən owner-ə bağlı token account-da saxlanılır; mint konkret aktivi müəyyən edir. Explorer-də əsas wallet, source/destination token account və mint birlikdə görünə bilər. Yalnız simvola baxmayın: eyni adlı saxta mint mümkündür.

Platforma Solana depozit ünvanı versə də, bütün mint-ləri qəbul etməyə bilər. Cari aktiv səhifəsində konkret token və şəbəkəni seçin.

Xaricdən SPL Token ödənişi alarkən mesaj nümunəsi necə qurulur?

Alıcı bir mesajda token adı ilə yanaşı rəsmi mint, Solana mainnet, owner/deposit address, minimum sınaq və platforma varsa cari qəbul qeydini verir. Göndərən signature-i paylaşır. Alıcı yalnız wallet-də eyni simvolu görməklə kifayətlənmir; mint və token account balansını yoxlayır. Ödəniş iş və ya xidmət üçündürsə, razılaşdırılmış fiat/AZN dəyəri, məzənnə vaxtı və invoice ayrıca saxlanılır. Blokçeyn signature-i ödəniş məqsədini özü göstərmir. Platforma credit gecikirsə, signature, mint, recipient və confirmation ilə rəsmi ticket açılır; seed və uzaqdan idarə lazım deyil. Bu yerli sənədləşmə həm texniki araşdırmanı, həm də tərəflər arasında hesablaşmanı aydın saxlayır.

Kiçik sınağın sərhədi

Sınaq minimum depozitdən yuxarı olmalı və yalnız signature success deyil, doğru mint-in recipient-də faktiki görünməsi gözlənilməlidir. Əsas ödənişdən əvvəl address və mint yenə müqayisə edilir. Sınaq köhnə order, dəyişmiş clipboard və ya sonradan dayandırılmış platforma network-ünü təsdiqləmir.

Signature TxID rolunu oynayır

Solana əməliyyatı bir və ya bir neçə imza daşıya bilər; axtarış üçün adətən ilk signature istifadə olunur. Signature ünvan deyil. Pulqabının tarixçəsindən tam imzanı kopyalayın və düzgün cluster-də — məsələn mainnet-də — axtarın.

Mainnet, devnet və testnet məlumatları ayrıdır. Test əməliyyatını mainnet brauzerində tapmamaq normaldır. Xüsusi RPC istifadə edən tətbiqdə onun hansı cluster-ə qoşulduğunu ayrıca yoxlamaq lazımdır.

Signature, slot və commitment necə oxunur?

Solana transaction-u signature ilə axtarılır. Wallet “sent” deyəndə signature-i saxlayın və etibarlı mənbədə err, slot, block time və commitment-i yoxlayın. Processed, confirmed və finalized müxtəlif vəziyyətlərdir; platforma daha konservativ hədd tələb edə bilər.

Signature heç yerdə yoxdursa, transaction RPC-dən yayılmamış və ya recent blockhash müddəti bitmiş ola bilər. Bu, zəncirdə err ilə görünən uğursuz transaction-dan fərqlidir.

Commitment mərhələlərini eyni rənglə ölçməyin

Solana processed, confirmed və finalized commitment səviyyələrini fərqləndirir. Bir interfeys confirmed-i “completed”, digəri isə yalnız finalized-dan sonra “success” adlandıra bilər. Termin yox, faktiki commitment və meta error əsasdır.

Platforma finalized nəticədən sonra da tokeni tanımaq, minimumu və hesab xəritələnməsini yoxlamaq üçün vaxt sərf edə bilər. Zəncir statusu ilə daxili balans statusunu iki ayrı mərhələ kimi qeyd edin.

Recent blockhash və itən yerli qeyd

Solana əməliyyatına recent blockhash daxil edilir. İmzadan sonra yayım gecikərsə, blockhash etibarlılığını itirə bilər. Belə əməliyyat sonsuz pending qalmır; pulqabı yeni blockhash ilə yeni mesaj qurmalı və siz onu yenidən yoxlayıb imzalamalısınız.

Signature tapılmırsa:

1. onun həqiqətən signature olduğunu yoxlayın;
2. cluster-i təsdiqləyin;
3. pulqabının yalnız imza yaratdığını, yoxsa RPC-yə göndərdiyini ayırın;
4. başqa etibarlı eyni-cluster məlumat mənbəyində baxın;
5. recent blockhash-in etibarlı olub-olmadığını qiymətləndirin.

Recent blockhash niyə transaction-u məhdudlaşdırır?

Adi transaction recent blockhash ilə məhdud vaxtda etibarlı olur. İmza alınıb gec göndərilərsə, köhnə mesaj işləməyə bilər. Yenidən imza yeni signature yaradır. Əvvəlki signature-i və qəbul balansını yoxlamadan təkrar ödəniş iki uğurlu transaction yarada bilər.

Frontend timeout-u da eyni risk yaradır. Xəta pəncərəsi transaction-un uğursuzluğunu sübut etmir; wallet activity və açıq zəncir məlumatını yoxlayın.

Compute və priority fee nəyi həll edir?

Compute unit limit proqram icrasına resurs sərhədi, priority fee isə planlaşdırma üçün iqtisadi siqnaldır. Yüksək priority fee səhv account, yanlış mint və proqramın biznes şərtini düzəltmir. err və logs hansı instruction-un dayandığını göstərməlidir.

Bir istifadəçi hərəkəti iki transaction-a bölünə bilər: məsələn token account yaratmaq və sonra swap. Birinci success, ikinci failed ola bilər. Bütün signature-ləri saxlayın.

SOL haqqı və token hesabları

Token göndərişində belə haqqı ödəyən hesab adətən SOL istifadə edir. Bəzi axınlarda qəbul üçün əlaqəli token account yaradılması da əlavə xərc yarada bilər. Pulqabı əməliyyat təlimatlarını və maksimum xərci imzadan əvvəl göstərməlidir.

İmza və status yoxlaması üçün bərpa sözləri lazım deyil. “Signature repair” səhifəsi seed istəyirsə, onu bağlayın. Platforma çıxarışında problem varsa, sifariş nömrəsi, signature, cluster, mint, ünvan, məbləğ və vaxtla rəsmi dəstəyə müraciət edin.

Təhlükəsiz qəbul və sübut

Ünvanı cari qəbul səhifəsindən götürün, mint-i rəsmi mənbə ilə yoxlayın, minimumdan yuxarı sınağı faktiki kreditləşməyə qədər gözləyin. Signature, mint, owner, token account, slot və məbləği qeyd edin. Bu məlumat platforma support-u üçün wallet balance şəkilindən daha faydalıdır.

Naməlum airdrop token və NFT linkinə girməyin. Balans yoxlaması seed tələb etmir.

Fee payer sizin hesabınız deyiləndə risk azalırmı?

Xeyr. Solana transaction-da başqa hesab fee payer ola bilər, amma sizin signer kimi verdiyiniz səlahiyyət token transferi və ya account dəyişməsinə icazə verə bilər. “Gas-sız” əməliyyat pulsuz görünür, imza riskini aradan qaldırmır. Signer-ləri, writable account-ları, program ID-ni, mint-i və gözlənilən balans dəyişməsini oxuyun. Naməlum NFT və token sizə göndərilibsə metadata linkinə girmək və “claim” imzası vermək lazım deyil. Public balance yoxlaması wallet connection və seed tələb etmir.

Address Lookup Table və çoxlu instruction zamanı nə edilir?

Versioned transaction Address Lookup Table ilə account siyahısını qısalda və bir neçə instruction-u eyni mesajda birləşdirə bilər. Wallet xülasəsi bütün account-ları göstərmirsə, etibar etdiyiniz simulation və tətbiqin rəsmi izahını istifadə edin. Hansı proqramın çağırıldığını, signer-ləri, writable account-ları, mint və gözlənilən balans dəyişməsini bilmədən blind signing etməyin. Bir instruction xətası bütün transaction nəticəsini poza bilər, amma istifadəçi axınında əvvəlki ayrıca transaction success qala bilər. Buna görə hər signature və asset dəyişməsi ayrıca saxlanılır.

Qeyd

Platforma kreditindən sonra düzgün token mint-i və net məbləği yoxlayın. Eyni simvollu başqa tokenin görünməsi uğurlu depozit sayılmır. Dəstək sorğusunda signature ilə yanaşı mint göstərmək araşdırmanı daha dəqiq edir və saxta token qarışıqlığını azaldır.

Solana transaction nəticəsini meta məlumatından oxumaq

Signature detail səhifəsində slot, block time, fee payer, account siyahısı, instruction-lar və transaction meta birlikdə yoxlanır. Success yalnız proqram çağırışlarının error qaytarmadığını bildirir. Tokenin düzgün owner-a çatdığını pre və post token balances, mint və destination token account vasitəsilə təsdiqləyin.

Fee adətən SOL ilə fee payer hesabından tutulur. Token balansı yüksək olsa da SOL yoxdursa, yeni transaction imzalanmaya bilər. Priority fee və compute budget əlavə olunarsa faktiki xərc dəyişir; köhnə signature-in fee-si gələcək çağırış üçün sabit norma deyil.

Wallet address ilə token account fərqi

SPL tokenləri çox vaxt Associated Token Account daxilində saxlanılır. Xarici transaction siyahısında görünən destination token account əsas wallet ünvanından fərqli ola bilər, lakin onun owner sahəsi gözlənilən wallet-i göstərməlidir. Yalnız outer account siyahısında istifadəçi ünvanını görməmək tokenin itməsini sübut etmir.

ATA mövcud deyilsə, transaction onu yarada və rent ilə bağlı xərc ödəyə bilər. Platforma isə müəyyən token account və memo qaydası tələb edə bilər. Depozit ekranındakı ünvanı olduğu kimi istifadə edin; özbaşına ATA hesablayıb başqa account-a göndərmək credit uyğunluğunu poza bilər.

Mint kimliyini yoxlamaq

Token simvolu, adı və şəkli dəyişdirilə və təqlid oluna bilər. Mint address əsas identifikatordur. Rəsmi issuer məlumatı, platformanın dəstək siyahısı və explorer detail-i arasında mint uyğunluğu yoxlanır. Token-2022 extension-ları və transfer fee kimi davranışlar platformanın dəstəyinə ayrıca təsir edə bilər.

Naməlum airdrop tokeni və NFT wallet-də görünürsə, onun linkinə daxil olmaq məcburi deyil. “Claim”, “verify” və ya “burn for reward” əməliyyatı əlavə imza istəyə bilər. Public mint və account məlumatı imza vermədən araşdırıla bilər.

Blockhash və signature ömrü

Solana transaction recent blockhash istifadə edir. Uzun müddət imzalanıb broadcast edilməyən transaction köhnələ və node tərəfindən qəbul edilməyə bilər. Bu vəziyyətdə eyni byte-ları təkrar göndərmək yerinə etibarlı wallet yeni blockhash ilə transaction-u yenidən qurur. Yeni transaction-un signature-i də yeni olacaq.

Wallet activity lokal olaraq sent göstərə bilər, lakin RPC signature-i tapmaya bilər. Broadcast cavabı, istifadə olunan cluster və yaranan signature yoxlanır. Mainnet, devnet və testnet nəticələri ayrı ledger-lərdədir; yanlış cluster-də axtarış “not found” yaradır.

Commitment səviyyələrini düzgün şərh etmək

processed, confirmed və finalized müşahidənin etibarlılıq səviyyələridir. Platforma öz risk siyasətinə görə daha dərin commitment gözləyə bilər. Explorer-də processed nəticə görünən kimi kredit zəmanəti verməyin. Status zamanla yüksələ və nadir hallarda uğursuz fork müşahidəsi itə bilər.

RPC node gecikəndə iki etibarlı provider fərqli commitment göstərə bilər. Slot və err sahəsini müqayisə edin, sorğunu həddən artıq təkrarlayıb rate limit yaratmayın. Rəsmi platformaya ticket göndərərkən müşahidə vaxtını da yazın.

Compute budget və proqram xətaları

Complex swap və DeFi çağırışı compute unit limitinə çata bilər. Program log hansı instruction-da və hansı custom error ilə dayandığını göstərə bilər. Sadəcə priority fee yüksəltmək məntiqi səhvi, slippage-i və ya hesab icazəsini düzəltmir. Wallet simulation nəticəsini oxumaq lazımdır.

Instruction siyahısında tanımadığınız proqram, əlavə account yazma icazəsi və ya anlaşılmayan transfer varsa, imzanı dayandırın. Solana transaction-u bir imzada bir neçə instruction daşıya bilər. UI-nin “claim” etiketi bütün icranı izah etməyə bilər.

Durable nonce istifadə edilirsə

Bəzi xüsusi iş axınları recent blockhash əvəzinə durable nonce account istifadə edir. Nonce authority və account state düzgün deyilsə transaction uğursuz ola bilər. Adi istifadəçi bunu hər transferdə gözləməməlidir; wallet və platforma açıq göstərmirsə, təsadüfi “nonce repair” təlimatına əməl etməyin.

Durable nonce transaction-u imzalamazdan əvvəl fee payer, authority, recipient və bütün instruction-lar yoxlanır. Authority private key-i heç vaxt support əməkdaşına verilmir. Public nonce account ünvanı texniki araşdırma üçün yetərlidir.

Swap nəticəsini balans dəyişiklikləri ilə yoxlamaq

Swap success olduqda input token azalması, output mint artımı, fee və mümkün wrapped SOL hesabının açılıb-bağlanması meta məlumatında görünür. UI-dəki təxmini output ilə faktiki post balance fərqli ola bilər. Slippage həddi transaction daxilindəki minimum nəticə ilə müqayisə edilir.

Route birdən çox proqramdan keçirsə, hər inner instruction-u əl ilə izah etmək çətin ola bilər, amma əsas mint-lər, owner və net balans dəyişikliyi yenə yoxlanmalıdır. Gözlənilməyən token approval və ya authority dəyişikliyi görünərsə, təhlükəsizlik araşdırması açılır.

Platforma depozitində Memo ehtimalı

Bəzi Solana platformaları ünvanla yanaşı Memo tələb edə bilər. Ünvan custodial hot wallet olduqda Memo daxili istifadəçi hesabını seçir. Memo unudulsa, chain-də token düzgün ünvana çata bilər, lakin avtomatik credit baş verməz. Manual recovery üçün signature, mint, token account, amount və hesab ticket-i lazımdır.

Memo mətnini köhnə screenshot-dan götürməyin. Hər depozitdə cari platforma səhifəsini açın və həm ünvanı, həm Memo-nu yoxlayın. Seed, private key və 2FA kodu Memo bərpası üçün texniki sübut deyil.

Stake hesabı və likvid token fərqi

Native stake account, wallet SOL balansı və liquid staking tokeni eyni aktiv forması deyil. Stake deaktivasiya və epoch qaydalarına tabe ola bilər; liquid token isə ayrıca mint və bazar riskinə malikdir. Platforma yalnız native SOL depozitini dəstəkləyirsə, stake account-u və ya başqa mint göndərmək uyğun deyil.

Unstake prosesində status və available balance ayrılıqda yoxlanır. Explorer-də stake account public görünə bilər, amma authority olmadan kənar support onu hərəkət etdirə bilməz. “Ani açma” üçün seed istəyən xidmət təhlükəlidir.

Address Lookup Table və versiyalı transaction

Versiyalı transaction account-ların bir hissəsini Address Lookup Table-dan götürə bilər. Sadə explorer bütün ünvanları dərhal aydın göstərməsə də, etibarlı decoder resolved account siyahısını təqdim etməlidir. İmza öncəsi wallet-in göstərdiyi proqram və balans dəyişikliklərinə diqqət edin.

Naməlum table və proqram kombinasiyası normal olaraq əlavə yoxlama tələb edir. “Blind signing” riski varsa, hardware wallet və tətbiqin dəstəklədiyi transaction versiyasını təsdiqləyin. Başa düşülməyən əməliyyatı kiçik məbləğ bəhanəsi ilə təsdiqləmək təhlükəsiz deyil.

Dəstəyə təqdim edilən fakt cədvəli

Signature, mainnet cluster, slot, block time, fee payer, destination owner, destination token account, mint, raw və çevrilmiş amount, status və commitment bir yerdə saxlanır. Platforma order ID və depozit səhifəsinin Memo məlumatı ayrıca əlavə olunur. Bu cədvəl “success görünür” kimi qeyri-dəqiq şikayətdən daha tez yoxlanır.

Kredit tamamlandıqda faktiki mint və net məbləği hesab tarixçəsi ilə tutuşdurun. Başqa signature ilə manual sweep edilibsə, platformadan əlaqəni ticket-də qeyd etməsini istəyin. Sonra köhnə depozit məlumatını daimi saymadan növbəti əməliyyat üçün yenisini alın.

Hadisədən sonra wallet gigiyenası

Şübhəli DApp-a imza verilibsə, connected apps siyahısını təmizləmək faydalıdır, lakin əvvəl verilmiş token authority və ya delegate icazəsini avtomatik ləğv etməyə bilər. Token account authority, delegate və son instruction-lar public məlumatla audit olunur. Seed sızması şübhəsində yeni wallet planı daha geniş olmalıdır.

Brauzer əlavəsini və mobil wallet-i yalnız rəsmi mənbədən yeniləyin. Support adı ilə ekran paylaşımı, seed yoxlaması və “validator vergisi” tələb edən şəxslə əlaqəni kəsin. Solana signature, public address və proqram log texniki diaqnostika üçün kifayətdir.

Yekun monitorinq addımları

Transaction-u status dəyişənədək uyğun fasilələrlə izləyin, hər sorğunu eyni saniyədə təkrarlamayın. Signature tapılmırsa cluster və broadcast, failed-dirsə program log, success-dirsə owner-mint-balans, platformada görünmürsə credit mərhələsi araşdırılır. Bu ardıcıllıq problemləri bir-birinə qarışdırmır.

Həll qeydində ilkin simptom, əsas səbəb, public sübut, platforma cavabı və qarşısını alan yeni qayda yazılır. Address book-da chain və mint məlumatı saxlanır, amma cari depozit ünvanı və Memo hər dəfə yenidən yoxlanır.