Solana imzası tapılmır: blockhash və commitment

Pulqabı imza yarada, amma node onu görməyə bilər

Solana transaction mesajı imzalandıqdan sonra RPC-yə göndərilir. İnternet kəsilməsi, RPC xətası, simulyasiya problemi və ya blockhash müddətinin keçməsi nəticəsində pulqabı yerli signature göstərə, ictimai node isə əməliyyat qaytarmaya bilər.

Bu vəziyyətlə zəncirdə failed olan əməliyyatı ayırın. Failed əməliyyat çox vaxt getTransaction nəticəsində meta error ilə görünür. Heç bir mənbədə tapılmayan signature isə yayım mərhələsinə çatmamış ola bilər.

Üç Base58 sətrini qarışdırmayın

Solana ünvanı, transaction signature və blockhash Base58 formasında görünür. Pulqabı tarixçəsindəki paylaşma düyməsindən tam signature-i götürün. Account səhifəsindəki ünvan və ya transaction mesajındakı recent blockhash axtarış üçün eyni məlumat deyil.

Sonra cluster-i yazın. Mainnet signature-i devnet-də, devnet signature-i mainnet-də görünməyəcək. Tətbiq custom RPC istifadə edirsə, onun hansı cluster-ə bağlandığını rəsmi parametrlə yoxlayın.

Signature və order ID-ni ayırın

Solana signature on-chain identifikatordur; platforma order və wallet request ID daxili qeyddir. Orijinal səhifədən tam signature kopyalayın. Platforma vermirsə, əsas sual “mainnet-ə yayımlanıbmı və signature nədir?” olmalıdır.

Yenidən göndərmə qərar cədvəli

Original signature etibarlı mənbələrdə yoxdur, recipient balansı dəyişməyib, wallet-də başqa yeni signature yoxdur və blockhash pəncərəsi bitibsə, yeni transaction qurmaq əsaslı ola bilər. Signature success-dirsə, yenidən göndərməyin. err varsa, əvvəl instruction səbəbini düzəldin. Status naməlumdursa, RPC və wallet support cavabını gözləyin. Hər yeni imzada address, mint, amount və order validity yenidən yoxlanmalıdır; əvvəlki məlumatı avtomatik götürmək olmaz.

Signature sonradan tapılarsa nəticə necə dəyişir?

Signature tapıldıqda err, recipient account, mint, amount, slot və block time yoxlanılır. err yoxdursa və asset dəyişməsi doğrudursa, yeni transfer etmək olmaz; məsələ recipient wallet görüntüsü və ya platforma kreditinə keçir. err varsa, log konkret səbəbi göstərir və yeni transaction qurmazdan əvvəl düzəliş edilir. Signature başqa amount və ya address göstərirsə, order-la əlaqəsi yoxdur və göndərən tətbiqə qaytarılır. Bu keçid ticket-də qeyd olunmalıdır ki, support hələ də “not found” kimi araşdırmasın.

Sonda hansı məlumatlar arxivlənir?

Order ID, bütün candidate signature-lər, blockhash məlumatı, recipient, mint, amount, RPC/app adı və final nəticə birlikdə saxlanılır. Uğursuz və expired namizədləri silməyin; onlar duplicate payment olmadığını izah edir. Məxfi açarlar və giriş kodları arxivə daxil edilmir.

Kiçik yekun

Signature tapılmadan yeni ödəniş qərarı verilmir; açıq sübut həmişə tətbiq bildirişindən üstün tutulur.

Commitment null nəticəsini dəyişə bilər

RPC sorğusu müəyyən commitment tələb etdikdə, əməliyyat həmin səviyyəyə çatmayıbsa və ya node tarixi saxlamırsa null qaytara bilər. Eyni cluster üçün ikinci etibarlı RPC ilə yoxlama aparın və tələb olunan commitment-i qeyd edin.

Commitment-i aşağı salmaq əməliyyatı final etmir. Sadəcə daha erkən müşahidə qatını qəbul edir. Qəbul platforması yenə confirmed və ya finalized gözləyə bilər.

Cluster səhvi

Mainnet, devnet və testnet ayrıca ledger-dir. Eyni address hər birində görünə bilər, lakin test token və signature mainnet-də yoxdur. Wallet və DApp environment-ini yoxlayın. Platforma depoziti adətən yalnız göstərilən mainnet aktivi qəbul edir.

RPC problemi ilə chain nəticəsini necə ayırırsınız?

