Kriptovalyuta göndərməyin ən əsas istifadəçi təcrübəsi problemlərindən biri insanların uzun və səhvə açıq blokçeyn ünvanları ilə işləmək məcburiyyətində qalmasıdır. Bank köçürməsində telefon nömrəsi və ya asan tanınan hesab məlumatı istifadə oluna bildiyi halda, kriptovalyuta sistemlərində istifadəçi çox vaxt düzgün blokçeyn şəbəkəsini seçməli, mürəkkəb ünvanı köçürməli və əməliyyat haqqını ödəmək üçün həmin şəbəkənin yerli tokeninə sahib olmalıdır.

Bunu həll etməyin ən sadə yolu e-poçt ünvanını birbaşa blokçeyn ünvanına bağlamaq kimi görünə bilər. Lakin bu yanaşma ciddi məxfilik problemi yaradır. Əgər bir şəxsin e-poçt ünvanından deterministik şəkildə blokçeyn ünvanı yaratmaq mümkündürsə, e-poçt ünvanını bilən hər kəs həmin şəxsin balansını, əməliyyat tarixçəsini və qarşı tərəflərlə münasibətlərini açıq blokçeyn üzərindən araşdıra bilər.

HFIPay, bu problemi insan tərəfindən asan istifadə olunan identifikatorla blokçeyn üzərindəki ödəniş ünvanını birbaşa bir-birinə bağlamamaqla həll etməyi hədəfləyən protokol arxitekturasıdır. Sistem məxfi identifikator yönləndirilməsi, göndərən tərəfindən yoxlana bilən təklif, intent-ə xas korlaşdırılmış bağlama və sıfır bilik isbatı ilə zəncir üzərində claim authorization qatlarını bir-birindən ayırır.

Göndərən yalnız alıcının e-poçt ünvanı kimi bir identifikator göstərir. Relay bu identifikatoru məxfi verilənlər bazasında həll edir, hər ödəniş üçün təsadüfi intentId yaradır və zəncirə alıcının e-poçt ünvanı və ya təkrar istifadə edilə bilən daimi alıcı etiketi əvəzinə yalnız həmin əməliyyata xas blinded binding dəyəri olan ρ-nu yazır.

Verified-quote rejimində göndərən pul göndərməzdən əvvəl ρ dəyərinin həqiqətən hədəflənən alıcının gizli bağlama açarına aid olduğunu off-chain proof ilə yoxlaya bilər. Vəsait yatırıldıqdan sonra isə relay pulu istədiyi başqa alıcıya yönləndirə bilməz; həqiqi alıcı ZK-ACE vasitəsilə eyni deterministik identiklik ailəsinə malik olduğunu sıfır bilik isbatı ilə sübut edərək vəsaiti seçdiyi ünvana köçürə bilər.

Tədqiqat həmçinin HFIPay-in n-Vm arxitekturası ilə birləşdirildikdə müxtəlif blokçeyn mühitləri arasında ödəniş yönləndirilməsi üçün istifadə oluna biləcəyini müzakirə edir. Lakin arxitektura hələ uçdan-uca performans benchmark-ları ilə təsdiqlənməyib.

İnsan üçün rahat kriptovalyuta ödəniş ünvanı niyə məxfilik problemi yaradır?

Bir istifadəçinin:

alice@example.com

ünvanının birbaşa:

keccak256(identifier) → blockchain address

kimi deterministik üsulla blokçeyn ünvanına çevrildiyini düşünək.

İstifadə baxımından son dərəcə asan görünən bu sistem blokçeynin şəffaflığı səbəbilə əks nəticə yaradır. Alice-in e-poçt ünvanını bilən hər bir şəxs eyni prosesi tətbiq edərək Alice-in blokçeyn ünvanını hesablaya bilər.

Bundan sonra hücumçu açıq zəncirdə:

