Pending, failed, confirmed və finalized izahı

Eyni söz müxtəlif sistemlərdə başqa mərhələ ola bilər

Pulqabı, RPC, blokçeyn brauzeri və platforma eyni əməliyyat üçün ayrı status yaza bilər. Completed platformanın çıxarış növbəsini, success zəncir icrasını, credited isə qəbul hesabının yenilənməsini göstərə bilər.

Statusu düzgün oxumaq üçün əvvəl onun mənbəyini adlandırın. “Əməliyyat pending-dir” əvəzinə “pulqabı Ethereum əməliyyatını pending göstərir, hash explorer-də görünür” demək diaqnostika üçün daha dəqiqdir.

Wallet, blokçeyn və platforma niyə fərqli status göstərir?

Wallet “sent” ilə imzalanmış məlumatın RPC-yə verildiyini, explorer on-chain nəticəni, platforma isə daxili kreditləşməni təsvir edə bilər. Buna görə eyni vaxtda “wallet completed, chain pending, platform not credited” mümkün kombinasiyadır. Statusu yazanda mənbəni də yazın.

Əsas statuslar nəyi sübut edir?

Token əməliyyatında receipt/log və transfer hadisəsini ayrıca oxuyun. Bir yaşıl işarə bütün aktiv dəyişikliklərini izah etmir.

Mübahisədə hansı status əsas götürülür?

Tərəflər əvvəlcədən completion meyarını yazmalıdır: public chain-də müəyyən confirmation, platforma account credit-i və ya xidmətin order statusu. Bir satıcı wallet-də pending görüb malı verə, alıcı isə platforma withdrawal-u completed sayaraq işin bitdiyini düşünə bilər. Dörd sətirlik audit qeydi — vaxt, mənbə, status, TxID/block — bu fərqi aydınlaşdırır. Interface rəngi hüquqi və texniki sübut deyil; sözlə status, chain nəticəsi və account istifadəsi ayrı yazılmalıdır.

Status dəyişməsə, nə qədər tez-tez yoxlamaq lazımdır?

Saniyəlik refresh yeni sübut yaratmır. Chain-in normal blok ritminə uyğun interval seçin və hər yoxlamada blok hündürlüyü/təsdiq artımını qeyd edin. Pending EVM üçün nonce və fee, Bitcoin üçün mempool/fee rate, Solana üçün signature status və blockhash ayrıca yoxlanır. Platforma maintenance elan edibsə, elan vaxtını saxlayın. Müəyyən edilmiş hədd və normal müddət keçəndə rəsmi ticket açın. Bu plan panikada duplicate transfer və saxta “sürətləndirmə” xidmətinə ödəniş riskini azaldır.

Qeyd

Hadisə bağlananda final status, istifadə edilə bilən balans vaxtı və varsa platforma ticket nəticəsini bir sətirdə yazın. Beləliklə chain success ilə business completion arasındakı fərq gələcək auditdə itmir və eyni əməliyyat ikinci dəfə hesablanmır.

Frilans ödənişini və ya ailə köçürməsini AZN ilə uçota alırsınızsa, status qeydinə TxID, şəbəkə, blok vaxtı, həmin tarixdə istifadə olunan məzənnə və qəbul tərəfinin faktiki kredit vaxtını əlavə edin. Platformadakı “completed” sözü bank qəbzi kimi görünə bilər, lakin blokçeyn və hesab balansı ayrıca sübut tələb edir.

Status lüğəti

Created və ya Signed

Əməliyyat qurulub və imzalanıb, amma RPC-yə çatmaya bilər. İctimai mənbədə TxID yoxdursa, yayım cavabını yoxlayın.

Submitted və ya Broadcast

Tətbiq node-a göndərmə cəhdi edib. Node-un əməliyyatı qəbul etməsi və onu blokda saxlamaq ayrı mərhələdir.

Pending və ya Unconfirmed

