Bir stablecoin ihraççısının bilançosunda yeterli miktarda Hazine bonosu, nakit veya başka uygun rezerv bulunması, bu varlıkların o anda yeni stablecoin arzını güvenli biçimde destekleyebileceği anlamına gelmez. Rezerv varlığı henüz settle edilmemiş olabilir, teminat altına verilmiş olabilir, doğru tüzel kişinin kontrolünde olmayabilir, custodian veya banka erişilemez durumda olabilir, fiyat verisi eskimiş olabilir ya da varlığın nakde dönüşmesi redemption talebinin karşılanması gereken süreden daha uzun sürebilir.

Seungwoo Lee'nin Project ATLAS Paper II çalışması bu farkı rezerv açıklamasından işlem-anı kontrolüne taşımaktadır. Çalışmada geliştirilen Core Programmable Treasury Reserve Layer (PTRL), rezervlerin yalnız toplam miktarını kaydetmek yerine her rezerv pozisyonunun settlement, encumbrance, erişim, hukuki koruma, değerleme güncelliği, sağlayıcı durumu ve vadeye göre kullanılabilirliğini ayrı ayrı değerlendirir. Yeni stablecoin yükümlülüğü ancak bütün bağlayıcı koşullar izin verdiği ölçüde oluşturulabilir.

Kaynağın önerdiği yapı bir stablecoin, CBDC veya tokenlaştırılmış Hazine bonosu değildir. Treasury Reserve Certificate (TRC), varlığın kendisini temsil eden alınıp satılabilir bir token değil; mevcut bir rezerv pozisyonuna ilişkin kanıt ve durum bilgisini bağlayan transfer edilemez bir kayıt nesnesidir. Mimari, rezerv kanıtlarını akıllı sözleşme koşullarına bağlarken mülkiyet, iflas önceliği, ödeme finalitesi ve hukuki yetki gibi konuların gerçek kurumlar ve yürürlükteki hukuk tarafından belirlenmeye devam ettiğini özellikle kabul eder.

On Solidity sözleşmesinden oluşan prototip sekiz uçtan uca EVM testinden geçmiştir. 100.000 otuz günlük simülasyon yolunu içeren dört kollu deneyde ise aggregate bilgi, güncel lot gözlemi, executable control ve daha dengeli maturity ladder sırasıyla karşılaştırılmıştır. Modelin kendi senaryo varsayımlarında bilgi, kontrol ve vade dağılımının her eklenişi ortalama zorunlu satışları ve likidasyon kayıplarını azaltmıştır. Ancak bu değerler gerçek stablecoin ihraççılarının beklenen sonuçları değil, mekanizma doğrulama senaryolarıdır.

Bir Stablecoin Rezervi Neden Yalnızca “1:1 Destekli” Olmakla Yetinmez?

Çünkü nominal rezerv miktarı, varlığın belirli bir anda gerçekten kullanılabilir olup olmadığını göstermez. Çalışmanın mimarisinde bir rezervin stablecoin arzını destekleyebilmesi için var olması yanında settle edilmiş, uygun, teminatsız, erişilebilir, korunan, aktif bir kurum üzerinden tutuluyor ve güncel değerleme verisiyle destekleniyor olması gerekir; kısa vadeli redemption için ayrıca ilgili zaman ufkunda nakde dönüşebilmelidir.

Bu ayrım muhasebe değeri ile operasyonel kapasite arasındaki farktır. Bir Hazine bonosu ekonomik olarak değerli olabilir fakat:

• settlement tamamlanmadıysa,
• başka bir yükümlülük için pledge edilmişse,
• custodian erişilemiyorsa,
• değerleme verisi stale ise,
• koruma veya beneficiary kaydı geçerli değilse,
• vadesi redemption ihtiyacından sonra geliyorsa

o anda aynı miktarda stablecoin yükümlülüğünü destekleyen kullanılabilir kapasite olarak kabul edilmeyebilir.

Kaynağın temel ilkesi: reserve backing bir durumdur

Makalenin merkezî önerisi rezerv backing'in statik bir stok değil, state-dependent permission olarak düşünülmesidir. Bir varlığın rezerv portföyünde görünmesi minting yetkisini otomatik olarak yaratmaz.

Her lot için tanıma koşullarının mantığı şu biçimde ifade edilir:

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

