Akademik tədqiqatlar, aydın dil

Verianla | Akademik Araştırmalardan Türkçe Ekonomi ve Bilim İçerikleri

27 sentyabr 2026, bazar
VERİANLAMüstəqil elmi yayımçılıq
Menyunu açın və ya bağlayın
...
Home / Sosial Elmlər / Maliyyə İqtisadiyyatı / Rezerv Açıqlamasından İcra Oluna Bilən Nəzarətə: Xəzinə Aktivləri ilə Dəstəklənən Stablecoinlər üçün Blokçeyn-Əsaslı Referans Arxitekturası
Maliyyə İqtisadiyyatı

Rezerv Açıqlamasından İcra Oluna Bilən Nəzarətə: Xəzinə Aktivləri ilə Dəstəklənən Stablecoinlər üçün Blokçeyn-Əsaslı Referans Arxitekturası

Bir stablecoin emitentinin balansında kifayət qədər Xəzinə bonosu, nağd vəsait və ya digər uyğun rezervlərin olması, həmin aktivlərin o anda yeni stablecoin buraxılışını təhlükəsiz şəkildə dəstəkləyə biləcəyi demək deyil.

21/09/2026  Veri Anla 87 baxış
Rezerv Açıqlamasından İcra Oluna Bilən Nəzarətə: Xəzinə Aktivləri ilə Dəstəklənən Stablecoinlər üçün Blokçeyn-Əsaslı Referans Arxitekturası

Bir stablecoin emitentinin balansında kifayət qədər Xəzinə bonosu, nağd vəsait və ya digər uyğun rezervlərin olması, həmin aktivlərin o anda yeni stablecoin buraxılışını təhlükəsiz şəkildə dəstəkləyə biləcəyi demək deyil. Rezerv aktivi hələ settle edilməmiş ola bilər, girov qoyulmuş ola bilər, düzgün hüquqi şəxsin nəzarətində olmaya bilər, custodian və ya bank əlçatmaz vəziyyətdə ola bilər, qiymət məlumatı köhnəlmiş ola bilər və ya aktivin nağda çevrilməsi redemption tələbinin qarşılanmalı olduğu müddətdən daha uzun çəkə bilər.

Seungwoo Lee-nin Project ATLAS Paper II işi bu fərqi rezerv açıqlamasından əməliyyat-anı nəzarətinə daşıyır. İşdə hazırlanmış Core Programmable Treasury Reserve Layer (PTRL), rezervlərin yalnız ümumi miqdarını qeydə almaq əvəzinə hər rezerv mövqeyinin settlement, encumbrance, çıxış, hüquqi qoruma, qiymətləndirmənin aktuallığı, provayder vəziyyəti və müddətə görə istifadəyə yararlılığını ayrı-ayrılıqda qiymətləndirir. Yeni stablecoin öhdəliyi yalnız bütün məcburi şərtlərin icazə verdiyi həddə yaradıla bilər.

Mənbənin təklif etdiyi struktur stablecoin, CBDC və ya tokenləşdirilmiş Xəzinə bonosu deyil. Treasury Reserve Certificate (TRC), aktivin özünü təmsil edən alınıb-satıla bilən token deyil; mövcud rezerv mövqeyi ilə bağlı sübutu və vəziyyət məlumatını birləşdirən transfer edilə bilməyən qeyd obyektidir. Arxitektura rezerv sübutlarını smart contract şərtlərinə bağlayarkən mülkiyyət, iflas prioriteti, ödəniş finality-si və hüquqi səlahiyyət kimi məsələlərin real institutlar və qüvvədə olan hüquq tərəfindən müəyyən edilməyə davam etdiyini xüsusi olaraq qəbul edir.

On Solidity müqaviləsindən ibarət prototip səkkiz ucdan-uca EVM testindən keçmişdir. 100.000 otuz günlük simulyasiya yolunu əhatə edən dörd qollu eksperimentdə aggregate məlumat, aktual lot müşahidəsi, executable control və daha balanslı maturity ladder ardıcıllıqla müqayisə edilmişdir. Modelin öz ssenari fərziyyələrində məlumat, nəzarət və müddət bölgüsünün hər əlavə olunması orta məcburi satışları və likvidasiya itkilərini azaltmışdır. Lakin bu dəyərlər real stablecoin emitentlərinin gözlənilən nəticələri deyil, mexanizm doğrulama ssenariləridir.