Əməliyyat hələ sabit bloka və ya tələb olunan commitment-ə çatmayıb. Ethereum-da nonce və fee, Bitcoin-də mempool şərti, Solana-da blockhash və cluster nəzərə alınır.

Confirmed

Əməliyyat müəyyən zəncir təsdiqi alıb. Platformanın kredit həddi daha yüksək ola bilər. Solana-da confirmed ayrıca commitment səviyyəsidir; başqa chain-də söz başqa cür istifadə edilə bilər.

Success

İcra uğurlu görünür. Token transferində müqavilə hadisəsi və balans dəyişməsini də yoxlamaq lazımdır. Xarici transaction success, gözlənilən tokenin köçdüyünə təkbaşına zəmanət deyil.

Failed və ya Reverted

Bloka daxil olmuş, amma icrada səhv vermiş əməliyyat ola bilər. Qaz və ya resurs istifadə oluna bilər. Pulqabının imzadan əvvəl verdiyi “failed simulation” isə zəncir receipt-i deyil.

Dropped, Replaced və ya Expired

Node əməliyyatı artıq saxlamır, başqa əməliyyat eyni nonce/girişləri əvəz edib və ya Solana blockhash etibarlılığı bitib. Bunlar “vəsait yox oldu” mənasına gəlmir; yeni hash və hesab vəziyyəti araşdırılır.

Finalized

Chain-in daha güclü yekunluq səviyyəsidir. Platformanın daxili kreditləşməsi yenə ayrıca davam edə bilər.

Üç qatlı qeyd nümunəsi

Bu cədvəli dolduranda ziddiyyət görünməyə bilər: platforma completed, chain success, qəbul xidməti processing yaza bilər və hər biri öz qatında doğru ola bilər.

Dropped, replaced və expired necə ayrılır?

Dropped bəzi node-ların pending namizədi saxlamadığını, replaced eyni nonce və ya giriş üçün başqa transaction olduğunu, expired isə məhdud etibarlılıq pəncərəsinin bitdiyini ifadə edə bilər. Bu sözlər wallet-in sadələşdirilmiş etiketi də ola bilər.

EVM-də eyni nonce hash-lərini, Bitcoin-də eyni input konfliktini, Solana-da yeni signature-i yoxlayın. Köhnə hash-in tapılmaması avtomatik refund deyil; ilkin balans və alternativ nəticə də yoxlanmalıdır.

Normal gözləmə nə vaxtdır?

Transaction doğru chain-dədir, ünvan və müqavilə doğrudur, təsdiq artır və qəbul həddi hələ çatmayıbsa, gözləmə normal ola bilər. Hədd keçib kredit yoxdursa, minimum məbləğ, Memo, maintenance və hesab statusu araşdırılır.

Bitcoin pending üçün fee rate/RBF, Ethereum üçün nonce, Solana üçün blockhash kimi chain-specific səbəblər var. Ümumi status cədvəli eyni həll düyməsi yaratmır.

Rəngə yox, sahəyə əsaslanın

Yaşıl, sarı və qırmızı rənglər interfeys dizaynıdır. Hash, chain, blok, status sahəsi, event, confirmation/commitment və platforma qaydası isə yoxlana bilən sübutdur.

Status araşdırması üçün seed və ya məxfi açar tələb olunmur. Sosial şəbəkədə biri “sistemdə statusu dəyişmək” üçün giriş kodu istəyirsə, bu rəsmi zəncir prosesi deyil.

Sübut zaman xətti necə yazılır?

Hər sətirdə vaxt, mənbə, status, blok/təsdiq və etdiyiniz hərəkət olsun. Speed up, cancel, yeni withdrawal və support cavabını gizlətməyin. Birdən çox hash varsa əlaqəsini yazın.

Qəbul edən şəxsə qısa xülasə verin: chain, TxID, ünvanın son simvolları, status və təsdiq. “Success” sözünü “istifadə edilə bilən balans” kimi tərcümə etməyin.

