Ripple(XRP) ağında dev adım: Token Escrow(XLS-85) ile XRPL’deki tüm tokenlar için on-chain kilitleme dönemi başladı

Ripple(XRP) ekosisteminin kalbi olan XRP Ledger(XRPL), uzun süredir sadece yerel varlık Ripple(XRP) için sunulan ‘escrow(emanet kilitleme)’ özelliğini artık ağ üzerindeki tüm tokenlara açtı. ‘Token Escrow(XLS-85)’ adı verilen bu güncelleme ile, XRPL üzerindeki *tüm* ‘IOU’ tipi güven hattı (trustline) tokenları ve çok amaçlı tokenlar(Multi-Purpose Token, MPT) için de koşullu ve süreli kilitleme gibi gelişmiş ‘on-chain’ ödeme ve mutabakat modelleri kullanılabilir hale geldi.

Token Escrow(XLS-85), 12 Şubat’ta (yerel saatle) ana ağda tamamen aktif edildi. Değişiklik, 34 doğrulayıcıdan 30’unun (yaklaşık ‘%88’ uzlaşma oranı) onayıyla kabul edildi ve Ripple düğüm yazılımı ‘rippled’ 2.5.0 sürümünde sunulan XLS-85 standardı üzerinden devreye alındı. Böylece XRP Ledger, daha önce yalnızca Ripple(XRP) için geçerli olan escrow mekanizmasını güven hattı(IOU) tokenları ve MPT dahil olmak üzere ağdaki tüm token katmanına genişleterek, ‘ödeme–takas’ altyapısını kurumsal senaryolar için ciddi ölçüde büyütmüş oldu.

Ripple’ın geliştirme birimi RippleX, bu adımı “tek bir yerel varlığa odaklanan mutabakat yapısını, XRPL üzerindeki tüm token yığınına genişleten bir hamle” olarak tanımladı. RippleX, X üzerinde yaptığı açıklamada “Token Escrow(XLS-85) artık XRPL ana ağında canlı. Bu özellik, yerel escrow mekanizmasını Ripple(XRP)’den tüm güven hattı tabanlı tokenlara(IOU) ve MPT’ye genişletiyor. RLUSD gibi ‘stabil kripto paralar’dan, ‘gerçek dünya varlıkları(RWA)’na kadar XRPL artık tüm varlıklar için güvenli ve koşullu on-chain ödemeleri destekliyor” ifadelerini kullandı ve “kurumsal DeFi araç setinin büyüdüğünü” vurguladı.

XRPL.org, escrow kavramını “geleneksel olarak iki taraf arasındaki işlemlerin üçüncü bir aracı tarafından tutulup yönetildiği sözleşme yapısı” olarak tanımlarken, XRP Ledger’da bu üçüncü tarafın ‘doğrudan deftere gömülü otomasyon sistemi’ ile değiştirildiğinin altını çiziyor. Bugüne kadar bu otomatik escrow sistemi sadece Ripple(XRP) için kullanılabiliyordu. Token Escrow değişikliğiyle birlikte aynı yapı, ‘değiştirilebilir(fungible)’ token kategorisindeki tüm varlıklara uygulanabilir hale geldi; yani NFT’ler kapsam dışında kalırken, XRPL üzerindeki likit token evreni escrow desteği kazandı.

Yeni modelde, güven hattı tabanlı tokenlar ve MPT varlıkları escrow fonksiyonuna erişebilmek için ayrı ayrı tanımlanan ‘bayrak(flag)’ ayarlarına ihtiyaç duyuyor. Güven hattı tokenlarında, öncelikle ihraç eden hesabın ‘Allow Trust Line Locking’ bayrağını açması gerekiyor. Bu bayrak etkinleşmediği sürece, ilgili IOU tokenı daha önce olduğu gibi sadece transfer edilebiliyor; herhangi bir escrow sözleşmesinde kilitlenemiyor. Böylece ihraççı, kendi tokenının escrow ile kilitlenmesine izin verip vermemeyi doğrudan kontrol edebiliyor.