• hesab balanslarını,
• keçmiş köçürmələri,
• hansı tokenlərin saxlanıldığını,
• hansı ünvanlarla əməliyyat aparıldığını,
• əməliyyat vaxtlarını

araşdıra bilər.

HFIPay-in əsas dizayn qərarı buna görə “insan üçün rahat identifikator = açıq blokçeyn ünvanı” bərabərliyini tamamilə aradan qaldırmaqdır.

HFIPay E-poçt Ünvanını Blokçeyndə Açıqlamadan Ödənişi Necə Yönləndirir?

HFIPay-də e-poçt ünvanı, telefon nömrəsi və ya sosial media istifadəçi adı blokçeyn üzərində birbaşa yerləşmir. Identifikator məxfi relay qatında həll olunur və blokçeyn tərəfində hər ödəniş üçün yeni yaradılmış birdəfəlik məlumatlardan istifadə edilir.

Protokolda beş əsas rol var:

Alıcının gizli bağlama açarı

Alıcı B, deterministik identiklik kökü REVB üzərindən müəyyən bir binding epoch üçün məxfi handle yaradır:

u_B,e = H(Derive(REV_B, Ctx_bind || e))

Bundan açıq təklif yoxlamasında istifadə edilə bilən binding-key commitment yaradılır:

K_B,e = H("hfipay:bind-key" || u_B,e)

Burada e binding epoch dəyəridir. Məqalə epoch etiketinin alıcıya xas təsadüfi identiklik olmaq əvəzinə gündəlik və ya həftəlik kimi kobud və ortaq zaman cədvəlindən seçilməsini təklif edir. Məqsəd epoch məlumatının öz-özlüyündə təkrar istifadə edilə bilən alıcı etiketinə çevrilməsinin qarşısını almaqdır.

Hər ödəniş niyə yeni intentId istifadə edir?

Göndərən ödəniş istədikdə relay kriptoqrafik olaraq təsadüfi 256-bit intent identikliyi yaradır:

intentId ← {0,1}²⁵⁶

Daha sonra zəncirə göndəriləcək birdəfəlik blinded recipient binding hesablanır:

ρ = H("hfipay:bind" || u_B,e || intentId)

Eyni alıcıya yenidən pul göndərildikdə yeni intentId yaradıldığı üçün ρ da dəyişir.

Bu xüsusiyyət HFIPay-in pre-claim unlinkability məqsədinin mərkəzindədir. Blokçeyn müşahidəçisi iki fərqli intent-in eyni e-poçt ünvanına aid olduğunu göstərəcək sabit recipient tag görmür.

Baseline və Verified-Quote niyə iki ayrı etibar modelidir?

Baseline rejimində relay pis niyyətli davranarsa ödənişdən əvvəl başqa alıcıya aid blinded binding yarada bilər. Mənbə bunu açıq şəkildə etibar fərziyyəsi kimi saxlayır.

Verified-quote rejimində isə müstəqil binding layer normallaşdırılmış istifadəçi identifikatoru ilə alıcının binding-key commitment dəyəri arasındakı əlaqəni təsdiqləyir.

Relay daha sonra göndərənə quote proof təqdim edir. Bu proof eyni gizli uB,e dəyərinin həm:

K_B,e = H("hfipay:bind-key" || u_B,e)

həm də:

ρ = H("hfipay:bind" || u_B,e || intentId)

əlaqələrini ödədiyini sübut edir.

Göndərən pulu köçürməzdən əvvəl proof-u və zəncirə yazılmış intent tuple-ını yoxladığı üçün relay-in sonradan alıcını dəyişdirməsinin qarşısı alınmağa çalışılır.

Göndərən Pulu Göndərdikdən Sonra Relay Pulu Başqa Ünvana Yönəldə bilərmi?

Verified-quote modelinin əsas təhlükəsizlik məqsədi bunun qarşısını almaqdır.

Göndərən vəsait yatırmazdan əvvəl:

1. binding attestation-ı yoxlayır,
2. quote proof-u yoxlayır,
3. deposit ünvanını intentId üzərindən özü yenidən hesablayır,
4. asset, məbləğ, chain, expiration və refund sahələrini yoxlayır,
5. blokçeyn üzərində qeydə alınmış intent tuple-ının qəbul etdiyi quote ilə eyni olduğunu təsdiqləyir.

Zəncirdə məsələn:

(ρ, a, v, e, Texp, γA, href)

məlumatları intent-ə bağlandıqdan sonra relay-in alıcı, token, məbləğ və ya refund semantikasını səssizcə dəyişdirə bilməsi üçün göndərənin yoxlamasını və ya istifadə edilən kriptoqrafik strukturları aşması tələb olunur.

Ödəniş prosesi beş əsas mərhələdən ibarətdir

EVM üzərində ödəniş ünvanı necə yaradılır?

EVM-uyğun blokçeynlərdə HFIPay deterministik deposit ünvanını CREATE2 üzərindən müəyyən edir:

α_EVM = CREATE2(factory, intentId, keccak256(initcode))

Bunun vacib xüsusiyyəti ünvanın contract hələ həqiqətən deploy edilmədən əvvəl hesablana bilməsidir.

Factory contract eyni zamanda intent-ə aid ρ, asset, məbləğ, epoch, expiration və refund məlumatlarını saxlaya bilər.

Solana üzərində necə tətbiq olunur?

Solana tərəfində qarşılıq gələn struktur Program Derived Address istifadə edir:

α_SOL = FindPDA(programId, ["hfipay" || intentId])

Intent state PDA daxilində:

• ρ,
• asset descriptor,
• məbləğ,
• epoch,
• expiration,
• refund metadata

saxlanılır.

SPL token istifadə edildikdə proqram əlavə olaraq intent-ə aid PDA-controlled token vault yarada bilər.

Claim zamanı alıcı nəyi sübut edir?

Alıcı zəncirə birbaşa “Mən bu e-poçt ünvanıyam” demir.

Bunun əvəzinə ZK-ACE istifadə edərək deterministik identikliyinin intent üzərindəki blinded binding ilə uyğun olduğunu sıfır bilik isbatı ilə sübut edir.

Claim mesajı mənbədə bu strukturla müəyyən edilir:

m_i = H("hfipay:claim" || d_dep || c_i || a_i || e_i || intentId_i || ρ_i || v_i || β_i || Texp || n_i)

Buradakı β alıcının vəsaiti almaq istədiyi destination address; n isə replay hücumlarına qarşı nonce-dur.

Claim proof aşağıdakı əlaqələri birlikdə bağlayır:

deterministik identiklik → epoch handle → ρ → intentId → asset → məbləğ → destination

Buna görə mempool müşahidəçisi claim transaction-ını kopyalayıb əvvəl göndərməyə çalışsa belə, proof vəsaitin hücumçu tərəfindən seçilmiş başqa destination address-ə köçürülməsinə icazə vermir.

Intent həyat dövrü

Hər intentId yalnız bir dəfə istifadə olunur.

CREATED → FUNDED → CLAIMED

və ya:

FUNDED → EXPIRED → REFUNDED

yollarından biri izlənir.

Refund əməliyyatı da relay-in birtərəfli qərarına buraxılmır. Mənbənin modelində göndərən, intent yaradılarkən refund destination üçün əvvəlcədən authorization təqdim edə bilər.

HFIPay Hansı Məxfilik Xüsusiyyətlərini Hədəfləyir?

1. Enumeration Resistance

Hücumçu Alice-in e-poçt ünvanını bilsə belə, yalnız blokçeyn məlumatlarını araşdıraraq hansı intent-lərin Alice-ə aid olduğunu müəyyən edə bilməməlidir.

Zəncirdə görünən əsas məlumatlar bunlardır:

Mənbə məxfilik iddiasının asset növünü, məbləği, zamanlamanı və ya chain məlumatını gizlətdiyini demir. Enumeration resistance analizi bu açıq metadata bərabərləşdirilərək aparılır.

2. Pre-Claim Unlinkability

Eyni istifadəçiyə claim baş verməzdən əvvəl iki fərqli ödəniş edildikdə, xarici müşahidəçi bu iki intent-in eyni şəxsə aid olduğunu yalnız on-chain struktura baxaraq anlaya bilməməlidir.

Bunun əsas səbəbi hər intent-in müstəqil təsadüfi intentId istifadə etməsi və blinded binding-in:

ρ_i = H("hfipay:bind" || u_B,e || intentId_i)

şəklində hər dəfə yenidən yaranmasıdır.

Claim həyata keçirildikdən sonra anonimlik eyni qalırmı?

Xeyr. Məqalə bu sərhədi açıq şəkildə qəbul edir.

Alıcı təkrar-təkrar eyni public destination address β-dan istifadə edərsə, bu claim-lər ortaq nəzarət altında kimi əlaqələndirilə bilər.

Həmçinin verifier interface hər claim zamanı eyni IDcomB commitment-ını açıq şəkildə göstərirsə, həmin commitment-ın təkrar istifadə olunduğu bütün əməliyyatlar zəncir səviyyəsində bir-birinə bağlana bilər.

Buna görə mənbə post-claim məxfiliyini önəmsəyən deployment-larda identity commitment-ın verifier interface arxasında gizlədilməsini və ya commitment rotasiyasını tövsiyə edir.

Verified-quote modelində fərqli göndərənlər bir-birini dolayı yolla fərq edə bilərmi?

Bəli. Mənbənin mühüm detallardan biri budur.

Eyni binding epoch daxilində eyni alıcıya ödəniş etmək istəyən fərqli göndərənlər quote daxilində eyni KB,e commitment-ını görür.

Bu göndərənlər əməkdaşlıq etsələr, eyni alıcıya ödəniş etdiklərini anlaya bilərlər.

Bu məlumat blokçeynə yazılmadığı üçün G1 və G2 çərçivəsində ümumi on-chain observer məxfiliyini birbaşa pozmur; lakin mənbə bunu cross-sender linkability kimi açıq məhdudiyyət olaraq müəyyən edir.

Relay Verilənlər Bazası Ələ Keçirilərsə Nə Baş Verər?

HFIPay zəncir üzərindəki identifier məlumatını gizlədir, lakin relay-in məxfi directory-si kritik məxfilik qatıdır.

Hücumçu relay verilənlər bazasını ələ keçirərsə:

Norm(e_B) → (IDcom_B, u_B,e, K_B,e, ...)

uyğunluqlarını və identifier-to-intent qeydlərini öyrənə bilər.

Daha önəmlisi, keçmiş epoch handle-ları saxlanılırsa, hücumçu blokçeyn üzərindəki köhnə intentId dəyərləri üçün:

H("hfipay:bind" || u_B,e || intentId)

hesablayaraq həmin zaman intervalındakı keçmiş əməliyyatları geriyə dönük şəkildə de-anonimləşdirə bilər.

Mənbə buna görə hücum təsirinin yalnız aktiv intent-lərlə məhdud olmadığını, ələ keçirilmiş və hələ də saxlanılan epoch-lara aid bütün keçmişə uzana biləcəyini vurğulayır.

Təklif edilən azaldıcı tədbirlər arasında encrypted-at-rest directory, hardware-backed keys, epoch rotasiyası, tamamlanmış epoch handle-larının silinməsi, köhnə intent/quote qeydlərinin təmizlənməsi və gələcəkdə relay xidmətinin bir neçə müstəqil operator arasında bölüşdürülməsi var.

Bununla belə relay-in ələ keçirilməsi təkbaşına əvvəldən zəncirə düzgün blinded binding ilə yazılmış intent-i hücumçunun öz ünvanına claim etməsinə imkan verməməlidir; claim yenə də ZK-ACE əlaqəsini ödəməlidir.