Son nəticə cümləsi

Yaxşı nəticə “transaction pisdir” deyil, “BSC-də success, doğru müqavilə və recipient, 15 təsdiq, platforma hələ kredit etməyib” kimi ölçülə bilən cümlədir. Naməlum hissə ayrıca yazılır. Belə format support, alıcı və göndərənin eyni faktlarla işləməsinə kömək edir.

Təhlükəsizlik sərhədi

Status yoxlaması private key tələb etmir. “Node unlock”, “validator tax” və “manual confirmation” üçün şəxsi ünvana ödəniş normal protokol əməliyyatı deyil. Support yalnız açıq TxID və rəsmi hesab doğrulaması ilə işləməlidir.

Status dəyişəndə hansı sahələr birlikdə yenilənməlidir?

Yalnız Pending sözünü Success ilə əvəz etməyin. Hadisə jurnalında data source, chain, block height, confirmation, receipt result, recipient, token contract, amount və platform order status birlikdə saxlanmalıdır. Bu sahələr fərqli suallara cavab verir: node transaction-u görürmü, protocol onu qəbul edibmi, contract istənilən işi görübmi və platforma istifadəçi balansını kreditləşdiribmi.

Replaced vəziyyətində köhnə və yeni hash, eyni nonce və çıxışların dəyişib-dəyişmədiyi qeyd olunur. Dropped və expired halında wallet yeni transaction yaradıbsa, onun identifikatoru ayrıca yazılır. Bir status sətrinin üstünə yeni dəyər yazmaq audit izini itirər.

Məlumat mənbələri ziddiyyətlidirsə, onların latest block və ya slot dəyərini müqayisə edin. Geri qalan explorer-in cache-i consensus nəticəsini dəyişdirmir.

Ödəniş tərəflərinə vəziyyət necə aydın izah olunur?

“Sistem ilişib” əvəzinə yoxlanılan səviyyəni yazın. Məsələn: “Transaction Ethereum-da public TxID ilə görünür, lakin hələ receipt yoxdur”; “Transfer BSC-də uğurludur, platforma hesabı kreditləşməyib”; “Wallet local signature göstərir, Solana mainnet mənbələri onu tapmır.” Bu cümlələr növbəti addımın kimdə olduğunu da göstərir.

Ödəniş müqaviləsində qəbul üçün tələb olunan confirmation əvvəlcədən göstərilə bilər. Qəbul edən tərəf bir confirmation-u kifayət saymırsa, bunu transaction-dan sonra izahsız dəyişməməlidir. Chain status biznesin mal və ya xidmət öhdəliyini avtomatik həll etmir; invoice və razılaşma ayrıca saxlanır.

Nəticə dəyişəndə qarşı tərəfə eyni TxID və yenilənmiş fakt verin. Yeni transaction yaranıbsa, bunun replacement, retry və ya ikinci ödəniş olduğunu aydın yazın.

Wallet, blockchain və platforma statusu necə ayrılır?

Wallet istifadəçinin imza və broadcast cəhdini göstərir. Blockchain transaction-un consensus və contract nəticəsini göstərir. Platforma isə öz withdrawal, deposit, risk və accounting prosesini idarə edir. Wallet “sent” yaza bilər, amma node transaction-u qəbul etməmiş ola bilər. Chain success ola bilər, amma platforma Memo və ya minimum səbəbilə credit etməyə bilər.

Araşdırmada hər səviyyə üçün öz identifikatorunu istifadə edin. Wallet local ID və ya platform order nömrəsi explorer-də axtarılan TxID deyil. Platforma Completed statusu public broadcast-dan əvvəl daxili mərhələni ifadə edə bilər. Tam TxID olmadan recipient chain-də sübut görə bilməz.

Bu ayrım support ticket-i düzgün tərəfə yönəldir. Broadcast yoxdursa göndərən wallet və ya platforma, contract failed-dirsə DApp və wallet, on-chain success amma credit yoxdursa qəbul platforması araşdırır.

