Təsdiq sayı niyə platformadan platformaya dəyişir?

Təsdiq taymer deyil

Bitcoin kimi chain-lərdə əməliyyat bloka daxil olduqdan sonra onun üzərində yeni bloklar qurulur və təsdiq dərinliyi artır. Blokların gəlməsi sabit saniyə cədvəli ilə zəmanət verilmir. Buna görə “3 təsdiq = dəqiq 30 dəqiqə” kimi çevirmə düzgün proqnoz deyil.

Başqa şəbəkələr yekunluğu başqa terminlərlə təqdim edir. Solana commitment səviyyələrindən istifadə edir, EVM tətbiqləri isə receipt blokundan cari bloka qədər dərinlik hesablayır. İstifadəçi interfeysində hamısına “confirmations” yazılsa da, texniki mexanizm eyni deyil.

Təsdiq sayı nəyi ölçür?

Əməliyyat bir bloka daxil olduqda ilk təsdiq yaranır, sonrakı bloklar həmin tarixçənin üzərinə qurulur. Bu sadə təsvir bütün şəbəkələr üçün eyni təhlükəsizlik ölçüsü yaratmır. Bitcoin, Ethereum, TRON və Solana müxtəlif blok vaxtı, yenidən təşkil və finality modeli istifadə edir. “Altı təsdiq hər yerdə kifayətdir” ümumi qayda deyil.

Platforma aktiv, şəbəkə, məbləğ və riskə görə öz kreditləşmə həddini seçə bilər. Zəncirdə success görünməsi ilə platformada istifadə edilə bilən balansın yaranması ayrı mərhələlərdir.

Qalan vaxt necə təxmin edilir?

Hazırkı təsdiq sayını qəbul xidmətinin tələb etdiyi saydan çıxın, qalan blokları son müşahidə olunan orta intervala vurun. Nəticəni diapazon kimi qəbul edin, geri sayım kimi yox. Blok intervalı dəyişir, platforma həddə çatdıqdan sonra əlavə indeks və risk yoxlaması edə bilər.

Qeydinizdə vaxt, blok hündürlüyü, təsdiq sayı və mənbə olsun. Məsələn, “14:20-də 7/12 təsdiq” sonradan prosesin irəliləyib-irəliləmədiyini göstərir. Yalnız son ekran görüntüsü zaman xəttini göstərmir.

Qəbul edən tərəfə status necə izah edilir?

Texniki olmayan alıcıya dörd məlumat verin: şəbəkə, TxID, recipient-in son simvolları və “hazırda X/Y təsdiq”. “Pul artıq finaldır” deməyin, əgər platforma hələ həddə çatmayıb və ya kredit etməyib. Alıcı platformadırsa, onun deposit history statusunu da ayrıca yazın. Bu yanaşma wallet notification, zəncir təsdiqi və istifadə edilə bilən balansı qarışdırmır. Gözləmə vaxtı uzananda eyni transaction-u yenidən göndərmək confirmation-u sürətləndirmir. Zəncir-specific fee bump yalnız uyğun pending hallarda, öz açarını idarə edən tərəf və ya göndərən platforma tərəfindən edilir.

Qısa cavab: neçə təsdiq kifayətdir?

Yeganə universal rəqəm yoxdur. Qəbul platformasının cari aktiv səhifəsində yazdığı hədd, konkret chain-in finality modeli və əməliyyatın dəyəri birlikdə nəzərə alınır. Əgər səhifə 12 təsdiq tələb edirsə, 11-də support-un balansı manual açacağına güvənməyin. 12 keçdikdən sonra da kredit yoxdursa, address, contract, minimum, Memo və maintenance yenidən yoxlanılır. Böyük məbləğ üçün tərəflər daha konservativ hədd seçə bilər, lakin əlavə blok səhv recipient-i düzəltmir. Hər qərarın yanında yoxlama vaxtını yazın, çünki platforma siyasəti və confirmation sayı sonradan dəyişə bilər.

Confirmation siyasəti nə vaxt yenidən yoxlanmalıdır?