Burada \(I_\ell\) gerekli koşullardan her birini temsil eden ikili göstergedir. Koşulların tamamı 1 ise lot tanınır. Tek bir koşul sıfırsa bütün çarpım sıfır olur.

Bu nedenle sistem “bazı koşullar iyi olduğu için ortalama olarak kabul et” mantığını kullanmaz. Yüksek kaliteli bir Hazine bonosu erişilemeyen custodian nedeniyle dışlanabilir; başka bir lotta fazla rezerv bulunması bu özel erişim problemini ortadan kaldırmaz.

Treasury Reserve Certificate (TRC) Nedir?

Treasury Reserve Certificate, mevcut bir rezerv pozisyonunun kimliğini, durumunu ve ilgili kanıt bağlantılarını tutan transfer edilemez bir state object'tir; Hazine bonosunun tokenlaştırılmış biçimi değildir, stablecoin sahibine belirli bir rezerv lotunda doğrudan mülkiyet hakkı vermez ve ERC-20 veya ERC-721 gibi alınıp satılabilir bir token olarak tasarlanmamıştır.

Her TRC beş ana bilgi grubuna bağlanır:

Aynı rezervin iki kez sayılması nasıl engelleniyor?

Prototipte bir positionCommitment yalnız bir TRC oluşturmak için kullanılabilir. Aynı commitment ile ikinci lot kaydedilirse işlem reddedilir.

Bu mekanizma yalnız protokol içindeki aynı commitment'ın tekrarını önler. Gerçek dünyadaki aynı ekonomik varlık iki farklı upstream kimlikle kaydedilmişse sözleşme bunun aynı varlık olduğunu kendiliğinden bilemez. Kaynak bu nedenle gerçek production sisteminde canonical asset identity ve kurumlar arası reconciliation gerektiğini açıkça belirtmektedir.

Vadesi dolan bono neden otomatik olarak nakit sayılmıyor?

Kontratsal maturity ile fiilî cash settlement aynı olay değildir. Kaynakta vadesi geçmiş bir non-cash lot, karşılık gelen nakit dönüşümü ayrıca doğrulanana kadar rezerv motoru tarafından nakit gibi kullanılmaz.

Bu ayrım özellikle redemption sistemlerinde önemlidir: “bugün vadesi doldu” ifadesi ile “bugün ödeme hesabında kullanılabilir nakit oluştu” ifadesi operasyonel olarak farklıdır.

Core PTRL Mimarisi Nasıl Çalışıyor?

Core PTRL beş mantıksal katmanda kurumsal kanıtı, risk hesabını, stablecoin yükümlülüğünü ve protokol yetkisini birbirine bağlar: kurumsal katman gerçek kurumları; evidence katmanı doğrulanabilir durum kayıtlarını; risk/control katmanı CRC ve likiditeyi; liability/settlement katmanı minting ve redemption'ı; authority/assurance katmanı ise NORMAL, STRESS, RESOLUTION ve PAUSED yetkilerini yönetir.

1. Kurumsal katman

Issuer, banka, custodian, trustee, oracle reporter, auditor, supervisor, dealer ve resolution authority gibi gerçek kurumlar burada yer alır. Blokzincir bu kurumları yaratmaz; yalnız kabul edilen kimlik ve yetki durumlarını paylaşılan kontrol alanına yansıtır.

2. Evidence katmanı

Rezerv lotları, protection kayıtları, valuation gözlemleri ve repo hatları typed commitment ve gözlemlere dönüştürülür.

3. Risk ve control katmanı

ReserveRiskEngine hangi lotların sayılacağını belirler; Conservative Reserve Coverage ve 1/7/30 günlük likiditeyi hesaplar. IssuerController daha sonra bütün limitlerin minimumunu alarak mint headroom'u belirler.

4. Liability ve settlement katmanı

AtlasSettlementToken yalnız prototipte stablecoin-benzeri yükümlülük tarafını test etmek için kullanılır. RedemptionRouter token'ı escrow'a alır, banka ödemesinin doğrulanmasını bekler ve ancak bundan sonra burn işlemini gerçekleştirir.

5. Authority ve assurance katmanı

AtlasStateController hangi protokol durumunda hangi işlemlerin mümkün olduğunu sınırlar. Auditor ve supervisor gibi roller ise olay geçmişinin ve source record'ların dış denetim ve doğrulamasında rol oynar.