Təkrar yoxlama intervalı necə seçilir?

Hər neçə saniyədən bir refresh etmək transaction-u sürətləndirmir və API limitinə səbəb ola bilər. Chain-in block və ya slot ritmi, transaction-un urgency-si və platformanın elan etdiyi emal intervalına uyğun yoxlama nöqtələri seçin. Hər nöqtədə eyni sahələri saxlayın ki, statusun həqiqətən dəyişib-dəyişmədiyi görünsün.

Şərt əsaslı eskalasiya daha faydalıdır: TxID public mənbələrdə görünmür, confirmation müəyyən müddət artırmır, receipt failed olur, platforma həddi keçilsə də credit yoxdur və ya maintenance statusu dəyişir. “Çox gözlədim” əvəzinə konkret şərti ticket-ə yazın.

İkinci transaction yaratmazdan əvvəl son dəfə original TxID-ni yoxlayın. Network bərpa olunanda hər iki transaction uğurlu ola bilər.

Yekun status hesabatı hansı cümlə ilə bağlanır?

Hesabatda final public nəticə, faktiki asset movement, platform credit və biznes nəticəsi ayrı sətirlərdə yazılır. Məsələn: “TxID block-da success oldu; USDT Transfer düzgün contract-dan recipient address-ə çatdı; platforma ticket 123 vasitəsilə daha sonra credit etdi; ödəniş həmin vaxt bağlandı.” Bu format gələcək dispute zamanı hər mərhələni yenidən yoxlamağa imkan verir.

Əgər platforma hələ qərar verməyibsə, bunu unknown kimi saxlayın. On-chain success platformanın manual recovery siyasətini əvvəlcədən müəyyən etmir. Eyni şəkildə failed transaction üçün ödənən Gas alıcının aktiv aldığını sübut etmir.

Public məlumatla izah edilə bilməyən “validator açma pulu” və “node vergi” tələbi hesabatın bir hissəsi deyil; bu, təhlükəsizlik hadisəsi kimi qeyd olunur.

Status dəyişəndə hansı qeydi yeniləmək lazımdır?

İzləmə cədvəlində hər müşahidəyə vaxt, istifadə olunan explorer, block nömrəsi, confirmation sayı və görünən status əlavə edin. Pending sonradan success olarsa, köhnə sətri silməyin; yeni sətrə keçidin vaxtını yazın. Failed nəticəsi dəyişməz qalsa, yalnız wallet tətbiqinin yaşıl bildirişinə əsasən “tamamlandı” qeyd etməyin.

Token transferində statusla yanaşı event log və alıcının balans dəyişikliyi də saxlanılır. Platforma kreditini isə ayrıca sütunda izləyin. Bu ayırma node nəticəsi, aktiv hərəkəti və mərkəzləşdirilmiş xidmətin daxili uçotu arasında səbəbsiz nəticə çıxarmağın qarşısını alır.

Statusları əməliyyat həyat dövrü üzrə necə oxumaq olar?

Status sözü yalnız ona cavab verən sistem adı ilə məna qazanır. Wallet istifadəçi niyyətini və lokal göndərişi, RPC node-un gördüyü transaction-u, consensus zəncir nəticəsini, token contract aktiv hərəkətini, platforma isə daxili accounting-i göstərir. Bu qatların hər birində “pending” və “completed” kimi oxşar söz ola bilər. Araşdırma cümləsində mənbə yazılmadıqda iki tərəf eyni sözdən fərqli mərhələ başa düşür.

Hazırlanmış, imzalanmış və yayımlanmış eyni deyil

Transaction wallet-da hazırlananda recipient, amount, fee və başqa sahələr hələ dəyişə bilər. İmza verildikdən sonra müəyyən message təsdiqlənir, amma internet və RPC problemi səbəbindən message node-a çatmaya bilər. Broadcast cavabı alındıqda public identifikator yaranır, lakin transaction hələ block-a daxil edilməyə bilər. Hər mərhələ üçün vaxt və nəticə ayrı saxlanır.