Stablecoin Rezervi Niyə Təkcə “1:1 Dəstəklənmiş” Olmaqla Kifayətlənmir?

Çünki nominal rezerv miqdarı aktivin müəyyən anda həqiqətən istifadə edilə bilən olub-olmadığını göstərmir. İşin arxitekturasında rezervin stablecoin buraxılışını dəstəkləyə bilməsi üçün mövcud olmaqla yanaşı settle edilmiş, uyğun, girovsuz, əlçatan, qorunan, aktiv institut vasitəsilə saxlanılan və aktual qiymətləndirmə məlumatı ilə dəstəklənən olması tələb olunur; qısamüddətli redemption üçün əlavə olaraq müvafiq zaman üfüqündə nağda çevrilə bilməlidir.

Bu fərq mühasibat dəyəri ilə əməliyyat qabiliyyəti arasındakı fərqdir. Xəzinə bonosu iqtisadi baxımdan dəyərli ola bilər, lakin:

  • settlement tamamlanmayıbsa,
  • başqa öhdəlik üçün pledge edilibsə,
  • custodian əlçatmazdırsa,
  • qiymətləndirmə məlumatı stale-dirsə,
  • qoruma və ya beneficiary qeydi etibarlı deyilsə,
  • müddəti redemption ehtiyacından sonra bitirsə

o anda eyni miqdarda stablecoin öhdəliyini dəstəkləyən istifadəyə yararlı qabiliyyət kimi qəbul edilməyə bilər.

Mənbənin əsas prinsipi: reserve backing bir vəziyyətdir

Məqalənin mərkəzi təklifi reserve backing-in statik stok deyil, state-dependent permission kimi düşünülməsidir. Aktivin rezerv portfelində görünməsi minting səlahiyyətini avtomatik yaratmır.

Hər lot üçün tanınma şərtlərinin məntiqi belə ifadə olunur:

\[ C_{j,t}(b)=\prod_{\ell \in P_{j,t}(b)} I_\ell \]

Burada \(I_\ell\) tələb olunan şərtlərin hər birini təmsil edən ikili göstəricidir. Şərtlərin hamısı 1-dirsə lot tanınır. Tək bir şərt sıfırdırsa bütün hasil sıfır olur.

Buna görə sistem “bəzi şərtlər yaxşıdır deyə orta hesabla qəbul et” məntiqindən istifadə etmir. Yüksək keyfiyyətli Xəzinə bonosu əlçatmaz custodian səbəbilə istisna edilə bilər; başqa lotda artıq rezervin olması bu konkret çıxış problemini aradan qaldırmır.

Treasury Reserve Certificate (TRC) Nədir?

Treasury Reserve Certificate mövcud rezerv mövqeyinin kimliyini, vəziyyətini və əlaqəli sübut linklərini saxlayan transfer edilə bilməyən state object-dir; Xəzinə bonosunun tokenləşdirilmiş forması deyil, stablecoin sahibinə konkret rezerv lotunda birbaşa mülkiyyət hüququ vermir və ERC-20 və ya ERC-721 kimi alınıb-satıla bilən token kimi nəzərdə tutulmayıb.

Hər TRC beş əsas məlumat qrupuna bağlanır:

Məlumat qrupuFunksiyası
KimlikLot kimliyi, unikal position commitment və qorunan asset identifier bağlantısı.
İqtisadi şərtlərAktiv növü, nominal dəyər, settlement vaxtı və maturity vaxtı.
İnstitusional əlaqəCustodian/bank və rezervin dəstəklədiyi beneficiary.
Əməliyyat vəziyyətiEligibility, encumbrance, availability və PENDING / SETTLED / FROZEN / MATURED / SOLD lifecycle vəziyyəti.
Risk sübutuMarket value, haircut, valuation vaxtı və ayrıca protection/access qeydləri.

Eyni rezervin iki dəfə sayılması necə qarşısı alınır?

Prototipdə bir positionCommitment yalnız bir TRC yaratmaq üçün istifadə oluna bilər. Eyni commitment ilə ikinci lot qeydə alınarsa əməliyyat rədd edilir.

Bu mexanizm yalnız protokol daxilində eyni commitment-ın təkrarını əngəlləyir. Real dünyada eyni iqtisadi aktiv iki fərqli upstream kimliklə qeydə alınıbsa müqavilə bunun eyni aktiv olduğunu öz-özünə bilə bilməz. Buna görə mənbə real production sistemində canonical asset identity və institutlararası reconciliation tələb olunduğunu açıq bildirir.