HFIPay Həqiqətən Mərkəzsizdirmi?

Tədqiqatın arxitekturası tamamilə relay-siz deyil. Müəllif bunu relay-assisted but non-custodial struktur kimi təsvir edir.

Relay:

• identifier directory saxlayır,
• istifadəçini payment intent ilə uyğunlaşdırır,
• bildiriş göndərir,
• transaction relaying edə bilər,
• istifadəçi adından gas və ya rent ödəyə bilər.

Buna görə relay privacy dependency və availability dependency olaraq qalır.

Lakin verified-quote rejimində relay-in səlahiyyəti klassik custodial “send to email” xidmətindən daha məhduddur. Relay vəsaiti custody altında saxlamır və intent maliyyələşdirildikdən sonra düzgün proof olmadan alıcını dəyişə bilməz.

Üçqat etibar arxitekturası

Zəncirlərarası Ödəniş Necə İşləyir?

HFIPay-in əsas claim mexanizmi eyni blokçeyn üzərində işləyə bildiyi kimi, mənbədə n-Vm adlı çoxlu virtual maşın arxitekturası ilə zəncirlərarası ödəniş üçün də genişləndirilir.

n-Vm ortaq identity layer altında birdən çox VM-nin işlədiyi Layer-1 yanaşması kimi təsvir edilir.

Tək bir identity commitment-dan fərqli mühitlər üçün ünvanlar törədilə bilər:

α_EVM = SHA-256("evm:" || id_com)[12:32]

α_SVM = SHA-256("svm:" || id_com)

α_BVM = SHA-256("bvm:" || id_com)

α_native = id_com

Nümunə zəncirlərarası axın

Mənbə xüsusilə mühüm bir sərhəd qoyur: n-Vm istifadəsi external-chain deposit verification problemini aradan qaldırmır.

Sistem yenə də mənbə zəncirdə həqiqətən ödəniş edildiyini yoxlamalıdır. Bu, light-client proof, validator attestation və ya ekvivalent üsulla həyata keçirilməlidir.

Beləliklə arxitektura bridge etibarını tamamilə aradan qaldırmır; onu n-Vm konsensus sərhədinə daxil etməyi hədəfləyir.

Bitcoin də əhatə olunurmu?

Tədqiqat n-Vm daxilində BVM modulunu fərz edərək Bitcoin üçün də konseptual axın müəyyən edir.

BTC əvvəlcə n-Vm deposit ünvanına köçürülür, sonra wBTC yaradılaraq intent-ə bağlanır. Alıcı claim-dən sonra BTC, EVM və ya SVM kimi hədəf seçə bilər.

Lakin mənbə BVM-nin Bitcoin sidechain, optimistic rollup və ya ZK Bitcoin Script yoxlaması üzərindən tam olaraq necə həyata keçiriləcəyini müəyyən etmir. Bu məsələ gələcək işə saxlanılır.

HFIPay ENS və Stealth Address Sistemlərindən Necə Fərqlənir?

Tədqiqatın Metodu və Nəticələri

Tədqiqat nə etdi?

Tədqiqat laboratoriya eksperimenti və ya production benchmark aparmayıb. Əsas metod:

1. identifier əsaslı kriptovalyuta ödənişlərində məxfilik probleminin threat model ilə müəyyənləşdirilməsi,
2. relay, deterministic identity, blinded binding və ZK authorization komponentlərinin vahid protokolda birləşdirilməsi,
3. baseline və verified-quote etibar modellərinin ayrılması,
4. enumeration resistance və pre-claim unlinkability üçün təhlükəsizlik eksperimentlərinin və proof sketch-lərin müəyyən edilməsi,
5. EVM və Solana üçün tətbiq eskizlərinin yaradılması,
6. n-Vm üzərindən zəncirlərarası genişlənmənin izah edilməsidir.