Wallet submitted yazırsa detail səhifəsində TxID və explorer linki axtarın. Public hash yoxdursa tətbiqin hansı statusu “submitted” adlandırdığını rəsmi sənəddən yoxlayın. Custodial platforma order-i compliance və ya withdrawal queue mərhələsində saxlaya bilər; bu zaman recipient chain-də heç bir transaction yoxdur. Qəbul edən tərəfə “blockchain pending” demək yanlış ola bilər.

Broadcast rejected olduqda error səbəbi vacibdir. Insufficient fee, invalid nonce, expired blockhash, simulation revert və rate limit fərqli addım tələb edir. Sadəcə düyməni yenidən basmaq iki transaction və ya yeni fee riski yarada bilər. Original message və retry əlaqəsi jurnalda saxlanır.

Mempool və ya pending statusu nəyi göstərir?

Bitcoin və bəzi EVM şəbəkələrində node transaction-u qəbul edib hələ block-a daxil etməyibsə pending və ya unconfirmed görünür. Bu, recipient-in final balans əldə etdiyini sübut etmir. Fee, nonce sırası, input conflict və node policy nəticəyə təsir edə bilər. Müxtəlif node-ların mempool-u tam eyni olmaya bilər; bir explorer-də görünməmək transaction-un hər yerdə yox olması demək deyil.

EVM-də aşağı nonce ilə gözləyən transaction sonrakıları bloklaya bilər. Wallet son transaction-u pending göstərsə də kök səbəb əvvəlki nonce ola bilər. Address üzrə nonce sırası və replacement hash-lər yoxlanır. “Cancel” çox vaxt zəncirdən silmə deyil, eyni nonce ilə başqa transaction rəqabətidir. Hansı hash block-a daxil olarsa yekun state-i o müəyyən edir.

Solana kimi sistemlərdə klassik uzunmüddətli public mempool görünüşü olmaya bilər. Signature processed, confirmed və finalized mərhələləri ilə izlənir; recent blockhash müddəti bitərsə transaction heç vaxt permanent nəticə yaratmaya bilər. Buna görə bütün chain-lərə eyni “mempool-da gözləyir” izahını tətbiq etməyin.

Success statusu hansı yoxlamaları tələb edir?

Transaction success olmaq onun məqsədinin yerinə yetdiyini avtomatik göstərmir. Native transferdə recipient və value, token transferində contract və Transfer event-i, DApp əməliyyatında isə konkret method nəticəsi yoxlanır. Approval success tokenin alıcıya göndərilməsi deyil. Swap success ola bilər, amma istifadəçi gözlədiyindən başqa token və ya məbləğ ala bilər.

EVM receipt statusu, logs və post-transaction balans birlikdə oxunur. Token contract to sahəsində görünə bilər, faktiki recipient event-də olur. Solana-da meta err, pre/post token balances, owner və mint əsasdır. Bitcoin-də output-lar və confirmation yoxlanır. Yaşıl rəng bütün chain-lərdə eyni semantikanı daşımır.

Platforma “on-chain success” olduqdan sonra minimum depozit, Memo, contract dəstəyi, confirmation və risk review səbəbilə credit verməyə bilər. Bu halda chain statusu dəyişdirilmir; yeni platform statusu əlavə olunur. “Success, amma balans yoxdur” ziddiyyət deyil, iki sistemin ayrı nəticəsidir.

Failed və reverted nəticəsində nə baş verir?

Failed transaction block-a daxil olub resurs istifadə edə bilər, lakin nəzərdə tutulan state dəyişiklikləri tətbiq olunmaya bilər. EVM contract revert olduqda Gas sərf edilir, token transfer event-i yekun receipt-də olmur. İstifadəçi fee azalmasını “pul recipient-ə getdi” kimi qəbul etməməlidir. Error log və contract method səbəbi müəyyən etməyə kömək edir.

