Güvenlik token'ları için kendi saklama: Kontrolünüzde ne…

Güvenlik tokenleri için kendi kendine saklama, yatırımcının tokenize edilmiş bir güvenliğin bulunduğu cüzdanın özel anahtarlarını kontrol etmesi anlamına gelir, ancak transfer yetkisi genellikle tokenin altyapısına yerleştirilmiş kimlik ve uyum kontrolleri ile paylaşılır.

Bir güvenlik tokeni kendi kendine saklama cüzdanında bulunabilir, ancak menkul kıymet kuralları ve “kodla uyum” özellikleri ham anahtar kontrolünün üzerinde yer aldığı için transfer edilemez, geri alınamaz veya aracının yetkilendirmesine tabi olabilir.

Ana Noktalar

• Kendi kendine saklama için güvenlik tokenleri üç katmanlı bir kontrol yığınıdır: özel anahtarlar, kimliğe bağlı transfer izinleri ve aracılar pozisyonu taşıdığında “sahiplik/kontrol” ile ilgili düzenlenmiş beklentiler.
• Bir token, kendi kendine saklama cüzdanında olabilir ve yine de hareket edemeyebilir eğer token izinli bir token isetransferlere izin vermeden önce uygunluğu kontrol eden veya beyaz listeye alan.
• SEC personelinin Kural 15c3-3(b)(1) hakkındaki görüşleri, bir aracının “fiziksel mülkiyet”i koruması gerektiğinde tek taraflı müşteri transfer yeteneğini bir sorun olarak görmektedir.kripto varlıkmenkul kıymetler.
• Bazı güvenlik token çerçeveleri, kimlik doğrulamasonrası kurtarmayı destekler, bu da anahtar kaybının her zaman kalıcı olduğu varsayımını değiştirir.

Güvenlik token kendi saklama işlemi nasıl farklıdır

Aynı cüzdan adresinin üzerinde üç ayrı “kontrol” bulunabilir., ve güvenlik tokenleri genellikle bu üçünü de kullanır. Birinci katman anahtar kontrolüdür: adresten imza atabilen herkes bir transfer gerçekleştirmeyi deneyebilir. İkinci katman transfer izinleridir: token sözleşmesi, gönderici ve alıcının kimlik veya uygunluk kurallarını karşılamadığı sürece imzalı transferi onaylamayı reddedebilir.

Üçüncü katman, düzenlenmiş bir aracının müşteri pozisyonunu taşıdığı durumlarda kimin etkili transfer yeteneğine sahip olabileceğinin düzenlenmiş yorumudur.

Bu yığın, saklama tokenleştirilmiş varlıkların BTC'yi bir donanım cüzdanında tutmakla aynı problem olmadığını gösterir. Birçok tokenleştirilmiş menkul kıymet, token sözleşmesi, geleneksel piyasa altyapısının genellikle zincir dışı olarak ele alacağı kısıtlamaları uygulamak için inşa edilmiştir. Bu, varlığın transfer fonksiyonunun bir uyum kontrol noktası haline geldiği “kodla uyum” fikrinin saf halidir.

Operasyonel sonuç basit ama belirgin değildir: “cüzdanımda” ifadesi “herhangi bir yere gönderebilirim” anlamına gelmez. Bir güvenlik tokeni, kontrol ettiğiniz bir adreste mevcut olabilir ve zincir, alıcı onaylı değilse, ihraç eden bir kısıtlama getirmişse veya tokenin kimlik kaydı varış noktasını tanımıyorsa bir transferi reddedecektir.

Bu aynı zamanda klasik saklama sorusunu yeniden çerçevelendirir. Sade kripto için anahtar soru “anahtarları kim tutuyor.” Güvenlik tokenleri için kendi kendine saklama durumunda, daha yüksek değerli soru “bu tokeni (hareket ettirmek veya hareket ettirmemek) kim sağlayabilir” şeklindedir; bu, anahtarlar, kimlik kapıları ve herhangi bir ihraç eden veya aracının kontrolleri üzerinden geçer.

Anahtarlar, cüzdanlar ve güvenlik trade-off'ları

Anahtar yönetimi hala önemlidir çünkü blockchain nihayetinde özel anahtarı bir işlemi yetkilendiren kimlik bilgisi olarak değerlendirir. Fireblocks’un saklama genel görünümü, temel mekanik hakkında açıktır: saklama, etkili bir şekilde kriptografik anahtarları korumakla ilgilidir ve eğer anahtarlar kaybolur veya çalınırsa, varlıklar geri alınamaz olabilir.

