Auto-Freeze ve Default Frozen: Çoğu Launch'ın Atladığı Kontrol Katmanı

Solana operatör sohbetlerinde "auto-freeze" terimi sık geçer ve çoğu zaman konuşan iki kişi aynı kelimeyi tamamen farklı iki şey için kullanır. Birincisi token doğarken bir kez seçilen ve sonsuza kadar kalan bir ayardır. İkincisi ise token yaşadıkça çalışan, her yeni cüzdan için ayrı bir karar üreten bir işletim akışıdır. İkisini birbirine karıştıran bir RWA projesi, lansmanı bitirir, optik iyi görünsün diye dondurma yetkisini siler, altı ay sonra yeni bir alıcının cüzdanının kalıcı olarak kilitli kaldığına dair destek talebiyle uyanır. Bu yazı iki katmanı ayırır, hangi senaryoda gerçekten oturduklarını gösterir, çoğu lansmanın bu yoldan neden uzak durduğuna bakar.

Önce bir benzetme. Default-frozen launch dediğimiz şey, üyelik kartını dağıtırken her kartı plastik içinde mühürlü göndermeye benzer. Kart sahibi kartı eline alır, evine asar, hatta arkadaşına gösterir, ama plastik mühür açılmadan kartla içeri girilemez. Mührü açma yetkisi sadece kapıdaki görevlide olur. Görevli sırayla insanları kontrol eder, listede olanların plastiğini keser, geri kalanı bekletir. Token tarafında "kart" cüzdandaki bakiyedir, "plastik mühür" dondurulmuş durumdur, "kapıdaki görevli" ise dondurma yetkisini elinde tutan operatördür.

İki mekanizma, tek isim

Birinci mekanizma Token-2022 sisteminin "donmuş doğsun" ayarıdır. Solana'nın yeni token sistemi olan Token-2022, klasik token sistemine göre yeni özellikler getiren bir ek katman barındırır; bu yazıdaki ayar onlardan biridir. Mint yaratırken bu ayarı açarsan, o token için açılan her yeni cüzdan otomatik olarak dondurulmuş halde doğar. Sahibi tek birim bile transfer edemez, dondurma yetkisi elinde olan operatör eritene kadar. Bu davranış token'ın DNA'sına yazılır, sonradan ne eklenebilir ne de çıkarılabilir.

İkinci mekanizma ise işletim katmanıdır. Yeni cüzdanları izleyen, kurallara göre erit komutu veren veya kararı insana ileten bir akıştır. j.tools'ta bu akışın aracı otomatik freeze işletim aracı olarak duruyor, şu anda yayın öncesi listede. Bu katman herhangi bir token için çalışır, klasik token mu Token-2022 mü olduğu fark etmez, koşul sadece dondurma yetkisinin operatörde kalmasıdır.

"Donmuş doğsun" ayarı pratikte ne yapar

Mint yaratırken bu ayarı seçtiğinde, ilk cüzdan dahil hiç kimse dondurma yetkisinden erit komutu almadan o cüzdanı kullanamaz. Erit komutunu sadece operatör verebilir. Önemli bir incelik var: bir cüzdan eritildikten sonra eritili kalır, operatör açıkça yeniden dondurmadıkça. Yani ayar doğuş anında etkilidir, geriye dönüp eski cüzdanları kendiliğinden yeniden dondurmaz. Eski bir cüzdanı yeniden kapatmak istersen tek tek elle dondurman gerekir, bunun için tekil hesap freeze aracı doğrudan iş görür.

Bu ayarı kullanmak istiyorsan tokeni Token-2022 üzerinde yaratman lazım, klasik token sistemine sonradan eklenemez. j.tools'ta giriş noktası Token-2022 mint oluşturma aracı. Karar token doğarken verilir; sonradan geri dönüş yoktur.

İşletim katmanı yükü neden taşır

Tek başına "donmuş doğsun" ayarı bir lansman stratejisi değildir. Çünkü her yeni cüzdan için "eritsek mi, beklesek mi, ret mi" kararı vermek gerekir. Bu kararı binlerce kişi için elle vermek operatörün gününü yer. İşletim katmanı bu yükü taşımak için var. Akış basit haliyle şu mantıkta çalışır: yeni bir cüzdan açıldığında bir kural seti tetiklenir. Kural KYC sağlayıcısından yeşil ışık alıyorsa erit. Gri liste ise operatöre bildir. Yaptırım listesinde ise dondurmaya devam et ve ret kaydı tut. Otomatik freeze işletim aracı bu kuralı dış sistemlerin onayıyla işletir.

Beş meşru kullanım senaryosu

"Donmuş doğsun" ayarına karşı varsayılan refleks "merkeziyetçi, kötü" şeklinde işler, ki bu okuma yanlış. Aşağıdaki beş senaryo bu kontrol katmanının gerçek anlamlı kullanıldığı yerleri gösterir.