Müddəti bitən bono niyə avtomatik nağd sayılmır?

Müqavilə üzrə maturity ilə faktiki cash settlement eyni hadisə deyil. Mənbədə müddəti keçmiş non-cash lot uyğun nağd çevrilməsi ayrıca doğrulanana qədər rezerv mühərriki tərəfindən nağd kimi istifadə edilmir.

Bu fərq xüsusilə redemption sistemlərində vacibdir: “bu gün müddəti bitdi” ifadəsi ilə “bu gün ödəniş hesabında istifadə edilə bilən nağd yarandı” ifadəsi əməliyyat baxımından fərqlidir.

Core PTRL Arxitekturası Necə İşləyir?

Core PTRL beş məntiqi qatda institusional sübutu, risk hesabını, stablecoin öhdəliyini və protokol səlahiyyətini bir-birinə bağlayır: institusional qat real institutları; evidence qatı doğrulana bilən vəziyyət qeydlərini; risk/control qatı CRC və likvidliyi; liability/settlement qatı minting və redemption-ı; authority/assurance qatı isə NORMAL, STRESS, RESOLUTION və PAUSED səlahiyyətlərini idarə edir.

1. İnstitusional qat

Issuer, bank, custodian, trustee, oracle reporter, auditor, supervisor, dealer və resolution authority kimi real institutlar burada yerləşir. Blokçeyn bu institutları yaratmır; yalnız qəbul edilən kimlik və səlahiyyət vəziyyətlərini ortaq nəzarət sahəsinə əks etdirir.

2. Evidence qatı

Rezerv lotları, protection qeydləri, valuation müşahidələri və repo xətləri typed commitment və müşahidələrə çevrilir.

3. Risk və control qatı

ReserveRiskEngine hansı lotların sayılacağını müəyyən edir; Conservative Reserve Coverage və 1/7/30 günlük likvidliyi hesablayır. IssuerController sonra bütün limitlərin minimumunu götürərək mint headroom-u müəyyən edir.

4. Liability və settlement qatı

AtlasSettlementToken yalnız prototipdə stablecoin-bənzər öhdəlik tərəfini test etmək üçün istifadə edilir. RedemptionRouter token-i escrow-a alır, bank ödənişinin doğrulanmasını gözləyir və yalnız bundan sonra burn əməliyyatını həyata keçirir.

5. Authority və assurance qatı

AtlasStateController hansı protokol vəziyyətində hansı əməliyyatların mümkün olduğunu məhdudlaşdırır. Auditor və supervisor kimi rollar isə hadisə tarixçəsinin və source record-ların xarici audit və doğrulamasında rol oynayır.

On modulun vəzifə bölgüsü

ModulƏsas vəzifəsi
ParticipantRegistryAktiv institusional rolları saxlayır.
TreasuryReserveCertificateUnikal rezerv lotunu və lifecycle məlumatını qeydə alır.
StabilityProtectionTrustProtection, beneficiary və çıxış vəziyyətini qeydə alır.
ReserveOracleAdapterÇoxmənbəli valuation, freshness və divergence nəzarəti aparır.
RepoCapacityOracleCounterparty əsasında 1/7/30 günlük repo qabiliyyətini saxlayır.
ReserveRiskEngineCRC və maturity liquidity hesablayır.
IssuerControllerReserve-first mint headroom-u hesablayır və tətbiq edir.
AtlasSettlementTokenPrototip öhdəlik token-i.
RedemptionRouterLock → ödəniş doğrulaması → burn ardıcıllığını tətbiq edir.
AtlasStateControllerNORMAL, STRESS, RESOLUTION və PAUSED vəziyyətlərini idarə edir.

Reserve-First Minting Nədir?

Reserve-first minting əvvəl stablecoin yaradıb sonra ona rezerv uyğunlaşdırmaq əvəzinə istifadəyə yararlı rezerv qabiliyyətinin əməliyyatdan əvvəl mövcud olmasını tələb edən dizayndır; mint-dən sonrakı supply riskə uyğunlaşdırılmış rezerv coverage-ının, 1/7/30 günlük redemption likvidliyinin, əməliyyat supply tavanının və protokol səlahiyyətinin icazə verdiyi ən aşağı dəyəri keçə bilməz.

Conservative Reserve Coverage

Tanınmış lot \(j\)-nin haircut tətbiq edilmiş dəyəri:

\[ \widetilde V_{j,t}= \operatorname{floor}\left(V_{j,t}(1-h_{j,t})\right) \]