Cüzdanın “sıcaklığı”, çoğu sahip için gerçekten hissedilen ilk kontrol düğmesidir. Sıcak cüzdanlar anahtarları çevrimiçi tutar ve hızı önceliklendirir, çünkü imza ortamı her zaman bağlıdır ve daha fazla maruz kalma ile sonuçlanır. Soğuk cüzdanlar anahtarları çevrimdışı tutar ve güvenliği önceliklendirir, ancak imza cihazının devreye girmesi gerektiği için yürütmeyi yavaşlatır.

Ilık cüzdanlar, anahtarları çevrimiçi tutarken imza için insan onayı gerektiren bir ara konumda yer alır. Güvenlik token'ları genellikle sahipleri ılık tarz iş akışlarına yönlendirir çünkü kurumsal eylemler, uyum odaklı transferler ve onaylar, ham hızdan daha önemli olabilir.

Paylaşılan kontrol kurulumları başka bir boyut ekler. Çok imzalı (multi-sig) sistem, bir işlemi yetkilendirmek için birden fazla anahtar gerektirir, bu da tek nokta tehlikesini azaltabilir ancak operasyonel sertlik getirir. Fireblocks, çok imzalı sistemin esnek olamayabileceğini vurgular çünkü imzalayan eşiklerini değiştirmek yeni cüzdanlar ve yeni adresler gerektirebilir ve varlık desteği değişkenlik gösterebilir.

MPC (çok taraflı hesaplama), bir anahtarı cihazlar veya ortamlar arasında paylara bölerek aynı sorunu farklı bir şekilde ele alır. Fireblocks’un tanımı, masa operasyonları avantajını vurgular: imzalayan ve eşik yapılandırmaları, cüzdan adresini değiştirmeden güncellenebilir.

Güvenlik token'ları için, “aynı adres, farklı kontrol seti” özelliği kozmetik değildir. Eğer token’ın uyum rayları adresleri beyaz listeye alıyorsa, adres değiştirmek yeniden kaydolmayı, yeniden onay almayı veya yeni adres tanınana kadar başarısız bir transferi gerektirebilir.

Transferler üzerindeki uyum ve kimlik kısıtlamaları

Kimlik kontrolleri birçok güvenlik token'ı için ek bir unsur değildir. Tokeny’nin çerçevesi, ihraççıların cüzdan sahiplerini tanımlaması ve güvenliği sahiplenme uygunluğunu doğrulaması gerektiğidir ve blockchain tabanlı kimliğin bu uyum gereksinimini çözebileceğini belirtir. Bu modelde, cüzdan kimlik değildir. Kimlik, token’ın transfer mantığının danışabileceği ayrı bir on-chain veya bağlantılı kimlik bilgisidir.

Yaygın bir uygulama deseni, akıllı sözleşmenin transfer kurallarını zorladığı izinli token tasarımıdır. Sahip bir işlemi imzalar, ancak sözleşme yalnızca gönderici ve alıcının token’ın uyum politikasını karşıladığı takdirde bunu yürütür.

Tokeny, bir kurtarma talebinin kökenini doğrulamak ve yeni bir cüzdanı yatırımcının kimliğine bağlamak için kullanılan standartlaştırılmış bir kimlik/KYC doğrulama adımı olarak ONCHAINID'yi (burada onchainid olarak gösterilmiştir) örnek olarak kullanır.

Burada “kendine ait saklama”, mutlak egemenlik olarak ele alındığında yanlış bir terim haline gelir. Yatırımcı anahtarları kontrol edebilir ve yine de onaylanmamış bir adrese transfer yapamayabilir. İhraççı, kripto yerlilerine yabancı görünen dondurma veya idari hareket gibi güçleri de elinde tutabilir.

Bazı token standartları ve ihraççı kurulumları, yetkili bir tarafın belirli koşullar altında token'ları taşıyabileceği zorunlu transfer yeteneğini de destekler.

Kullanıcıya yönelik sonuç, transferlerin iki aşamalı bir yetkilendirme haline gelmesidir: kriptografik yetkilendirme (imza) ve uyum yetkilendirmesi (token’ın kuralları). Bu, güvenlik token’ı kendine ait saklamanın, aracılara sahip olmayan bir saklama yerine koruma çitleri olan bir saklama gibi hissettirebilmesinin temel nedenidir.

Aracı kurumun saklama işlemleri devreye girdiğinde

Kural 15c3-3(b)(1), bir aracı kurum pozisyonu taşıdığında “nitelikli saklayıcı vs kendi kendine saklama” durumunu gerçek bir çatışmaya dönüştüren kısıtlamadır. Kural, bir aracı kurumun, müşterileri için taşıdığı tamamen ödenmiş ve fazla marj menkul kıymetlerinin fiziksel mülkiyetini veya kontrolünü derhal elde etmesini ve bunu sürdürmesini gerektirir.

