Hızlı kontrol: anahtarlar, imzalar ve cüzdan izinleri
GameFi’de daha sık “hesap” değil, cüzdana erişim kaybedilir: anahtarlar ve harcama izinleri (approve/permit).
- Ana risk noktası → seed/özel anahtar ve imzalar: imza = bir eyleme izin.
- Ana tuzak → “Connect wallet” ve “Approve/Permit” bir “giriş” değil, bir sözleşmeye yetki vermektir.
- Proje için hızlı filtre → denetim (rapor + sözleşme adresleri) + admin yetkileri (multisig/timelock) + ilerleme, ödül ve çekimi etkileyen bağımlılıklar (köprüler/oracle’lar/sunucu).
- 3 cüzdan kuralı → cold (saklama) / ana (aktivite) / oyun (minimum); approve limitli; etkinliklerden sonra revoke.
- Operasyonel sonuç → anahtarları ve izinleri kontrol etmek daha önemlidir: risk imza anında doğar ve oturumdan sonra da kalır.
Cüzdan = anahtarlar (erişim) + izinler (harcama hakkı). Kontrol iki seviyede de olmalıdır.
Web2 vs GameFi: güvenlikte ne değişir
Web2’de daha sık hesap ele geçirilir. GameFi’de daha sık cüzdana erişim veya bir sözleşmeye token harcama hakkı veren approve/permit izinleri ele geçirilir.
| Katman | Web2 oyunları | GameFi |
|---|---|---|
| Hedef alınan | Hesap, parola, 2FA | Seed/anahtarlar, imzalar, izinler (approve) |
| Kaybedilen | Profil ve envantere erişim | Token/NFT — çoğu zaman geri dönüş yok |
| “Kurtarma” | Destek üzerinden (parola/2FA sıfırlama) | Çoğu zaman mümkün değil: işlemler geri alınamaz |
| Her şeyin koptuğu yer | Hesabın ele geçirilmesi | Anahtar/izinlerin ele geçirilmesi veya smart contract hatası |
Pratik anlam: GameFi’ye “girmek” çoğu zaman bir eylemi imzalamak demektir. Hangi sözleşmenin ve hangi eylemin token harcama hakkı aldığı açıklanamıyorsa bu bir “login” değil, bir izin vermedir.
Kullanıcılar için tehditler
Kaybın en sık nedeni “blockchain’in kırılması” değil; token harcama hakkı veren (approve/permit) veya çekim/transferi onaylayan bir imzadır.
🎭 Phishing ve sahte siteler
Arayüz kopyalanır, benzer alan adı yapılır ve “claim/airdrop” gibi gösterilerek imzaya yönlendirilir.
- Nasıl görünür
“acil”, “sadece bugün”, “almak için onaylayın”. - Nasıl biter
harcama izni (approve/permit) verilir veya çekim imzalanır. - Ne yapmak gerekir
yer iminden girmek, domain ve ağı kontrol etmek, “DM’den support”u yok saymak.
Pratik sonuç: chat’ten gelen “claim” neredeyse her zaman tuzaktır. Güvenli ekranı resmi site/dok üzerinden bulmak daha doğru olur.
🧩 Zararlı eklentiler ve yazılımlar
Adresleri ve tıklamaları değiştirir, “benzer” pencereler gösterir, cüzdan veya faydalı bir eklenti gibi görünür.
- Nasıl görünür
gereksiz imza istekleri, garip pop-up’lar, adresin “kendiliğinden” değişmesi. - Nasıl biter
cihaz ele geçirilirse cüzdan da risk altındadır: yazılım adresleri, imzaları veya onay pencerelerini değiştirebilir. - Ne yapmak gerekir
kripto için ayrı tarayıcı profili, minimum eklenti, güncellemeler, cihaz kontrolü.
Pratik sonuç: daha çok eklenti, adres veya imza penceresinin fark edilmeden değiştirilme ihtimalini artırır.
🧾 Gereksiz izinler (approve) ve “riskli imzalar”
Sık senaryo: sözleşme token harcama hakkı alır ve izin aktif kalır.
- Nasıl görünür
unlimited approve, belirsiz sözleşme, “anlamsız” veya detay içermeyen imza. - Nasıl biter
tokenlar daha sonra gidebilir — sahipten yeni imza gerekmeden. - Ne yapmak gerekir
approve için limit koymak, düzenli revoke yapmak, cüzdanları ayırmak.
Pratik sonuç: “şu an sorun yok” demek, daha sonra harcama olmayacağı anlamına gelmez.
Tipik kayıp senaryosu: “claim” imzalanır, içinde unlimited approve vardır. İzin kalır, tokenlar daha sonra gider.
Neden: sözleşme, yeni onay olmadan token harcama hakkı almıştır.
Kullanıcı için GameFi güvenliği = cihaz + cüzdan + izinler.
Proje kaynaklı tehditler
“Dürüst” bir proje bile kod, admin yetkileri ve altyapı nedeniyle güvensiz olabilir.
🧱 Smart contract açıkları
Sözleşme mantığında, erişim yetkilerinde ve kontrollerde/limitlerde hatalar.
- Risk
kasanın boşaltılması, “havadan” token basımı, limit/koşul atlatma. - Ne kontrol edilir
denetim (rapor açık), düzeltme geçmişi, bug bounty, sözleşme sürümleri ve tarihleri. - Koruma/Standart
limitler, durdurmalar (circuit breakers), timelock, yetki minimizasyonu, rol ayrımı.
Pratik sonuç: denetim yoksa test edilen oyun değil, kod hatası riskidir.
🗝️ Admin yetkileri ve merkezileşme
Ekip kritik parametreleri değiştirebiliyorsa, kötü niyet olmasa bile risk vardır.
- Risk
ücret/kuralların değiştirilmesi, fonksiyonların dondurulması, “elle” istisnalar, gizli yetenekler. - Ne kontrol edilir
multisig, timelock, rol listesi ve her rolün yetkileri. - Koruma/Standart
kritik değişiklikler yalnızca gecikme ve kolektif imza ile.
Pratik sonuç: “kontrolsüz admin anahtarı” = kuralları istenen anda değiştirme imkânı.
🌉 Köprüler, oracle’lar ve off-chain altyapı
GameFi sıkça hibrit mimari kullanır: token ve NFT on-chain tutulur; ilerleme, maç ve ödül hesapları proje sunucusunda yapılır.
Gerçek örnek: 2022’de Ronin Bridge (Axie Infinity) hack’i yaklaşık $625 milyon kayba yol açtı — köprüler ve validator anahtarları GameFi’de en pahalı risk sınıflarından biridir.
- Risk
köprü/oracle hack’i, servisin durması, veri değişimi/manipülasyonu. - Ne kontrol edilir
ödül, sezon ve ilerleme için bağımlılıkların kritiklik düzeyi; sonuçların “hakikat kaynağı” — smart contract mı, proje sunucusu mu, oracle mı. - Koruma/Standart
çekim/işlem limitleri, durdurmalar, multisig ve kritik eylemlerde gecikme, off-chain bağımlılıkların azaltılması.
Pratik sonuç: sonuç ve ödülleri sunucu belirliyorsa “NFT cüzdanda” olmak kurtarmaz: sunucu kapanırsa NFT kalır ama oyun değeri düşer.
Projeyi 60 saniyede kontrol: (1) denetim var mı, auditor kim? (2) admin anahtarları: multisig + timelock var mı? (3) köprü/oracle/sunucu kritik mi? (4) ödül ve sezonlar için “hakikat kaynağı” neresi?
GameFi projesinde yeşil ve kırmızı bayraklar
Hızlı блок: ne endişe verici, ne güveni artırır.
✅ Yeşil bayraklar
- Denetim var → rapor açık, sözleşme adresleri verilmiş, neyin ne zaman düzeltildiği görülebiliyor.
- Admin yetkileri sınırlı → multisig + timelock, roller tanımlı ve anlaşılır.
- Bug bounty var → açık koşullar ve düzeltmelerin kamu geçmişi.
- Şeffaf mimari → neyin on-chain olduğu, neyin sunucuda olduğu, ilerleme için “hakikat kaynağı”.
- Güvenli UX → imzalar, approve ve limitler açıklanır, riskler hakkında uyarılır.
🚩 Kırmızı bayraklar
- Denetim yok → veya “yakında” deniyor ama rapor/sürüm/sözleşme adresleri yok.
- Belirsiz admin anahtarları → multisig yok, timelock yok, roller gizli veya “sözlü”.
- Unlimited approve isteniyor → nedenini açıklamadan ve güvenli alternatif (limit) sunmadan.
- Agresif getiri vaatleri → “garantili APY”, “risksiz”, “kesin kazanırsın”.
- Zayıf iletişim → “support” DM’den yazar, linkler sadece chat’ten gelir, resmi kaynak yok.
2–3 kırmızı bayrak varsa, tutarı azaltmak ve ayrı bir oyun cüzdanı kullanmak veya projeyi pas geçmek mantıklıdır.
Risk haritası
Riskleri katmanlara ayırma: kullanıcıya bağlı olanlar, projeye bağlı olanlar, dış çevre faktörleri.
| Kullanıcı katmanı | Proje katmanı | Dış faktörler |
|---|---|---|
|
|
|
En yönetilebilir riskler kullanıcı tarafıdır: cihaz, anahtarlar ve izinlere bağlıdır. Başlangıç noktası — cüzdan, cihaz ve approve/revoke.
Koruma: pratikte ne yapılır
Kısa plan: minimum adım, maksimum risk azaltımı.
- Adım 1 → ayrı bir oyun cüzdanı (üzerinde yalnızca kaybedilmesi kabul edilebilir tutar).
- Adım 2 → approve için limit (unlimited değil) ve etkinliklerden/aktif oturumlardan sonra revoke.
- Adım 3 → birikimler ayrı: cold cüzdan veya oyun bağlantısı olmayan ana cüzdan.
- Adım 4 → projeyi “4 noktada” kontrol: denetim, admin anahtarları, köprü/oracle/sunucu, ne on-chain ne değil.
Hangi sözleşmenin ve hangi eylemin token harcama hakkı aldığı açıklanamıyorsa, imza gereksizdir.
Üç şey sınırlandırılır: oyun cüzdanındaki tutar, approve limitleri ve güvenilir sitelerin listesi.
Cüzdan izinleri: approve/permit ve “unlimited”
Kayıpların sık nedeni: bir sözleşme token harcama hakkı aldı (approve) ve izin oturumdan sonra da aktif kaldı.
Approve — sözleşmeye token harcama izni belirli bir limite kadar verilir.
Unlimited approve — limiti “çok büyük” yaparak yeniden onaylamamayı amaçlar. Rahattır, ama risk daha yüksektir.
Permit — izin imza ile verilir; bazen ayrı bir on-chain işlem olmadan (token/standarta bağlıdır).
Revoke — daha önce verilen izin iptal edilir (sözleşmenin erişimi kapanır).
20 saniyelik kontrol:
- Erişim hangi sözleşmeye veriliyor?
- Limit nedir?
- Unlimited gerekli mi?
- Hemen ardından revoke mümkün mü?
Mini kontrol: imza öncesi, imza penceresinde sözleşme adresi ve eylem doğrulanır (neyin tam olarak yetkilendirildiği).
Oturum sonrası: verilen izinler (approvals) listesi açılır ve gereksiz olanlar revoke ile kaldırılır.
Approve “açık kapı”dır. Revoke, aktivite bitince kapıyı kapatmaktır.
Zaten “yanlış yere tıklandıysa”
Cüzdan şüpheli bir siteye bağlandıysa veya şüpheli bir eylem imzalandıysa uygulanacak eylem planı.
Senaryo: cüzdan bağlandı, approve/permit veya bir “onay” imzalandı ve ardından şüphe oluştu.
Şimdi yapılacaklar:
- Varlıkları önceden doğrulanmış “temiz” bir adrese taşımak (tercihen yeni/cold).
- Şüpheli sözleşmelerdeki izinleri geri almak (revoke approvals).
- Yeni bir oyun cüzdanı oluşturmak ve eskisini GameFi için kullanmamak.
- Cihazı kontrol etmek: gereksiz eklentileri kaldırmak, tarayıcı/OS güncellemek, antivirüs/tarama çalıştırmak.
- Cüzdan/Explorer üzerinden approvals listesini kontrol etmek ve tanınmayan veya kullanılmayan her şeyi revoke ile kapatmak.
Neden önemli: 2021’de saldırganlar BadgerDAO frontend’ine zararlı script enjekte etti ve “yerleştirilmiş” bir onayla bazı kullanıcıların fonlarını çıkardı. Şüpheli bir imzadan sonra en güvenilir adım — varlıkları taşımak + revoke.
Hızlı test: “bu sözleşme nedir ve neden erişim istiyor” açıklanamıyorsa, erişim gereksizdir.
Kural: şüpheli imzada cüzdanı “kompromize” kabul etmek ve taşınmak mantıklıdır.
FAQ
GameFi’de yeni başlayan için en tehlikeli şey nedir?
En tehlikelisi — neyin yetkilendirildiğini anlamadan imzalamaktır. Bu çoğu zaman unlimited approve, permit imzaları ve belirsiz sözleşmelere giden işlemlerdir. Minimum hızlı koruma: ayrı oyun cüzdanı + approve limitleri.
Denetim güvenlik garantisi midir?
Hayır. Denetim riski azaltır, ancak projeyi “güvenli” yapmaz. Ek olarak şunlar kontrol edilir: admin anahtarlarını kim tutuyor, multisig + timelock var mı, bug bounty var mı ve oyunun kritik bağımlılıkları neler (köprüler, oracle’lar, sunucu tarafı).
Her şey “çalışıyorken” neden revoke approvals yapılır?
Çünkü approve oturumdan sonra da geçerlidir. “Şu an her şey normal” olsa bile izin daha sonra kullanılabilir: sözleşme açık verir, güncellenir veya approve yanlış adrese verilmiş olabilir. Revoke, aktivite bitince “kapıyı kapatmaktır”.
NFT’nin cüzdanda olması “güvende” olmak anlamına gelir mi?
NFT sahipliği kanıtlar, ancak fayda garantisi vermez. İlerleme, kurallar veya ödüller sunucuya bağlıysa oyun kapanabilir; NFT kalır ama eski anlamını kaybeder.
Çalınan fonlar geri alınabilir mi?
Çoğu zaman hayır: işlemler geri alınamaz. Bu yüzden savunma stratejisi — önleme (anahtarlar, cihaz, izinler) ve “hot” oyun cüzdanındaki tutarı sınırlamaktır.
Bir projenin aşırı riskli olduğu hızlıca nasıl anlaşılır?
Risk sinyalleri: denetim/rapor yok, admin anahtarlarını kimin tuttuğu belirsiz, çok sayıda merkezileşmiş kontrol, agresif getiri vaatleri, unlimited approve talebi ve tuhaf imzalar. 2–3 sinyal varsa tutarı azaltmak veya projeyi pas geçmek mantıklıdır.
Final plan: riski gerçekten azaltan 3 kural
GameFi’de korunması gereken “hesap” değil, iki şeydir: anahtarlar ve verilen izinler.
- Kural 1 → 3 cüzdan: cold (saklama) / ana (aktivite) / oyun (minimum tutar).
Eylem: oyun cüzdanında yalnızca kaybedilmesi kabul edilebilir tutar tutulur. - Kural 2 → approve yalnızca limitli. Unlimited bir istisnadır, standart değil.
Eylem: limit “işe göre” konur, “her şeye” değil. - Kural 3 → aktivite sonrası revoke: etkinlik bitti / oyun kapandı — erişim kapandı.
Eylem: haftada bir ve etkinliklerden sonra approvals temizlenir.
İmza öncesi kontrol (10 saniye):
- Ne tam olarak yetkilendiriliyor?
- Erişim kime veriliyor (hangi sözleşme)?
- Limit nedir ve hemen ardından revoke mümkün mü?
Anahtarlar erişim sağlar, approve harcama hakkı verir. Kayıplar çoğu zaman ikincisiyle başlar.