kimi hesablanır.

Ümumi Conservative Reserve Coverage:

\[ CRC_t=\sum_j I_{j,t}\widetilde V_{j,t} \]

şəklindədir.

Burada \(I_{j,t}=0\) olan lotun dəyəri nə qədər yüksək görünsə də CRC-yə daxil edilmir.

1, 7 və 30 günlük likvidlik

Hər \(H\in\{1,7,30\}\) üfüqü üçün yalnız müvafiq müddət daxilində istifadəyə yararlı hala gələn və digər tanınma şərtlərini keçən aktivlər maturity liquidity-yə əlavə olunur.

Repo qabiliyyəti ayrıca hesablanır; rezerv dəyəri sayılmır. Repo xətti:

  • fresh,
  • aktiv,
  • unimpaired,
  • horizon ardıcıllığı tutarlı,
  • aktiv bank/counterparty ilə əlaqəli

olmadıqda likvidliyə daxil edilmir.

Horizon şərti

Hər zaman üfüqü üçün:

\[ q_H S_t^{post} \le L_t^{mat}(H)+\widetilde R_t(H) \]

şərti tətbiq olunur.

\(q_H\), həmin zaman üfüqündə dəstəklənməsi istənən stress-redemption payıdır. Mənbədə istifadə olunan \(q_1\), \(q_7\) və \(q_{30}\) dəyərləri governance və risk parametrləridir; model tərəfindən “doğru” və ya “optimal” nisbətlər kimi kəşf edilməyib.

Minimum məcburi limit

Dəstəklənə bilən maksimum mint-sonrası supply:

\[ K_t= \min \left\{ CRC_t, O_t, \left\lfloor \frac{L_t^{mat}(1)+\widetilde R_t(1)}{q_1} \right\rfloor, \left\lfloor \frac{L_t^{mat}(7)+\widetilde R_t(7)}{q_7} \right\rfloor, \left\lfloor \frac{L_t^{mat}(30)+\widetilde R_t(30)}{q_{30}} \right\rfloor \right\} \]

kimi müəyyən edilir.

NORMAL vəziyyətdə yeni mint qabiliyyəti:

\[ M_t=\max(K_t-S_t,0) \]

olduğu halda NORMAL-dan kənar vəziyyətlərdə:

\[ M_t=0 \]

olur.

Bu minimum əməliyyatı dizaynın ən vacib nöqtələrindən biridir. Məsələn, çox yüksək ümumi rezerv qeyri-kafi bir günlük nağd qabiliyyətini orta hesabla gizlədə bilməz.

Nominal Olarak Artıq Rezerv Varkən Mint Qabiliyyəti Sıfır Ola Bilərmi?

Bəli. Mənbənin normallaşdırılmış deterministik ssenarisində cash-bank outage-dan sonra sistemin tanıdığı non-cash rezerv dəyəri 80 olaraq qalsa da bir günlük dəstək sıfıra enir; bir günlük likvidlik məcburi hala gəldiyi üçün mint cap sıfıra düşür.

SsenariCRC1 günlük dəstək7 günlük dəstək30 günlük dəstəkMint cap
Baseline1002050100100
Protected-access loss5020505050
Custodian outage2020202020
Cash-bank outage80030800
All valuations stale00000
STRESS state10020501000
Matured but unconfirmed7020207050

Bu nümunələr yalnız rezerv miqdarını deyil, rezervin istifadə oluna bilmə vəziyyətini və authority vəziyyətini də minting həddinə daxil edən arxitekturanın davranışını göstərir.

Redemption Niyə “Kilidlə → Ödə → Doğrula → Yandır” Ardıcıllığını İzləyir?

Çünki stablecoin öhdəliyi blokçeyndə olduğu halda qarşılığındakı fiat ödəniş ayrı bank sistemində tamamlanır; token ödəniş baş verməzdən əvvəl yandırılarsa holder-in tələbi yox ola bilər, fiat ödəniş edilib token dövriyyədə saxlanılarsa isə eyni öhdəlik iki dəfə iqtisadi dəyər daşıya bilər.

Mənbənin referans axını:

  1. Holder token miqdarını və qorunan payout instruction commitment-ını göndərir.
  2. RedemptionRouter token-ləri escrow-da kilidləyir.
  3. Bank və ya payment process fiat ödənişi həyata keçirir.
  4. Səlahiyyətli ödəniş operatoru nonzero payment-proof commitment qeydə alır.
  5. Request PAID olur və escrow-dakı token yandırılır.