Senaryo	Neden oturur	Optik maliyet
Gerçek dünya varlığı tokenı (RWA) ile KYC	Erit adımı kimlik doğrulamanın ta kendisidir; doğrulamadan transfer yok	Hedef kitle zaten merkezi yapıyı bekliyor, maliyet düşük
Hukuken kısıtlı menkul kıymet tokenı	Yaptırım listeleri ve coğrafi kısıtlar erit kararından geçer	Uyum maliyetine kıyasla optik önemsiz
Snipera karşı meme lansmanı	İlk 5 ila 15 dakikadaki bot hesaplarını süzer, ardından toplu erit	Yüksek; perakende topluluk dondurma yetkisini sevmez
Vesting cliff zorlaması	Yatırımcı tahsisleri donmuş cüzdanlara basılır, cliff tarihi erit tarihidir	Düşük; yatırımcı tarafı kontrolü zaten kabul eder
Lansman öncesi takım dağıtımı	Özel anahtarlar sızsa bile kimse satış başlamadan satamaz	Çok düşük; sadece iç süreç

Bu beş kategorinin dışında üçüncü taraf uyum partnerleriyle entegre olan farklı varyantlar da var, ancak çekirdek mantık aynı kalır: erit komutu, zincir dışı bir kararın zincir üstü ifadesidir. Konuyu daha derinden incelemek istersen operatör rehberleri kategorisi kontrol katmanlarına dair pratik incelemeleri kapsar.

Çoğu lansman neden bu yoldan uzak durur

Beş senaryo ne kadar meşrusa, perakende odaklı çoğu lansmanın bu yoldan kaçınmasının sebepleri de o kadar gerçektir. İlk neden borsa toplayıcı filtresidir. Jupiter ve Raydium gibi ön yüzler, dondurma yetkisi canlı ve "donmuş doğsun" ayarı açık tokenlerde kullanıcıların "transfer edemiyorum" hatasıyla karşılaşmasını istemez. Token teknik olarak yaşar ama yönlendirme zayıflar. Listeleme bekleyen bir lansman için bu fiili bir bariyerdir.

İkinci neden optiktir. Holder Solscan'ı açar, dondurma yetkisini görür, doğuş hali ayarını fark eder ve "takım bakiyemi kilitleyebilir" diye okur. Niyet ne kadar masum olursa olsun bu okuma lansman hikayesini boğar. Üçüncü neden ekosistem kapsamıdır; Token-2022 zaten klasik token sistemine göre daha dar cüzdan, gezgin ve borsa desteğine sahiptir; üstüne "donmuş doğsun" ayarı koymak entegrasyon yüzeyini bir kez daha daraltır. Dördüncü neden işletim yüküdür. Beşincisi merkezi borsa listeleme süreci; çoğu borsa listeleme ekibi dondurma yetkisi canlı tokenlere yatırım yapmaz.

Tuzak: "serbest bıraktım" yanılgısı

"Donmuş doğsun" tokeni açıp ilk holder dalgasını erittikten sonra "artık ademi merkezi olalım" diyerek freeze yetkisi iptal aracı üzerinden bu yetkiyi yakarsan, yeni cüzdanlar hâlâ donmuş doğmaya devam eder. Ama artık kimse onları eritemez. Altı ay sonra senin tokenini transfer almaya çalışan yeni bir alıcı kalıcı olarak kilitli kalır. Bu tuzak gerçek RWA projelerini vurdu.

Aynı problem tüm yetkileri iptal aracı için de geçerlidir. Tüm yetkileri tek seferde iptal etmek doğuş hali ayarını söndürmez, sadece kimse o ayarı yönetemez hâle gelir. Eğer "donmuş doğsun" ile çıktıysan ve gerçekten serbest dolaşımlı bir token istiyorsan sıra şudur: önce var olan tüm holderları eritirsin, sonra basım yetkisini kapatırsın, en son dondurma yetkisini iptal edersin. Aksi takdirde tokenin yarı ömrü vardır.

"Kalıcı vekil" ayarıyla karışıklığı

Token-2022 dünyasında sık karıştırılan bir başka ayar "kalıcı vekil"dir (permanent delegate). Bu ayar, belirlenmiş bir yetkilinin herhangi bir holder cüzdanından token çekebilmesine izin verir. İkisi farklı problemleri çözer. "Donmuş doğsun" kim transfer edebilir sorusunu kontrol eder, bekletme uygular. "Kalıcı vekil" ise bakiyeyi sahibinin rızası olmadan dışarı taşımaya açar. Uyum açısından "kalıcı vekil" daha ağır bir kontroldür çünkü holderın irade dışı tahliyesine kapı açar. "Donmuş doğsun" sadece "henüz dolaşıma giremezsin" der.

j.tools üzerinde tam akış

"Donmuş doğsun" ile bir lansman sürecini j.tools'ta uçtan uca kurmak istersen sıra basittir. Önce Token-2022 mint oluşturma aracı ile tokeni doğuş hali açık yaratırsın, dondurma yetkisi operatör cüzdanında durur. Ardından otomatik freeze işletim aracı üzerinden kural setini bağlarsın (KYC sağlayıcısı, yaptırım listesi, gri liste mantığı). Ad-hoc müdahaleler için tekil hesap freeze aracı ve tekil hesap erit aracı elinde kalır. Belirli aralıklarla holder snapshot aracı ile dondurma durumunu denetlersin. Tokeni tamamen serbest bırakmaya karar verdiğin gün, tüm aktif holderları erittikten ve basım yetkisini kapadıktan sonra dondurma yetkisini iptal edersin.