SEC'in 2025 Ticaret ve Pazarlar personel açıklaması (17 Aralık 2025 tarihli) görüşlerini menkul kıymet olan kripto varlıklara uygular ve “kripto varlık menkul kıymetleri” içinde bir hisse veya borç menkul kıymetinin tokenleştirilmiş versiyonlarını açıkça içerir.

Kendi kendine saklama için ana nokta, SEC personelinin özel anahtar erişimini nasıl çerçevelediğidir. SEC'in 2020 Komisyon açıklaması, bir dijital varlık menkul kıymetinin, yetkisiz bir kişinin özel anahtarı bilmesi veya erişimi olması durumunda ve aracı kurumun yetkisi olmadan transfer yapabilmesi halinde Kural 15c3-3 mülkiyet/kontrolüne uygun olarak tutulmadığını belirtmektedir.

2025 Ticaret ve Pazarlar personel açıklaması, başka bir kişinin, müşteri dahil, aracı kurum yetkisi olmadan varlığı transfer edemeyeceğini sağlamak için özel anahtar koruma kontrollerini tanımlayarak operasyonel beklentiyi sıkılaştırmaktadır.

Ekran düzeyindeki gerçeklik budur: bir aracı kurum “mülkiyet” sahibi olması gerektiğinde, müşterinin tek taraflı transfer yeteneği bir saklama hatası olarak değerlendirilir, bir özellik olarak değil. Bu, nitelikli saklayıcı teriminin konuşmalarda ortaya çıktığı yerdir, ancak SEC materyalleri burada aracı kurumlar ve Kural 15c3-3(b)(1) üzerine odaklanmaktadır, her piyasa katılımcısı için evrensel bir saklama rejimi değil.

İki uyarı önemlidir. İlk olarak, hem 2020 hem de 2025 SEC personel materyalleri, hukuki bir güce veya etkiye sahip olmadıklarını ve geçerli yasayı değiştirmediklerini veya değiştirmediklerini vurgulamaktadır. İkincisi, 2025 personel açıklaması açıkça (b)(1) paragrafı ile sınırlıdır ve diğer aracı kurum yükümlülüklerini ele almamaktadır.

Bu açıklamaları, düzenleyicilerin ve aracılarının anahtar kontrolü ve transfer yetkisi hakkında nasıl düşündüğüne dair bir harita olarak değerlendirin.

Kurtarma, kesintiler ve pratik riskler

Kurtarma, birçok menkul kıymet token tasarımını tipik kripto varsayımlarından en net şekilde ayıran özelliktir. Tokeny, ihraççıların yatırımcılara karşı yasal olarak sorumlu oldukları için dijital kimliğin, kimlik doğrulama sonrasında güvenlik tokenlarının yeni bir cüzdana kurtarılmasını sağlayabileceğini savunmaktadır.

Tanımladıkları akış operasyonel olarak basittir: yatırımcı kaybı bildirir, ihraççı veya temsilci kimliği onchainid tarzı KYC kullanarak doğrular, ardından ihraççı tokenları yeni bir cüzdana taşımak için kurtarma işlevini tetikler. Bu, bir arka plan ile kendi kendine saklama olup, yedeklerin ve kayıp senaryolarının nasıl modellenmesi gerektiğini değiştirir.

Anahtar riski kaybolmaz, şekil değiştirir. Fireblocks'un uyarısı, anahtar katmanında geçerliliğini korumaktadır: anahtarları kaybetmek, varlıkların kurtarılamayabileceği anlamına gelir. Tokeny'nin modeli, ikinci bir bağımlılık getirir: belirli tokenin ihraççısının ve akıllı sözleşmelerin gerçekten kurtarmayı destekleyip desteklemediği ve hangi yasal ve operasyonel koşullar altında.

Kısa not, ihraççı tarafından tetiklenen kurtarmanın piyasa genelinde yaygınlığının belirsiz olduğunu açıkça belirtmektedir.

SEC'in saklama açıklamaları, çoğu cüzdan kılavuzunun göz ardı ettiği risklere dikkat çekmektedir çünkü bunlar “seed phrase” sorunları değildir. SEC'in 2020 açıklaması, hırsızlık ve dolandırıcılık, özel anahtarların kaybı, istenmeyen adreslere transferler ve geleneksel menkul kıymet altyapısına kıyasla yanlış veya yetkisiz işlemleri geri döndürme yeteneğinin sınırlı olduğu konularını vurgulamaktadır.