Burada payment-proof hash real bank ödənişini blokçeyn tərəfindən first principles-dən sübut etmir. Hash, səlahiyyətli auditorun çata bilməli olduğu qorunan bank qeydinə integrity bağlantısı təmin edir.

NORMAL, STRESS, RESOLUTION və PAUSED Arasındakı Fərq Nədir?

NORMAL adi minting və redemption vəziyyətidir; STRESS yeni supply-ni dayandırarkən etibarlı redemption-ı davam etdirir; RESOLUTION yeni adi redemption tələblərini bağlayaraq gözləyən tələbləri və qorunan rezerv nəzarətini səlahiyyətli həll prosesinə daşıyır; PAUSED isə ciddi məlumat və ya control qeyri-müəyyənliyində minting və ödəniş əməliyyatlarını müvəqqəti dayandıran circuit breaker vəziyyətidir.

FunksiyaNORMALSTRESSRESOLUTIONPAUSED
Yeni mintBəli, limitlər daxilindəXeyrXeyrXeyr
Yeni adi redemptionBəliBəliXeyrXeyr
Gözləyən bank-təsdiqli redemptionBəliBəliBəliXeyr
Protected-control releaseXeyrXeyrBəliBəli

Mənbədə NORMAL-dan birbaşa RESOLUTION-a keçilməməsi də dizayn xüsusiyyətidir. STRESS müşahidə oluna bilən escalation boundary yaradır.

Oracle divergence niyə PAUSED yaradır?

Birdən çox qəbul olunmuş valuation mənbəyi konfiqurasiya edilmiş tolerantlıqdan artıq ayrışarsa sistem “ən uyğun qiyməti seçmək” əvəzinə ortaq dəyərin müdafiə edilə bilən olmadığı nəticəsinə gəlir və PAUSED yolunu işlədir.

Bu mexanizm oracle-ın doğru məlumat verdiyini sübut etmir. Yalnız hansı məlumat şərtində protokolun əməliyyat aparmağı rədd edəcəyini açıq edir.

İşin Metodu və Nəticələri

Design-science metodu

İş klassik müşahidə iqtisadiyyatı və ya səbəbli təsir araşdırması deyil. Design-science yanaşmasında əvvəl institusional tələblər ayrışdırılmış, sonra onları təmsil edən executable artifact yaradılmış və artifact-ın müəyyən olunmuş davranışları test edilmişdir.

Hər tələb üç mərhələdə qurulmuşdur:

  1. Institutional claim: maliyyə, hüquqi və ya əməliyyat funksiyası.
  2. Source and boundary: bu funksiyanın əsaslandığı mənbə və mənbənin sübut etmədiyi sahə.
  3. Executable consequence: məlumat, rol, precondition, postcondition və fail-closed davranış.

Test qatları

Doğrulama səkkiz hissəli stack ehtiva edir:

  1. Pinned dependency-lərlə compilation.
  2. Səkkiz ucdan-uca local-EVM testi.
  3. EVM ilə Python fixture correspondence.
  4. On səkkiz Python testi.
  5. 100.000 yolluq əsas dinamik eksperiment.
  6. 3×3 commonality/dealer-capacity sensitivity grid.
  7. Dealer-capacity reverse stress.
  8. SHA-256 manifest-ləri ilə source/output izlənə bilənliyi.

Property-based transition testing, adversarial fuzzing, real gas profilləmə, müstəqil təhlükəsizlik auditi, permissioned pilot və jurisdiction-specific legal review tamamlanmış doğrulama dəstinin xaricində qalır.

Səkkiz EVM mexanizm testi

TestSınanan əsas invariant
Protected-lot horizon liquidity1/7/30 günlük likvidliyin ayrıca və konservativ hesablanması.
Reserve-first mint capƏn kiçik CRC, RLR və ya supply limiti məcburidir.
Access loss / stale valueUğursuz lot rezervdən çıxarılır.
Matured but unconfirmedMüddətin bitməsi avtomatik nağd demək deyil.
Repo haircut / inactive bankHaircut tətbiq olunur; inactive counterparty qabiliyyəti çıxarılır.
Oracle divergencePAUSED circuit breaker işə düşür.
STRESS redemptionMinting dayanır; lock–payment–burn ardıcıllığı işləyə bilər.
Duplicate lot / protected releaseDuplicate commitment və NORMAL vəziyyətdə release rədd edilir.