Bir RPC limit, geridə qalma və tarix saxlamama səbəbi ilə null və ya HTTP error verə bilər. Son slot-u və ikinci etibarlı mənbəni müqayisə edin. Query read-only-dir; custom RPC seed tələb etməməlidir.

İnkişaf etdirici sendTransaction cavabı, RPC URL, vaxt, blockhash, last valid block height və simulation error-u saxlamalıdır. Signature qaytarılması confirmation zəmanəti deyil.

Blockhash etibarlılığını ayrıca yoxlayın

Solana mesajına recent blockhash daxildir. O, müəyyən müddətdən sonra etibarsız olur. isBlockhashValid metodu konkret commitment-də blockhash-in hələ qəbul edilə bilib-bilmədiyini yoxlamağa kömək edir.

Etibarlılıq bitibsə, köhnə imzanı “canlandırmaq” əvəzinə pulqabı yeni blockhash ilə yeni transaction qurmalıdır. Yenidən imzalamazdan əvvəl köhnə əməliyyatın başqa RPC-də həyata keçmədiyini və təkrar ödəniş riski olmadığını yoxlayın.

Recent blockhash necə təsir edir?

Adi transaction məhdud blockhash pəncərəsində etibarlıdır. İmza alınıb gec təqdim olunarsa, köhnə transaction işləməyə bilər və tarixdə görünməyə bilər. Yenidən qurulan transaction yeni signature alır. Əvvəl wallet activity və recipient balansını yoxlamadan təkrar imza iki ödəniş yarada bilər.

Dörd nəticə, dörd addım

Signature tapılır, amma err varsa

Bu artıq “not found” deyil. Logs, instruction index, account, mint, compute və fee-ni oxuyun. Priority fee yanlış account və contract şərtini düzəltmir. Token transferində source/destination token account, owner, mint və balans dəyişməsini yoxlayın.

Frontend timeout və təkrar ödəniş

Tətbiq RPC cavabından əvvəl timeout göstərə bilər, ilk transaction isə success ola bilər. Yenidən ödəmədən wallet activity və qəbul address-i üzrə eyni vaxtdakı bütün signature-ləri yoxlayın. Merchant order bir neçə signature-i eyni payment intent-lə bağlamalıdır.

Yeni transaction qurulanda

Yeni blockhash alındıqdan sonra alıcı, mint, məbləğ, instruction-lar və fee payer-i yenidən oxuyun. Köhnə signature-i yeni mesajın sübutu kimi istifadə etməyin; yeni transaction yeni signature daşıyır.

Heç bir signature yoxlaması bərpa sözləri tələb etmir. Platforma çıxarışı üçün sifariş nömrəsi, signature, cluster, mint, ünvan, məbləğ və vaxt yetərlidir. Seed istəyən “repair bot” pulqabı nəzarətinə çalışır.

Platforma ticket məlumatı

Aktiv, Solana mainnet, məbləğ, recipient, order ID, withdrawal vaxtı, hesabdan çıxma və “on-chain signature yoxdur” məlumatını verin. Yayımlanmayıbsa ləğvi, yayımlanıbsa tam signature-i soruşun. Verilən signature başqa address və məbləğ göstərirsə, göndərən platformaya qaytarın.

Azərbaycandan xaricdəki müştəriyə və ya ailə üzvünə Solana ilə ödəniş göndərirsinizsə, qarşı tərəfə yeni ödəniş etməzdən əvvəl əvvəlki signature-ın mainnet-də olub-olmadığını yoxlayın. AZN uçotu üçün signature, blok vaxtı, razılaşdırılmış məzənnə və alıcının faktiki kredit vaxtını ayrıca saxlayın; platformadakı order ID-ni on-chain signature kimi təqdim etməyin.

Təhlükəsizlik nəticəsi

Olmayan signature-i “mainnet-ə inject” etmək üçün seed, remote desktop və qabaqcadan haqq tələb olunması normal protokol deyil. Ya transaction təqdim olunmayıb və yeni imza lazımdır, ya da başqa signature mövcuddur, ya da success transaction yeni refund tələb edir. Heç biri zəmanətli gizli bərpa xidməti deyil.

Qeyd

Yeni transaction lazım olarsa, əvvəlki order-un hələ aktiv olduğunu və recipient address-in dəyişmədiyini təsdiqləyin. Yeni recent blockhash, yeni signature və yenilənmiş fee ayrıca qeyd olunur. Köhnə signature tapılarsa, duplicate riskinə görə dərhal yenidən yoxlayın.