Bəzi tətbiqlər bir neçə daxili addımı göstərir. Əməliyyat atomic-dirsə bir addımın vizual olaraq “completed” görünməsi bütün transaction success demək deyil. Receipt yekun statusu və balans dəyişikliyi əsasdır. Atomic olmayan cross-chain prosesində isə source deposit success, message pending, destination execution failed ola bilər; hər hissə ayrıca hash və status daşıyır.

Təkrar cəhddən əvvəl failed səbəb düzəldilir. Gas limitini artırmaq yanlış chain, recipient, allowance və contract pause problemini həll etmir. Yeni transaction yeni hash və fee yaradır. Biznes jurnalı original failed cəhdi silmir, onu retry səbəbi ilə bağlayır.

Replaced, dropped və expired necə sübut olunur?

EVM replacement adətən eyni sender və nonce ilə başqa transaction block-a daxil olduqda görünür. Original hash explorer-də replaced kimi işarələnə bilər. Yeni hash, recipient və value yoxlanır; replacement sadəcə fee bump yox, məzmun dəyişikliyi də ola bilər. Recipient-ə hansı transaction-un faktiki icra olunduğu bildirilir.

Bitcoin RBF-də eyni input-ları istifadə edən daha yüksək fee-li transaction originalı əvəz edə bilər. CPFP isə original output-u xərcləyən child transaction vasitəsilə paket stimulunu dəyişir. Hər iki halda txid-lər və input/output əlaqəsi saxlanır. Naməlum şəxsin ayrıca address-ə “miner fee” istəməsi bu mexanizmləri sübut etmir.

Solana recent blockhash müddəti keçmiş transaction expired ola bilər və daimi chain qeydi yaratmaya bilər. Yeni transaction yeni blockhash və signature ilə qurulur. Original signature-in heç bir etibarlı mənbədə success olmadığını yoxlamadan retry iki ödəniş riski yarada bilər. Chain-ə uyğun termin istifadə edilir; bütün itmiş qeydlərə “dropped” etiketi vurulmur.

Confirmation və finality hansı qərara xidmət edir?

Confirmation sayı riskin azalmasını göstərir, amma bütün chain-lərdə eyni təhlükəsizlik həddi deyil. Platforma aktiv, chain və risk siyasətinə görə öz deposit threshold-unu seçə bilər. Explorer-də bir confirmation görünməsi platformanın dərhal credit verməli olduğunu sübut etmir. Eyni zamanda platforma tələb etdiyi həddi açıq göstərirsə, faktiki sayı ticket-də verilir.

Reorganization ehtimalı olan mərhələdə transaction başqa block-a keçə və ya müvəqqəti görünüş dəyişə bilər. İzləmə cədvəlində block nömrəsi, hash, confirmation və vaxt saxlanır. Köhnə sətir silinmir. Finality daha güclü olduqda nəticə yenilənir. İstifadəçi “final” sözünü geri qaytarma zəmanəti kimi başa düşməməlidir; səhv recipient-ə final transaction yenə geri dönməz ola bilər.

Cross-chain bridge-də source chain finality yalnız ilk mərhələdir. Mesajın relayer və ya validator tərəfindən işlənməsi, destination chain execution və recipient balansı ayrıca yoxlanır. Source success görünən kimi eyni məbləği yenidən göndərmək destination-də iki nəticə yarada bilər.

Platforma statuslarını ayrıca lüğətə çevirin

Queued, processing, completed, credited, rejected, manual review və reversed platformadan platformaya dəyişə bilər. Help center və hesab daxilindəki izah əsasında lokal lüğət yaradın: status hansı sistemi göstərir, public hash nə vaxt verilir, istifadəçi hansı addımı atmalıdır və hansı müddətdən sonra ticket açılır. Marketinq bildirişi texniki sənədi əvəz etmir.