Bu testlərin hamısı keçmişdir. Lakin example-based testlərin keçməsi bütün mümkün adversarial transition-ların təhlükəsiz olduğunu sübut etmir.

Dörd qollu eksperiment niyə lazım idi?

Mənbənin əvvəlki ATLAS işində daha yaxşı məlumatla daha yaxşı maturity allocation eyni anda dəyişdiyi üçün nəticənin hansı mexanizmdən qaynaqlandığı ayrışdırıla bilmirdi. Paper II buna görə eyni shock tape üzərində dörd ardıcıl qol yaratmışdır.

QolTərif
A — Aggregate informationCurrent lot-state execution yoxdur; maturity confirmation gecikməlidir; repo çıxışı məhduddur; rollover passivdir.
B — Lot-observed, passiveEyni portfel; aktual lot müşahidəsi və daha yaxşı execution; rollover hələ passivdir.
C — Lot-observed + executable controlB ilə eyni portfel; tam repo execution və RLR/run vəziyyətində maturity cash retention.
D — Controlled maturity ladderC-nin məlumat və nəzarətləri; yalnız ilkin maturity distribution dəyişdirilir.

D qolu üçün equality audit

XüsusiyyətA/B/CD
Ümumi rezerv100100
Cash1515
Mövqe sayı44
Weighted-average maturity37,05 gün37,05 gün
Linear yield proxy422,23 bp422,23 bp
Operating-cost proxy3,00 bp3,00 bp
7 günlük maturity liquidity3040
30 günlük maturity liquidity5565
Ən böyük mövqe4535

Buna görə D qolunun fərqi “daha çox rezerv” və ya “daha qısa orta maturity” deyil. Ssenari daxilində eyni resursların daha fərqli müddət bölgüsü ilə yerləşdirilməsidir.

Simulyasiya quruluşu

Əsas eksperiment:

  • 100.000 müstəqil sistem yolu,
  • 30 gün,
  • 3 issuer,
  • başlanğıcda hər issuer üçün 100 rezerv və 100 token supply,
  • eyni path daxilində bütün qollar üçün ortaq redemption, bank, custody, repo, stress və dealer-capacity draw-ları

istifadə edir.

Market-wide stress sistem yollarının %12-sində qurulmuşdur. Bunun və digər stochastic distribution-ların mənbədə açıq şəkildə ssenari fərziyyələri olduğu bildirilir; issuer və ya holder davranışı üçün empirik təxmin deyil.

Əsas dinamik nəticələr

NəticəABCD
Orta məcburi satış, %6,8116,5496,0015,034
P95 məcburi satış, %52,76951,86549,15240,955
P99 məcburi satış, %60,26159,53558,75756,312
Hər hansı məcburi satış ehtimalı, %57,63339,73534,86628,146
Orta liquidation loss, bp11,4739,7668,5886,268
Orta daily queue, %0,05000,04840,04240,0299
Day-30 queue ehtimalı, %0,6110,6110,6060,610

D qolu hər metrikdə mütləq üstün deyil. Məsələn, day-30 queue ehtimalı C-dən çox kiçik miqdarda yüksəkdir və uyğun paired interval sıfırı ehtiva edir. Mənbənin daha dar nəticəsi D-nin satış, itki və horizon daxilində queue burden-i ssenari altında azaltmasıdır.

Ardıcıl təsirlər

MexanizmMəcburi satış azalmasıİtki azalmasıHər hansı satış ehtimalı azalması
Məlumat tətbiqi — B−A0,262 faiz bəndi1,707 bp17,898 faiz bəndi
Executable control — C−B0,548 faiz bəndi1,178 bp4,869 faiz bəndi
Maturity allocation — D−C0,967 faiz bəndi2,320 bp6,720 faiz bəndi

Bu təsirlər modeldə istifadə edilən treatment təriflərindən asılıdır. Məsələn, B−A saf “məlumatın abstrakt dəyəri” deyil; daha sürətli maturity confirmation, daha yüksək executable repo payı və gec satış priminin aradan qaldırılması kimi mənbədə məlumat tətbiqi ilə birlikdə müəyyən edilmiş əməliyyat fərqlərini əhatə edir.

Həssaslıq və reverse stress

Maturity-allocation itki üstünlüyü test edilən 3×3 common-factor / dealer-capacity grid-in doqquz hüceyrəsinin hamısında müsbət qalmış və təxminən 0,959–4,720 baz bəndi arasında dəyişmişdir.

