Tokenizasyon projesi, “blokzincir kullanabilir miyiz?” sorusuyla değil, hangi hakkın kim tarafından oluşturulduğu, nasıl devredildiği, nasıl saklandığı, nakit ve varlık tarafının nasıl kesinleştiği, uyuşmazlıkta hangi kaydın üstün olduğu ve mevcut çözüme göre hangi ölçülebilir verimi sağladığı sorularıyla değerlendirilir. Hak, kayıt, mutabakat veya ekonomik fayda net değilse token üretmek projeyi uygulanabilir hâle getirmez.
Tokenizasyon değil, çözülmesi gereken problem tanımlanmalıdır
Bir projenin ilk dosyası teknoloji mimarisi değil, mevcut sürecin sorun haritasıdır. Kayıtların farklı kurumlarda tutulması, hak sahipliğinin geç doğrulanması, manuel mutabakat, parçalı işlem zinciri, yüksek asgari yatırım tutarı, sınırlı erişim veya ödeme ile varlık tesliminin farklı zamanlarda gerçekleşmesi ölçülebilir sorunlardır. Bunlardan hangisinin gerçekten tokenizasyonla iyileşeceği ayrıca kanıtlanmalıdır.
| Problem | Tokenizasyonun muhtemel katkısı | Önce sorulacak soru |
|---|---|---|
| Parçalı kayıt ve mutabakat | Ortak ve senkronize işlem durumu sağlayabilir. | Katılımcılar ortak yönetişimi kabul ediyor mu? |
| Ödeme–teslim ayrışması | Koşullu veya atomik mutabakat tasarlanabilir. | Nakit ayağı aynı güven ve kesinlik düzeyinde mi? |
| Yüksek asgari yatırım | Ekonomik hakkı daha küçük birimlerde temsil edebilir. | Bölünebilirlik hukuken ve operasyonel olarak geçerli mi? |
| Likidite eksikliği | Tek başına çözmez; erişim ve işlem altyapısı sağlayabilir. | Gerçek alıcı–satıcı talebi ve piyasa yapıcısı var mı? |
Tokenın temsil ettiği hak açık ve uygulanabilir olmalıdır
Token, bir varlığın kendisi olmayabilir; alacak, ortaklık, kullanım, gelir paylaşımı, saklama makbuzu veya başka bir sözleşmesel hakkı temsil edebilir. Yatırımcı veya kullanıcı tokenı aldığında neye sahip olduğunu, bu hakkı kime karşı ileri sürebileceğini, hakkın hangi kayıtla doğduğunu ve hangi koşullarda sona erdiğini anlayabilmelidir.
- Dayanak varlık: Fiziksel, finansal veya dijital varlığın tanımı ve doğrulama yöntemi.
- İhraççı: Hakkı oluşturan ve yükümlülüğü taşıyan taraf.
- Hak kapsamı: Mülkiyet, alacak, gelir, oy, kullanım veya itfa hakkı.
- Üstün kayıt: Uyuşmazlıkta blokzincir kaydı mı, merkezi sicil mi, sözleşme mi esas alınır?
- Kurumsal olay: Temettü, kupon, itfa, bölünme, rehin, haciz, miras ve kayıp anahtar nasıl yönetilir?
- İptal ve düzeltme: Hatalı veya yetkisiz işlem hangi yetki ve kayıtla düzeltilir?
Bu bölüm hukuki görüş yerine geçmez. Proje dosyasında ilgili ülke ve ürün için yetkili hukuk, vergi, muhasebe ve düzenleyici uzman görüşü ayrı kanıt olarak yer almalıdır.
Katılımcılar ve sorumluluk zinciri tasarlanmalıdır
İhraççı ve kayıt sorumlusu
Tokenı oluşturan, dayanak varlığı doğrulayan ve yükümlülüğü yerine getiren taraf ayrıştırılır.
Saklama ve anahtar yönetimi
Özel anahtar, müşteri varlığı, görevler ayrılığı ve kurtarma süreci tanımlanır.
Platform ve piyasa rolü
Emir, eşleşme, transfer, uygunluk ve fiyat oluşumu sorumlulukları belirlenir.
Dış veri sağlayıcıları
Fiyat, mülkiyet, olay veya performans verisinin kaynağı ve itiraz süreci yazılır.
“Akıllı sözleşme otomatik yapar” ifadesi sorumluluğu ortadan kaldırmaz. Kod güncellemesi, acil durdurma, anahtar rotasyonu, katılımcı kabulü, yaptırım taraması ve hata düzeltme gibi kararlar için açık yetki matrisi gerekir.
Defter mimarisi iş modelinden türetilmelidir
İzinli veya izinsiz ağ, ortak veya özel defter, zincir üstü ya da zincir dışı kayıt seçimi; katılımcı güveni, gizlilik, işlem hacmi, kesinleşme, denetim ve entegrasyon gereksinimlerinden türetilmelidir. Birden fazla defter kullanılacaksa hangi olayın hangi sistemde kesinleştiği açıkça belirtilmelidir.
| Karar | Değerlendirme ölçütü | Risk |
|---|---|---|
| İzinli ağ | Tanımlı katılımcı, kurumsal gizlilik ve yönetişim ihtiyacı. | Operatör yoğunlaşması ve sınırlı birlikte çalışabilirlik. |
| Halka açık ağ | Açık erişim, geniş ekosistem ve standart token altyapısı. | Ücret oynaklığı, gizlilik ve yönetişim belirsizliği. |
| Zincir dışı kayıt | Hassas veri, büyük belge veya mevcut sicil bağımlılığı. | İki kayıt arasındaki tutarsızlık ve oracle riski. |
| Köprü/interoperabilite | Başka ağ, piyasa veya ödeme sistemiyle bağlantı. | Köprü güvenliği, kesinleşme farkı ve operasyonel karmaşıklık. |
Nakit ayağı ve mutabakat kesinliği birlikte çözülmelidir
Tokenize varlık transferi tamamlanırken ödeme başka sistemde bekliyorsa karşı taraf ve teslim riski devam eder. Tasarım; ticari banka parası, merkez bankası parası, elektronik para, stablecoin veya başka ödeme aracının nasıl kullanılacağını; ödeme ile varlık transferinin hangi koşulda kesinleşeceğini tanımlamalıdır.
BIS Project Agorá, tokenlaştırılmış ticari banka mevduatları ile merkez bankası rezervlerinin ortak bir programlanabilir platformda atomik, çok para birimli mutabakatını prototip düzeyinde göstermiştir. Ancak BIS, çalışmanın deneysel olduğunu ve teknik, operasyonel, sözleşmesel ve hukuki gereksinimlerin daha fazla geliştirilmesi gerektiğini de açıkça belirtir.
- Ödeme aracının ihraççısı ve kredi riski.
- İşlem kesinliği ve geri alınamazlık noktası.
- Çalışma saatleri, likidite ve fonlama gereksinimi.
- Başarısız bacak, zaman aşımı ve iade senaryosu.
- Farklı ülke ve sistemlerde hukuki kesinleşme.
- Mutabakat, muhasebe ve raporlama kayıtlarının eşleşmesi.
Token üretmek likidite üretmez
Likidite; yeterli yatırımcı, bilgi şeffaflığı, güvenilir fiyatlama, piyasa yapıcılığı, işlem ve saklama altyapısı, transfer edilebilirlik ve makul maliyetin birlikte oluşmasına bağlıdır. Küçük parçalara bölünebilirlik potansiyel erişimi artırabilir; fakat dayanak varlık değerlemesi zayıfsa veya çıkış kanalı yoksa yatırımcı riski büyüyebilir.
Risk modeli teknoloji, finans ve operasyonu birlikte kapsamalıdır
- İhraççı ve dayanak varlık riski.
- Akıllı sözleşme hatası, yükseltme ve yönetici anahtarı riski.
- Saklama, özel anahtar, müşteri varlığı ayrımı ve kurtarma riski.
- Oracle, fiyat ve dış kayıt doğruluğu.
- AML/CFT, yaptırım, kimlik ve transfer kısıtları.
- Gizlilik, kişisel veri ve ticari sırların defterde kalıcılığı.
- Ağ, köprü, node, bulut ve hizmet sağlayıcı yoğunlaşması.
- İş sürekliliği, olay müdahalesi ve güvenli kapanış.
Fizibilite ve karar matrisi
| Boyut | Güçlü fizibilite göstergesi | Zayıf fizibilite göstergesi | Kanıt |
|---|---|---|---|
| Problem | Çok taraflı mutabakat veya ödeme–teslim sorunu ölçülmüş. | Yalnız pazarlama ve “yenilik” amacı. | Mevcut süreç süresi, hata ve maliyet verisi. |
| Hak | Tokenın temsil ettiği hak ve üstün kayıt açık. | Hak yalnız teknik dokümanda tanımlı. | Sözleşme, sicil ve uzman görüşü. |
| Ekonomi | Gelir, maliyet, erişim veya sermaye verimi ölçülebilir. | Likidite ve talep varsayıma dayanıyor. | Talep testi ve birim ekonomi. |
| Mutabakat | Nakit ve varlık bacakları kesinlik modeliyle bağlı. | Ödeme zincir dışında belirsiz kalıyor. | Uçtan uca işlem senaryosu. |
| Yönetişim | Katılım, değişiklik, hata ve kriz yetkileri yazılı. | Teknik ekip veya tek anahtar fiilen sınırsız. | RACI, anahtar politikası ve olay planı. |
| Çıkış | Veri, hak ve katılımcıların geçiş planı var. | Ağ veya sağlayıcı değişimi düşünülmemiş. | Taşınabilirlik ve kapanış testi. |
Pilot; teknoloji gösterisi değil, karar deneyi olmalıdır
- Kapsam: Tek varlık, sınırlı katılımcı ve açık işlem senaryosu seçilir.
- Başlangıç ölçümü: Mevcut süreç maliyeti, süre, hata ve mutabakat yükü kaydedilir.
- Hukuk ve operasyon: Hak, kayıt, ödeme, saklama ve olay senaryoları masa başında doğrulanır.
- Teknik test: Yetkisiz işlem, anahtar kaybı, ağ kesintisi, hatalı oracle ve geri alma senaryoları çalıştırılır.
- Ekonomik test: Talep, likidite, işlem maliyeti ve ölçek etkisi ölçülür.
- Durdurma kriteri: Hak belirsizliği, ekonomik faydasızlık, kontrol açığı veya sürdürülemez bağımlılık varsa proje durdurulur.
Kaynaklar ve gözden geçirme notu
Bu rehberde değişebilir veya teknik iddialar için öncelikle resmî kurum, ürün geliştiricisi ve birincil araştırma kaynakları kullanılmıştır. Bağlantılar 27 Temmuz 2026 tarihinde gözden geçirilmiştir.
- 01IOSCO — Tokenization of Financial Assets, Report of the Board
Finansal varlık tokenizasyonunda piyasa yapısı, risk, düzenleyici yaklaşım ve gelişim alanlarını ele alan resmî rapor.
- 02BIS — Project Agorá: A shared programmable platform for wholesale cross-border payments
Tokenlaştırılmış rezerv ve mevduatlarla atomik mutabakat prototipini, mimariyi, hukuki analizi ve sınırlılıkları açıklar.
- 03BIS — Project Agorá press release, 27 May 2026
Prototip bulgularını, gerçek değerli testlere geçiş planını ve deneysel çalışma sınırını özetler.
- 04Bank of England — What is tokenisation?
Finansal varlık tokenizasyonunu ve ortak defter yaklaşımını merkez bankası perspektifiyle açıklar.
- 05BIS Annual Economic Report 2025 — The next-generation monetary and financial system
Tokenizasyon, birleşik defter, merkez bankası parası ve finansal sistem tasarımı ilişkisini değerlendirir.