Platforma dəstəklədiyi chain-i, tələb olunan blok sayını və maintenance vəziyyətini dəyişə bilər. Address book-da “12 təsdiq” yazılması daimi qayda deyil. Hər böyük depozitdən əvvəl cari səhifəni açın, tarix və şəbəkə ilə screenshot saxlayın. Sınaq əməliyyatı köhnə siyasət dövründə edilibsə, əsas məbləğ üçün yeni həddi yoxlayın. İşgüzar qəbul sistemində hər chain üçün “göründü”, “riskli ilkin qəbul”, “final qəbul” və “platformada istifadə oluna bilir” mərhələləri ayrı qeyd edilə bilər. Bu, müştəriyə yalan dəqiqə vədi vermədən operativ xidmət göstərməyə kömək edir.

Qəbul platforması niyə daha çox gözləyir?

Platforma zəncir reorganizasiya riskini, tokeni, depozit məbləğini, node vəziyyətini və daxili risk siyasətini nəzərə alır. Eyni şəbəkədə bir xidmət balansı tez yaza, digəri daha çox təsdiq tələb edə bilər.

Bu hədd şəbəkənin universal qanunu deyil. Platforma qaydanı dəyişə bilər; köhnə forum mesajındakı rəqəmi cari depozit səhifəsinə üstün tutmayın.

Böyük məbləğ üçün daha çox təsdiq yetərlidirmi?

Əlavə təsdiq zəncir tarixçəsinin sabitliyi barədə daha çox əminlik verə bilər, amma səhv ünvanı, səhv şəbəkəni və saxta token müqaviləsini düzəltmir. Böyük ödənişdə əvvəl ünvanı və aktiv müqaviləsini ikinci kanalla yoxlayın, kiçik sınaq edin, sonra uyğun finality siyasəti seçin.

Biznes ödənişində tərəflər əvvəlcədən “hansı statusda mal təhvil verilir” şərtini yazmalıdır. Bir tərəf wallet notification-u, digəri platforma kreditini son nəticə sayırsa, mübahisə yaranacaq.

Reorg və platforma riski necə ayrılır?

Təsdiq siyasəti zəncir tarixçəsinin dəyişmə riskini azaltmağa çalışır; platformanın KYC, hesab bloklanması və daxili texniki gecikməsi isə başqa risklərdir. Daha çox blok ikinci qrup problemi həll etmir. On-chain hədd çatıbsa, support-a məhz hesab statusunu soruşun.

Dörd ayrı vəziyyəti qarışdırmayın

1. TxID yoxdur: hələ zəncir yayımını sübut etməmisiniz.
2. TxID var, blok yoxdur: əməliyyat namizəddir, təsdiq saymağa başlamayıb.
3. Blok var, hədd tamam deyil: zəncir irəliləyir, platforma gözləyir.
4. Hədd tamamdır, balans yoxdur: chain, contract, Memo/Tag və platforma emalı ayrıca yoxlanmalıdır.

Rəqəm dəyişmirsə

Əvvəl səhifəni yeniləyin və eyni hash, eyni chain baxdığınızı təsdiqləyin. Bir explorer geridə qalırsa, eyni chain üzrə ikinci məlumat mənbəsi ilə müqayisə edin.

Əməliyyat pendingdirsə, təsdiq sayının artmaması normaldır; onun bloku yoxdur. Bu halda fee, nonce, yayım və ya blockhash diaqnostikasına keçmək lazımdır. Bloklar artır, amma platforma sayğacı dayanıbsa, daxili indeksləmə problemi ola bilər.

Hansı vəziyyət sadəcə təsdiq gözləməsi deyil?

TxID heç yerdə tapılmırsa, əvvəl şəbəkə və identifikatoru yoxlayın. Status failed-dirsə, daha çox təsdiq onu success etməyəcək. Tələb olunan say keçib, balans yenə görünmürsə, minimum depozit, Memo/Tag, token müqaviləsi, platforma maintenance və hesab statusunu araşdırın.

Support sorğusunda say deyil, sübut verin

“10 təsdiq oldu” yazmaqla yanaşı TxID, chain, blok, məbləğ və platforma depozit ünvanını təqdim edin. Platformanın öz səhifəsində tələb olunan həddi göstərən cari məlumat varsa, sorğuya əlavə edin.

Heç kim seed və ya parolla təsdiq sayını artıra bilməz. Bitcoin-də RBF və CPFP kimi fee mexanizmləri yalnız uyğun təsdiqlənməmiş əməliyyatlara aiddir; “validatora pul verib confirmation yazmaq” iddiası saxtakarlıq siqnalıdır.

Nə vaxt rəsmi dəstəyə yazmaq lazımdır?