Dealer qabiliyyəti 15 olduqda fayda daha böyük, 40 olduqda daha kiçikdir. Bu nəticə real bazarda dealer capacity-nin digər bütün amillərdən daha vacib olduğunu sübut etmir; yalnız mənbədə istifadə edilən modeldə allocation üstünlüyünün conversion bottleneck-ə həssas olduğunu göstərir.

Reverse stress-də seçilən “maximum queue > %5” meyarının ən çox %5 yolda görülməsi üçün minimum test edilən stressed dealer capacity:

  • A: 25,
  • B: 25,
  • C: 24,
  • D: 22

olmuşdur.

Bu rəqəmlər real Treasury bazarındakı qabiliyyət və ya tənzimləyici təhlükəsizlik hədləri deyil.

Bu İş Blockchain-in Off-Chain Nəzarətdən Üstün Olduğunu Sübut Edirmi?

Xeyr. Mənbənin açıq falsification meyarına görə, eyni reserve uniqueness, role separation, mint constraint, reconstruction və incident accountability funksiyası doğrulana bilən off-chain sistemlə daha aşağı xərc, məxfilik riski və governance yükü ilə təmin edilə bilirsə, müvafiq funksiyanın blokçeyndə saxlanması üçün iş üstünlük iddiası irəli sürmür.

Etimad yox olmur, yerini dəyişir

Protokol müqavilənin qəbul etdiyi state üzərində qaydanın düzgün tətbiq olunub-olunmadığını sınaqdan keçirə bilər. Lakin aşağıdakı xarici müddəalar institutlardan asılı qalır:

  • Custodian həqiqətən aktivi saxlayırmı?
  • Rezerv üzərində başqa hüquq və ya lien varmı?
  • Oracle-ın upstream məlumatı doğrudurmu?
  • Trust/protection strukturu hüquqi baxımdan effektivdirmi?
  • Bank ödənişi həqiqətən finaldırmı?
  • Resolution aktoru həqiqətən tələb olunan hüquqi səlahiyyətə malikdirmi?

Buna görə “on-chain” olmaq “trustless” olmaq demək deyil.

Məxfilik sərhədi

Mənbə müştəri kimliyi, bank hesabları, custody statement-ları, ödəniş təlimatları və hüquq rəyləri kimi məlumatların daimi public ledger-a qoyulmamasını müdafiə edir. Paylaşılan state yalnız qaydanın doğrulanması üçün tələb olunan minimum məlumatı saxlamalıdır.

Hash istifadəsi də təkbaşına məxfilik zəmanəti deyil. Timestamp, ünvan, lot dəyişməsi, böyük rezerv hərəkəti və ya STRESS keçidi metadata vasitəsilə iqtisadi məlumat sızdıra bilər.

Miqyas və xərc sərhədi

Mövcud prototip real böyük portfellərdə gas, throughput, storage growth, proof generation, recovery time və ya ucdan-uca latency benchmark hesabatı vermir.

Müqavilələrin EIP-170 bytecode limitindən aşağı olması yalnız deployment edilə bilmənin nəzarətidir; production miqyaslana bilməsi nəticəsi deyil.

İstehsal üçün mərhələli yanaşma

Mənbə dörd geniş mərhələ təklif edir:

  1. Phase I — Shadow ledger: Canlı fond və minting səlahiyyəti olmadan source məlumatın mirror edilməsi və reconciliation.
  2. Phase II — Controlled pilot: Məhdud asset, participant, supply və duration ilə paralel legacy control.
  3. Phase III — Supervised production: Davamlı reconciliation, audit, incident reporting və scale limitləri ilə nəzarətli live authority.
  4. Phase IV — Optional public-sector research: Yalnız Core və rəqabətli özəl kanalların həll edə bilmədiyi davamlı bottleneck müstəqil sübutla göstərilərsə ayrıca araşdırma.

Bu ardıcıllıq avtomatik deployment yol xəritəsi deyil. Hər mərhələdə legal, data, security, operations və net-benefit şərtləri təmin edilməzsə irəliləyiş dayanmalıdır.

İşin dəstəklədiyi nəticə

Mənbə ilə dəstəklənən: rezerv mövqelərinin settlement, eligibility, encumbrance, protection, çıxış, aktual valuation, maturity və provider vəziyyətləri açıq state şərtlərinə çevrilə bilər; bu state yeni stablecoin öhdəliyi yaratmaq səlahiyyətini və redemption davranışını deterministik şəkildə məhdudlaşdıra bilər.