Withdrawal completed olub TxID verilibsə public chain yoxlanır. TxID yoxdursa broadcast vaxtı və hash soruşulur. Deposit credited olubsa hesab balansı, aktiv, məbləğ və vaxt chain event-i ilə tutuşdurulur. Rejected statusu aktivin avtomatik geri qayıtdığını deməyə bilər; source balance və platforma qərarı yoxlanır.

Maintenance elanları status şərhinə daxil edilir, amma hər gecikmə maintenance ilə izah olunmur. Rəsmi status page tarixçəsi saxlanır. Sosial şəbəkədə naməlum hesabın “node açmaq üçün fee” istəyi platforma statusu deyil və təhlükəsizlik hadisəsi kimi qeyd olunur.

Token event-i və balans statusdan daha dəqiq ola bilər

Token transferində contract event faktiki aktiv hərəkətini göstərir. Event-də contract, from, to və raw amount oxunur; decimal ilə istifadəçi məbləğinə çevrilir. Eyni simvollu saxta token səhv nəticə yarada bilər, buna görə contract rəsmi mənbə ilə yoxlanır. Recipient address düzgün olsa belə platforma həmin contract-ı dəstəkləməyə bilər.

Balance snapshot event-i tamamlayır. Transaction-dan əvvəl və sonra recipient token balansı müqayisə edilir. Rebase, fee-on-transfer və başqa contract davranışları sadə “göndərilən məbləğ = alınan məbləğ” fərziyyəsini poza bilər. Platforma credit-i üçün faktiki event məbləği və platforma minimumu əsasdır.

NFT və başqa aktiv növündə token ID, collection contract və ownership ayrıca yoxlanır. Ümumi transaction success statusu yanlış tokenin doğru address-ə getməsi problemini həll etmir. Araşdırma məqsədi əməliyyatın yalnız icra olunduğunu deyil, gözlənilən aktivin gözlənilən sahibə çatdığını sübut etməkdir.

Mübahisə və support üçün sübut paketi

Paketdə əməliyyat məqsədi, wallet və ya platforma order nömrəsi, public TxID, chain, recipient, asset contract, amount, fee, hər statusun mənbəyi və vaxt xətti olur. Screenshot əlavə edilirsə domen və əsas sahələr oxunaqlı saxlanır, şəxsi balans və login məlumatı örtülür. Link session token daşıyırsa paylaşılmaz.

Support-a “pul itib” deyil, konkret ayrım göndərin: wallet broadcast etdi, chain-də transaction yoxdur; chain success-dir, token event düzgündür, platforma credit etməyib; receipt failed-dir və Gas sərf olunub; original hash replacement ilə əvəz olunub. Bu format ticket-i doğru komandaya yönəldir.

Recipient ilə biznes mübahisəsində public chain sübutu, platforma credit-i və müqavilə öhdəliyi ayrılır. Chain recipient wallet-a token çatdığını göstərə bilər, amma qarşı tərəfin platforma hesabında istifadə edə bilməməsi ayrıca fakt ola bilər. Hüquqi nəticə çıxarmadan hər texniki mərhələ sənədləşdirilir.

Avtomatik monitorinq hansı siqnalları verməlidir?

Monitor yalnız “status dəyişdi” bildirişi verməməlidir. TxID görünmədikdə broadcast gecikməsi, confirmation artmadıqda stalling, receipt failed olduqda error, token event recipient ilə uyğun gəlmədikdə mismatch və platforma credit gecikdikdə daxili eskalasiya ayrı siqnallardır. Hər siqnalın owner-i və növbəti addımı olur.

API provider müvəqqəti null qaytara bilər. Monitor ikinci mənbə və retry intervalı istifadə edir, lakin saniyədə çox sorğu ilə rate limit yaratmır. Müşahidə mənbə və vaxtla saxlanır. Avtomatlaşdırma seed, private key və 2FA saxlamır; public hash və read-only API kifayətdir.

