XRP Ledger'da borç verme standardı inceleniyor, ana ağ etkinleştirmesi henüz yok

Ripple, XRP Ledger'ın (XRP Ledger, XRPL) tek varlıklı kasa (XLS-65) ve borç verme protokolü (XLS-66) özelliklerini kurumsal zincir üstü kredi altyapısının temel bileşenleri olarak sundu. Her iki değişiklik önerisi de ilgili yazılıma dahil edildi, ancak ana ağda etkinleştirilmeleri için gereken inceleme ve oylama süreci henüz tamamlanmadı.

Ripple, 29 Haziran'da yayımladığı yazıda kurumların borçlu değerlendirmesini ve düzenleyici uyumluluğu zincir dışında yaptığını, protokolün ise kredi kullandırma, geri ödeme ve koşulların uygulanmasını standartlaştırdığını belirtti. Yani kredi değerlendirmesi zincir dışında, işlem süreci ise zincir üzerinde gerçekleştiriliyor.

Tek varlıklı kasa, kredi fonlarının toplandığı temel işlevi görüyor. XRP Ledger'ın resmi belgelerine göre kasa; XRP, trust line token'ları veya çok amaçlı token (MPT) türlerinden yalnızca birini toplayarak diğer zincir üstü protokollere aktarıyor.

MPT, XRP Ledger üzerinde tokenleştirilmiş varlıkları temsil eden bir özellik. Bir kasada yalnızca tek bir varlık türü bulunabiliyor; borç verme protokolü ise bu şekilde toplanan fonları sabit vadeli teminatsız kredilerde kullanıyor.

Kredi oluşturulabilmesi için hem kredi aracısının hem de borçlunun imzası gerekiyor. Kredi aracısı, kredi ve düzenleyici uyumluluk değerlendirmesini zincir dışında yaptıktan sonra, üzerinde anlaşılan koşulları zincir üstü işlem olarak uyguluyor.

Bu yapı, otomatik tasfiye mekanizması üzerine kurulu mevcut DeFi kredi sistemlerinden farklılaşıyor. XRP Ledger belgeleri, mevcut uygulamada otomatikleştirilmiş zincir üstü teminat yönetimi veya tasfiye yönetimi bulunmadığını açıkça belirtiyor. Dolayısıyla XLS-66, klasik teminatlı kredi ya da otomatik tasfiyeli para piyasası olarak değerlendirilemez.

TokenPost daha önce XLS-66'nın teminatsız kredi yapısını ve zincir dışı kredi değerlendirme yöntemini haberleştirmişti. O dönemde de standart önerisinin inceleme ve kod testi aşamasında olduğu, ancak ana ağda henüz kullanılabilir bir özellik olmadığı temel sorun olarak öne çıkmıştı.

XRP Ledger'ın resmi 'Known Amendments' belgesinde tek varlıklı kasa ve borç verme protokolü ayrı ayrı 'Loading' (yükleniyor) durumunda gösteriliyor ve varsayılan oy 'No' (hayır) olarak belirtiliyor. İki standart belgesi de henüz taslak aşamasını ifade eden 'Draft' olarak sınıflandırılıyor.

XRP Ledger'da bir değişiklik önerisinin etkinleşebilmesi için doğrulayıcı desteğinin yüzde 80'i aşması ve bu oranın 2 hafta boyunca korunması gerekiyor. Kodun yazılıma dahil edilmiş olması ile özelliğin ağda fiilen etkinleştirilmiş olması birbirinden farklı anlamlar taşıyor.

28 Ocak'ta yayımlanan XRP Ledger 3.1.0 sürümüne tek varlıklı kasa ve borç verme protokolünü destekleyen kod dahil edildi. 15 Haziran'da çıkan xrpld 3.2.0'da da bu iki özelliğe ilişkin düzeltme ve bakım çalışmaları yer aldı.

TokenPost, xrpld 3.2.0'da tek varlıklı kasa ve borç verme protokolündeki doğruluk ve yuvarlama hatalarının düzeltildiğini aktarmıştı. Fonların toplanıp krediye dönüştürüldüğü bu yapıda, kasa muhasebesi ve geri ödeme işlemlerinin hassasiyeti fiili işleyişin ön koşulu haline geliyor.

Güvenlik şirketi Halborn, 21 Temmuz - 5 Ağustos 2025 tarihleri arasında borç verme protokolünü denetleyerek 13 sorun tespit etti. Ciddiyet derecesine göre dağılım şöyleydi: △kritik 4 △yüksek 1 △orta 4 △düşük 4. Halborn, bildirilen tüm sorunların giderildiğini açıkladı.

Ancak denetim sonuçları, ilgili dönemde incelenen koda dayanıyor. Standardın kesinleşmesi ve ağda etkinleştirilmesi sürecinde kodda değişiklik yapılırsa, güncellenen uygulama için ek doğrulama da önem kazanacak.

Toplulukta hem beklenti hem de endişeler bir arada dile getiriliyor. XRPL Commons, 6 Mart'ta XLS-65'e olumlu oy verdiğini açıklayarak tek varlıklı kasayı, fon ortak yönetimi için gerekli protokol düzeyinde bir temel işlev olarak değerlendirdi.

Buna karşın XRPL-Standards GitHub tartışmalarında ABD menkul kıymetler mevzuatına uyum ihtimali, zincir dışı değerlendirme sorumluluğu ile dağıtık kimlik doğrulama (DID) ve müşteri tanıma (KYC) tasarımına ilişkin endişeler dile getirildi. İki değişiklik önerisinin ana ağda etkinleşebilmesi için doğrulayıcı desteğinin yüzde 80'i 2 hafta boyunca aşması gerekiyor.