Həmçinin mənbə ssenarisində lot məlumatı, executable control və daha balanslı maturity allocation-ın hər birinin əlavə olunması orta məcburi satış və liquidation loss-u azaltmışdır.

İşin dəstəkləmədiyi nəticə

Mənbənin sübut etmədiyi: Core PTRL-nin production-secure olduğu, real stablecoin emitentlərində eyni itki azalmasını yaradacağı, hüquqi protection və ya bankruptcy priority yaratdığı, real dealer capacity-ni düzgün modelləşdirdiyi, təklif olunan RLR nisbətlərinin optimal olduğu və ya blokçeynin hər vəziyyətdə ən yaxşı implementation texnologiyası olduğu göstərilməyib.

İş həmçinin stablecoin qiymətini, holder welfare-i, Treasury borrowing cost-u, monetary transmission-u və ya tam bazar equilibrium-unu proqnozlaşdırmır.

Mənbə və Metod Qeydi

Orijinal iş: From Reserve Disclosure to Executable Control: A Blockchain-Native Reference Architecture for Treasury-Backed Stablecoins.

Müəllif: Seungwoo Lee.

Affiliasiya: Independent Researcher.

ORCID: 0009-0001-7041-8467.

Mənbə: SSRN working paper / Project ATLAS Paper II.

SSRN Abstract ID: 7282663.

DOI: 10.2139/ssrn.7282663.

Date Written: 14 avqust 2026.

SSRN göndərilmə tarixi: 18 avqust 2026.

Uzunluq: 62 səhifə.

Lisenziya: Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International — CC BY-NC-ND 4.0.

Resenziya vəziyyəti: SSRN working paper; resenziyalı jurnal versiyası göstərilmir.

Araşdırma növü: Design-science, executable reference architecture və scenario-based mechanism validation.

Tətbiq: On Solidity müqaviləsi; EVM referans arxitekturası.

Doğrulama: Səkkiz ucdan-uca local-EVM testi, integer-exact Python mirror və ümumilikdə on səkkiz Python testi.

Əsas simulyasiya: 100.000 yol × 30 gün × 3 issuer; ortaq shock tape üzərində dörd eksperiment qolu.

Əsas çıxışlar: forced-sale volume, liquidation loss, forced-sale ehtimalı, queue ölçüləri, repo istifadəsi və redemption.

Əsas şərh sərhədi: Simulyasiya əmsalları empirik olaraq təxmin edilmiş real issuer və ya Treasury-market parametrləri deyil. Monte Carlo intervalları yalnız verilmiş ssenari altında finite-run simulation error-u ölçür.

Production-security sərhədi: Property-based testing, geniş fuzzing, müstəqil security audit, real gas/throughput benchmark-ları və canlı permissioned pilot tamamlanmayıb.

Hüquqi sərhəd: Kod mülkiyyət, bankruptcy remoteness, ödəniş finality-si və ya resolution səlahiyyəti yaratmır. Bunlar real sənədlər, institutlar və tətbiq olunan hüquqdan asılıdır.

Legal source cutoff: 14 avqust 2026.

Maliyyələşdirmə: Xarici maliyyələşdirmə alınmayıb.

Maraqlar toqquşması: Müəllif əlaqəli maraqlar toqquşması bildirmir.

Data və code: Versioned source code, contract fixture-ları və şəffaf scenario outputs istifadə olunmuş; confidential issuer, müştəri, bank, custodian və ya payment məlumatı istifadə edilməyib.

Generative AI istifadəsi: Kod inkişafı, debugging, drafting və editorial review proseslərində generative AI dəstəyi istifadə olunmuşdur. Araşdırma suallarının və arxitekturanın seçilməsi, fərziyyələrin nəzərdən keçirilməsi, executable outputs-un doğrulanması və yekun məsuliyyət müəllifə aiddir.

Maliyyə şərhi sərhədi: İş stablecoin, Xəzinə bonosu və ya başqa maliyyə məhsulu üçün investisiya tövsiyəsi vermir.


Paylaşın:

Şərhlər yoxlandıqdan sonra yayımlanır.Şərhiniz təsdiq prosesinə daxil ediləcək və uyğun hesab olunduqda görünəcək.

Şərh yazın

E-poçt ünvanınız yayımlanmayacaq. Məcburi sahələr * ilə işarələnib

Your experience on this site will be improved by allowing cookies Cookie Policy