Doğru şəbəkədə success, doğru ünvan və müqavilə, minimumdan yuxarı məbləğ və platforma həddindən çox təsdiq varsa, amma hesab qeydi yoxdursa, ticket üçün kifayət qədər əsas var. TxID, cari təsdiq, ünvan, müqavilə, məbləğ, depozit səhifəsi və yoxlama vaxtını əlavə edin.

Hələ həddə çatmamısınızsa, eyni məbləği yenidən göndərməyin. Qəbul platforması bloka təsdiq əlavə edə bilməz; yalnız zəncir irəliləyir.

Hesabat üçün hansı sübutlar saxlanılır?

TxID, şəbəkə, blok hündürlüyü, ilk görülmə vaxtı, həddə çatma vaxtı və platforma kredit vaxtını ayrı yazın. Xaricdən ödəniş və ya iş gəliri üçün AZN ekvivalenti lazımdırsa, məzənnə mənbəyi və vaxtı da əlavə edin. Blokçeyn təsdiqi ödənişin hüquqi məqsədini özü izah etmir.

Fırıldaq xəbərdarlığı

Heç bir “validator agenti” ödəniş müqabilində mövcud bloka saxta təsdiq əlavə edə bilməz. TxID açıqdır, private key isə təsdiq sayını artırmır. “On ikinci təsdiqi açmaq” üçün şəxsi ünvana kripto tələb olunursa, bu yeni ödənişdir və dayandırılmalıdır.

Təsdiq sayı necə hesablanır?

Transaction daxil olduğu block-dan sonra canonical chain-ə əlavə edilən hər yeni block onun dərinliyini artırır. Explorer-lər bəzən daxil olduğu block-u birinci təsdiq sayır, bəzən “confirmations” sahəsini cari height ilə hesablayır. Mübahisədə TxID, daxilolma block height-i və cari canonical height birlikdə qeyd edilməlidir.

Mempool-da görünən transaction-un sıfır təsdiqi var. Pending, processed və ya “seen by node” ifadəsi block inclusion ilə eyni deyil. Platforma yalnız müəyyən finality və dərinlikdən sonra daxili kredit yarada bilər. Wallet bildirişi platformanın risk həddini əvəz etmir.

Bitcoin üçün risk nəyə görə məbləğlə dəyişə bilər?

Bitcoin confirmation-ları proof-of-work block-ları ilə artır. Kiçik ödəniş üçün bir neçə block kifayət sayıla, böyük depozit üçün xidmət daha çox dərinlik tələb edə bilər. Fee rate inclusion sürətinə təsir edir, transaction block-a girdikdən sonra isə yeni confirmation-lar şəbəkənin normal block istehsalı ilə yaranır.

RBF siqnalı və double-spend riski sıfır confirmation qəbulunda ayrıca qiymətləndirilir. İlkin TxID replacement ilə dəyişərsə, köhnə hash-in confirmation-u artmayacaq. Qəbul edən tərəf canonical transaction və recipient output-u yoxlamalıdır. Sadəcə eyni məbləği görmək hash əlaqəsini sübut etmir.

Ethereum və EVM şəbəkələrində block dərinliyi

EVM explorer receipt success göstərdikdə transaction block-a daxil olub. Sonrakı block-lar dərinliyi artırır, amma platforma əlavə finality qaydası tətbiq edə bilər. Chain congestion confirmation sayının hesabını dəyişmir; əsas dəyişən block vaxtı və xidmətin tələb etdiyi həddir.

Layer 2 şəbəkələrində local block inclusion ilə L1 settlement eyni mərhələ deyil. Platforma yalnız L2 confirmation sayı, əlavə batch finality və ya öz risk qaydasını gözləyə bilər. Depozit səhifəsində hansı şəbəkənin və hansı ölçünün nəzərdə tutulduğunu dəqiq oxuyun.

PoS finality və sadə block sayı

Proof-of-stake chain-də block dərinliyi ilə protokol finality statusu fərqli anlayış ola bilər. Explorer “finalized” məlumatı verirsə, bunu sadə confirmation rəqəmi ilə birlikdə oxuyun. Platformanın “N confirmations” yazması öz daxili əməliyyat qaydasıdır və protokol terminindən fərqlənə bilər.

Validator səsverməsi istifadəçinin private key-i ilə sürətləndirilmir. İstifadəçi transaction fee-ni yalnız broadcast və inclusion mərhələsində seçir. Block-a daxil olmuş transaction-a kənar şəxs pulla əlavə “təsdiq” yaza bilməz.