MPT tarafında ise bu izinler daha baştan, token oluşturulurken tanımlanmak zorunda. İhraççı, ‘Can Escrow’ ve ‘Can Transfer’ bayraklarıyla tokenın hem escrow içine alınabilir olduğunu, hem de vade dolduğunda veya koşullar sağlandığında tekrar transfer edilebileceğini belirtiyor. Bu ikili yapı sayesinde, ‘kilitlemeye izin verme’ ile ‘kilit açıldıktan sonra gerçekten hareket edip edemeyeceği’ arasında net bir ayrım oluşturuluyor. yorum Bu, kurumsal senaryolarda farklı token sınıfları için detaylı hak ve yetki kurgusu yapmayı kolaylaştırıyor.

Bununla birlikte, ihraççı tarafına kritik bir kısıtlama getirildi. İhraç hesabı, ‘kendi çıkardığı tokenları kendisi için escrow’a kilitleyemiyor’. Yani bir tokenın ihraççısı, o varlığı kendi bilançosu üzerinde teminat veya dolaşım kontrolü amacıyla escrow’a koyan taraf olamıyor; ancak başka bir kullanıcının oluşturduğu escrow’dan çıkan tokenları ‘alıcı’ sıfatıyla teslim alabiliyor. yorum Bu tasarım, ihraççı ile tokenın piyasadaki dolaşım yapısı arasındaki olası çıkar çatışmalarını azaltma denemesi olarak değerlendiriliyor.

Token Escrow yapısında ‘yetkilendirme(authorization)’ yönetimi de merkezi bir unsur olarak karşımıza çıkıyor. Eğer ihraççı belirli bir tokenı ‘onay gerektiren(authorization-required)’ modelde işletiyorsa, escrow’a giden fonlar için de önceden yetki alınması zorunlu. Daha net ifade etmek gerekirse, token gönderen hesap escrow oluşturmak istiyorsa, bunu yapmadan önce ihraççıdan onay almış olmalı. Aynı şekilde escrow süresi dolup iptal edildiğinde, tokenları geri alacak hesabın da, geri alım gerçekleşmeden önce onaylı alıcı statüsünde olması gerekiyor. Bu şart, ‘escrow’u kimin iptal ettiğinden bağımsız şekilde değişmeden uygulanıyor.

Escrow’un alıcısı olacak hesap için de durum farklı değil. Tokenın onaylı alıcı modeliyle çalıştığı senaryolarda, escrow tamamlanıp ‘EscrowFinish’ ile çözülmeden önce alıcı hesabın da ihraççı tarafından önceden yetkilendirilmiş olması gerekiyor. Yetkisi olmayan bir hesaba escrow çözülmeye çalışılırsa, işlem onaylanmıyor. Bu yapı, kara para aklama karşıtı önlemler(AML), menkul kıymet benzeri token düzenlemeleri ve ‘izinli DeFi’ modelleri için zincir üstü erişim kontrolü katmanı sunuyor. yorum Özellikle regüle pazarlarda ‘kim, ne zaman, hangi şartla token alabilir’ sorusuna teknik yanıt verilmesini kolaylaştırıyor.

Teknik işleyiş tarafında XRP Ledger, daha önce olduğu gibi üç ana escrow tipini desteklemeye devam ediyor: ‘zaman bazlı(time-based)’, ‘koşul bazlı(condition-based)’ ve ‘hibrit(karma) modeller’. Kullanıcı, ‘EscrowCreate’ işlemiyle fonları kilitliyor; belirlenen koşullar sağlandığında ‘EscrowFinish’ ile kilidi açıyor; süre dolarsa ‘EscrowCancel’ ile anaparayı geri istiyor. Token Escrow tarafındaki önemli farklardan biri, ‘vade süresinin(expiration time)’ tanımlanmasının zorunlu olması. Yani sonsuz süreli, kalıcı kilitleme yapılamıyor. Bu nedenle model, özellikle ‘vesting(dağıtım planı)’ ve ‘lock-up(kilitlenme)’ gibi, başlangıçta net süre ve koşullar belirlenmiş modeller için uygun.

