
Kuwepo kwa kiasi cha kutosha cha hati za Hazina, fedha taslimu au akiba nyingine inayofaa kwenye mizania ya mtoaji wa stablecoin hakumaanishi kwamba mali hizo zinaweza, katika wakati huo, kuunga mkono utoaji mpya wa stablecoin kwa usalama. Mali ya akiba inaweza kuwa bado haija-settle, inaweza kuwa imewekwa dhamana, inaweza isiwe chini ya udhibiti wa taasisi sahihi ya kisheria, custodian au benki inaweza kutopatikana, data ya bei inaweza kuwa imepitwa na wakati, au kubadilisha mali kuwa fedha taslimu kunaweza kuchukua muda mrefu kuliko kipindi ambacho ombi la redemption linapaswa kutimizwa.
Utafiti wa Project ATLAS Paper II wa Seungwoo Lee unahamisha tofauti hii kutoka ufichuzi wa akiba kwenda udhibiti wa wakati wa muamala. Core Programmable Treasury Reserve Layer (PTRL) iliyotengenezwa katika utafiti, badala ya kurekodi tu kiasi cha jumla cha akiba, hutathmini kando settlement, encumbrance, ufikivu, ulinzi wa kisheria, uhalisia wa valuation, hali ya mtoa huduma na upatikanaji kulingana na maturity ya kila nafasi ya akiba. Wajibu mpya wa stablecoin unaweza kuundwa tu kwa kiwango ambacho masharti yote yanayofunga yanaruhusu.
Muundo unaopendekezwa na chanzo si stablecoin, CBDC wala hati ya Hazina iliyotokenishwa. Treasury Reserve Certificate (TRC) si token inayoweza kuuzwa inayowakilisha mali yenyewe; ni kitu cha rekodi kisichoweza kuhamishwa kinachounganisha ushahidi na taarifa ya hali kuhusu nafasi ya akiba iliyopo. Wakati usanifu huu unaunganisha ushahidi wa akiba na masharti ya smart contract, unatambua kwa uwazi kwamba masuala kama umiliki, kipaumbele katika ufilisi, finality ya malipo na mamlaka ya kisheria yanaendelea kuamuliwa na taasisi halisi na sheria inayotumika.
Prototipu yenye mikataba kumi ya Solidity imepita majaribio nane ya EVM ya mwisho-hadi-mwisho. Katika jaribio lenye matawi manne linalojumuisha njia 100.000 za simulizi za siku thelathini, aggregate information, uchunguzi wa sasa wa lot, executable control na maturity ladder iliyo na uwiano zaidi zililinganishwa kwa mpangilio. Chini ya dhana za senario za modeli yenyewe, kila nyongeza ya taarifa, udhibiti na mgawanyo wa maturity ilipunguza wastani wa mauzo ya kulazimishwa na hasara za liquidation. Hata hivyo, thamani hizi si matokeo yanayotarajiwa kwa watoaji halisi wa stablecoin; ni senario za uthibitishaji wa mekanizimu.
Kwa Nini Akiba ya Stablecoin Haitoshi Kuwa Tu “Imeungwa Mkono 1:1”?
Kwa sababu kiasi cha akiba cha nomino hakionyeshi kama mali inaweza kutumika kweli katika muda fulani. Katika usanifu wa utafiti, ili akiba iweze kuunga mkono utoaji wa stablecoin, lazima isiwe tu ipo bali pia iwe ime-settle, inastahili, haina dhamana, inafikika, imelindwa, inashikiliwa kupitia taasisi hai na inaungwa mkono na data ya valuation iliyo ya sasa; kwa redemption ya muda mfupi, lazima pia iweze kubadilishwa kuwa fedha taslimu ndani ya upeo husika wa wakati.
Hii ndiyo tofauti kati ya thamani ya kihasibu na uwezo wa kiutendaji. Hati ya Hazina inaweza kuwa na thamani kiuchumi lakini ikiwa:
- settlement haijakamilika,
- imewekwa pledge kwa wajibu mwingine,
- custodian haipatikani,
- data ya valuation ni stale,
- rekodi ya protection au beneficiary si halali,
- maturity yake iko baada ya hitaji la redemption
basi huenda isikubaliwe wakati huo kama uwezo unaoweza kutumika kuunga mkono kiasi sawa cha wajibu wa stablecoin.
Kanuni kuu ya chanzo: reserve backing ni hali
Hoja kuu ya makala ni kwamba reserve backing inapaswa kufikiriwa si kama hisa tuli bali kama state-dependent permission. Kuonekana kwa mali kwenye portfolio ya akiba hakutengenezi moja kwa moja mamlaka ya minting.
Mantiki ya masharti ya utambuzi kwa kila lot inaonyeshwa hivi:
\[ C_{j,t}(b)=\prod_{\ell \in P_{j,t}(b)} I_\ell \]
Hapa \(I_\ell\) ni kiashiria cha binary kinachowakilisha kila sharti linalohitajika. Ikiwa masharti yote ni 1, lot inatambuliwa. Ikiwa sharti moja tu ni sifuri, zao lote huwa sifuri.
Kwa hiyo mfumo hautumii mantiki ya “kubali kwa wastani kwa sababu baadhi ya masharti ni mazuri”. Hati ya Hazina yenye ubora wa juu inaweza kuondolewa kwa sababu custodian haipatikani; kuwepo kwa akiba ya ziada katika lot nyingine hakuondoi tatizo hilo mahususi la ufikivu.
Treasury Reserve Certificate (TRC) Ni Nini?
Treasury Reserve Certificate ni state object isiyoweza kuhamishwa inayohifadhi utambulisho, hali na viungo vya ushahidi vinavyohusiana na nafasi ya akiba iliyopo; si toleo la token la hati ya Hazina, haimpi mmiliki wa stablecoin haki ya moja kwa moja ya umiliki katika lot fulani ya akiba, na haijaundwa kama token inayoweza kuuzwa kama ERC-20 au ERC-721.
Kila TRC inaunganishwa na makundi matano makuu ya taarifa:
| Kundi la taarifa | Kazi |
|---|---|
| Utambulisho | Kitambulisho cha lot, position commitment ya kipekee na kiungo cha asset identifier iliyolindwa. |
| Masharti ya kiuchumi | Aina ya mali, thamani ya nomino, muda wa settlement na muda wa maturity. |
| Uhusiano wa kitaasisi | Custodian/benki na beneficiary inayoungwa mkono na akiba. |
| Hali ya kiutendaji | Eligibility, encumbrance, availability na hali ya lifecycle ya PENDING / SETTLED / FROZEN / MATURED / SOLD. |
| Ushahidi wa hatari | Market value, haircut, muda wa valuation na rekodi tofauti za protection/access. |
Kuhesabu akiba ileile mara mbili kunazuiwaje?
Katika prototipu, positionCommitment moja inaweza kutumika kuunda TRC moja tu. Ikiwa lot ya pili itasajiliwa kwa commitment hiyo hiyo, muamala unakataliwa.
Mekanizimu hii inazuia tu kurudiwa kwa commitment hiyo hiyo ndani ya protokali. Ikiwa katika ulimwengu halisi mali ileile ya kiuchumi imesajiliwa kwa vitambulisho viwili tofauti vya upstream, mkataba hauwezi kujua wenyewe kwamba ni mali ileile. Ndiyo maana chanzo kinaeleza wazi kwamba mfumo halisi wa production unahitaji canonical asset identity na reconciliation kati ya taasisi.
Kwa nini hati iliyoiva haichukuliwi moja kwa moja kuwa fedha taslimu?
Maturity ya kimkataba na cash settlement halisi si tukio moja. Katika chanzo, lot ya non-cash ambayo maturity yake imepita haitumiki na injini ya akiba kama fedha taslimu hadi ubadilishaji wake unaolingana kuwa fedha taslimu uthibitishwe kando.
Tofauti hii ni muhimu hasa katika mifumo ya redemption: kauli “imeiva leo” na kauli “leo kumetokea fedha taslimu zinazoweza kutumika kwenye akaunti ya malipo” ni tofauti kiutendaji.
Usanifu wa Core PTRL Unafanyaje Kazi?
Core PTRL inaunganisha ushahidi wa kitaasisi, hesabu ya hatari, wajibu wa stablecoin na mamlaka ya protokali katika tabaka tano za kimantiki: tabaka la kitaasisi linawakilisha taasisi halisi; tabaka la evidence linawakilisha rekodi za hali zinazoweza kuthibitishwa; tabaka la risk/control linahesabu CRC na ukwasi; tabaka la liability/settlement linasimamia minting na redemption; na tabaka la authority/assurance linasimamia mamlaka za NORMAL, STRESS, RESOLUTION na PAUSED.
1. Tabaka la kitaasisi
Issuer, benki, custodian, trustee, oracle reporter, auditor, supervisor, dealer na resolution authority kama taasisi halisi zipo hapa. Blockchain haitengenezi taasisi hizi; inaakisi tu hali za utambulisho na mamlaka zinazokubalika kwenye eneo la pamoja la udhibiti.
2. Tabaka la Evidence
Lot za akiba, rekodi za protection, uchunguzi wa valuation na mistari ya repo hubadilishwa kuwa typed commitment na uchunguzi.
3. Tabaka la risk na control
ReserveRiskEngine huamua lot zipi zihesabiwe; huhesabu Conservative Reserve Coverage na ukwasi wa siku 1/7/30. IssuerController kisha huchukua minimum ya mipaka yote ili kubainisha mint headroom.
4. Tabaka la liability na settlement
AtlasSettlementToken hutumika tu katika prototipu kupima upande wa wajibu unaofanana na stablecoin. RedemptionRouter huweka token kwenye escrow, husubiri uthibitisho wa malipo ya benki na hufanya burn tu baada ya hapo.
5. Tabaka la authority na assurance
AtlasStateController huweka kikomo kwa ni operesheni zipi zinawezekana katika kila hali ya protokali. Majukumu kama auditor na supervisor yana nafasi katika audit ya nje na uthibitishaji wa historia ya matukio na source record.
Mgawanyo wa majukumu ya moduli kumi
| Moduli | Kazi kuu |
|---|---|
| ParticipantRegistry | Huhifadhi majukumu hai ya kitaasisi. |
| TreasuryReserveCertificate | Husajili lot ya akiba ya kipekee na taarifa ya lifecycle. |
| StabilityProtectionTrust | Husajili hali ya protection, beneficiary na access. |
| ReserveOracleAdapter | Hufanya udhibiti wa valuation ya vyanzo vingi, freshness na divergence. |
| RepoCapacityOracle | Huhifadhi uwezo wa repo wa siku 1/7/30 kwa kila counterparty. |
| ReserveRiskEngine | Huhesabu CRC na maturity liquidity. |
| IssuerController | Huhesabu na kutekeleza reserve-first mint headroom. |
| AtlasSettlementToken | Token ya wajibu ya prototipu. |
| RedemptionRouter | Hutekeleza mlolongo Lock → uthibitisho wa malipo → burn. |
| AtlasStateController | Husimamia hali za NORMAL, STRESS, RESOLUTION na PAUSED. |
Reserve-First Minting Ni Nini?
Reserve-first minting ni muundo unaotaka uwezo wa akiba unaoweza kutumika uwepo kabla ya muamala badala ya kutengeneza stablecoin kwanza na kuifananisha na akiba baadaye; supply baada ya mint haiwezi kuzidi thamani ya chini zaidi inayoruhusiwa na risk-adjusted reserve coverage, ukwasi wa redemption wa siku 1/7/30, dari ya supply ya kiutendaji na mamlaka ya protokali.
Conservative Reserve Coverage
Thamani ya lot inayotambuliwa \(j\) baada ya haircut huhesabiwa kama:
\[ \widetilde V_{j,t}= \operatorname{floor}\left(V_{j,t}(1-h_{j,t})\right) \]
.
Jumla ya Conservative Reserve Coverage ni:
\[ CRC_t=\sum_j I_{j,t}\widetilde V_{j,t} \]
.
Hapa thamani ya lot yenye \(I_{j,t}=0\) haiingii kwenye CRC hata kama inaonekana kubwa kiasi gani.
Ukwasi wa siku 1, 7 na 30
Kwa kila upeo \(H\in\{1,7,30\}\), ni mali tu zinazopatikana ndani ya kipindi husika na zinazopita masharti mengine ya utambuzi ndizo huongezwa kwenye maturity liquidity.
Uwezo wa repo huhesabiwa kando; hauhesabiwi kama thamani ya akiba. Mstari wa repo hauingii kwenye ukwasi ikiwa hauko:
- fresh,
- hai,
- unimpaired,
- na mpangilio wa horizon unaolingana,
- umeunganishwa na benki/counterparty hai
.
Sharti la Horizon
Kwa kila upeo wa muda:
\[ q_H S_t^{post} \le L_t^{mat}(H)+\widetilde R_t(H) \]
hutumika.
\(q_H\) ni sehemu ya stress-redemption inayotakiwa kuungwa mkono katika upeo huo wa muda. Thamani za \(q_1\), \(q_7\) na \(q_{30}\) zinazotumika katika chanzo ni vigezo vya governance na hatari; hazikugunduliwa na modeli kuwa uwiano “sahihi” au “bora”.
Kikomo cha chini kinachofunga
Supply ya juu baada ya mint inayoweza kuungwa mkono hufafanuliwa kama:
\[ 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\} \]
.
Katika hali ya NORMAL, uwezo mpya wa mint ni:
\[ M_t=\max(K_t-S_t,0) \]
wakati katika hali nyingine isipokuwa NORMAL:
\[ M_t=0 \]
.
Operesheni hii ya minimum ni mojawapo ya sehemu muhimu zaidi za muundo. Kwa mfano, jumla kubwa sana ya akiba haiwezi kuficha uwezo usiotosha wa fedha taslimu wa siku moja kupitia wastani.
Je, Uwezo wa Mint Unaweza Kuwa Sifuri Hata Kama Kuna Akiba ya Ziada kwa Nomino?
Ndiyo. Katika senario ya kawaida ya deterministiki ya chanzo, baada ya cash-bank outage, ingawa thamani ya non-cash reserve inayotambuliwa na mfumo inabaki 80, msaada wa siku moja hushuka hadi sifuri; kwa sababu ukwasi wa siku moja unakuwa kizuizi kinachofunga, mint cap hushuka hadi sifuri.
| Senario | CRC | Msaada wa siku 1 | Msaada wa siku 7 | Msaada wa siku 30 | Mint cap |
|---|---|---|---|---|---|
| Baseline | 100 | 20 | 50 | 100 | 100 |
| Protected-access loss | 50 | 20 | 50 | 50 | 50 |
| Custodian outage | 20 | 20 | 20 | 20 | 20 |
| Cash-bank outage | 80 | 0 | 30 | 80 | 0 |
| All valuations stale | 0 | 0 | 0 | 0 | 0 |
| STRESS state | 100 | 20 | 50 | 100 | 0 |
| Matured but unconfirmed | 70 | 20 | 20 | 70 | 50 |
Mifano hii inaonyesha tabia ya usanifu unaojumuisha si tu kiasi cha akiba bali pia hali ya upatikanaji wa akiba na hali ya authority katika kikomo cha minting.
Kwa Nini Redemption Hufuata Mlolongo wa “Funga → Lipa → Thibitisha → Choma”?
Kwa sababu wajibu wa stablecoin upo kwenye blockchain huku malipo ya fiat yanayolingana yakikamilishwa katika mfumo tofauti wa benki; token ikichomwa kabla ya malipo kukamilika, dai la holder linaweza kutoweka, na fiat ikilipwa huku token ikibaki kwenye mzunguko, wajibu huo huo unaweza kubeba thamani ya kiuchumi mara mbili.
Mtiririko rejea wa chanzo:
- Holder hutuma kiasi cha token na payout instruction commitment iliyolindwa.
- RedemptionRouter hufunga token kwenye escrow.
- Benki au payment process hufanya malipo ya fiat.
- Opereta wa malipo aliyeidhinishwa husajili nonzero payment-proof commitment.
- Request huwa PAID na token iliyo kwenye escrow huchomwa.
Hapa payment-proof hash haithibitishi malipo halisi ya benki kutoka first principles kwa blockchain. Hash hutoa kiungo cha integrity kwenda kwenye rekodi ya benki iliyolindwa ambayo auditor aliyeidhinishwa anapaswa kuweza kuifikia.
Tofauti Kati ya NORMAL, STRESS, RESOLUTION na PAUSED Ni Nini?
NORMAL ni hali ya kawaida ya minting na redemption; STRESS husimamisha supply mpya huku ikiendeleza redemption halali; RESOLUTION hufunga maombi mapya ya kawaida ya redemption na kuhamisha maombi yanayosubiri pamoja na udhibiti wa akiba iliyolindwa kwenda mchakato wa utatuzi ulioidhinishwa; PAUSED ni hali ya circuit breaker inayosimamisha kwa muda minting na malipo wakati kuna kutokuwa na uhakika mkubwa wa data au control.
| Kazi | NORMAL | STRESS | RESOLUTION | PAUSED |
|---|---|---|---|---|
| Mint mpya | Ndiyo, ndani ya mipaka | Hapana | Hapana | Hapana |
| Redemption mpya ya kawaida | Ndiyo | Ndiyo | Hapana | Hapana |
| Redemption inayosubiri yenye uthibitisho wa benki | Ndiyo | Ndiyo | Ndiyo | Hapana |
| Protected-control release | Hapana | Hapana | Ndiyo | Ndiyo |
Kutokuruka moja kwa moja kutoka NORMAL kwenda RESOLUTION pia ni sifa ya muundo katika chanzo. STRESS huunda escalation boundary inayoonekana.
Kwa nini oracle divergence husababisha PAUSED?
Ikiwa vyanzo vingi vinavyokubalika vya valuation vinatofautiana zaidi ya tolerance iliyosanidiwa, mfumo, badala ya “kuchagua bei inayofaa zaidi”, huhitimisha kuwa thamani ya pamoja haiwezi kutetewa na huanzisha njia ya PAUSED.
Mekanizimu hii haithibitishi kwamba oracle inajua ukweli. Inaweka wazi tu ni chini ya masharti gani ya data protokali itakataa kufanya muamala.
Mbinu na Matokeo ya Utafiti
Mbinu ya Design-science
Utafiti si uchumi wa kawaida wa uchunguzi wala utafiti wa athari za kisababishi. Katika mbinu ya Design-science, mahitaji ya kitaasisi yalitenganishwa kwanza, kisha executable artifact inayoyawakilisha ikaundwa na tabia zake zilizobainishwa zikajaribiwa.
Kila hitaji liliundwa kwa hatua tatu:
- Institutional claim: kazi ya kifedha, kisheria au kiutendaji.
- Source and boundary: chanzo ambacho kazi hii inategemea na eneo ambalo chanzo halithibitishi.
- Executable consequence: data, jukumu, precondition, postcondition na tabia ya fail-closed.
Tabaka za majaribio
Uthibitishaji unajumuisha stack ya sehemu nane:
- Compilation yenye pinned dependency.
- Majaribio nane ya end-to-end ya local-EVM.
- EVM na Python fixture correspondence.
- Majaribio kumi na nane ya Python.
- Jaribio kuu la mienendo la njia 100.000.
- 3×3 commonality/dealer-capacity sensitivity grid.
- Dealer-capacity reverse stress.
- Ufuatiliaji wa source/output kwa manifest za SHA-256.
Property-based transition testing, adversarial fuzzing, profiling halisi ya gas, security audit huru, permissioned pilot na jurisdiction-specific legal review ziko nje ya seti ya uthibitishaji iliyokamilishwa.
Majaribio nane ya mekanizimu ya EVM
| Jaribio | Invariant kuu inayojaribiwa |
|---|---|
| Protected-lot horizon liquidity | Kuhesabu ukwasi wa siku 1/7/30 kando na kwa tahadhari. |
| Reserve-first mint cap | CRC, RLR au supply limit ndogo zaidi ndiyo inayofunga. |
| Access loss / stale value | Lot inayoshindwa huondolewa kwenye akiba. |
| Matured but unconfirmed | Kufikia maturity hakumaanishi moja kwa moja kuwa fedha taslimu. |
| Repo haircut / inactive bank | Haircut hutumika; uwezo wa inactive counterparty huondolewa. |
| Oracle divergence | PAUSED circuit breaker huanzishwa. |
| STRESS redemption | Minting husimama; mlolongo lock–payment–burn unaweza kufanya kazi. |
| Duplicate lot / protected release | Duplicate commitment na release katika NORMAL hukataliwa. |
Majaribio haya yote yamepita. Lakini kupita kwa example-based tests hakuthibitishi kwamba adversarial transition zote zinazowezekana ni salama.
Kwa nini jaribio la matawi manne lilihitajika?
Katika kazi ya awali ya ATLAS ya chanzo, taarifa bora na maturity allocation bora zilibadilika kwa wakati mmoja, hivyo haikuwezekana kutenganisha ni mekanizimu gani iliyosababisha matokeo. Kwa hiyo Paper II iliunda matawi manne mfululizo kwenye shock tape ileile.
| Tawi | Maelezo |
|---|---|
| A — Aggregate information | Hakuna current lot-state execution; maturity confirmation imechelewa; access ya repo ni ndogo; rollover ni passive. |
| B — Lot-observed, passive | Portfolio ileile; uchunguzi wa sasa wa lot na execution bora; rollover bado ni passive. |
| C — Lot-observed + executable control | Portfolio ileile na B; repo execution kamili na maturity cash retention katika hali ya RLR/run. |
| D — Controlled maturity ladder | Taarifa na controls za C; ni initial maturity distribution pekee inayobadilishwa. |
Equality audit kwa tawi D
| Sifa | A/B/C | D |
|---|---|---|
| Jumla ya akiba | 100 | 100 |
| Cash | 15 | 15 |
| Idadi ya nafasi | 4 | 4 |
| Weighted-average maturity | siku 37,05 | siku 37,05 |
| Linear yield proxy | 422,23 bp | 422,23 bp |
| Operating-cost proxy | 3,00 bp | 3,00 bp |
| Maturity liquidity ya siku 7 | 30 | 40 |
| Maturity liquidity ya siku 30 | 55 | 65 |
| Nafasi kubwa zaidi | 45 | 35 |
Kwa hiyo tofauti ya tawi D si “akiba zaidi” wala “maturity ya wastani iliyo fupi zaidi”. Ni kuweka rasilimali zilezile kwa mgawanyo tofauti wa maturity ndani ya senario.
Muundo wa simulizi
Jaribio kuu linatumia:
- njia 100.000 huru za mfumo,
- siku 30,
- issuer 3,
- mwanzoni akiba 100 na token supply 100 kwa kila issuer,
- ndani ya path ileile, redemption, benki, custody, repo, stress na dealer-capacity draw za pamoja kwa matawi yote
.
Market-wide stress imewekwa katika %12 ya njia za mfumo. Hii na stochastic distribution nyingine zimeainishwa wazi katika chanzo kuwa dhana za senario; si makadirio ya kihisia ya tabia ya issuer au holder.
Matokeo makuu ya mienendo
| Matokeo | A | B | C | D |
|---|---|---|---|---|
| Wastani wa mauzo ya kulazimishwa, % | 6,811 | 6,549 | 6,001 | 5,034 |
| P95 mauzo ya kulazimishwa, % | 52,769 | 51,865 | 49,152 | 40,955 |
| P99 mauzo ya kulazimishwa, % | 60,261 | 59,535 | 58,757 | 56,312 |
| Uwezekano wa mauzo yoyote ya kulazimishwa, % | 57,633 | 39,735 | 34,866 | 28,146 |
| Wastani wa liquidation loss, bp | 11,473 | 9,766 | 8,588 | 6,268 |
| Wastani wa daily queue, % | 0,0500 | 0,0484 | 0,0424 | 0,0299 |
| Uwezekano wa Day-30 queue, % | 0,611 | 0,611 | 0,606 | 0,610 |
Tawi D si bora kabisa katika kila kipimo. Kwa mfano, uwezekano wa day-30 queue ni mkubwa kwa kiasi kidogo sana kuliko C na paired interval husika inajumuisha sifuri. Hitimisho finyu zaidi la chanzo ni kwamba D hupunguza mauzo, hasara na queue burden ndani ya horizon chini ya senario.
Athari za mfuatano
| Mekanizimu | Upungufu wa mauzo ya kulazimishwa | Upungufu wa hasara | Upungufu wa uwezekano wa mauzo yoyote |
|---|---|---|---|
| Utekelezaji wa taarifa — B−A | pointi za asilimia 0,262 | 1,707 bp | pointi za asilimia 17,898 |
| Executable control — C−B | pointi za asilimia 0,548 | 1,178 bp | pointi za asilimia 4,869 |
| Maturity allocation — D−C | pointi za asilimia 0,967 | 2,320 bp | pointi za asilimia 6,720 |
Athari hizi zinategemea treatment definitions zinazotumiwa na modeli. Kwa mfano, B−A si “thamani dhahania safi ya taarifa”; inajumuisha tofauti za kiutendaji zilizoainishwa katika chanzo pamoja na utekelezaji wa taarifa, kama maturity confirmation ya haraka zaidi, sehemu kubwa ya executable repo na kuondolewa kwa premium ya mauzo ya kuchelewa.
Usikivu na reverse stress
Faida ya hasara ya maturity-allocation ilibaki chanya katika seli zote tisa za 3×3 common-factor / dealer-capacity grid iliyojaribiwa na ilitofautiana takriban kati ya pointi 0,959–4,720 za msingi.
Faida ni kubwa zaidi dealer capacity ikiwa 15 na ndogo zaidi ikiwa 40. Matokeo haya hayathibitishi kwamba dealer capacity ni muhimu kuliko mambo mengine yote katika soko halisi; yanaonyesha tu kwamba katika modeli iliyotumiwa na chanzo faida ya allocation ni nyeti kwa conversion bottleneck.
Katika reverse stress, minimum tested stressed dealer capacity ili kigezo kilichochaguliwa cha “maximum queue > %5” kionekane katika si zaidi ya %5 ya njia kilikuwa:
- A: 25,
- B: 25,
- C: 24,
- D: 22
.
Namba hizi si uwezo halisi wa soko la Treasury wala viwango vya usalama vya udhibiti.
Je, Utafiti Huu Unathibitisha Blockchain Ni Bora Kuliko Udhibiti wa Off-Chain?
Hapana. Kwa mujibu wa falsification criterion iliyo wazi ya chanzo, ikiwa kazi ileile ya reserve uniqueness, role separation, mint constraint, reconstruction na incident accountability inaweza kutolewa na mfumo wa off-chain unaoweza kuthibitishwa kwa gharama ya chini, hatari ndogo ya faragha na mzigo mdogo wa governance, utafiti hautoi dai la ubora kwa kuweka kazi husika kwenye blockchain.
Uaminifu hauondoki, unahamia kwingine
Protokali inaweza kupima kama sheria imetekelezwa kwa usahihi kwenye state inayokubaliwa na mkataba. Lakini madai yafuatayo ya nje yanaendelea kutegemea taasisi:
- Je, custodian kweli inashikilia mali?
- Je, kuna haki nyingine au lien juu ya akiba?
- Je, data ya upstream ya oracle ni sahihi?
- Je, muundo wa trust/protection una athari kisheria?
- Je, malipo ya benki kweli ni final?
- Je, resolution actor kweli ana mamlaka ya kisheria inayohitajika?
Kwa hiyo kuwa “on-chain” hakumaanishi kuwa “trustless”.
Kikomo cha faragha
Chanzo kinatetea kutoweka kwenye public ledger ya kudumu data kama utambulisho wa mteja, akaunti za benki, custody statement, maelekezo ya malipo na maoni ya kisheria. State inayoshirikiwa inapaswa kushikilia tu taarifa ya chini kabisa inayohitajika kuthibitisha sheria.
Matumizi ya hash pekee pia si dhamana ya faragha. Timestamp, anwani, mabadiliko ya lot, harakati kubwa ya akiba au mpito wa STRESS vinaweza kuvuja taarifa za kiuchumi kupitia metadata.
Kikomo cha ukubwa na gharama
Prototipu ya sasa hairipoti benchmark ya gas, throughput, storage growth, proof generation, recovery time au end-to-end latency katika portfolio kubwa halisi.
Mikataba kuwa chini ya kikomo cha bytecode cha EIP-170 ni ukaguzi tu wa uwezekano wa deployment; si matokeo ya production scalability.
Mbinu ya hatua kwa hatua kwa production
Chanzo kinapendekeza hatua nne pana:
- Phase I — Shadow ledger: Ku-mirror source data na reconciliation bila fedha hai au mamlaka ya minting.
- Phase II — Controlled pilot: Legacy control sambamba yenye asset, participant, supply na duration iliyowekewa mipaka.
- Phase III — Supervised production: Live authority inayodhibitiwa yenye reconciliation endelevu, audit, incident reporting na scale limits.
- Phase IV — Optional public-sector research: Utafiti tofauti tu ikiwa bottleneck ya kudumu ambayo Core na njia binafsi shindani haziwezi kutatua itaonyeshwa kwa ushahidi huru.
Mfuatano huu si deployment roadmap ya moja kwa moja. Ikiwa katika hatua yoyote masharti ya legal, data, security, operations na net-benefit hayatimizwi, maendeleo yanapaswa kusimama.
Hitimisho linaloungwa mkono na utafiti
Kinachoungwa mkono na chanzo: hali za settlement, eligibility, encumbrance, protection, access, valuation ya sasa, maturity na provider za nafasi za akiba zinaweza kubadilishwa kuwa masharti ya wazi ya state; state hii inaweza kuweka kikomo cha deterministiki kwa mamlaka ya kuunda wajibu mpya wa stablecoin na tabia ya redemption.
Zaidi ya hayo, katika senario ya chanzo, kuongezwa kwa kila moja ya lot information, executable control na maturity allocation iliyo na uwiano zaidi kulipunguza wastani wa mauzo ya kulazimishwa na liquidation loss.
Hitimisho ambalo utafiti hauungi mkono
Ambacho chanzo hakithibitishi: haijaonyeshwa kwamba Core PTRL ni production-secure, kwamba italeta upungufu uleule wa hasara kwa watoaji halisi wa stablecoin, kwamba inatengeneza protection ya kisheria au bankruptcy priority, kwamba inaiga dealer capacity halisi kwa usahihi, kwamba uwiano uliopendekezwa wa RLR ni bora, au kwamba blockchain ndiyo implementation technology bora katika kila hali.
Utafiti pia hautabiri bei ya stablecoin, holder welfare, Treasury borrowing cost, monetary transmission au full market equilibrium.
Dokezo la Chanzo na Mbinu
Kazi ya asili: From Reserve Disclosure to Executable Control: A Blockchain-Native Reference Architecture for Treasury-Backed Stablecoins.
Mwandishi: Seungwoo Lee.
Ushirika: Independent Researcher.
ORCID: 0009-0001-7041-8467.
Chanzo: SSRN working paper / Project ATLAS Paper II.
SSRN Abstract ID: 7282663.
DOI: 10.2139/ssrn.7282663.
Date Written: 14 Agosti 2026.
Tarehe ya kuwasilishwa SSRN: 18 Agosti 2026.
Urefu: kurasa 62.
Leseni: Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International — CC BY-NC-ND 4.0.
Hali ya peer review: SSRN working paper; toleo la jarida lililopitiwa na wenzao halijaonyeshwa.
Aina ya utafiti: Design-science, executable reference architecture na scenario-based mechanism validation.
Utekelezaji: Mikataba kumi ya Solidity; usanifu rejea wa EVM.
Uthibitishaji: Majaribio nane ya end-to-end ya local-EVM, integer-exact Python mirror na jumla ya majaribio kumi na nane ya Python.
Simulizi kuu: njia 100.000 × siku 30 × issuer 3; matawi manne ya jaribio kwenye shock tape ya pamoja.
Matokeo makuu: forced-sale volume, liquidation loss, uwezekano wa forced-sale, vipimo vya queue, matumizi ya repo na redemption.
Kikomo kikuu cha tafsiri: Koefishenti za simulizi si vigezo halisi vya issuer au Treasury-market vilivyokadiriwa kwa data ya kihisia. Vipindi vya Monte Carlo hupima tu finite-run simulation error chini ya senario iliyotolewa.
Kikomo cha production-security: Property-based testing, fuzzing pana, security audit huru, benchmark halisi za gas/throughput na permissioned pilot ya moja kwa moja hazijakamilika.
Kikomo cha kisheria: Code haitengenezi umiliki, bankruptcy remoteness, finality ya malipo au mamlaka ya resolution. Haya yanategemea nyaraka halisi, taasisi na sheria inayotumika.
Legal source cutoff: 14 Agosti 2026.
Ufadhili: Hakuna ufadhili wa nje uliopokelewa.
Mgongano wa maslahi: Mwandishi haripoti mgongano husika wa maslahi.
Data na code: Versioned source code, contract fixture na scenario outputs zilizo wazi zilitumika; confidential issuer, mteja, benki, custodian au payment data hazikutumika.
Matumizi ya Generative AI: Msaada wa generative AI ulitumika katika ukuzaji wa code, debugging, drafting na editorial review. Uteuzi wa maswali ya utafiti na usanifu, mapitio ya dhana, uthibitishaji wa executable outputs na wajibu wa mwisho ni wa mwandishi.
Kikomo cha tafsiri ya kifedha: Utafiti hautoi ushauri wa uwekezaji kuhusu stablecoin, hati za Hazina au bidhaa nyingine yoyote ya kifedha.

Acha maoni
Anwani yako ya barua pepe haitachapishwa. Sehemu za lazima zimewekewa alama ya *