On modülün görev ayrımı

Reserve-First Minting Nedir?

Reserve-first minting, önce stablecoin üretip daha sonra buna rezerv eşleştirmek yerine kullanılabilir rezerv kapasitesinin işlemden önce mevcut olmasını şart koşan tasarımdır; mint sonrası supply, risk ayarlı rezerv kapsamının, 1/7/30 günlük redemption likiditesinin, operasyonel arz tavanının ve protokol yetkisinin izin verdiği en düşük değeri aşamaz.

Conservative Reserve Coverage

Tanınmış lot \(j\)'nin haircut uygulanmış değeri:

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

olarak hesaplanır.

Toplam Conservative Reserve Coverage:

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

şeklindedir.

Burada \(I_{j,t}=0\) olan lot değeri ne kadar yüksek görünürse görünsün CRC'ye katılmaz.

1, 7 ve 30 günlük likidite

Her \(H\in\{1,7,30\}\) ufku için yalnız ilgili süre içinde kullanılabilir hale gelen ve diğer tanıma koşullarını geçen varlıklar maturity liquidity'ye eklenir.

Repo kapasitesi ayrıca hesaplanır; rezerv değeri sayılmaz. Repo hattı:

• fresh,
• aktif,
• unimpaired,
• horizon sırası tutarlı,
• aktif bir banka/counterparty ile bağlantılı

olmadığında likiditeye katılmaz.

Horizon koşulu

Her zaman ufku için:

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

koşulu uygulanır.

\(q_H\), o zaman ufkunda desteklenmesi istenen stress-redemption payıdır. Kaynakta kullanılan \(q_1\), \(q_7\) ve \(q_{30}\) değerleri yönetişim ve risk parametreleridir; model tarafından “doğru” veya “optimal” oranlar olarak keşfedilmiş değildir.

Minimum bağlayıcı limit

Desteklenebilir 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\} \]

olarak tanımlanır.

NORMAL durumunda yeni mint kapasitesi:

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

iken NORMAL dışındaki durumlarda:

\[ M_t=0 \]

olur.

Bu minimum işlemi tasarımın en önemli noktalarından biridir. Örneğin çok yüksek toplam rezerv, yetersiz bir günlük nakit kapasitesini ortalama yoluyla gizleyemez.

Nominal Olarak Fazla Rezerv Varken Mint Kapasitesi Sıfır Olabilir mi?

Evet. Kaynağın normalize deterministik senaryosunda cash-bank outage sonrasında sistemin tanıdığı non-cash rezerv değeri 80 olarak kalmasına rağmen bir günlük destek sıfıra iner; bir günlük likidite bağlayıcı hale geldiği için mint cap sıfıra düşer.

Bu örnekler yalnız rezerv miktarını değil, rezervin kullanılabilirlik durumunu ve otorite durumunu da minting sınırına dâhil eden mimarinin davranışını göstermektedir.

Redemption Neden “Kilitle → Öde → Doğrula → Yak” Sırasını İzliyor?

Çünkü stablecoin yükümlülüğü blokzincirde bulunurken karşılığındaki fiat ödeme ayrı bir banka sisteminde tamamlanır; token ödeme gerçekleşmeden yakılırsa holder'ın talebi ortadan kalkabilir, fiat ödeme yapılıp token dolaşımda bırakılırsa ise aynı yükümlülük iki kez ekonomik değer taşıyabilir.

Kaynağın referans akışı:

1. Holder token miktarını ve korunan payout instruction commitment'ını gönderir.
2. RedemptionRouter token'ları escrow'a kilitler.
3. Banka veya payment process fiat ödemeyi gerçekleştirir.
4. Yetkili ödeme operatörü nonzero payment-proof commitment kaydeder.
5. Request PAID olur ve escrow'daki token yakılır.

Burada payment-proof hash gerçek banka ödemesini blokzincir tarafından ilk ilkelerden kanıtlamaz. Hash, yetkili denetçinin erişebilmesi gereken korunan banka kaydına integrity bağlantısı sağlar.

NORMAL, STRESS, RESOLUTION ve PAUSED Arasındaki Fark Nedir?