Solana commitment pillələri

Solana processed, confirmed və finalized commitment səviyyələri təqdim edir. Bunlar müxtəlif node müşahidəsini və fork riskini ifadə edir. Platforma finalized gözləyirsə, processed nəticə göründükdə kredit tələb etmək tezdir. Signature, slot və err sahəsi hər müşahidədə qeyd olunur.

RPC provider-lər qısa müddət fərqli nəticə göstərə bilər. Eyni signature-i mainnet-də və etibarlı iki endpoint-də uyğun fasilə ilə yoxlayın. Sorğunu fasiləsiz təkrarlamaq finality-ni artırmır, yalnız rate limit yarada bilər.

TRON confirmation yanaşması

TRON transaction receipt success olduqdan sonra platforma müəyyən sayda block gözləyə bilər. TRC20 transferində confirmation-la yanaşı event recipient və contract doğruluğu da tələb olunur. Yanlış token success olsa, yüzlərlə block keçməsi onu dəstəklənən aktivə çevirmir.

Energy və Bandwidth transaction icrasının resurslarıdır, confirmation sayını satın alan mexanizm deyil. Failed contract çağırışında yeni block-lar xətanı success etməyəcək. Yenidən göndərmə qərarı recipient, contract, result və fee səbəbi yoxlandıqdan sonra verilir.

Reorganization zamanı nə görünə bilər?

Qısa chain reorganization son block-ların başqa canonical budaqla əvəzlənməsidir. Yeni daxil olmuş transaction müvəqqəti itə, mempool-a qayıda və ya başqa block-a daxil ola bilər. Explorer block hash-i dəyişirsə, confirmation rəqəmi geriyə gedə bilər. Bu, avtomatik refund demək deyil.

Hadisə zamanı köhnə block hash, yeni status və müşahidə vaxtını saxlayın. Bir neçə etibarlı explorer və ya node nəticəsi canonical vəziyyəti aydınlaşdırır. Platforma riskini azaltmaq üçün confirmation buffer seçir; yüksək dəyərli transferlərdə bunun səbəbi məhz belə nadir dəyişikliklərdir.

Platforma niyə şəbəkədən daha çox gözləyə bilər?

Depozit sistemi node-dan block görsə də indexer, risk engine, compliance və account mapping mərhələləri ayrıca işləyir. “12 confirmation tamamdır” yalnız chain həddinin bitdiyini göstərə bilər. Daxili maintenance və ya Memo problemi kreditin başqa mərhələdə qalmasına səbəb ola bilər.

Ticket-də confirmation həddi ilə faktiki sayı yanaşı yazılır. Hədd tamamlanıbsa, recipient, aktiv contract, minimum məbləğ və Memo növbəti yoxlama olur. Problem kateqoriyasını dəyişmədən sadəcə “daha çox gözləyin” cavabını təkrar etmək kifayət deyil.

Deposit qaydası nə vaxt qeydə alınmalıdır?

Ən yaxşı sübut transferdən əvvəl açılmış cari depozit səhifəsidir. Burada şəbəkə adı, aktiv, minimum, confirmation tələbi və maintenance statusu görünür. Screenshot-a tarix və domen daxil olsun. Platforma şərti sonradan dəyişərsə, əməliyyat anındakı qaydanı ayırmaq mümkün olar.

Köhnə bloq yazısı, sosial media cavabı və başqa istifadəçinin hesabı eyni risk dərəcəsini göstərməyə bilər. Rəsmi account daxilində görünən qayda əsas götürülür. Şübhə varsa böyük məbləğdən əvvəl dəstəkdən yazılı təsdiq alınır.

Vaxt proqnozunu necə vermək olar?

Orta block vaxtı statistik göstəricidir, zəmanətli cədvəl deyil. N confirmation üçün sadə vurma təxmini interval verir, lakin block-lar bərabər aralıqda gəlmir. Transaction hələ mempool-dadırsa, inclusion gözləməsi bu intervala əlavə olunur. Platforma processing müddəti də ayrıca hesablanır.

İstifadəçiyə “dəqiq 30 dəqiqə” demək əvəzinə mərhələni göstərin: broadcast edilib, block-a daxil olmayıb; 3/12 confirmation; chain həddi tamamdır, platforma credit gözlənir. Bu dil yanlış zəmanəti azaldır və növbəti yoxlama vaxtını əsaslandırır.

