DeFi güvenliği neden her şeyi belirler
DeFi hızla büyüyor; saldırılar da onunla birlikte büyüyor. Smart contract hatalarından arayüz ve köprülerin ele geçirilmesine kadar açıklar yalnızca kodda değil, protokol ekonomisinde ve kullanıcı davranışında da ortaya çıkar. Bu yüzden “bir şey olmaz” yaklaşımı artık çalışmaz: güvenlik tek seferlik bir olay değil, sürekli bir süreçtir.
Bu materyalin amacı: önce temel riskleri (teknik, ekonomik ve sosyal) yapılandırmak; sonra önemli vakaları incelemek; son olarak ekipler ve kullanıcılar için somut koruma pratikleri vermek.
DeFi güvenliği nelerden oluşur
Kod: smart contractlar, kütüphaneler, derleyiciler, upgrade proxyleri.
Protokol ekonomisi: tokenomics, likidasyon kuralları, oracle’lar, piyasa parametreleri.
Arayüzler ve DevOps: site/frontend, admin anahtarları, CI/CD, altyapı sağlayıcıları.
İnsan katmanı: kullanıcılar, moderatörler, geliştiriciler, karşı taraflar ve operasyonel prosedürler.
Güvenlik metrikleri ve SLO
| 🧭 Metrik | 🎯 Hedef (SLO) | 📐 Nasıl hesaplanır | 🛠️ Sapma olursa ne yapılır |
|---|---|---|---|
| ⏱️ Time-to-Patch (TTP) | ≤ 48 saat (kritik) | Rapor ile fix release arasındaki Δ |
|
| 🔎 Denetim kapsamı | Kritik kodun ≥ %95’i | Release içindeki kritik modüllerin LOC değeri |
|
| 🚨 MTTD / 🧯 MTTR | MTTD ≤ 10 dk; MTTR ≤ 2 saat | Alarm/stop olay logları |
|
| 🏴 Bug bounty sağlığı | White hat’lerden çeyrek başına ≥ 1 kritik | Immunefi/Code4rena raporları |
|
| ⏸️ Pause kapsamı | Kritik fonksiyonların %100’ü pauselenebilir | Piyasalara göre pause() indeksi |
|
Olgunluğun temel göstergeleri
- TVL ve dinamik: yalnızca mutlak değer değil, dayanıklılık da önemlidir. Ani sıçramalar/çıkışlar kaynakları incelemek için sebeptir.
- Denetimler ve bug bounty: herkese açık raporlar, remediation SLA, white hat aktivitesi.
- Yönetim ve yetkiler: timelock, multisig yapısı, ekip/yatırımcı vestingi, DAO quorumları.
- Rezervler ve sigorta: sigorta havuzları/poliçeleri, “kara gün” fonları, şeffaf rezervler.
- Track record: yaş, post-mortem kalitesi ve projenin stresleri nasıl atlattığı.
Güvenlik olgunluk modeli
| 🪜 Seviye | 📌 Özellikler | ➡️ Sonraki adım |
|---|---|---|
| ❌ L0 “Şansa bırakılmış” |
|
Multisig, temel denetim, bug bounty |
| 🟡 L1 “Temel” |
|
2x denetim, pause mekanizmaları, on-chain izleme |
| 🟢 L2 “İleri” |
|
Red-team simülasyonları, IR runbook |
| 🏆 L3 “Secure by default” |
|
Bağımsız pentestler, seviyeyi koruma |
Tehdit haritası (özet)
| 🧩 Kategori | 🔎 Alt tür | ⚠️ Risk | 🎯 Ne bozulur | 🛡️ Temel koruma |
|---|---|---|---|---|
| ⚙️ Teknik | Reentrancy, overflow, erişimler | 🔴 Yüksek | Contract mantığı |
|
| ⚙️ Teknik | Flash loan, MEV/front-running | 🔴 Yüksek | 1 blok içindeki invariantlar |
|
| 📉 Ekonomik | Fiyat/oracle manipülasyonu | 🔴 Yüksek | Teminat değerlemesi |
|
| 📉 Ekonomik | Governance saldırıları | 🟠 Orta-yüksek | Hazine/ayarlar |
|
| 🎭 Sosyal | Phishing, sahte siteler, airdrop tokenları | 🔴 Yüksek | Anahtarlar/imzalar |
|
| 🛠️ Altyapı | UI/DNS/CDN veya anahtar hack’i | 🔴 Yüksek | Frontend/erişimler |
|
| 🔗 Cross-chain | Bridge exploitleri | 🔴 Kritik | Vault/validatörler |
|
| 🧨 Scam | Rug pull, exit scam, honeypot | 🔴 Yüksek | Likidite/yetkiler |
|
Smart contract teknik zafiyetleri
Reentrancy ve durum hataları
Klasik örnek: contract, bakiyeler güncellenmeden önce harici çağrının aynı fonksiyona tekrar girmesine izin verir. Sonuçta saldırgan fonları defalarca “boşaltır”. Bu yüzden Checks-Effects-Interactionskalıbını kullanır, ReentrancyGuardekler ve daha iyisi, kritik bölümlerde harici çağrıları en aza indiririz.
Erişim kontrolleri ve upgrade proxyleri
Yanlış yapılandırılmış admin/operatör rolleri ve “delikli” proxy contractlar çoğu zaman tam kompromiye yol açar. Buradan minimum yetki ilkesi, rol ayrımı (admin/operatör/pauser), update’ler için timelock ve tüm upgrade yollarının denetimi gelir.
Flash loanlar ve “tek blok” invariantları
Anlık krediler tek başına nötrdür; ancak invariantlar yalnızca final durumuna göre kontrol edildiğinde saldırıları güçlendirir. Bu nedenle TWAP fiyatları, post-condition kontrolleri ve işlem serisi sonrasında “sanity” kontrolleri, ayrıca tek bir işlemin “gücüne” limitler yardımcı olur.
MEV ve front-running
Açık mempool, DEX’lerde “sandwich” için fırsat yaratır. Bu nedenle büyük işlemlerde özel mempool/relay uygundur; protokol tarafında ise batch auction, yayın gecikmesi gibi koruyucu mekanikler yardımcı olur.
Smart contract threat modeling: hızlı şablon
Aktörler: kullanıcı, liquidator, arbitrajcı, admin/DAO, oracle, bridge, harici contractlar.
Invariantlar: kim, hangi koşullarda hareket ettirebilir bakiye/parametreyi? post-condition var mı?
Yüzey: harici çağrılar, upgrade/proxy, roller, oracle, pause/no-pause, blok başına limitler.
Kötüye kullanım: reentrancy, flash-loan kompozisyonları, MEV, ince likidite.
Koruma: CEI, ReentrancyGuard, timelock, multisig, TWAP/çoklu kaynaklar, limitler, pause.
Ekonomik saldırılar ve manipülasyonlar
Fiyat manipülasyonu ve oracle’lar
“Gerçeğin kaynağı” oynatılabiliyorsa oynatılır. Düşük likidite, oracle olarak kendi havuzları, TWAP/çoklu kaynak eksikliği — bunların hepsi saldırı davetidir. Bu yüzden güvenilir oracle seçer, egzotik tokenları teminat olarak sınırlı kullanır ve “sapma limiti” koyarız.
Governance saldırıları
Flash loan + anlık quorum = DAO’nun bir blokta ele geçirilmesi. Başkalarının hatalarını tekrarlamamak için karar yürütmeye timelock koyar, flash loan ile alınmış oyları dışlar ve tartışma süresiyle gerçek quorum isteriz.
MEV: mempool nasıl sömürülür
- Sandwich saldırıları: bot sizin emrinizden önce varlığı alır, fiyatı yükseltir ve hemen sonra satar — siz daha kötü fiyattan ödersiniz.
- Front-run/back-run: kârlı arbitrajların ve likidasyonların dahil edilme önceliğiyle yakalanması.
- TWAP/oracle back-running: fiyatı güncelleme “penceresinde” istenen seviyeye itmek.
Bridge’ler ve cross-chain riskler
- Mesaj doğrulama: doğrulama/state-proof zafiyetleri → alıcı/sahip değiştirme.
- İmza merkezileşmesi: küçük M-of-N quorumları ve validatörlerin zayıf operasyonel güvenliği.
- Operasyonel hatalar: yanlış update’ler, başlatılmamış parametreler, eski bağımlılıklar.
Frontend ve DevOps hardening
- CSP + SRI: tüm scriptler için sıkı Content-Security-Policy ve Subresource Integrity.
- HSTS/DNSSEC: zorunlu HTTPS ve korumalı DNS bölgeleri.
- Adminler için 2FA/SSO: CDN/Git/CI erişimi SSO üzerinden; anahtarlar yalnızca donanım (FIDO2).
- Secrets yönetimi: token rotasyonu, “minimum yetki”, deny-by-default.
- Frontend diff izleme: bundle/DOM değişikliği için alarm; RPC domain whitelist.
Vakalar: koruma nerede ve nasıl kırıldı
Curve Finance (2023): Vyper derleyicisindeki bug reentrancy guard’ı kırdı ve havuzların tekrar çağrılarla boşaltılmasına izin verdi.
Ronin Bridge (2022): 9 validatörden 5’inin kompromisi (phishing + fazla erişim) devasa çekimleri yetkilendirmeye izin verdi.
Mango Markets (2022): kendi tokenının ince likiditeli fiyatının manipülasyonu, teminat “değerini” yükseltti ve tüm fonların çekilmesine izin verdi.
Euler (2023): donateToReserves etrafındaki mantık bug’ı “kötü borç” oluşturmayı ve flash loan işlemleriyle teminatları kademeli çekmeyi mümkün kıldı.
Beanstalk (2022): flash-loan oylarıyla anlık oylama rezervleri aynı blokta saldırgan adresine taşıdı.
BadgerDAO (2021): frontend kompromisi fazladan Approvegösterdi, ardından fonlar toplu şekilde çekildi.
bZx (2021): geliştirici phishing’i → seed hırsızlığı → contractların yeniden imzalanması ve varlıkların birkaç ağda çekilmesi.
Poly Network (2021): cross-chain mesaj doğrulama hatası, coffer sahibinin değiştirilmesine izin verdi.
Koruma yöntemleri: çok katmanlı yaklaşım
Denetim, testler ve bug bounty
Önce denetim ve doğrulama ile “kolay” bugları temizleriz; sonra saldırıları modelleriz; son olarak topluluğu bug bounty ile dahil ederiz.
- Çok aşamalı denetim: dış firmalar + iç review; derleyici/kütüphane sürümlerini sabitleme; zafiyetli release block listi.
- Formal doğrulama: bridge’ler, treasury, upgrade hatları; tipik saldırı simülasyonları (reentrancy, flash loan, MEV).
- Bug bounty: büyük ödüllü herkese açık program; ikinci savunma hattı ve proje olgunluğu sinyali.
Yetki mimarisi: timelock, multisig, minimum ayrıcalık
Tek bir hata veya tek bir anahtarın toplam kayba yol açmaması için tasarlarız.
- Timelock: kullanıcı fonlarını etkileyen tüm değişiklikler için gecikme.
- Multisig: hazine ve admin fonksiyonları M-of-N ile; roller için ayrı anahtarlar (admin/operatör/pauser).
- Limitler ve cap’ler: işlem/blok başına hacim, emisyon/borç cap’leri, pause sonrası anlık “yeniden açma” yasağı.
İzleme ve “acil durdurma”
TTD/MTTR’yi kısaltırız: hızlı fark et — hızlı durdur — hızlı düzelt.
- On-chain alarmlar: anormal bakiyeler, toplu Approve, büyük tranche’ler, TVL/fiyat sıçramaları.
- Pause: piyasa/contract seviyesinde pause mekanizmaları; önceden atanmış “acil pauser”.
- Mempool gözlemi: exploit/MEV imzaları ve yanıt prosedürü (kim, ne zaman “stop vanasını” çeker).
Sigorta ve harici koruma servisleri
Güçlü korumada bile sıfır risk yoktur — bu yüzden “tampon” ve kurtarma süreçleri gerekir.
- Merkeziyetsiz sigorta: Nexus Mutual, InsurAce, Sherlock vb. — protokol ve kullanıcılar için kapsam.
- Risk analitiği ve rezervler: harici risk sağlayıcıları, “kara gün” fonları, herkese açık post-mortemler ve tazminat politikası.
Hızlı kazanımlar (ekip için):
- Tüm kritik değişiklikler için timelock ve multisig’i açın.
- Bug bounty ve white-hat iletişim kanalını yayınlayın.
- On-chain alarmları ve “acil durdurma” prosedürünü kurun.
- Arayüzde tüm infinite approve kullanımını sınırlayın ve eski izinleri gözden geçirin.
Olay yanıt runbook’u
- Tespit: alarm/rapor tetikleyicisi → on-call atamak ve timeline loglamak.
- Zarar sınırı: çağırmak
pause()/piyasaları sınırlamak; topluluklara/exchange’lere bildirmek. - Analitik: durum snapshot’ı, modül izolasyonu, exploit’in fork üzerinde yeniden üretilmesi.
- İletişim: hacker’a on-chain mesaj, bug bounty teklifi, her N saatte bir herkese açık update.
- Fix ve release: emergency timelock yolu ile hot patch; patch’in bağımsız kontrolü.
- Restart ve post-mortem: aşamalı unpause, rapor, tazminatlar/sigorta ödemeleri, SLO iyileştirmesi.
Şablon: “T+7 dk’da tespit → T+18 dk’da pause → T+4 saatte fix v1.1 → 24 saat sonra limitli unpause”.
İzleme ve alarm stack’i
| 🔔 Sinyal | 🧰 Araç | 🎚️ Eşik | 🛟 Eylem |
|---|---|---|---|
| 🧾 Anormal Approve | On-chain botlar | 5 dk içinde ≥ X |
|
| 📈 Fiyat/TVL sıçraması | Oracle + TWAP | Δ > Y% / 1 dk |
|
| 🧪 Şüpheli deploy’lar | CI/Git denetimi | Release branch dışı diff |
|
| ⚡ MEV imzaları | Mempool gözlemcisi | Pattern eşleşmesi |
|
Anti-MEV: ne çalışır ve ne zaman
| 🧩 Teknik | 🛡️ Nasıl yardım eder | 📌 Ne zaman uygulanır |
|---|---|---|
| 🔒 Özel mempool/relay | Tx’leri “sandwich”ten gizler | Büyük işlemler/hassas operasyonlar |
| 🧮 Batch auction / CoW modeli | Emirleri birleştirir, front-run’ı dengeler | Yüksek aktiviteli DEX/agregatörler |
| ⚙️ Düşük slippage + TWAP | Sandwich penceresini daraltır | Kullanıcı swapları/stratejileri |
| 🎲 Randomized delay | Tahmin edilebilirliği azaltır | “Pik” zafiyetli protokoller |
Stablecoinler ve tokenomics kusurları
UST/LUNA çöküşü, algoritmik bir stablecoin’in peg’i ne kadar hızlı kaybedip ekosistemi “ölüm sarmalına” çekebileceğini gösterdi. Ayrı bir sorun da sürdürülebilir gelir kaynağı olmayan “sihirli” APY’lerdir.
- Kontrol edilecekler: rezervler ve yapısı, redemption kuralları, stres testleri.
- Protokoller için pratik: riskli stablecoinleri teminat olarak kullanmaya cap; depeg halinde devre dışı bırakma.
- Kullanıcı için pratik: stablecoin çeşitlendirmesi ve tek pozisyona limitler.
Likidite ve “bank run”lar
- Semptomlar: anormal spread/slippage, havuzların “kuruması”, uzun çekim kuyrukları.
- Karşı önlemler: tek seferlik çekim limitleri, dengesizlikte dinamik ücretler, harici kredi hatları, sigorta fonları.
- Kullanıcıya tavsiye: büyük işlemleri bölün, TVL ve teminat oranlarını izleyin.
Piramit APY ve rug pull
- Red flag’ler: anonim ekip, agresif pazarlama, vesting/denetim yok, likidite kontrolü kurucuda.
- Pratik: küçük tutarlarla başlamak, smart contract/audit okumak, token dağılımını kontrol etmek.
Insider’lar ve yetki yoğunlaşması
- Riskler: tekil admin anahtarları, dar multisigler, upgrade/pause için “süper yetki”, koddaki arka kapılar.
- Koruma: dağıtılmış multisig quorumları, rol ayrımı, hassas işlemlerde timelock, herkese açık post-mortemler.
Regülasyon ve itibar riskleri
- Önlem: alternatif frontendler, açık kaynak kod, şeffaf rezervler, merkezi sağlayıcılara ölçülü bağımlılık.
- İletişim: düzenli raporlar, olayların dürüst analizi, anlaşılır tazminat politikası.
DeFi kullanıcısı için güvenlik checklisti
- Hardware wallet ve PIN kullanın; seed’i offline saklayın.
- Yalnızca resmi linklerden gidin; daha iyisi, yer imlerinden.
- Her işlemi okuyun: özellikle Approve ve şüpheli çağrıları.
- İzinleri sınırlayın ve düzenli revoke yapın (Revoke servisleri).
- Çeşitlendirin: uzun vade ve aktif işlemler için ayrı cüzdanlar.
- Denetimi olmayan yeni protokollerde ve bridge’lerde büyük tutar tutmayın.
- Alarm aboneliği kurun: adresiniz/protokolünüz için bir izleme botu.
- Unutmayın: “fazla kârlı” neredeyse her zaman risklidir.
“Tehdit → koruma” matrisi
| ⚠️ Tehdit | 📌 Örnek | 🔓 Zafiyet | 🛡️ Koruma |
|---|---|---|---|
| ♻️ Reentrancy | Curve (2023) | Bakiye güncellenmeden tekrar çağrı | CEI kalıbı, ReentrancyGuard, harici çağrıları yasaklama |
| ⚡ Flash loan | Euler (2023) | Invariantlar bir blokta kırılır | TWAP/cap limitleri, post-condition, tx “gücü” limiti |
| 🎯 Fiyat manipülasyonu | Mango (2022) | İnce likidite, “ev yapımı” oracle | Güvenilir oracle’lar, çoklu kaynaklar, teminatta egzotik yasağı |
| 🗳️ Governance saldırısı | Beanstalk (2022) | Anlık yürütme, flash loan oyları | Timelock, flash-loan oy filtresi, quorum/tartışma |
| 🎭 Phishing/sosyal mühendislik | bZx (2021) | Seed hırsızlığı → admin anahtarlarına erişim | Operasyonel güvenlik, multisig, ayrı roller/cihazlar |
| 🖥️ UI hack’i | BadgerDAO (2021) | Kötü niyetli script fazladan Approve | 2FA/SSO, diff izleme, “sonsuz” izinleri revoke |
| 🔗 Bridge exploit’i | Poly (2021), Ronin (2022) | Zayıf mesaj doğrulama/imza merkezileşmesi | Multisigler, limitler, formal kontroller, update denetimi |
| 💸 Stablecoin depeg | UST/LUNA (2022) | Algoritmik peg, kırılgan tokenomics | Rezervler/stres testleri, teminat cap’leri, otomatik kapatma politikaları |
| 🏦 Likidite krizi | Dengesiz havuzlar | Çekim yoğunlaşması/ince likidite | Çekim limitleri, değişken ücretler, harici hatlar |
| 🕵️ Insider/admin anahtarı | — | Tekil yetkiler/dar multisigler | Rol ayrımı, timelock, dağıtılmış quorumlar |
| 🏛️ Regülasyon şoku | Frontend blokajı | Merkezi servislere bağımlılık | Alternatif UI’lar, merkeziyetsiz RPC, şeffaflık |
| 🧨 Rug pull / honeypot | AnubisDAO ve diğerleri | Likidite/kurucu yetkisi kontrolü | Denetim, havuz şeffaflığı, “körü körüne” yatırım yapmamak |
Sorular ve cevaplar (FAQ)
Kendimizi rahat hissetmek için tek denetim yeterli mi?
Hardware wallet güvenliği garanti eder mi?
Bridge’leri güvenli kullanmak mümkün mü?
DEX’te MEV/“sandwich” riskini nasıl azaltırız?
İzinleri (approve) düzenli revoke etmek gerekir mi?
Admin anahtarları için Multisig mi MPC mi daha güvenilir?
Her zaman Approve tutarını “sonsuz” yerine sınırlamak gerekir mi?
Proje için denetçi nasıl seçilir?
Sonuç
DeFi teknolojileri hızla gelişiyor; ancak dayanıklılık “tek önlemle” değil, disiplinlerin toplamıyla oluşur: kaliteli kod, sıkı süreçler, izleme, sigorta ve elbette eğitim. Dolayısıyla proje güvenliği “varsayılan” olarak ne kadar erken kurarsa krizleri atlatma ve güven kazanma şansı o kadar yükselir.
Ana fikir: güvenlik kalıcı bir döngüdür: önle → tespit et → yanıt ver → geliştir. Bu döngüden ne kadar hızlı geçerseniz “patlama yarıçapı” o kadar küçülür ve DeFi ürününüz o kadar sağlam olur.
🎭 Sosyal mühendislik, UI ve altyapı
Phishing, sahte siteler ve airdrop tuzakları
“Ücretsiz” tokenlar, site klonları ve mesajlaşma uygulamalarındaki sahte destek tipik tuzaklardır. Seed/anahtar paylaşmayın, alan adını kontrol edin ve anlaşılmayan Approveimzalamayın. En önemlisi, eski izinleri düzenli olarak revoke edin.
Frontend ve anahtar kompromisi
Site değiştirilmişse ve admin anahtarı çalınmışsa mükemmel contract bile güçsüzdür. Bu nedenle ekipler 2FA/SSO kullanmalı, yetkileri sınırlamalı, frontend değişikliklerini izlemeli ve kritik anahtarları multisig’de tutmalıdır.
Bridge’ler ve cross-chain
Bridge’ler iki veya daha fazla ağın risklerini birleştirir. Bu yüzden yüksek validatör merkeziyetsizliği, sıkı mesaj doğrulama, çekim limitleri ve her update için denetim gerekir. Kullanıcılar için büyük tutarları bridge’lerde “öylesine” tutmamak mantıklıdır.