NORMAL olağan minting ve redemption durumudur; STRESS yeni arzı durdururken geçerli redemption'ı sürdürür; RESOLUTION yeni olağan redemption taleplerini kapatarak bekleyen talepler ve korunan rezerv kontrolünü yetkili çözüm sürecine taşır; PAUSED ise ciddi veri veya kontrol belirsizliğinde minting ve ödeme işlemlerini geçici olarak durduran circuit breaker durumudur.

Kaynakta NORMAL'dan doğrudan RESOLUTION'a atlanmaması da tasarımsal bir özelliktir. STRESS gözlenebilir bir escalation boundary oluşturur.

Oracle divergence neden PAUSED yaratıyor?

Birden fazla kabul edilen valuation kaynağı yapılandırılmış toleransın üzerinde ayrışırsa sistem “en uygun fiyatı seçmek” yerine ortak değerin savunulabilir olmadığı sonucuna varır ve PAUSED yolunu çalıştırır.

Bu mekanizma oracle'ın doğruyu bildiğini kanıtlamaz. Yalnız hangi veri koşulunda protokolün işlem yapmayı reddedeceğini açık hale getirir.

Çalışmanın Yöntemi ve Bulguları

Design-science yöntemi

Çalışma klasik gözlemsel ekonomi veya nedensel etki araştırması değildir. Design-science yaklaşımında önce kurumsal gereklilikler ayrıştırılmış, daha sonra bunları temsil eden executable artifact oluşturulmuş ve artifact'ın belirlenmiş davranışları test edilmiştir.

Her gereklilik üç aşamada kurulmuştur:

1. Institutional claim: finansal, hukuki veya operasyonel fonksiyon.
2. Source and boundary: bu fonksiyonun dayandığı kaynak ve kaynağın kanıtlamadığı alan.
3. Executable consequence: veri, rol, precondition, postcondition ve fail-closed davranış.

Test katmanları

Doğrulama sekiz parçalı bir stack içerir:

1. Pinned dependency'lerle compilation.
2. Sekiz uçtan uca local-EVM testi.
3. EVM ile Python fixture correspondence.
4. On sekiz Python testi.
5. 100.000 yollu ana dinamik deney.
6. 3×3 commonality/dealer-capacity sensitivity grid.
7. Dealer-capacity reverse stress.
8. SHA-256 manifestleriyle source/output izlenebilirliği.

Property-based transition testing, adversarial fuzzing, gerçek gas profillemesi, bağımsız güvenlik auditi, permissioned pilot ve jurisdiction-specific legal review tamamlanmış doğrulama setinin dışında kalmaktadır.

Sekiz EVM mekanizma testi

Bu testlerin tamamı geçmiştir. Fakat example-based testlerin geçmesi bütün olası adversarial transition'ların güvenli olduğunu kanıtlamaz.

Dört kollu deney neden gerekliydi?

Kaynağın önceki ATLAS çalışmasında daha iyi bilgi ile daha iyi maturity allocation aynı anda değiştiği için sonucun hangi mekanizmadan kaynaklandığı ayrıştırılamıyordu. Paper II bu nedenle aynı shock tape üzerinde dört ardışık kol oluşturmuştur.

D kolu için equality audit

Dolayısıyla D kolunun farkı “daha fazla rezerv” veya “daha kısa ortalama maturity” değildir. Senaryo içinde aynı kaynakların daha farklı vade dağılımıyla yerleştirilmesidir.

Simülasyon yapısı

Ana deney:

• 100.000 bağımsız sistem yolu,
• 30 gün,
• 3 issuer,
• başlangıçta issuer başına 100 rezerv ve 100 token supply,
• aynı path içinde bütün kollar için ortak redemption, banka, custody, repo, stress ve dealer-capacity draw'ları

kullanmaktadır.

Market-wide stress sistem yollarının %12'sinde yapılandırılmıştır. Bunun ve diğer stochastic distribution'ların kaynakta açıkça senaryo varsayımları olduğu belirtilmektedir; issuer veya holder davranışı için ampirik tahmin değildir.

Ana dinamik sonuçlar

D kolu her metrikte mutlak biçimde üstün değildir. Örneğin day-30 queue olasılığı C'den çok küçük miktarda yüksektir ve ilgili paired interval sıfırı içermektedir. Kaynağın daha dar sonucu D'nin satış, kayıp ve horizon içindeki queue burden'ı senaryo altında düşürmesidir.