Explorer-lər fərqli rəqəm göstərirsə

Explorer cache-i, node height-i və finality metoduna görə qısa fərq yarana bilər. Hər mənbənin son block height-ini, transaction block-un hündürlüyünü və statusunu müqayisə edin. Fərq bir neçə block-dursa, uyğun fasilə ilə yenidən yoxlamaq adətən kifayətdir.

Chain adı səhvdirsə, rəqəmlərin heç biri müqayisə edilə bilməz. Eyni 0x hash formatı və ünvan müxtəlif EVM şəbəkələrində axtarıla bilər. Wallet network, platforma withdrawal seçimi və explorer domeni eyni chain-i göstərməlidir.

Batch və internal transfer halları

Bir transaction çoxlu recipient event-i yarada bilər. Confirmation bütün transaction üçün artır, platforma krediti isə sizin event və hesab mapping-inizə aiddir. Ümumi transaction məbləğini öz depozitiniz kimi yazmayın; event index və faktiki amount göstərilməlidir.

Mərkəzləşdirilmiş platformanın daxili istifadəçilərarası transferi heç public TxID yaratmaya bilər. Bu halda “confirmation sayı” deyil, daxili ledger statusu araşdırılır. Platforma order ID-ni block explorer-də axtarmaq nəticə verməyəcək.

Merchant və invoice qərarı

Satıcı malı neçə confirmation-dan sonra təqdim edəcəyini əvvəlcədən müəyyən etməlidir. Kiçik rəqəmsal xidmət, fiziki məhsul və yüksək dəyərli irreversible təhvil üçün risk eyni deyil. Qayda invoice-də yazılır və ödənişdən sonra müştəriyə qarşı dəyişdirilmir.

Ödəniş gecikirsə invoice expiry, recipient amount və canonical TxID yoxlanır. Müştəridən eyni məbləği dərhal ikinci dəfə istəmək double payment yarada bilər. Replacement və ya refund olarsa bütün əlaqəli hash-lər order qeydinə əlavə edilir.

Support üçün vaxt xətti

Broadcast vaxtı, first seen, block inclusion, hər əsas confirmation mərhələsi, tələb olunan hədd və platforma credit vaxtı ayrı sətirlərdə saxlanır. UTC istifadə etmək timezone qarışıqlığını azaldır. Explorer linki ilə screenshot birlikdə daha davamlı sübut yaradır.

Status geriyə gedərsə, reorg və ya explorer fərqi qeyd olunur. TxID dəyişərsə, replacement əlaqəsi sübut edilir. Bu cədvəl “çoxdan göndərmişəm” cümləsini konkret və yoxlana bilən hadisəyə çevirir.

Təhlükəsiz sərhəd

Confirmation araşdırması public hash və node məlumatı ilə aparılır. Seed, private key, wallet PIN və uzaqdan cihaz nəzarəti lazım deyil. Kimsə “node-a transaction əlavə etmək” üçün məxfi məlumat istəyirsə, prosesi dayandırın.

Rəsmi support belə mövcud transaction-un confirmation sayını əl ilə yaza bilməz; yalnız öz kredit siyasətini və daxili statusunu idarə edir. Şəxsi ünvana ödəniş protokol finality-sini sürətləndirmir. Hər təklif ticket və rəsmi domain vasitəsilə təsdiqlənir.

Araşdırmanın bağlanması

Hədd tamamlandıqda final block, confirmation sayı, recipient və platforma credit nəticəsi saxlanır. Kredit yoxdursa məsələ confirmation kateqoriyasından recipient, contract, Memo, minimum və ya platforma processing kateqoriyasına keçir. Səbəbi dəyişmədən sonsuz gözləmək düzgün diaqnostika deyil.

Gələcək əməliyyat üçün platformanın cari həddi yenidən yoxlanır. Keçmişdəki “12 confirmation” qaydası bütün aktivlərə və bütün tarixlərə şamil edilmir. Qeyd olunan chain, aktiv və tarix konteksti qərarı təkrar istifadə edilə bilən edir.

Finality pozularsa əməliyyat planı

Platforma confirmation tamamlandıqdan sonra reorg aşkarlayarsa kredit müvəqqəti hold-a düşə bilər. İstifadəçi köhnə block screenshot-u ilə yeni canonical nəticə arasındakı fərqi qeyd edir. Transaction yeni block-a qayıdıbsa onun yeni dərinliyi gözlənir; conflict tərəfindən əvəzlənibsə recipient nəticəsi yenidən yoxlanır.