Signature, address, mint və order ID necə fərqləndirilir?

Solana interfeysində bir neçə Base58 sətri görünə bilər. Signature transaction identifikatorudur, address account və owner rolunu oynaya bilər, mint tokeni müəyyən edir, platform order ID isə yalnız xidmətin daxili sistemində keçərlidir. Hər sətri mənbə sahəsi ilə birlikdə saxlayın. Qısaldılmış ekran görüntüsü kopyalama üçün uyğun deyil.

Explorer-də signature yerinə wallet address axtarsanız account tarixçəsi çıxar; mint axtarsanız token məlumatı görünər; order ID isə heç nə qaytarmaya bilər. Boş nəticə almadan əvvəl doğru dəyərin doğru axtarış sahəsində olduğunu təsdiqləyin. Platforma withdrawal üçün həm daxili order, həm public signature tələb olunur.

İdentifikatoru chat-dan kopyalayanda boşluq, sətir sonu və durğu işarəsini təmizləyin. Lakin sətrin öz simvollarını “düzəltməyin”. Dəyişdirilmiş signature başqa transaction olmur, sadəcə etibarsız sorğuya çevrilir.

Wallet imza yaradıb RPC qəbul etməyibsə nə baş verir?

Wallet istifadəçiyə local activity göstərə bilər, sonra serialized transaction-u RPC-yə göndərir. Bağlantı kəsilməsi, simulation xətası, node rejection və ya blockhash expiry səbəbilə public chain-də davamlı qeyd yaranmaya bilər. Buna görə “wallet-da sent yazılıb” cümləsi public broadcast sübutu deyil.

Mümkünsə sendTransaction cavabını, error mətnini, istifadə olunan RPC-ni, recent blockhash və last valid block height-i saxlayın. Adi istifadəçi wallet notification və vaxtı saxlayıb rəsmi support-a verə bilər. Heç bir mərhələdə seed tələb olunmur.

Retry-dan əvvəl original signature bir neçə etibarlı mənbədə yoxlanır. Yeni blockhash ilə qurulan transaction yeni signature yaradır və hər iki cəhd order jurnalında ayrı göstərilir.

null nəticəsi hansı halları əhatə edir?

null node-un hazırda uyğun transaction statusu qaytarmadığını deyir; səbəbi təkbaşına göstərmir. Yanlış cluster, geri qalan RPC, tarixçə saxlamayan node, hələ qəbul edilməmiş transaction və ya heç vaxt broadcast olunmayan local qeyd mümkün səbəblərdir. İkinci source və latest slot müqayisəsi məlumat xidməti problemini ayırmağa kömək edir.

Signature tapılır və meta içində err varsa, artıq “tapılmır” problemi yoxdur. Bu, icra xətasıdır. Program log, fee, pre/post balances, owner, token account və mint yoxlanılır. Failed transaction üçün recipient-dən uğurlu credit gözləmək olmaz.

Köhnə transaction üçün archival explorer lazım ola bilər. Naməlum şəxsin “private RPC” linkinə seed daxil etmək public tarixçə əldə etməyin normal yolu deyil.

Commitment səviyyələri araşdırmaya necə təsir edir?

Processed, confirmed və finalized eyni mərhələ deyil. Yüksək commitment sorğusu yeni transaction-u müvəqqəti göstərməyə bilər. Əvvəl transaction-un aşağı mərhələdə görünməsini, sonra daha güclü mərhələyə keçməsini izləyin. Platforma finalized tələb edirsə, confirmed nəticə hələ onun credit şərtini tamamlamaya bilər.

Bir source transaction-u processed göstərib sonra itirirsə, slot və source məlumatını saxlayın. Bu, fork və ya data service fərqini araşdırmağa imkan verir. Dərhal eyni ödənişi yenidən yaratmaq əvəzinə, original nəticənin sabitləşib-sabitləşmədiyini yoxlayın.

Qəbul edən tərəfə konkret commitment və signature verin. “Solana success” kimi ümumi söz müxtəlif tətbiqlərdə fərqli mənaya gələ bilər.

Token ödənişinin həqiqətən tamamlandığını necə yoxlayırsınız?

Signature tapıldıqdan sonra transaction meta, owner, destination token account, mint, amount və pre/post token balances yoxlanılır. Associated token account transaction daxilində yaradıla bilər; əsas wallet address-i outer account siyahısında görmək kifayət deyil. Destination token account-un owner-i gözlənilən alıcı olmalıdır.