Sıralı etkiler

Bu etkiler model tarafından kullanılan treatment tanımlarına bağlıdır. Örneğin B−A saf “bilginin soyut değeri” değildir; daha hızlı maturity confirmation, daha yüksek executable repo payı ve geç satış priminin kaldırılması gibi kaynakta bilgi uygulamasıyla birlikte tanımlanmış operasyonel farkları içerir.

Duyarlılık ve reverse stress

Maturity-allocation kayıp avantajı test edilen 3×3 common-factor / dealer-capacity grid'in dokuz hücresinde de pozitif kalmış ve yaklaşık 0,959–4,720 baz puan arasında değişmiştir.

Dealer kapasitesi 15 olduğunda fayda daha büyük, 40 olduğunda daha küçüktür. Bu sonuç gerçek piyasada dealer capacity'nin diğer bütün faktörlerden daha önemli olduğunu kanıtlamaz; yalnız kaynakta kullanılan modelde allocation avantajının conversion bottleneck'e duyarlı olduğunu gösterir.

Reverse stress'te seçilen “maximum queue > %5” kriterinin en fazla %5 yolda görülmesi için minimum test edilen stressed dealer capacity:

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

olmuştur.

Bu sayılar gerçek Treasury piyasasındaki kapasite veya düzenleyici güvenlik eşikleri değildir.

Bu Çalışma Blockchain'in Off-Chain Kontrolden Üstün Olduğunu Kanıtlıyor mu?

Hayır. Kaynağın açık falsification kriterine göre, aynı reserve uniqueness, role separation, mint constraint, reconstruction ve incident accountability işlevi doğrulanabilir bir off-chain sistemle daha düşük maliyet, gizlilik riski ve yönetişim yüküyle sağlanabiliyorsa ilgili fonksiyonun blokzincirde tutulması için çalışma bir üstünlük iddiası üretmez.

Güven ortadan kalkmıyor, yer değiştiriyor

Protokol kontratın kabul ettiği state üzerinde kuralın doğru uygulanıp uygulanmadığını sınayabilir. Ancak şu dış önermeler kurumlara bağlı kalır:

• Custodian gerçekten varlığı tutuyor mu?
• Rezerv üzerinde başka hak veya lien var mı?
• Oracle'ın upstream verisi doğru mu?
• Trust/protection yapısı hukuken etkili mi?
• Banka ödemesi gerçekten final mi?
• Resolution aktörü gerçekten gerekli hukuki yetkiye sahip mi?

Bu nedenle “on-chain” olmak “trustless” olmak anlamına gelmez.

Gizlilik sınırı

Kaynak müşteri kimliği, banka hesapları, custody statement'ları, ödeme talimatları ve hukuk görüşleri gibi verilerin kalıcı public ledger'a konulmamasını savunur. Paylaşılan state yalnız kuralın doğrulanması için gereken minimum bilgiyi tutmalıdır.

Hash kullanımı da tek başına gizlilik garantisi değildir. Timestamp, adres, lot değişimi, büyük rezerv hareketi veya STRESS geçişi metadata üzerinden ekonomik bilgi sızdırabilir.

Ölçek ve maliyet sınırı

Mevcut prototip gerçek büyük portföylerde gas, throughput, storage growth, proof generation, recovery time veya uçtan uca latency benchmark'ı raporlamamaktadır.

Sözleşmelerin EIP-170 bytecode sınırının altında olması yalnız deployment yapılabilirliğinin bir kontrolüdür; production ölçeklenebilirliği sonucu değildir.

Üretim için aşamalı yaklaşım

Kaynak dört geniş aşama önerir:

1. Phase I — Shadow ledger: Canlı fon veya minting yetkisi olmadan kaynak verinin mirror edilmesi ve reconciliation.
2. Phase II — Controlled pilot: Sınırlı asset, participant, supply ve duration ile paralel legacy control.
3. Phase III — Supervised production: Sürekli reconciliation, audit, incident reporting ve scale limitleriyle kontrollü live authority.
4. Phase IV — Optional public-sector research: Yalnız Core ve rekabetçi özel kanalların çözemediği kalıcı bir bottleneck bağımsız kanıtla gösterilirse ayrı araştırma.

