Dijital varlık saklama değerlendirmesi; varlığın ve hak sahibinin doğru kaydından özel anahtar ve işlem yetkisine, müşteri varlığı ayrımından ağ olaylarına, günlük mutabakattan kurtarma ve iflas senaryosuna kadar uçtan uca yapılır. Teknoloji kontrolü, hukuki sahiplik ve operasyonel süreç birbirinin yerine geçmez.
Saklama hizmeti, varlığa erişim ve transfer kontrolüyle tanımlanmalıdır
Kurum anahtarı doğrudan tutabilir, nitelikli bir saklama kuruluşu kullanabilir, çok taraflı hesaplama veya çoklu imza düzeni kurabilir ya da alt saklama zinciri kullanabilir. “Custody” etiketi gerçek kontrol modelini tek başına açıklamaz.
| Karar alanı | Kanıt | Kırmızı bayrak |
|---|---|---|
| Hak sahipliği | Müşteri, cüzdan ve kayıt eşlemesi. | Toplu cüzdan var, alt kayıt zayıf. |
| Anahtar kontrolü | Üretim, parça, yedek ve erişim prosedürü. | Tek kişi veya tek sistem bağımlılığı. |
| Transfer | Talep, onay, imza ve yayın akışı. | İşlem limitleri ve geri çağırma yok. |
| İflas/çıkış | Varlığın hukuki ayrımı ve iade süreci. | Müşteri varlığı kurum bilançosuyla karışıyor. |
Sıcak, ılık ve soğuk mimari kullanım amacıyla dengelenmelidir
Sıcak cüzdan hızlı işlem sağlar fakat çevrim içi saldırı yüzeyi büyüktür. Soğuk düzen çevrim dışı koruma sağlar fakat işlem ve kurtarma süresi uzar. Kurum; günlük likidite ihtiyacı, varlık profili, müşteri talebi ve risk iştahına göre katmanlı politika kurmalıdır.
Operasyon likiditesi
Düşük bakiye, sıkı limit, sürekli izleme.
Kontrollü erişim
Ek onay ve sınırlı çevrim içi bileşen.
Uzun süreli koruma
Çevrim dışı anahtar, fiziksel prosedür ve tatbikat.
MPC/çoklu imza
Taraf ve eşik tasarımı, parça kaybı ve tedarikçi riski.
Özel anahtar yaşam döngüsü baştan sona denetlenmelidir
- Güvenli anahtar üretimi ve entropi kaynağı.
- HSM, MPC veya fiziksel cihaz mimarisi.
- Anahtar parçalarının kişi, kurum ve coğrafya dağılımı.
- Yedekleme, kurtarma ve kayıp parça senaryosu.
- Yetki değişikliği, işten ayrılma ve rol devri.
- Anahtar rotasyonu ve adres değişikliği.
- Testnet/üretim ve müşteri/kurum anahtar ayrımı.
- İmha ve doğrulanabilir kapanış.
Teknoloji sağlayıcısının “anahtarı görmüyoruz” beyanı, kurumun tek taraflı kontrol veya kurtarma bağımlılığı bulunmadığını kanıtlamaz.
İşlem üretme, onaylama ve yayınlama görevleri ayrılmalıdır
| Aşama | Kontrol | Kanıt |
|---|---|---|
| Talep | Kimlik, hak sahipliği ve iş gerekçesi. | Talep kaydı. |
| Risk kontrolü | Adres, limit, yaptırım ve davranış kontrolleri. | Kural sonucu. |
| Onay | Çift kontrol, eşik ve ayrı rol. | Onay izi. |
| İmza | Politika tabanlı anahtar kullanımı. | İmza sistemi logu. |
| Yayın | Ağ, ücret ve son kontrol. | İşlem hash’i. |
| Mutabakat | Defter, zincir ve müşteri kaydı eşlemesi. | Günlük fark raporu. |
Müşteri varlığı hem hukuken hem operasyonel olarak ayrılmalıdır
Adres ayrımı tek başına hukuki ayrım değildir; toplu adres kullanımı da otomatik olarak ayrım olmadığı anlamına gelmez. Kurumun müşteri haklarını, kayıt bütünlüğünü, varlık kullanım yasağını, rehypothecation durumunu, iflas korumasını ve iade sürecini açıkça tanımlaması gerekir.
- Müşteri ve kurum varlığı için ayrı kayıt ve onay.
- Müşteri varlığının ödünç, teminat veya kurum hesabına kullanım sınırı.
- Alt saklama ve üçüncü taraf cüzdanların görünürlüğü.
- Bağımsız mutabakat ve periyodik doğrulama.
- Eksik, kayıp veya erişilemeyen varlık için sorumluluk.
- İflas ve hizmet kapanışında iade planı.
Ağ ve protokol olayları için önceden karar politikası gerekir
Fork, airdrop, staking, slashing, zincir durması, finality sorunu, akıllı sözleşme açığı veya token migration olayları saklama operasyonunu etkiler. Her varlığın teknik ve ekonomik özellikleri aynı değildir.
| Olay | Karar | Müşteri bilgisi |
|---|---|---|
| Fork | Hangi zincirin destekleneceği ve tekrar oynatma koruması. | Hak ve erişim takvimi. |
| Staking/slashing | Validator, kilit ve kayıp sorumluluğu. | Getiri ve risk ayrımı. |
| Airdrop | Destek, tahsil ve dağıtım maliyeti. | Uygunluk ve zaman. |
| Zincir durması | İşlem askısı ve yeniden açma eşiği. | Kesinti ve risk açıklaması. |
On-chain kayıt ile müşteri alt defteri düzenli mutabakat görmelidir
- Adres, varlık, ağ, miktar ve müşteri eşlemesi.
- Bekleyen, başarısız, yeniden düzenlenen ve ücretli işlemler.
- Token decimal, contract migration ve yanlış ağ riski.
- Fiat, stablecoin ve diğer nakit ayağı mutabakatı.
- Gün sonu farkı, yaşlandırma ve bağımsız inceleme.
- Proof-of-reserves benzeri kanıtların yükümlülük ve hukuki hakları tek başına kanıtlamadığı uyarısı.
Kurtarma yalnız yedek anahtarın bulunması değildir
Personel kaybı, tedarikçi iflası, HSM arızası, bölgesel afet, yaptırım, zincir olayı ve siber saldırı için ayrı senaryolar gerekir. Kurtarma tatbikatı gerçek varlığı riske atmayan kontrollü ortamda yapılmalıdır.
- Alternatif imza ve yetkili kombinasyonu.
- Bağımsız temiz cihaz ve ağ erişimi.
- Tedarikçi olmadan veri ve kayıt erişimi.
- Müşteri talebi ve toplu iade kapasitesi.
- Acil durdurma ve kontrollü yeniden açma.
- Yıllık kurtarma ve çıkış tatbikatı.
Saklama tedarikçisi teknoloji, finans ve yönetişimle birlikte incelenmelidir
Değerlendirme; lisans ve düzenleyici durum, müşteri varlığı rejimi, sermaye ve sigorta, güvenlik mimarisi, alt saklama zinciri, olay geçmişi, hizmet seviyesi, denetim raporları, iş sürekliliği ve çıkış kapasitesini kapsamalıdır.
Kontrol kanıt paketi karar komitesine düzenli sunulmalıdır
Saklama modelinin güvenli olduğu yalnız mimari sunumla kabul edilmemelidir. Anahtar töreni kaydı, yetki matrisi, cüzdan limitleri, günlük mutabakat raporu, bağımsız güvenlik testleri, kurtarma tatbikatı, alt saklama sözleşmeleri, müşteri varlığı ayrımına ilişkin hukuk değerlendirmesi ve olay kayıtları tek kanıt paketinde toplanmalıdır. Kanıtın tarihi, kapsamı ve hangi varlık/ağları kapsadığı görünür olmalıdır.
Yönetim raporu bakiye büyüklüğünü tek başına başarı göstergesi olarak sunmamalıdır. Sıcak cüzdan oranı, başarısız işlem, mutabakat farkı, anahtar erişim istisnası, tedarikçi kesintisi, kurtarma süresi, müşteri iade süresi ve açık aksiyonlar birlikte izlenmelidir. Böylece operasyon büyürken kontrol kapasitesinin aynı hızda gelişip gelişmediği ölçülebilir. Kritik göstergeler yalnız aylık raporda değil, önceden tanımlı eşikler aşıldığında anlık eskalasyon üretmelidir; özellikle mutabakat farkı, anahtar istisnası ve kurtarma başarısızlığı bekletilmemelidir. Eşik sahipleri açıkça tanımlanmalıdır.
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 — Policy Recommendations for Crypto and Digital Asset Markets
Müşteri varlığı koruması, saklama ve operasyonel/teknolojik risk için uluslararası öneriler sunar.
- 02IOSCO — Thematic Review of Crypto and Digital Asset Recommendations
Saklama politikası, hukuki ve operasyonel ayrım uygulamalarındaki ilerleme ve boşlukları inceler.
- 03Financial Stability Board — Crypto and Digital Asset Markets Recommendations
Müşteri varlığı koruması ve operasyonel risk için küresel düzenleyici taban sunar.
- 04BIS CPMI-IOSCO — Principles for Financial Market Infrastructures
Saklama, operasyonel risk, ayrım ve erişim sürekliliği için temel piyasa altyapısı ilkelerini açıklar.
- 05Basel Committee — Cryptoasset exposures framework
Kripto varlık faaliyetlerinde operasyonel risk ve risk yönetimi beklentilerini açıklar.