Hadisə bağlandıqda final chain nəticəsi, aktiv hərəkəti, platforma credit-i və biznes qərarı ayrı statuslarla tamamlanır. Bu dördü bir completed=true sahəsinə sıxışdırılmır. Belə model gələcək araşdırmada hansı mərhələnin həqiqətən uğurlu, hansının isə sadəcə gözləmədə olduğunu göstərir.

Status vaxt xətti üçün nümunə struktur

Sadə cədvəldə müşahidə vaxtı, mənbə, identifikator, görünən status, block və ya slot, confirmation, aktiv nəticəsi və növbəti addım sütunları olur. Wallet sətri lokal niyyəti, explorer sətri public chain-i, platforma sətri isə daxili credit-i göstərir. Eyni vaxtda üç fərqli status yazıla bilər; biri digərinin üzərinə yazılmır.

Məsələn, 10:00-da platforma withdrawal processing, 10:07-də public TxID yaranıb pending, 10:15-də chain success, 10:32-də recipient platforma credited göstərə bilər. Yekun “32 dəqiqə çəkdi” nəticəsi yalnız bütün sətirlər saxlananda anlaşılır. TxID yaranana qədər olan vaxt chain confirmation vaxtına əlavə edilmir.

Status geriyə gedirsə mənbə səhvi, reorg, cache və ya daxili review ehtimalı araşdırılır. Köhnə screenshot silinmir. Yeni müşahidə həmin mənbənin vaxtı ilə əlavə olunur. İki provider zidd nəticə verirsə hər ikisinin block hündürlüyü və cluster-i yoxlanır.

İstifadəçiyə status necə izah edilməlidir?

İstifadəçiyə yalnız rəng və texniki termin göndərmək əvəzinə sübut olunan və hələ bilinməyən hissə deyilir. “Transaction chain-də success olub və token doğru recipient-ə çatıb; platforma hələ credit etməyib” cümləsi “pending-dir” sözündən daha faydalıdır. Eyni şəkildə “wallet imza göstərir, amma public hash heç bir mənbədə yoxdur” ayrıca problemi göstərir.

Təxmini müddət zəmanət kimi yazılmır. Platformanın rəsmi emal aralığı varsa mənbə və tarix göstərilir, hadisənin həmin həddi keçib-keçmədiyi qeyd olunur. Maintenance, compliance və manual recovery statusları chain gecikməsi kimi təqdim edilmir.

İkinci ödəniş barədə qərar ayrıca approval tələb edir. Recipient-in “gəlməyib, yenidən göndər” mesajı public status yoxlamasını əvəz etmir. Original transaction success və credit gecikməsi varsa duplicate risk yüksəkdir. Yeni transaction olarsa onun hash-i və invoice əlaqəsi ayrıca sənədləşdirilir.

Status lüğətinin dəyişiklik nəzarəti

Wallet və platforma UI-si terminləri yeniləyə bilər. Komanda lüğəti ekran görüntüsü, help center və real transaction nümunəsi ilə dövri yoxlayır. Complete sözünün hansı mərhələyə aid olduğu dəyişibsə prosedur və API mapping birlikdə yenilənir. Köhnə hadisələr yeni terminlə səssizcə yenidən yazılmır.

API status kodu ilə UI mətni arasında mapping saxlanır. Naməlum yeni kod avtomatik success kimi qəbul edilmir; review növbəsinə düşür. Monitor yalnız public chain nəticəsini yox, data source-un freshness və error vəziyyətini də bildirir. Provider timeout-u transaction failure kimi yazılmır.

Dəyişiklik əvvəl test transaction və ya anonimləşdirilmiş tarixi nümunədə yoxlanır. Məqsəd daha çox status toplamaq deyil, hər statusun hansı qərarı başladacağını aydın etməkdir. Qərarı olmayan dekorativ rəng və bildiriş əməliyyat nəzarəti sayılmır.