
Stablecoin чыгаруучусунун балансында жетиштүү көлөмдө Казыналык векселдери, накталай акча же башка ылайыктуу резервдердин болушу, бул активдер ошол учурда жаңы stablecoin чыгарууну коопсуз колдой алат дегенди билдирбейт. Резервдик актив али settle боло элек болушу мүмкүн, күрөөгө коюлушу мүмкүн, туура юридикалык жактын көзөмөлүндө болбой калышы мүмкүн, custodian же банк жеткиликсиз болушу мүмкүн, баа маалыматы эскирип калышы мүмкүн же активди накталай акчага айландыруу redemption талабын канааттандыруу керек болгон мөөнөттөн узакка созулушу мүмкүн.
Seungwoo Leeнин Project ATLAS Paper II эмгеги бул айырманы резервди ачыктоодон операция учурундагы көзөмөлгө жылдырат. Иште иштелип чыккан Core Programmable Treasury Reserve Layer (PTRL) резервдердин жалпы көлөмүн гана каттабай, ар бир резерв позициясынын settlement, encumbrance, жеткиликтүүлүк, укуктук коргоо, баалоонун жаңылыгы, провайдердин абалы жана мөөнөтүнө жараша колдонулушун өз-өзүнчө баалайт. Жаңы stablecoin милдеттенмеси бардык милдеттүү шарттар уруксат берген өлчөмдө гана түзүлө алат.
Булак сунуштаган түзүм stablecoin, CBDC же токендештирилген Казыналык вексель эмес. Treasury Reserve Certificate (TRC) активдин өзүн билдирген соодалануучу токен эмес; ал учурдагы резерв позициясына тиешелүү далилди жана абал маалыматтарын байланыштырган өткөрүлбөс каттоо объектиси. Архитектура резерв далилдерин smart contract шарттарына байлаганы менен, менчик, банкроттуктагы артыкчылык, төлөмдүн finality-си жана укуктук ыйгарым укук сыяктуу маселелер реалдуу институттар жана колдонуудагы мыйзам тарабынан аныктала берерин өзгөчө тааныйт.
Он Solidity келишиминен турган прототип сегиз end-to-end EVM тестинен өткөн. 100.000 отуз күндүк симуляция жолун камтыган төрт бутактуу экспериментте aggregate маалымат, актуалдуу lot байкоосу, executable control жана тең салмактуу maturity ladder ирети менен салыштырылган. Моделдин өз сценарий божомолдорунда маалымат, көзөмөл жана мөөнөт бөлүштүрүүнүн ар бир кошумчасы орточо мажбурланган сатууларды жана ликвидациялык жоготууларды азайткан. Бирок бул көрсөткүчтөр реалдуу stablecoin чыгаруучуларынын күтүлгөн натыйжалары эмес, механизмди текшерүү сценарийлери.
Stablecoin Резерви Эмне Үчүн Жөн Гана “1:1 Камсыздалган” Болуу Менен Чектелбейт?
Анткени номиналдык резерв көлөмү активдин белгилүү бир учурда чындап колдонууга жеткиликтүү экенин көрсөтпөйт. Иштин архитектурасында резерв stablecoin чыгарууну колдой алышы үчүн бар болуу менен бирге settle болгон, жарактуу, күрөөсүз, жеткиликтүү, корголгон, активдүү институт аркылуу кармалган жана актуалдуу баалоо маалыматтары менен бекемделген болушу керек; кыска мөөнөттүү redemption үчүн кошумча түрдө тиешелүү убакыт горизонту ичинде накталай акчага айланышы керек.
Бул айырма бухгалтердик нарк менен операциялык мүмкүнчүлүктүн ортосундагы айырма. Казыналык вексель экономикалык жактан баалуу болушу мүмкүн, бирок:
- settlement бүтө элек болсо,
- башка милдеттенме үчүн pledge кылынса,
- custodian жеткиликсиз болсо,
- баалоо маалыматы stale болсо,
- коргоо же beneficiary каттоосу жараксыз болсо,
- мөөнөтү redemption муктаждыгынан кийин бүтсө
ошол учурда ошол эле көлөмдөгү stablecoin милдеттенмесин колдогон колдонууга жарактуу мүмкүнчүлүк катары кабыл алынбашы мүмкүн.
Булактын негизги принциби: reserve backing — бул абал
Макаланын борбордук сунушу reserve backing статикалык запас эмес, state-dependent permission катары каралышы керек деген ой. Активдин резерв портфелинде көрүнүшү minting ыйгарым укугун автоматтык түрдө жаратпайт.
Ар бир lot үчүн таануу шарттарынын логикасы төмөнкүчө берилет:
\[ C_{j,t}(b)=\prod_{\ell \in P_{j,t}(b)} I_\ell \]
Бул жерде \(I_\ell\) зарыл шарттардын ар бирин билдирген бинардык көрсөткүч. Бардык шарттар 1 болсо lot таанылат. Бир гана шарт нөл болсо, бүт көбөйтүндү нөл болот.
Ошондуктан система “айрым шарттар жакшы болгондуктан орточо эсеп менен кабыл ал” логикасын колдонбойт. Жогорку сапаттагы Казыналык вексель жеткиликсиз custodian себебинен четтетилиши мүмкүн; башка lotтогу ашыкча резерв бул конкреттүү жеткиликтүүлүк көйгөйүн жойбойт.
Treasury Reserve Certificate (TRC) Эмне?
Treasury Reserve Certificate — учурдагы резерв позициясынын иденттүүлүгүн, абалын жана тиешелүү далил шилтемелерин сактаган өткөрүлбөс state object; ал Казыналык векселдин токендештирилген формасы эмес, stablecoin ээсине белгилүү бир резерв lotунда түз менчик укугун бербейт жана ERC-20 же ERC-721 сыяктуу соодалануучу токен катары иштелип чыккан эмес.
Ар бир TRC беш негизги маалымат тобуна байланышат:
| Маалымат тобу | Функциясы |
|---|---|
| Идентификация | Lot идентификатору, уникалдуу position commitment жана корголгон asset identifier байланышы. |
| Экономикалык шарттар | Активдин түрү, номиналдык нарк, settlement убактысы жана maturity убактысы. |
| Институционалдык байланыш | Custodian/банк жана резерв колдогон beneficiary. |
| Операциялык абал | Eligibility, encumbrance, availability жана PENDING / SETTLED / FROZEN / MATURED / SOLD lifecycle абалы. |
| Тобокелдик далили | Market value, haircut, valuation убактысы жана өзүнчө protection/access каттоолору. |
Бир эле резервдин эки жолу эсептелиши кантип алдын алынат?
Прототипте бир positionCommitment бир гана TRC түзүү үчүн колдонулушу мүмкүн. Ошол эле commitment менен экинчи lot катталса операция четке кагылат.
Бул механизм протоколдун ичинде ошол эле commitmentтын кайталанышын гана токтотот. Реалдуу дүйнөдө ошол эле экономикалык актив эки башка upstream идентификатор менен катталса, келишим анын бир эле актив экенин өз алдынча биле албайт. Ошондуктан булак production системасында canonical asset identity жана институттар аралык reconciliation талап кылынарын ачык белгилейт.
Мөөнөтү бүткөн вексель эмнеге автоматтык түрдө накталай деп эсептелбейт?
Келишимдик maturity менен иш жүзүндөгү cash settlement бир окуя эмес. Булакта мөөнөтү өткөн non-cash lot тиешелүү накталай айлануу өзүнчө тастыкталмайынча резерв кыймылдаткычы тарабынан накталай катары колдонулбайт.
Бул айырма айрыкча redemption системаларында маанилүү: “бүгүн мөөнөтү бүттү” деген сөз менен “бүгүн төлөм эсебинде колдонууга мүмкүн болгон накталай пайда болду” деген сөз операциялык жактан эки башка нерсе.
Core PTRL Архитектурасы Кантип Иштейт?
Core PTRL беш логикалык катмарда институционалдык далилди, тобокелдик эсебин, stablecoin милдеттенмесин жана протокол ыйгарым укугун байланыштырат: институционалдык катмар реалдуу институттарды; evidence катмары текшерилүүчү абал каттоолорун; risk/control катмары CRC жана ликвиддүүлүктү; liability/settlement катмары minting жана redemptionды; authority/assurance катмары болсо NORMAL, STRESS, RESOLUTION жана PAUSED ыйгарым укуктарын башкарат.
1. Институционалдык катмар
Issuer, банк, custodian, trustee, oracle reporter, auditor, supervisor, dealer жана resolution authority сыяктуу реалдуу институттар ушул жерде. Блокчейн бул институттарды жаратпайт; болгону кабыл алынган идентификация жана ыйгарым укук абалдарын жалпы көзөмөл аймагына чагылдырат.
2. Evidence катмары
Резерв lotтору, protection каттоолору, valuation байкоолору жана repo линиялары typed commitment жана байкоолорго айландырылат.
3. Тобокелдик жана control катмары
ReserveRiskEngine кайсы lotтор эсептелерин аныктайт; Conservative Reserve Coverage жана 1/7/30 күндүк ликвиддүүлүктү эсептейт. IssuerController андан кийин бардык чектердин минимумун алып, mint headroomду аныктайт.
4. Liability жана settlement катмары
AtlasSettlementToken прототипте гана stablecoin сымал милдеттенме тарабын тесттөө үчүн колдонулат. RedemptionRouter токенди escrowго алат, банк төлөмүнүн тастыкталышын күтөт жана андан кийин гана burn операциясын аткарат.
5. Authority жана assurance катмары
AtlasStateController кайсы протокол абалында кайсы операциялар мүмкүн экенин чектейт. Auditor жана supervisor сыяктуу ролдор окуялар тарыхын жана source recordдорду тышкы аудиттен өткөрүүдө жана текшерүүдө роль ойнойт.
Он модулдун милдет бөлүштүрүлүшү
| Модуль | Негизги милдети |
|---|---|
| ParticipantRegistry | Активдүү институционалдык ролдорду сактайт. |
| TreasuryReserveCertificate | Уникалдуу резерв lotун жана lifecycle маалыматын каттайт. |
| StabilityProtectionTrust | Protection, beneficiary жана жеткиликтүүлүк абалын каттайт. |
| ReserveOracleAdapter | Көп булактуу valuation, freshness жана divergence көзөмөлүн жүргүзөт. |
| RepoCapacityOracle | Counterparty боюнча 1/7/30 күндүк repo мүмкүнчүлүгүн сактайт. |
| ReserveRiskEngine | CRC жана maturity liquidity эсептейт. |
| IssuerController | Reserve-first mint headroomду эсептеп, колдонот. |
| AtlasSettlementToken | Прототип милдеттенме токени. |
| RedemptionRouter | Lock → төлөмдү текшерүү → burn тартибин ишке ашырат. |
| AtlasStateController | NORMAL, STRESS, RESOLUTION жана PAUSED абалдарын башкарат. |
Reserve-First Minting Эмне?
Reserve-first minting — адегенде stablecoin чыгарып, андан кийин ага резерв дал келтирүүнүн ордуна, колдонууга жарактуу резерв мүмкүнчүлүгү операциядан мурда бар болсун деген дизайн; mintтен кийинки supply тобокелдикке ылайыкташкан резерв coverage, 1/7/30 күндүк redemption ликвиддүүлүгү, операциялык supply чеги жана протокол ыйгарым укугу уруксат берген эң төмөн мааниден ашпашы керек.
Conservative Reserve Coverage
Таанылган lot \(j\)нин haircut колдонулган мааниси:
\[ \widetilde V_{j,t}= \operatorname{floor}\left(V_{j,t}(1-h_{j,t})\right) \]
түрүндө эсептелет.
Жалпы Conservative Reserve Coverage:
\[ CRC_t=\sum_j I_{j,t}\widetilde V_{j,t} \]
болот.
Бул жерде \(I_{j,t}=0\) болгон lotтун наркы канчалык жогору көрүнбөсүн, CRCге кирбейт.
1, 7 жана 30 күндүк ликвиддүүлүк
Ар бир \(H\in\{1,7,30\}\) горизонту үчүн тиешелүү мөөнөт ичинде колдонууга жеткиликтүү болгон жана башка таануу шарттарынан өткөн активдер гана maturity liquidityге кошулат.
Repo мүмкүнчүлүгү өзүнчө эсептелет; резервдин наркы катары саналбайт. Repo линиясы:
- fresh,
- активдүү,
- unimpaired,
- horizon тартиби шайкеш,
- активдүү банк/counterparty менен байланышкан
болбосо ликвиддүүлүккө кошулбайт.
Horizon шарты
Ар бир убакыт горизонту үчүн:
\[ q_H S_t^{post} \le L_t^{mat}(H)+\widetilde R_t(H) \]
шарты колдонулат.
\(q_H\) — ошол горизондо колдоого алынышы керек болгон stress-redemption үлүшү. Булактагы \(q_1\), \(q_7\) жана \(q_{30}\) маанилери governance жана тобокелдик параметрлери; модель тарабынан “туура” же “оптималдуу” катыштар катары табылган эмес.
Минималдуу милдеттүү чек
Колдоого мүмкүн болгон максималдуу mintтен кийинки 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\} \]
деп аныкталат.
NORMAL абалында жаңы mint мүмкүнчүлүгү:
\[ M_t=\max(K_t-S_t,0) \]
болсо, NORMALдан башка абалдарда:
\[ M_t=0 \]
болот.
Бул minimum операциясы дизайндын эң маанилүү жерлеринин бири. Мисалы, өтө жогору жалпы резерв бир күндүк жетишсиз накталай мүмкүнчүлүктү орточо эсеп менен жашыра албайт.
Номиналдуу Түрдө Ашыкча Резерв Барда Mint Мүмкүнчүлүгү Нөл Болушу Мүмкүнбү?
Ооба. Булактын нормалдаштырылган детерминисттик сценарийинде cash-bank outage болгондон кийин система тааныган non-cash резерв наркы 80 бойдон калса да, бир күндүк колдоо нөлгө түшөт; бир күндүк ликвиддүүлүк милдеттүү болуп калгандыктан mint cap нөлгө түшөт.
| Сценарий | CRC | 1 күндүк колдоо | 7 күндүк колдоо | 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 |
Бул мисалдар резерв көлөмүн гана эмес, резервдин колдонууга жеткиликтүүлүк абалын жана authority абалын да minting чегине кошкон архитектуранын жүрүмүн көрсөтөт.
Redemption Эмне Үчүн “Кулпула → Төлө → Текшер → Күйгүз” Иретин Карманат?
Анткени stablecoin милдеттенмеси блокчейнде турганда, каршыдагы fiat төлөм өзүнчө банк системасында аяктайт; токен төлөм ишке ашмайынча күйгүзүлсө holderдин талабы жок болуп кетиши мүмкүн, ал эми fiat төлөнүп, токен жүгүртүүдө кала берсе ошол эле милдеттенме эки жолу экономикалык нарк алып жүрүшү мүмкүн.
Булактын референстик агымы:
- Holder токен көлөмүн жана корголгон payout instruction commitmentын жөнөтөт.
- RedemptionRouter токендерди escrowго кулпулайт.
- Банк же payment process fiat төлөмдү жүргүзөт.
- Ыйгарым укуктуу төлөм оператору nonzero payment-proof commitment каттайт.
- Request PAID болот жана escrowдогу токен күйгүзүлөт.
Бул жерде payment-proof hash реалдуу банк төлөмүн блокчейн тарабынан first principles деңгээлинде далилдебейт. Hash ыйгарым укуктуу аудитор жетүүгө тийиш болгон корголгон банк каттоосуна integrity байланышын берет.
NORMAL, STRESS, RESOLUTION жана PAUSED Ортосундагы Айырма Эмне?
NORMAL — кадимки minting жана redemption абалы; STRESS жаңы supplyды токтотуп, жарактуу redemptionду улантат; RESOLUTION жаңы кадимки redemption талаптарын жаап, күтүп турган талаптарды жана корголгон резерв көзөмөлүн ыйгарым укуктуу чечүү процессине өткөрөт; PAUSED болсо олуттуу маалымат же control белгисиздигинде minting жана төлөм операцияларын убактылуу токтоткон circuit breaker абалы.
| Функция | NORMAL | STRESS | RESOLUTION | PAUSED |
|---|---|---|---|---|
| Жаңы mint | Ооба, чектердин ичинде | Жок | Жок | Жок |
| Жаңы кадимки redemption | Ооба | Ооба | Жок | Жок |
| Күтүүдө турган банк-тастыктаган redemption | Ооба | Ооба | Ооба | Жок |
| Protected-control release | Жок | Жок | Ооба | Ооба |
Булакта NORMALдан түз RESOLUTIONга өтпөө да дизайндык өзгөчөлүк. STRESS байкалуучу escalation boundary түзөт.
Oracle divergence эмне үчүн PAUSED жаратат?
Бир нече кабыл алынган valuation булагы белгиленген толеранттуулуктан ашык айырмаланса, система “эң ылайыктуу бааны тандоонун” ордуна жалпы маанини коргоого мүмкүн эмес деп чечип, PAUSED жолун иштетет.
Бул механизм oracle туура маалымат берет деп далилдебейт. Болгону кайсы маалымат шартында протокол операция жүргүзүүдөн баш тартарын ачык кылат.
Иштин Методу жана Табылгалары
Design-science ыкмасы
Иш классикалык байкоочу экономика же себептик таасир изилдөөсү эмес. Design-science ыкмасында адегенде институционалдык талаптар ажыратылган, андан кийин аларды чагылдырган executable artifact түзүлүп, artifactтын белгиленген жүрүмдөрү тесттелген.
Ар бир талап үч баскычта түзүлгөн:
- Institutional claim: финансылык, укуктук же операциялык функция.
- Source and boundary: бул функция таянган булак жана булак далилдебеген аймак.
- Executable consequence: маалымат, роль, precondition, postcondition жана fail-closed жүрүмү.
Тест катмарлары
Текшерүү сегиз бөлүктөн турган stack камтыйт:
- Pinned dependencyлер менен compilation.
- Сегиз end-to-end local-EVM тест.
- EVM жана Python fixture correspondence.
- Он сегиз Python тест.
- 100.000 жолдук негизги динамикалык эксперимент.
- 3×3 commonality/dealer-capacity sensitivity grid.
- Dealer-capacity reverse stress.
- SHA-256 manifestтери менен source/output из салуу.
Property-based transition testing, adversarial fuzzing, реалдуу gas profiling, көз карандысыз security audit, permissioned pilot жана jurisdiction-specific legal review аяктаган текшерүү топтомунан тышкары.
Сегиз EVM механизм тести
| Тест | Сыналган негизги invariant |
|---|---|
| Protected-lot horizon liquidity | 1/7/30 күндүк ликвиддүүлүктү өзүнчө жана консервативдүү эсептөө. |
| Reserve-first mint cap | Эң кичине CRC, RLR же supply чеги милдеттүү. |
| Access loss / stale value | Ийгиликсиз lot резервден чыгарылат. |
| Matured but unconfirmed | Мөөнөтү бүтүшү автоматтык түрдө накталай дегенди билдирбейт. |
| Repo haircut / inactive bank | Haircut колдонулат; inactive counterparty мүмкүнчүлүгү чыгарылат. |
| Oracle divergence | PAUSED circuit breaker иштетилет. |
| STRESS redemption | Minting токтойт; lock–payment–burn ирети иштей алат. |
| Duplicate lot / protected release | Duplicate commitment жана NORMAL абалында release четке кагылат. |
Бул тесттердин баары өткөн. Бирок example-based тесттердин өтүшү бардык мүмкүн болгон adversarial transitionдор коопсуз экенин далилдебейт.
Төрт бутактуу эксперимент эмне үчүн керек болду?
Булактын мурунку ATLAS ишинде жакшыраак маалымат менен жакшыраак maturity allocation бир учурда өзгөргөндүктөн, натыйжа кайсы механизмден чыкканын бөлүү мүмкүн болгон эмес. Ошондуктан Paper II бир эле shock tape үстүндө төрт ырааттуу бутак түзгөн.
| Бутак | Аныктама |
|---|---|
| A — Aggregate information | Current lot-state execution жок; maturity confirmation кечиккен; repo жеткиликтүүлүгү чектелүү; rollover пассивдүү. |
| B — Lot-observed, passive | Ошол эле портфель; актуалдуу lot байкоосу жана жакшыраак execution; rollover дагы эле пассивдүү. |
| C — Lot-observed + executable control | B менен бирдей портфель; толук repo execution жана RLR/run абалында maturity cash retention. |
| D — Controlled maturity ladder | Cнин маалымат жана көзөмөлдөрү; баштапкы maturity distribution гана өзгөртүлөт. |
D бутак үчүн equality audit
| Өзгөчөлүк | A/B/C | D |
|---|---|---|
| Жалпы резерв | 100 | 100 |
| Cash | 15 | 15 |
| Позициялардын саны | 4 | 4 |
| Weighted-average maturity | 37,05 күн | 37,05 күн |
| Linear yield proxy | 422,23 bp | 422,23 bp |
| Operating-cost proxy | 3,00 bp | 3,00 bp |
| 7 күндүк maturity liquidity | 30 | 40 |
| 30 күндүк maturity liquidity | 55 | 65 |
| Эң чоң позиция | 45 | 35 |
Демек D бутактын айырмасы “көбүрөөк резерв” же “кыскараак орточо maturity” эмес. Сценарий ичинде ошол эле ресурстарды башкача мөөнөт бөлүштүрүү менен жайгаштыруу.
Симуляция түзүлүшү
Негизги эксперимент:
- 100.000 көз карандысыз система жолу,
- 30 күн,
- 3 issuer,
- башында ар бир issuer үчүн 100 резерв жана 100 token supply,
- ошол эле path ичинде бардык бутактар үчүн жалпы redemption, банк, custody, repo, stress жана dealer-capacity drawлары
колдонот.
Market-wide stress система жолдорунун %12 бөлүгүндө конфигурацияланган. Бул жана башка stochastic distributionдар булакта ачык сценарий божомолдору деп айтылат; issuer же holder жүрүмү үчүн эмпирикалык баа эмес.
Негизги динамикалык натыйжалар
| Натыйжа | A | B | C | D |
|---|---|---|---|---|
| Орточо мажбурланган сатуу, % | 6,811 | 6,549 | 6,001 | 5,034 |
| P95 мажбурланган сатуу, % | 52,769 | 51,865 | 49,152 | 40,955 |
| P99 мажбурланган сатуу, % | 60,261 | 59,535 | 58,757 | 56,312 |
| Кандайдыр бир мажбурланган сатуу ыктымалдыгы, % | 57,633 | 39,735 | 34,866 | 28,146 |
| Орточо liquidation loss, bp | 11,473 | 9,766 | 8,588 | 6,268 |
| Орточо daily queue, % | 0,0500 | 0,0484 | 0,0424 | 0,0299 |
| Day-30 queue ыктымалдыгы, % | 0,611 | 0,611 | 0,606 | 0,610 |
D бутак бардык метрикада абсолюттук артык эмес. Мисалы, day-30 queue ыктымалдыгы Cден өтө аз гана жогору жана тиешелүү paired interval нөлдү камтыйт. Булактын тарыраак тыянагы — D сценарий шартында сатуу, жоготуу жана horizon ичиндеги queue burdenди азайтат.
Ырааттуу таасирлер
| Механизм | Мажбурланган сатуу азайышы | Жоготуу азайышы | Кандайдыр бир сатуу ыктымалдыгынын азайышы |
|---|---|---|---|
| Маалыматты колдонуу — B−A | 0,262 пайыздык пункт | 1,707 bp | 17,898 пайыздык пункт |
| Executable control — C−B | 0,548 пайыздык пункт | 1,178 bp | 4,869 пайыздык пункт |
| Maturity allocation — D−C | 0,967 пайыздык пункт | 2,320 bp | 6,720 пайыздык пункт |
Бул таасирлер модель колдонгон treatment аныктамаларына көз каранды. Мисалы, B−A таза “маалыматтын абстракттуу наркы” эмес; булакта маалыматты колдонуу менен кошо аныкталган тезирээк maturity confirmation, жогору executable repo үлүшү жана кеч сатуу премиясынын алынып салынышы сыяктуу операциялык айырмаларды камтыйт.
Сезимталдык жана reverse stress
Maturity-allocation жоготуу артыкчылыгы тесттелген 3×3 common-factor / dealer-capacity gridдин тогуз клеткасынын баарында оң бойдон калып, болжол менен 0,959–4,720 базистик пункт арасында өзгөргөн.
Dealer мүмкүнчүлүгү 15 болгондо пайда чоңураак, 40 болгондо кичирээк. Бул натыйжа реалдуу рынокто dealer capacity башка бардык факторлордон маанилүү экенин далилдебейт; болгону булактагы моделде allocation артыкчылыгы conversion bottleneckке сезимтал экенин көрсөтөт.
Reverse stressте тандалган “maximum queue > %5” критерийи эң көп %5 жолдо көрүлүшү үчүн минималдуу тесттелген stressed dealer capacity:
- A: 25,
- B: 25,
- C: 24,
- D: 22
болгон.
Бул сандар реалдуу Treasury рыногундагы мүмкүнчүлүк же жөнгө салуучу коопсуздук чектери эмес.
Бул Иш Blockchain Off-Chain Көзөмөлдөн Жогору Экенин Далилдейби?
Жок. Булактын ачык falsification критерийине ылайык, ошол эле reserve uniqueness, role separation, mint constraint, reconstruction жана incident accountability функциясы текшерилүүчү off-chain система менен төмөнүрөөк чыгым, купуялуулук тобокелдиги жана governance жүгү аркылуу камсыздалса, иш тиешелүү функцияны блокчейнде кармоо боюнча артыкчылык талабын койбойт.
Ишеним жоголбойт, орду өзгөрөт
Протокол келишим кабыл алган state үстүндө эреженин туура колдонулуп-колдонулбаганын текшере алат. Бирок төмөнкү тышкы билдирүүлөр институттарга көз каранды бойдон калат:
- Custodian чындап активди кармап турабы?
- Резерв үстүндө башка укук же lien барбы?
- Oracleдын upstream маалыматы туурабы?
- Trust/protection түзүмү укуктук жактан натыйжалуубу?
- Банк төлөмү чындап finalбы?
- Resolution актору чындап керектүү укуктук ыйгарым укукка ээби?
Ошондуктан “on-chain” болуу “trustless” болуу дегенди билдирбейт.
Купуялуулук чеги
Булак кардардын идентификациясы, банк эсептери, custody statementтар, төлөм көрсөтмөлөрү жана укуктук пикирлер сыяктуу маалыматтарды туруктуу public ledgerге жайгаштырбоону жактайт. Бөлүшүлгөн state эрежени текшерүү үчүн гана керектүү минималдуу маалыматты сакташы керек.
Hash колдонуу да өзү эле купуялуулук кепилдиги эмес. Timestamp, дарек, lot өзгөрүүсү, чоң резерв кыймылы же STRESS өтүүсү metadata аркылуу экономикалык маалыматты ачыкка чыгарышы мүмкүн.
Масштаб жана чыгым чеги
Учурдагы прототип реалдуу чоң портфелдер үчүн gas, throughput, storage growth, proof generation, recovery time же end-to-end latency benchmark отчет бербейт.
Келишимдердин EIP-170 bytecode чегинен төмөн болушу deployment мүмкүн экенин гана текшерет; production масштабдалуусу тууралуу жыйынтык эмес.
Production үчүн этаптуу ыкма
Булак төрт кең этапты сунуштайт:
- Phase I — Shadow ledger: Жандуу фонд же minting ыйгарым укугу жок кезде source маалыматты mirror кылуу жана reconciliation.
- Phase II — Controlled pilot: Чектелген asset, participant, supply жана duration менен параллелдүү legacy control.
- Phase III — Supervised production: Туруктуу reconciliation, audit, incident reporting жана scale limitтери менен көзөмөлдөнгөн live authority.
- Phase IV — Optional public-sector research: Core жана атаандаш жеке каналдар чече албаган туруктуу bottleneck көз карандысыз далил менен көрсөтүлсө гана өзүнчө изилдөө.
Бул ирет автоматтык deployment жол картасы эмес. Ар бир этапта legal, data, security, operations жана net-benefit шарттары аткарылбаса, илгерилөө токтошу керек.
Иш колдогон тыянак
Булак тарабынан колдоого алынган: резерв позицияларынын settlement, eligibility, encumbrance, protection, жеткиликтүүлүк, актуалдуу valuation, maturity жана provider абалдары ачык state шарттарына айландырылышы мүмкүн; бул state жаңы stablecoin милдеттенмесин түзүү ыйгарым укугун жана redemption жүрүмүн детерминисттик түрдө чектей алат.
Мындан тышкары, булак сценарийинде lot маалыматы, executable control жана тең салмактуу maturity allocationдын ар бири кошулган сайын орточо мажбурланган сатуу жана liquidation loss азайган.
Иш колдобогон тыянак
Булак далилдебеген: Core PTRL production-secure экени, реалдуу stablecoin чыгаруучуларында ошол эле жоготуу азайышын берери, укуктук protection же bankruptcy priority түзөрү, реалдуу dealer capacityни туура моделдей турганы, сунушталган RLR катыштары оптималдуу экени же блокчейн ар бир учурда эң мыкты implementation технологиясы экени көрсөтүлгөн эмес.
Иш ошондой эле stablecoin баасын, holder welfare, Treasury borrowing cost, monetary transmission же толук рынок equilibriumун божомолдобойт.
Булак жана Метод Эскертүүсү
Оригиналдуу эмгек: From Reserve Disclosure to Executable Control: A Blockchain-Native Reference Architecture for Treasury-Backed Stablecoins.
Автор: Seungwoo Lee.
Аффилиация: Independent Researcher.
ORCID: 0009-0001-7041-8467.
Булак: SSRN working paper / Project ATLAS Paper II.
SSRN Abstract ID: 7282663.
DOI: 10.2139/ssrn.7282663.
Date Written: 14-август 2026.
SSRNге жөнөтүлгөн дата: 18-август 2026.
Көлөмү: 62 бет.
Лицензия: Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International — CC BY-NC-ND 4.0.
Рецензия абалы: SSRN working paper; рецензияланган журнал версиясы көрсөтүлгөн эмес.
Изилдөөнүн түрү: Design-science, executable reference architecture жана scenario-based mechanism validation.
Ишке ашыруу: Он Solidity келишими; EVM референстик архитектурасы.
Текшерүү: Сегиз end-to-end local-EVM тест, integer-exact Python mirror жана жалпысынан он сегиз Python тест.
Негизги симуляция: 100.000 жол × 30 күн × 3 issuer; жалпы shock tape үстүндө төрт эксперимент бутак.
Негизги чыгыштар: forced-sale volume, liquidation loss, forced-sale ыктымалдыгы, queue өлчөмдөрү, repo колдонуу жана redemption.
Негизги интерпретация чеги: Симуляция коэффициенттери эмпирикалык бааланган реалдуу issuer же Treasury-market параметрлери эмес. Monte Carlo интервалдары берилген сценарийдеги finite-run simulation errorду гана өлчөйт.
Production-security чеги: Property-based testing, кеңири fuzzing, көз карандысыз security audit, реалдуу gas/throughput benchmarkтар жана жандуу permissioned pilot аяктаган эмес.
Укуктук чеги: Код менчик, bankruptcy remoteness, төлөм finalityси же resolution ыйгарым укугун жаратпайт. Булар реалдуу документтерге, институттарга жана колдонулуучу мыйзамга көз каранды.
Legal source cutoff: 14-август 2026.
Каржылоо: Тышкы каржылоо алынган эмес.
Кызыкчылыктардын кагылышы: Автор тиешелүү кызыкчылыктардын кагылышын билдирбейт.
Data жана code: Versioned source code, contract fixtureлар жана ачык scenario outputs колдонулган; confidential issuer, кардар, банк, custodian же payment маалыматы колдонулган эмес.
Generative AI колдонуу: Код иштеп чыгуу, debugging, drafting жана editorial review процесстеринде generative AI колдоосу колдонулган. Изилдөө суроолорун жана архитектураны тандоо, божомолдорду кароо, executable outputs текшерүү жана акыркы жоопкерчилик авторго таандык.
Финансылык интерпретация чеги: Иш stablecoin, Казыналык вексель же башка финансылык продукт боюнча инвестициялык кеңеш бербейт.

Пикир калтырыңыз
E-mail дарегиңиз жарыяланбайт. Милдеттүү талаалар * менен белгиленген