G1: Enumeration Resistance

Mənbədə G1 eksperimenti hücumçuya hədəf identifier və uyğunlaşdırılmış public metadata altında yeni intent tuple verilməsi ilə müəyyən edilir.

Müəllifin təklifinə görə relay directory ələ keçirilməyibsə, aktiv və ya saxlanılan epoch handle-ları public məlumatdan əldə edilə bilmirsə və istifadə edilən hash uyğun domain separation ilə təhlükəsizdirsə, polynomial-time on-chain müşahidəçisinin target recipient ilə comparison recipient-i ayırdetmə üstünlüyü cüzi qalmalıdır.

Bu nəticə protokolun müəyyən etdiyi müşahidəçi modeli altındakı proof sketch-dir; tədqiqat bunu ümumi və tam formal verification nəticəsi kimi təqdim etmir.

G2: Pre-Claim Unlinkability

İkinci təhlükəsizlik eksperimenti iki pre-claim intent-in eyni alıcıya, yoxsa iki fərqli alıcıya aid olduğunu müşahidəçinin ayırd edib-etməyəcəyini araşdırır.

Hər intent üçün müstəqil təsadüfi intentId istifadəsi və ρ-nun gizli handle ilə bu yeni intentId-dən törədilməsi sayəsində, public metadata bərabərləşdirildikdə on-chain müşahidəçi baxımından same recipient/two recipients vəziyyətlərini ayırd etməyə imkan verən təkrar istifadə edilə bilən public struktur olmadığı irəli sürülür.

Quote-to-Claim Composition

Tədqiqatın Lemma 3.1-i verified-quote ilə claim proof arasındakı əlaqəni qurur.

Quote proof:

K = H("hfipay:bind-key" || u)

və:

ρ = H("hfipay:bind" || u || intentId)

əlaqələrini ödəyən gizli u olduğunu sübut edir.

Claim proof isə deterministik identiklikdən törədilən u' dəyərinin eyni ρ-nu yaratdığını göstərir.

Müəllif istifadə olunan hash-in collision resistance fərziyyəsi altında fərqli u və u' dəyərlərinin eyni strukturlaşdırılmış ρ-nu yaratmasının hash collision tələb edəcəyini müdafiə edir. Buna görə uğurlu quote və claim-in eyni epoch-scoped hidden handle-a bağlandığı nəticəsinə gəlir.

Ölçülmüş performans nəticələri varmı?

Xeyr.

Məqalə açıq şəkildə aşağıdakı ölçmələri hələ hesabat vermir:

• end-to-end prototype benchmark,
• quote proof ölçüsü,
• ZK verification latency,
• gas cost,
• relay API latency,
• throughput,
• yük altında scalability.

Buna görə HFIPay-in praktikada klassik transferdən neçə millisaniyə daha yavaş olduğu, əməliyyat başına nə qədər xərc yaratdığı və ya saniyədə neçə ödəniş emal edə bildiyi bu məqalədən çıxarıla bilməz.

Verified-quote-un əlavə xərci

Mənbə kəmiyyət benchmark verməsə də, arxitekturanın əlavə yükünü keyfiyyət baxımından təsvir edir.

Baseline HFIPay:

directory lookup + intent registration + recipient claim proof + on-chain proof verification

tələb edir.

Verified-quote versiyası bunlara əlavə olaraq:

relay tərəfindən quote proof generation + göndərən tərəfindən quote verification

əlavə edir.

Göndərənin gördüyü quote materialının ölçüsü:

O(|τ_B| + |π^quote|)

claim transaction ölçüsü isə:

O(|π_i|)

kimi ifadə olunur.

Əsas məhdudiyyətlər