Somutlaştırmak için bir örnek: gayrimenkul gelirlerini paylaşan bir RWA tokeni çıkarıyorsun. Holder talep formunu doldurur, tokeni cüzdanına alır, cüzdan donmuş halde doğar. Operatör KYC raporunu inceler, listede olduğunu görür, erit komutunu gönderir. Holder o andan itibaren tokeni özgürce transfer edebilir. Listede olmayan bir cüzdan tokeni alır ama hiçbir zaman kullanamaz, çünkü hiç eritilmez. Bu akış doğru kurulduğunda operatör hem mevzuat sorumluluğunu yerine getirir hem de eline geçen her cüzdanı tek tek incelemeden işi otomatize eder.

"Donmuş doğsun" ayarı, uyum veya lansman kontrol enstrümanı olarak çok güçlüdür, ancak merkeziyet maliyeti açıktır. Karar her iki tarafı da göz önüne alarak verilir; bir kez token yarattıktan sonra geri dönüş yoktur. Solana etiketli yazılar arşivi kontrol katmanlarına dair diğer pratik incelemeleri kapsar.

---

Freeze authority nedir ve neden korkutucu görünür

Freeze authority, bir Solana tokeninde tek bir cüzdana verilen yetkidir: o yetkiyi elinde tutan adres, herhangi bir holderın token hesabını dondurabilir. Dondurulan hesap bakiyeyi görür ama tek birim bile transfer edemez, ta ki aynı yetki onu tekrar eritene kadar. Yetki token doğarken atanır; operatör isterse onu bir cüzdanda tutar, istemezse tamamen yakar.

Korkutucu görünmesinin sebebi basit. Bir holder Solscan'da tokenin freeze authority alanını dolu görünce, "demek ki birileri benim bakiyemi her an kilitleyebilir" diye okur. Bu okuma teknik olarak doğrudur. Ama yetkinin var olması ile kötüye kullanılması aynı şey değildir. Yukarıda anlatılan beş senaryoda yetki, kötü niyetten değil mevzuat veya bot süzme ihtiyacından canlı tutulur. Buna karşılık serbest dolaşımlı bir meme tokeninde freeze authority'nin canlı durması gerçekten bir uyarı işaretidir, çünkü o tokenin böyle bir yetkiye meşru bir ihtiyacı yoktur.

Kısa ayrım: freeze authority bir hesabı dondurma yetkisidir. mint authority yeni token basma yetkisidir. update authority tokenin adını ve görselini değiştirme yetkisidir. Üçü ayrı yetkidir ve ayrı ayrı yakılır; biri canlı diye diğeri de canlı sanılmamalı.

Auto-freeze kullanan bir token güvenli mi: alıcı kontrol listesi

Bir tokeni almadan önce freeze tarafını birkaç dakikada kabaca okuyabilirsin. Token-2022 mü klasik SPL mi olduğunu, freeze authority'nin canlı olup olmadığını ve defaultAccountState ayarını holder snapshot ve analiz aracıyla ya da bir zincir gezgininde tek bakışta görürsün. Aşağıdaki sorular kararı netleştirir.

• Bu tokenin freeze yetkisine meşru bir ihtiyacı var mı? RWA, KYC gerektiren menkul kıymet veya kurumsal dağıtım ise mantıklıdır. Sıradan bir topluluk memecoini ise değildir.
• Cüzdanlar donmuş mu doğuyor? defaultAccountState=Frozen açıksa, aldığın token cüzdanına donmuş düşebilir ve operatör eritene kadar satamazsın. Likidite sağlamayı düşünüyorsan bu doğrudan seni etkiler.
• Operatör kimliğini ve kural setini açıklamış mı? Hangi durumda erit, hangi durumda dondur kararının nasıl verildiği belgeliyse risk öngörülebilirdir. Hiçbir açıklama yoksa, dondurma keyfi olabilir.
• Erit yolu işliyor mu? Yukarıdaki "serbest bıraktım" tuzağı tam burada ısırır: freeze yetkisi yakılmış ama defaultAccountState hâlâ Frozen ise, yeni cüzdanlar donmuş doğar ve artık kimse onları eritemez. Böyle bir token transfer için ölü doğmuştur. Küçük bir test alımı yapıp transferin gerçekten çalıştığını görmek bu durumu erken yakalar.

Pratik kural: freeze authority'nin canlı olması tek başına ne "güvenli" ne "dolandırıcılık" demektir. Tokenin niyetiyle birlikte okunur. Net bir uyum hikayesi olan bir RWA tokeninde canlı yetki tasarımın parçasıdır; hikayesi olmayan bir tokende ise satış engelleme veya honeypot riskinin habercisidir. İkinci durumda, operatörün yetkiyi kalıcı olarak yakıp yakmadığı (freeze yetkisini iptal edip etmediği) en belirleyici sinyaldir.