2025 Ticaret ve Pazarlar personel açıklaması, blockchain arızalarını, %51 saldırılarını, hard fork'ları ve airdrop'ları öngören kesinti planları çağrısında bulunarak daha da ileri gitmektedir, ayrıca el koyma, dondurma, yakma veya transferi önleme gibi yasal emirlerle uyum sağlamak için düzenlemeler talep etmektedir.

Kendi kendine saklama sahibi için çıkarım, her senaryoyu ezberlemek değildir. Güvenlik tokenlarının hem kripto nihaiyetini hem de menkul kıymet yükümlülüklerini miras aldığını ve bunların kesintiler sırasında çarpıştığını kabul etmektir.

Kendiliği seçmek veya bir saklayıcı

Kontrol yığını açıkça ortaya konduğunda karar nadiren ideolojik olur. Kendiliği, sahibin işlemleri imzalaması anlamına gelebilir, ancak token'ın uyum rayları ve aracının yükümlülükleri, bir transferin izinli olup olmadığını hala belirleyebilir. Saklayıcı bir yapı, operasyonel yükü azaltabilir, ancak anahtar riski ve politika riskini saklayıcıda yoğunlaştırır.

Faydalı bir durum tespiti sırası, sistemin gerçekten başarısız olduğu sırayla sorular sormaktır:

1. Transfer yetkisini haritalayın. Token'ın izinli bir token olup olmadığını, hangi uygunluk kontrollerinin mevcut olduğunu ve ihraççı yönetici işlevlerinin dondurma, zorunlu transfer veya kurtarma gibi işlevleri içerip içermediğini belirleyin. 2. Kimlik bağını netleştirin. Hangi kimlik sisteminin kullanıldığını, onchainid tarzı doğrulamanın gerekip gerekmediğini ve bir cüzdan değiştirildiğinde ne olacağını doğrulayın. 3.

Taşıma modelini belirleyin. Eğer bir aracılık-dealer pozisyonu taşıyorsa, kendiliği beklentilerini Kural 15c3-3(b)(1) mülkiyet mantığı ile ve SEC personelinin müşterilerin aracılık-dealer yetkisi olmadan transfer yapmamaları gerektiği görüşü ile uzlaştırın. 4. İş akışına uygun cüzdan kontrollerini seçin.

Beklenen aktiviteye uygun olarak sıcak, ılık veya soğuk depolamanın uygun olup olmadığını ve çok imzalı veya MPC'nin adres tabanlı beyaz listeyi bozmadan operasyonel olarak desteklenip desteklenmeyeceğini karar verin. 5. Kesinti yönetimini stres testine tabi tutun. Forklar, airdrop'lar veya ağ olayları sırasında ne olacağını ve bir hizmet sağlayıcısı başarısız olursa kapanma veya transfer planının ne olduğunu sorun.

Bu aynı zamanda “nitelikli saklayıcı vs kendiliği”nin bir slogan yerine somut bir karşılaştırma haline geldiği yerdir. Gerçek soru, bir şeyler ters gittiğinde hangi tarafın kontrol, süreklilik ve uyum göstermesi beklendiğidir. Bu, tasarım gereği uyum tokenizasyonunun kalbidir.

Sonuç

Akıllı insanların kendiliği ikili bir rozet olarak gördüğünü, ardından bir token'ın bir taşıyıcı varlık yerine kapalı bir enstrüman gibi davrandığında şaşırdıklarını izledim. Pahalı bir yanlış anlama, özel anahtarın tüm hikaye olduğunu düşünmektir. Güvenlik token'ları ile transfer kuralları sözleşmede yer alabilir, kimlik katmanı kimin uygun olduğunu belirleyebilir ve ihraççı kurtarma veya zorunlu transfer gibi yetkileri elinde tutabilir.

Diğer tuzak, bir aracılık-dealerin dahil olduğu durumlarda ortaya çıkar. SEC'in 2020 açıklaması ve 17 Aralık 2025 Ticaret ve Pazar personelinin açıklaması, Kural 15c3-3(b)(1) hakkında aynı yöne işaret ediyor: eğer müşteri varlığı aracılık-dealerin yetkisi olmadan hareket ettirebiliyorsa, bu bir mülkiyet sorunu olarak okunur.

Bu nedenle, bir güvenlik token'ını kişisel bir cüzdana kabul etmeden önce sorulması gereken tek soru, “Bu token'ı kim hareket ettirebilir ve hangi koşullar altında?”dır.

Kaynaklar

• ABD Menkul Kıymetler ve Borsa Komisyonu
• ABD Menkul Kıymetler ve Borsa Komisyonu
• Fireblocks
• Tokeny