Bu müddətdə eyni invoice üçün yeni ödəniş yalnız qarşı tərəfin yazılı razılığı və double-payment planı ilə edilir. “Təsdiq silindi” ifadəsi vəsaitin avtomatik göndərənə qayıtdığını göstərmir. UTXO və ya account state public şəkildə yoxlanmalıdır.

Multisig və timelock transaction-ları

Multisig əməliyyatda kifayət qədər imza toplanması broadcast və confirmation-dan əvvəlki mərhələdir. Proposal ID və PSBT public TxID olmaya bilər. Son imza tamamlanıb transaction yayımlandıqdan sonra hash explorer-də görünür və block dərinliyi hesablanır.

Timelock və ya contract şərti transaction-un hansı vaxtdan etibarən icra oluna biləcəyini məhdudlaşdıra bilər. Bu şərt block confirmation sayı ilə eyni deyil. Support sənədində “imza gözlənir”, “vaxt kilidi aktivdir”, “mempool-dadır” və “N confirmation var” ayrı statuslar kimi yazılır.

Bridge confirmation-u necə çoxmərhələlidir?

Source chain-də N confirmation tamamlanması bridge relayer-in mesajı qəbul etməsi üçün bir şərt ola bilər. Sonra validator və ya proof mərhələsi, destination transaction və bəzən istifadəçi claim-i gəlir. Source count destination balansının dərhal görünəcəyinə zəmanət vermir.

Bridge statusunda source hash, message ID və destination hash saxlanır. Hansı mərhələnin hansı chain finality-sini gözlədiyi rəsmi sənəddən yoxlanır. Naməlum “relayer agent”ə ödəniş mövcud mesajı qanuni şəkildə dəyişdirmir.

Stablecoin issuer freeze ssenarisi

Transaction confirmation-ları artsa da token contract issuer tərəfindən ünvan məhdudiyyəti tətbiq edə bilər. Receipt success, event və son balans birlikdə oxunur. Freeze və ya blacklist ayrıca contract state-dir; daha çox block onun siyasətini avtomatik ləğv etmir.

Platforma credit vermirsə contract, recipient və risk statusunu support ilə dəqiqləşdirin. “Confirmation tamamdır” arqumenti bütün token məntiqini əhatə etmir. Heç bir üçüncü tərəfə seed və ya “unfreeze fee” göndərməyin.

Audit üçün nümunə qərar cümlələri

“TxID mempool-dadır, block-a daxil olmayıb” sıfır confirmation halıdır. “Transaction block 100-dədir, cari height 105-dir, xidmət 12 tələb edir” gözləmə halıdır. “Tələb olunan 12 tamamdır, doğru event var, kredit yoxdur” platforma eskalasiyasıdır. “Receipt failed” isə yeni block-larla düzəlməyən icra xətasıdır.

Bu cümlələr fakt, hədd və növbəti addımı eyni anda göstərir. Qeyri-dəqiq “transfer ilişib” ifadəsindən fərqli olaraq məsul mərhələni müəyyən edir. Ticket hər status dəyişəndə eyni strukturla yenilənə bilər.

Monitorinq tezliyi

Şəbəkənin tipik block intervalına uyğun yoxlama seçin. Hər saniyə refresh etmək confirmation yaratmır və API rate limit yarada bilər. Böyük dərinlik tələb olunan depozitdə əsas mərhələlərdə qeyd almaq kifayətdir: inclusion, yarım hədd, tam hədd və platforma credit.

Monitorinq avtomatlaşdırılıbsa chain reorg, hash replacement və API xətası üçün ayrıca xəbərdarlıq qurulur. Sadəcə count artımını izləmək yanlış chain və ya yanlış recipient problemini aşkar etməz.

Owner təsdiqi ilə bağlanma

Ödəniş biznes əməliyyatıdırsa texniki confirmation-dan sonra sifariş sahibi faktiki məbləği və qarşı tərəfi təsdiqləyir. Operator yalnız hash-in dərinliyinə baxıb yanlış invoice-i completed etməməlidir. Order ID, recipient output və canonical TxID bir-birinə bağlanır.

Refund verilibsə refund yeni transaction və yeni confirmation xəttidir. Orijinal ödəniş silinmir. Hər iki tərəfin məbləği, fee-si və final block-u hesabatda ayrıca qalır.