Token adı və simvolu saxtalaşdırıla bilər. Mint əvvəlcədən alıcı və ya platforma ilə təsdiqlənməlidir. Wrong mint success statusu ilə göndərilsə belə, platforma onu dəstəklənən aktiv kimi credit etməyə bilər.

Platforma deposit üçün signature, mainnet, owner, token account, mint, amount, slot və commitment ticket-ə əlavə edilir. Daxili order nömrəsi ayrıca qalır.

RPC nəticələri zidd görünəndə hansı sıra izlənir?

Əvvəl signature mətnini boşluq və durğu işarələrindən təmizləyin, sonra mainnet endpoint-də getSignatureStatuses və explorer nəticəsini müqayisə edin. Bir RPC null, digəri nəticə qaytarırsa, arxiv dərinliyi və node gecikməsi ehtimalını qeyd edin. Eyni sorğunu saniyədə çox dəfə göndərmək məlumatı final etmir və rate limit yarada bilər.

Slot görünürsə, block time, confirmation status və err sahəsini birlikdə oxuyun. finalized yazısı tokenin düzgün mint və owner-a çatdığını təkbaşına sübut etmir. Token balance dəyişiklikləri və instruction-lar ayrılıqda yoxlanmalı, yalnız bundan sonra platforma dəstəyinə dəqiq sübut paketi göndərilməlidir.

Signature hadisəsini qat-qat necə araşdırmaq olar?

Solana-da “signature tapılmır” bir neçə fərqli vəziyyəti eyni cümlədə gizlədir. Wallet lokal signature yarada, RPC transaction-u qəbul etməyə, node qəbul edib sonra nəticəni saxlamaya və ya istifadəçi yanlış cluster-də axtara bilər. Buna görə araşdırma imzadan başlayır, amma signature ilə bitmir. Cluster, message, recent blockhash, broadcast cavabı, slot və transaction meta ayrı sübut qatlarıdır.

Lokal wallet qeydi hansı faktı göstərir?

Wallet tarixçəsindəki signature istifadəçinin müəyyən message-i imzaladığını göstərə bilər. Bu, həmin baytların etibarlı RPC-yə çatdığını və leader tərəfindən işlənib block-a daxil edildiyini avtomatik sübut etmir. Tətbiq internet bağlantısını itirə, RPC rate limit ala və ya simulation xətasından sonra lokal qeyd saxlaya bilər. Wallet “sent” yazısını public consensus nəticəsi kimi təqdim etməməlidir.

Hadisə anında wallet versiyası, istifadə olunan cluster, RPC adı, signature, recipient, mint, amount və görünən error saxlanır. Məxfi açar və seed saxlanmır. Tətbiq transaction detail-də explorer linki verirsə, linkin mainnet, devnet və ya başqa cluster-ə getdiyini yoxlayın. Səhv cluster linki etibarlı signature üçün boş nəticə yarada bilər.

Əgər tətbiq raw transaction export etməyə icazə verirsə, onu yalnız təhlükəsiz lokal mühitdə saxlayın və public paylaşmadan əvvəl içindəki hesabları anlayın. Raw transaction private key daşımır, amma recipient, amount və başqa əməliyyat məlumatını aça bilər. Naməlum support kanalına bütöv fayl göndərmək əvəzinə signature və public sahələri verin.

Broadcast cavabı hansı sualı həll edir?

RPC sendTransaction və ya uyğun broadcast çağırışına cavab verirsə, signature qaytara bilər. Lakin cavab transaction-un final olduğunu demir. Client confirmation gözləməli və getSignatureStatuses kimi metodla nəticəni izləməlidir. Tətbiq yalnız signature aldıqdan sonra bağlanıbsa, istifadəçi public statusu ayrıca yoxlamalıdır.

RPC error kodu və mesajı mümkün olduqda saxlanır. Preflight simulation failure, blockhash not found, account in use, insufficient funds və rate limit eyni problem deyil. Error-u “network busy” kimi ümumiləşdirmək düzgün recovery seçimini çətinləşdirir. Təkrar cəhd etməzdən əvvəl mesajın hansı mərhələdə rədd edildiyini müəyyən edin.

Bir neçə RPC-yə eyni imzalanmış transaction-u göndərmək bəzən yayım ehtimalını artıra bilər, amma blockhash etibarlılığı bitibsə köhnə baytlar qəbul olunmayacaq. İstifadəçi hər endpoint-ə seed vermir; imzalanmış transaction wallet tərəfindən hazırlanır. Naməlum veb-formaya private key daxil etmək broadcast üsulu deyil.