1. Relay tamamilə aradan qalxmır: məxfilik, notification və availability baxımından relay asılılığı var.
2. Baseline rejimində recipient substitution riski etibar fərziyyəsidir.
3. Binding issuer yanlış attestation verə və ya əlçatmaz ola bilər.
4. Relay directory compromise keçmiş intent-ləri geriyə dönük de-anonimləşdirə bilər.
5. Post-claim privacy daha zəifdir: eyni destination və ya public ID commitment təkrar istifadə olunarsa əlaqə qurula bilər.
6. Verified-quote daxilində eyni epoch-dakı sender-lər K_B,e vasitəsilə eyni alıcıya ödəniş etdiklərini anlaya bilər.
7. Network-layer traffic analysis əhatə xaricindədir.
8. E-poçt/OIDC account takeover ilkin enrollment təhlükəsizliyini poza bilər.
9. Cross-chain deposit verification ayrıca etibar problemidir.
10. Production benchmark hələ yoxdur.

Gələcək tədqiqat istiqamətləri

Mənbə dörd əsas inkişaf istiqaməti təklif edir:

• Quote-proof optimization: sender-verifiable proof-ların sıxılması və ya aqreqasiyası.
• Private directory federation: tək relay üzərindəki compromise riskini azaltmaq üçün directory-nin müstəqil operatorlara paylanması.
• Proof aggregation: yüksək əməliyyat həcmi üçün ZK-ACE claim proof-larının batch və ya recursive verification üsulu ilə birləşdirilməsi.
• Lazy first-receipt onboarding: əvvəllər qeydiyyatdan keçməmiş alıcının ilk ödəniş zamanı güclü və təhlükəsiz şəkildə sistemə daxil edilməsi.

Mənbə və Metod Qeydi

Orijinal başlıq: HFIPay: Privacy-Preserving, Cross-Chain Cryptocurrency Payments to Human-Friendly Identifiers

Müəllif: Jian Sheng Wang.

Institusional əlaqə: Yeah LLC.

Tarix: 27 Mart 2026.

Mənbə: arXiv.

ArXiv identifikatoru: arXiv:2603.26970v1 [cs.CR].

Tədqiqat növü: Kriptoqrafik protokol və ödəniş sistemi arxitekturası.

Əsas təklif: İnsan üçün rahat identifier-lara məxfi relay həlli, intent-specific blinded recipient binding və sıfır bilik isbatlı claim authorization ilə kriptovalyuta ödənişi.

Əsas məxfilik məqsədləri: Enumeration resistance və pre-claim unlinkability.

Authorization infrastrukturu: ZK-ACE.

Deterministik identiklik recovery komponenti: Va-Dar.

Cross-chain genişlənməsi: n-Vm.

Araşdırılan tətbiq mühitləri: EVM-compatible chains və Solana; Bitcoin/n-Vm BVM üçün konseptual genişlənmə.

Mühüm texniki komponentlər: random 256-bit intentId, blinded binding ρ, binding-key commitment K_B,e, verified quote, CREATE2, Solana PDA, ZK claim proof, sender-authorized refund.

Rəy statusu: Mənbə arXiv versiyasıdır; yüklənmiş sənəd rəyli jurnal və ya konfrans qəbul məlumatı təqdim etmir.

Eksperimental vəziyyət: Mənbə uçdan-uca production prototype benchmark və ya kəmiyyət performans qiymətləndirilməsi hesabat vermir.

Formal təhlükəsizlik sərhədi: G1 və G2 üçün nəticələr müəyyən edilmiş observer modeli altında proof sketch xarakterlidir; tədqiqat bunları tam game-based cryptographic reduction kimi təqdim etmir.

Elmi şərh sərhədi: HFIPay arxitekturası insan üçün rahat identifier ilə kriptovalyuta ödənişində istifadə rahatlığı və məxfilik arasında yeni dizayn nöqtəsi təklif edir. Mənbə sistemin praktiki istehsal mühitində xərc, gecikmə, yüksək yük altında performans və ya təhlükəsizlik əməliyyatları baxımından doğrulandığını göstərmir.