Bu sıra otomatik bir deployment yol haritası değildir. Her aşamada legal, data, security, operations ve net-benefit koşulları sağlanmazsa ilerleme durmalıdır.

Çalışmanın desteklediği sonuç

Kaynakla desteklenen: rezerv pozisyonlarının settlement, eligibility, encumbrance, protection, erişim, güncel değerleme, maturity ve provider durumları açık state koşullarına dönüştürülebilir; bu state, yeni stablecoin yükümlülüğü oluşturma yetkisini ve redemption davranışını deterministik biçimde sınırlandırabilir.

Ayrıca kaynak senaryosunda lot bilgisi, executable control ve daha dengeli maturity allocation'ın her birinin eklenmesi ortalama zorunlu satış ve liquidation loss'u azaltmıştır.

Çalışmanın desteklemediği sonuç

Kaynağın kanıtlamadığı: Core PTRL'nin production-secure olduğu, gerçek stablecoin ihraççılarında aynı kayıp azaltımını üreteceği, hukuki koruma veya bankruptcy priority yarattığı, gerçek dealer kapasitesini doğru modellediği, önerilen RLR oranlarının optimal olduğu veya blokzincirin her durumda en iyi implementation teknolojisi olduğu gösterilmemiştir.

Çalışma ayrıca stablecoin fiyatı, holder welfare, Treasury borrowing cost, monetary transmission veya tam piyasa equilibrium'u tahmin etmemektedir.

Kaynak ve Yöntem Notu

Özgün çalışma: From Reserve Disclosure to Executable Control: A Blockchain-Native Reference Architecture for Treasury-Backed Stablecoins.

Yazar: Seungwoo Lee.

Afiliyasyon: Independent Researcher.

ORCID: 0009-0001-7041-8467.

Kaynak: SSRN working paper / Project ATLAS Paper II.

SSRN Abstract ID: 7282663.

DOI: 10.2139/ssrn.7282663.

Date Written: 14 Ağustos 2026.

SSRN gönderim tarihi: 18 Ağustos 2026.

Uzunluk: 62 sayfa.

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

Hakemlik durumu: SSRN working paper; hakemli dergi sürümü belirtilmemektedir.

Araştırma türü: Design-science, executable reference architecture ve scenario-based mechanism validation.

Uygulama: On Solidity sözleşmesi; EVM referans mimarisi.

Doğrulama: Sekiz uçtan uca local-EVM testi, integer-exact Python mirror ve toplam on sekiz Python testi.

Ana simülasyon: 100.000 yol × 30 gün × 3 issuer; ortak shock tape üzerinde dört deney kolu.

Temel ana çıktılar: forced-sale volume, liquidation loss, forced-sale olasılığı, queue ölçüleri, repo kullanımı ve redemption.

Ana yorum sınırı: Simülasyon katsayıları ampirik olarak tahmin edilmiş gerçek issuer veya Treasury-market parametreleri değildir. Monte Carlo aralıkları yalnız verilen senaryo altındaki finite-run simulation error'u ölçer.

Production-security sınırı: Property-based testing, kapsamlı fuzzing, bağımsız security audit, gerçek gas/throughput benchmark'ları ve canlı permissioned pilot tamamlanmamıştır.

Hukuki sınır: Kod mülkiyet, bankruptcy remoteness, ödeme finalitesi veya resolution yetkisini yaratmaz. Bunlar gerçek belgeler, kurumlar ve uygulanabilir hukuka bağlıdır.

Legal source cutoff: 14 Ağustos 2026.

Finansman: Dış finansman alınmamıştır.

Çıkar çatışması: Yazar ilgili çıkar çatışması bildirmemektedir.

Data ve code: Versioned source code, contract fixture'ları ve şeffaf scenario outputs kullanılmış; confidential issuer, müşteri, banka, custodian veya payment verisi kullanılmamıştır.

Generative AI kullanımı: Kod geliştirme, debugging, drafting ve editorial review süreçlerinde generative AI desteği kullanılmıştır. Araştırma sorularının ve mimarinin seçimi, varsayımların incelenmesi, executable outputs'un doğrulanması ve nihai sorumluluk yazara aittir.

Finansal yorum sınırı: Çalışma stablecoin, Hazine bonosu veya başka bir finansal ürün için yatırım tavsiyesi üretmemektedir.