Recent blockhash və son etibarlı blok hündürlüyü

Adi Solana transaction recent blockhash ilə məhdud müddət üçün etibarlı olur. Wallet transaction hazırlayanda blockhash və last valid block height məlumatını alır. Şəbəkə gecikməsi və ya istifadəçinin imzanı gec təsdiqləməsi bu pəncərəni daralda bilər. Müddət keçdikdən sonra köhnə transaction-u sonsuz təkrar göndərmək onu etibarlı etmir; yeni blockhash ilə yeni message və yeni signature tələb olunur.

Köhnə və yeni signature-i eyni əməliyyat kimi qarışdırmayın. Recipient və amount eyni olsa belə, yeni message ayrıca transaction-dur. Təkrar yaratmazdan əvvəl köhnə signature-in heç bir etibarlı mənbədə qəbul olunmadığını yoxlayın. Əks halda iki ayrı ödəniş baş verə bilər. Xüsusilə platforma withdrawal-u öz retry mexanizminə malikdirsə, istifadəçi ayrıca wallet transferi yaratmamalıdır.

Durable nonce istifadə edən xüsusi transaction-lar adi recent blockhash qaydasından fərqlənə bilər. Belə flow yalnız tətbiq həqiqətən nonce account istifadə etdiyini göstərirsə nəzərə alınır. Ümumi istifadəçi transaction-u üçün “durable nonce idi” fərziyyəsi ilə köhnə signature-i etibarlı saymayın; message və instruction-ları yoxlayın.

RPC mənbələri niyə fərqli nəticə verə bilər?

Node-lar eyni cluster-də olsa da tarixçə saxlanması, index gecikməsi və yük vəziyyəti fərqli ola bilər. Bir RPC null, explorer isə transaction göstərə bilər. Bu halda explorer-in hansı RPC və index-dən istifadə etdiyini bilməsəniz də block, slot, status və meta kimi yoxlanıla bilən sahələri götürə bilərsiniz. İkinci etibarlı RPC ilə signature statusu və slot müqayisə edilir.

Node-un latest slot-u geridədirsə yeni transaction-u görməməsi mümkündür. Yalnız eyni sorğunu sürətlə təkrarlamaq node-u sinxron etmir. Source adı, müşahidə vaxtı və latest slot qeydə alınır. Sonra başqa provider və ya rəsmi endpoint ilə fərq yoxlanır. Araşdırma nəticəsində “RPC A-da 15:20-də null, RPC B-də slot 123-də confirmed” kimi dəqiq cümlə yazılır.

Köhnə transaction üçün bəzi RPC-lər tam tarixçə qaytarmaya bilər. Explorer arxiv nəticəsi göstərirsə, transaction meta və block məlumatı saxlanır. “Heç bir şey tapılmır” qərarı yalnız bir pulsuz endpoint-in məhdudiyyətinə bağlanmır. Bununla belə naməlum arxiv xidmətinə wallet qoşmaq və ya ödəniş etmək məcburi deyil.

Commitment səviyyəsini biznes nəticəsi ilə qarışdırmayın

Processed node-un transaction-u müəyyən fork-da gördüyünü, confirmed daha güclü səsvermə müşahidəsini, finalized isə daha sabit nəticəni ifadə edir. Tətbiq və platforma riskinə görə fərqli commitment tələb edə bilər. İstifadəçi processed nəticəni yekun credit kimi təqdim etməməlidir; eyni zamanda finalized gözləyən platformanın gecikməsini “transaction tapılmır” kimi də təsnif etməməlidir.

İzləmə cədvəlində hər status dəyişikliyi yeni sətir olur. Köhnə processed müşahidəsi silinmir. Əgər transaction sonradan görünməzsə və başqa etibarlı mənbələrdə də yoxdursa, fork və ya provider fərqi ehtimalı qeyd olunur. Yenidən ödəniş yalnız original nəticə və platforma qaydası aydınlaşdıqdan sonra qərarlaşdırılır.

Recipient platforma finalized tələb edirsə, ticket-ə signature, slot, hazırkı commitment, err və token transfer detallarını verin. “Explorer yaşıl göstərir” texniki sübut paketini əvəz etmir. Platforma öz credit mərhələsini ayrıca işlədə bilər.

Priority fee və compute budget nəyi dəyişir?