Yeni özelliğin zincir üstü maliyet boyutu da dikkate değer. XRPL.org’un dokümantasyonuna göre, escrow işlemi en az iki adet işlem gerektiriyor ve özellikle ‘Crypto-Conditions(kripto koşullar)’ kullanıldığında işlem ücretleri artıyor. Crypto-Conditions, bir işlemin geçerli sayılması için belirli kriptografik şartların sağlanmasını zorunlu kılan bir yapı olarak tanımlanıyor. Şu an XRP Ledger üzerinde sadece ‘PREIMAGE-SHA-256’ türündeki Crypto-Conditions desteği bulunuyor. Bu yöntemin kullanıldığı senaryolarda, koşulun sağlanıp sağlanmadığını doğrulayan ek denetim adımları nedeniyle ‘EscrowFinish’ maliyeti yükseliyor.

Resmi dokümanlara göre, kripto koşul içeren bir ‘EscrowFinish’ işlemi için en az ‘330 drop’ XRP gerekiyor ve buradan sonraki ek ücret, koşulu temsil eden veri(fulfillment) boyutuna göre artıyor. Bu ücret yapısı, ağın temel ücret parametreleri güncellendiğinde beraberinde yeniden ayarlanıyor. Sonuç olarak Token Escrow, ‘güvenlik ve koşul esnekliği’ sağlarken, basit transferlere kıyasla daha yüksek on-chain maliyet anlamına geliyor. Kurumsal kullanıcılar ve proje ekiplerinin, işlem ücreti ile zincir üstü otomasyon avantajı arasında denge kurarak hangi ödeme–takas adımlarında escrow kullanacaklarını baştan tasarlamaları gerekiyor.

RippleX, Token Escrow’un öne çıkan kullanım alanları arasında ‘token vesting ve hibe(grant) ödemeleri’, ‘koşullu ödeme ve OTC(tezgah üstü) takaslar’, ‘hazine(treasury) ve şirket finansmanı süreçlerindeki hukuki blokaj ve teminat yönetimi’, ‘tokenize haklar ve RWA(reel varlık) temelli açılma(unlock) modelleri’ni sayıyor. Örneğin, bir proje ekibi yatırımcı ve ekip tahsislerini escrow’a koyup, belirlenmiş takvime göre adım adım serbest bırakılan bir dağıtım planını tamamen on-chain olarak kurgulayabiliyor. OTC piyasada ise taraflar, hem tokenları hem de ödenecek kripto parayı ‘koşul sağlanana kadar kilitleyerek’ karşı taraf riskini minimize edebiliyor.

Hukuki uyuşmazlıklar veya regülasyon kaynaklı soru işaretleri doğduğunda, ilgili varlıkların belirli süreli ‘hukuki bekleme(legal hold)’ rejimine alınması da escrow üzerinden yönetilebiliyor. RWA tokenlarında ise zincir dışı olaylar (belge teslimi, regülasyon onayı, vade dolumu vb.) Crypto-Conditions ile bağlanarak, sadece şartlar sağlandığında varlığın serbest kalacağı yapılar tasarlanabiliyor. Ortak nokta, tüm bu senaryoların ‘belli bir zamana ya da koşula kadar varlığı kilitleyen yerel bir mekanizma’ya ihtiyaç duyması. Token Escrow, bu ‘X gerçekleşene kadar kilitli tut(lock until X)’ modelini XRP Ledger’ın token katmanına yerel olarak sunarak, üçüncü taraf saklama(custody) şirketlerine veya tamamen zincir dışı koordinasyona olan bağımlılığı azaltıyor.

Ripple ve XRPL ekosisteminin uzun süredir ‘regülasyon uyumluluğu ve kurumsal odaklı’ bir çizgi izlediği düşünüldüğünde, Token Escrow(XLS-85) güncellemesi, sade bir özellik eklemesinden çok daha fazlası olarak okunuyor. Ripple(XRP) dışına taşan escrow desteği sayesinde, XRPL üzerinde ‘stabil kripto paralar, RWA, çeşitli fayda(token utility) tokenları ve kurumsal nitelikli yapılandırılmış ürünler’ tabanlı ödeme, teminat ve takas çözümlerinin daha yoğun şekilde denenmesinin önü açılmış durumda. yorum Özellikle bankalar, finans kurumları ve kurumsal yatırımcılar için tasarlanan ‘kurumsal DeFi’ vizyonunda, Token Escrow ağın ödeme–takas katmanını güçlendiren stratejik bir bileşen olarak öne çıkıyor.