Yüklü dövrdə tətbiq compute budget və priority fee instruction-ları əlavə edə bilər. Daha yüksək priority fee transaction-un qəbul şansına təsir edə bilər, amma səhv recipient, yanlış mint, vaxtı keçmiş blockhash və ya proqram xətasını düzəltmir. Wallet preview-də ümumi fee və instruction-lar oxunur. Naməlum şəxsə ayrıca “validator haqqı” göndərmək priority fee deyil.

Transaction simulation compute limit-in kifayət etmədiyini və ya proqramın hansı xətada dayandığını göstərə bilər. Limit artırılmadan əvvəl error log-u və çağırılan program yoxlanır. Limitsiz compute seçimi təhlükəsizlik yoxlamasını əvəz etmir. Transaction failed olub block-a daxil olarsa fee istifadə oluna bilər, token transfer isə baş verməz.

Retry zamanı yeni priority parametr əlavə olunursa, yeni signature yaranır. Köhnə və yeni signature eyni case qeydinə bağlanır. Recipient-ə yalnız uğurlu signature nəticəsi təqdim edilir; failed və expired cəhdlər də audit üçün saxlanır.

Versioned transaction və lookup table necə oxunur?

Versioned transaction bəzi account address-ləri Address Lookup Table vasitəsilə gətirə bilər. Sadə explorer görünüşündə bütün hesabları dərhal anlamaq çətin ola bilər. Transaction meta və resolved account siyahısı ilə recipient, token account, mint və program ID-lər yoxlanır. İstifadəçi yalnız outer instruction adından nəticə çıxarmamalıdır.

Wallet və ya köhnə hardware proqramı versioned message-i düzgün dəstəkləmirsə imza və ya göstərmə problemi yarana bilər. Proqramı rəsmi mənbədən yeniləyin və cihaz ekranında göstərilən məlumatı diqqətlə oxuyun. Uyğunluq problemi üçün seed-i başqa sayta köçürmək lazım deyil.

Lookup table unavailable və ya köhnədirsə transaction hazırlığı uğursuz ola bilər. Bu halda tətbiqin rəsmi dəstəyi və program sənədləri yoxlanır. Eyni instruction-u əl ilə naməlum saytda qurmaq böyük risk yaradır, çünki account sırası və writable hüquqları dəyişə bilər.

SPL token depozitini hansı sübutlar tamamlayır?

Token göndərişində recipient wallet address-i ilə destination token account ayrı ola bilər. Associated token account owner-i gözlənilən recipient, mint isə platformanın dəstəklədiyi aktiv olmalıdır. Pre və post token balances faktiki məbləğ dəyişikliyini göstərir. Token simvolu və loqosu contract uyğunluğunu sübut etmir.

Destination token account transaction zamanı yaradılıbsa əlavə instruction və xərc görünə bilər. Yaradılma success olsa, amma token transfer instruction-u failed olsa recipient token almayıb. Bütün transaction atomic ola bilər; meta error yekun state-i müəyyən edir. Explorer-in ayrı-ayrı addımları yaşıl rənglə göstərməsi receipt məntiqini əvəz etmir.

Platforma deposit ticket-i üçün signature, mainnet, slot, commitment, owner, token account, mint, amount və block time verilir. Daxili platform order nömrəsi ayrıca sahədir. Memo və ya reference tələb olunursa onun transaction-da olub-olmadığı da yoxlanır.

Təkrar ödəniş qərarını kim verməlidir?

Şəxsi wallet əməliyyatında owner public status və balansı yoxlayıb yeni transaction qərarı verə bilər. Custodial platforma withdrawal-unda isə retry platformanın sisteminə aiddir. İstifadəçi platforma order-i pending olduğu halda eyni recipient-ə ayrıca wallet transferi etməməlidir. Hər iki ödəniş sonradan uğurlu ola bilər.

Biznes ödənişində recipient-ə vəziyyət üç hissədə izah olunur: original signature public mənbədə görünürmü, aktiv hərəkəti olubmu və yeni cəhd planlaşdırılırmı. “Solana gecikir” kimi ümumi cümlə əvəzinə konkret fakt verilir. Yeni transaction təsdiqlənirsə amount, recipient və invoice əlaqəsi ikinci dəfə yoxlanır.

Hadisə bağlandıqda bütün signature-lər statusla birlikdə saxlanır: expired və ya not broadcast, failed, success. Yalnız son uğurlu hash-i saxlamaq ödənən fee-ni və retry səbəbini gizlədir. Məxfi açar, seed və login məlumatı hadisə jurnalına daxil edilmir.