Akıllı sözleşme denetimi; erişim kontrolü, durum geçişleri, aritmetik, yükseltme, dış çağrı, oracle, test ve kod güvenliği gibi teknik alanlara odaklanır. İş modeli denetimi; tokenın temsil ettiği hak, gelir ve nakit akışı, tarafların sorumluluğu, müşteri varlığı, fiyatlama, yönetişim, acil durum ve hukuki-operasyonel bağları inceler. Bir rapor diğerinin yerine geçmez. Karar vericinin ihtiyacı, kod denetimi ile ekonomik ve operasyonel durum tespitini ortak bir kabul matrisi içinde birleştirmektir.
İki denetim aynı nesneye farklı sorular sorar
Akıllı sözleşme, iş kuralının belirli bölümünü kod olarak çalıştırır. Kod incelemesi “Bu kural, tanımlandığı biçimde güvenli ve öngörülebilir çalışıyor mu?” diye sorar. İş modeli incelemesi ise “Tanımlanan kural doğru mu, hangi taraf için değer yaratıyor, hangi hakkı temsil ediyor ve başarısız olduğunda kim ne yapacak?” sorularını cevaplar. Kod, dış dünyadaki varlığın gerçekten mevcut olduğunu, müşteriye verilen vaadin sürdürülebilir olduğunu veya yöneticinin çıkar çatışması taşımadığını kendi başına kanıtlayamaz.
| Alan | Akıllı sözleşme denetimi | İş modeli denetimi |
|---|---|---|
| Temel nesne | Kod, durum ve teknik bağımlılıklar | Hak, taraf, gelir, operasyon ve yönetişim |
| Başarı sorusu | Kod güvenli ve şartnameye uygun mu? | Şartname ekonomik ve operasyonel olarak anlamlı mı? |
| Tipik çıktı | Bulgu, önem seviyesi, test ve düzeltme | Varsayım, kırmızı bayrak, fizibilite ve karar şartı |
| Sınır | Gerçek dünya varlığını ve hukuki hakkı doğrulamaz | Koddaki yeniden giriş veya erişim açığını bulmayabilir |
Akıllı sözleşme denetimi teknik güvenlik ve doğrulanabilir davranışa odaklanır
Teknik denetim yalnız otomatik tarama değildir. Sözleşme mimarisi, tehdit modeli, durum makinesi, yetkili roller, dış bağımlılıklar ve yükseltme mekanizması anlaşılmadan araç çıktıları yanlış güven hissi verebilir. Ethereum güvenlik rehberleri erişim kontrolü, dış çağrılar, değişmezlik, test ve güvenli geliştirme sürecinin birlikte ele alınmasını önerir.
- İşlev ve durum geçişleri açık şartnameye bağlı mı?
- Yönetici, mint, burn, pause, upgrade ve fon transferi yetkileri sınırlandırılmış mı?
- Yeniden giriş, fiyat manipülasyonu, frontrunning ve aritmetik hataları test edildi mi?
- Oracle, köprü, token ve diğer sözleşme bağımlılıkları tehdit modeline dahil mi?
- Proxy ve yükseltme düzeni depolama çakışması veya yetki devri riski üretiyor mu?
- Fail-safe, pause, limit, zaman kilidi ve geri alma seçenekleri tasarlandı mı?
- Test kapsamı yalnız satır sayısını değil kritik özellik ve invariants doğrulamasını içeriyor mu?
- Denetlenen commit, derleyici, ağ ve dağıtım adresi değişmez biçimde kaydedildi mi?
Formal verification belirli güvenlik özelliklerini matematiksel modele karşı sınayabilir; ancak model yanlış veya eksikse doğrulama yalnız yanlış varsayımı daha güçlü biçimde teyit eder. Bu nedenle teknik şartname ile iş şartnamesi arasında izlenebilirlik kurulmalıdır.
İş modeli denetimi kodun dışında kalan değer zincirini inceler
Bir token veya protokol yalnız sözleşmeden oluşmaz. İhraççı, platform, saklama kuruluşu, veri sağlayıcısı, müşteri, likidite sağlayıcı, yönetici, alt yüklenici ve gerçek dünya varlığını tutan taraflar birlikte çalışır. İnceleme, kimin hangi hakkı verdiğini ve hangi sorumluluğu taşıdığını belgelemelidir.
Token neyi temsil ediyor?
Mülkiyet, alacak, kullanım, gelir paylaşımı, yönetişim veya yalnız teknik erişim mi?
Değer nereden geliyor?
Gerçek nakit akışı, rezerv, ağ etkisi, teşvik veya yeni katılımcı talebi mi?
Off-chain yükümlülük kimde?
Varlık saklama, fiyat verisi, itfa, müşteri desteği ve mutabakat nasıl yürütülüyor?
Kim değiştirebilir?
Yönetici anahtarı, oy, acil durum komitesi, yükseltme ve ihtilaf mekanizması kimde?
İş modeli denetimi ayrıca müşteri edinme maliyeti, gelir yoğunlaşması, teşviklerin sürdürülebilirliği, likidite varsayımı, mevzuat kapsamı, vergi ve muhasebe etkisi, tedarikçi bağımlılığı, veri kalitesi ve çıkış planını değerlendirir. Hukuki sınıflandırma gerekli olduğunda yetkili hukuk uzmanı ayrıca inceleme yapmalıdır; teknoloji raporu hukuki görüş yerine geçmez.
Kod kusursuz çalışırken ekonomik sonuç yine yanlış olabilir
Sözleşme, teminat oranı belirli eşiğin altına düştüğünde varlığı otomatik satabilir. Kod bu kuralı hatasız uygular; fakat fiyat verisi sığ piyasadan geliyorsa, likidasyon kapasitesi yetersizse veya müşteri sözleşmesi bu davranışı açık anlatmıyorsa sistem ekonomik zarar ve uyuşmazlık üretir. Benzer biçimde token arzı teknik olarak sınırlandırılmış olabilir; ancak kurucu tahsisi, unlock takvimi ve piyasa yapısı fiyat baskısını sürdürülemez hâle getirebilir.
| Durum | Kod sonucu | İş modeli riski |
|---|---|---|
| Otomatik likidasyon | Şart sağlanınca doğru çalışır | Oracle, likidite ve müşteri açıklaması yetersiz olabilir |
| Rezerv karşılığı mint | Yetkili adres token üretir | Off-chain rezerv gerçek veya erişilebilir olmayabilir |
| Yönetişim oylaması | Oylar doğru sayılır | Oy gücü yoğunlaşmış ve çıkar çatışmalı olabilir |
| Gelir dağıtımı | Formüle göre ödeme yapar | Gelirin kaynağı, muhasebesi ve devamlılığı belirsiz olabilir |
Birleşik kabul matrisi teknik ve ekonomik kapıları ayırmalıdır
Yönetim kuruluna veya yatırım komitesine tek bir “audit tamamlandı” rozeti sunmak yerine, ayrı kapılar kullanılmalıdır. Teknik kapı kodun güvenlik durumunu; ürün kapısı müşteri ve iş değerini; operasyon kapısı gerçek dünya süreçlerini; yönetişim kapısı yetki ve sorumlulukları; uyum kapısı düzenleyici ve sözleşmesel ihtiyaçları gösterir.
| Kapı | Asgari kanıt | Karar |
|---|---|---|
| Teknik güvenlik | Tehdit modeli, bağımsız denetim, test ve düzeltme kaydı | Dağıt / düzelt / durdur |
| Ekonomik fizibilite | Nakit akışı, teşvik, stres senaryosu ve birim ekonomi | Pilot / yeniden tasarım |
| Hak ve varlık bağı | Sözleşme, kayıt, saklama ve itfa kanıtı | Kabul / eksik kanıt |
| Operasyon | RACI, mutabakat, olay, çıkış ve iş sürekliliği planı | Canlıya geç / hazırlık |
| Yönetişim | Admin anahtarı, upgrade, oy ve çatışma kontrolleri | Sınırla / şeffaflaştır |
Denetim geliştirme bittikten sonra başlayan tek seferlik iş olmamalıdır
- İş hedefini, tarafları, hakları ve başarısızlık senaryolarını yazın.
- Bu iş modelini teknik özelliklere ve güvenlik invariants setine çevirin.
- Mimari ve tehdit modeli incelemesini kod tamamlanmadan yapın.
- Otomatik analiz, birim test, fuzzing, invariant test ve manuel kod incelemesini birlikte yürütün.
- İş modeli için stres, likidite, fiyat, rezerv, müşteri ve yönetişim senaryolarını sınayın.
- Bulguları önem, olasılık, etki, sahip ve kapanış kanıtıyla yönetin.
- Dağıtım öncesi commit, bytecode, parametre ve yetki listesini doğrulayın.
- Canlıda admin işlemleri, oracle sapması, likidite, olay ve ekonomik KPI’ları izleyin.
- Her yükseltmede değişiklik etkisine göre yeniden denetim yapın.
Denetim kapsamı yeni kodla sınırlanmamalıdır. Parametre değişikliği, oracle kaynağı, yönetici cüzdanı, token listesi veya off-chain mutabakat değişimi de risk profilini değiştirebilir.
Senaryo: kira gelirine bağlı tokenizasyon projesi
Sözleşme yatırımcı bakiyelerini doğru tutuyor ve gelir dağıtımını formüle göre yapıyor olabilir. İş modeli incelemesi ise mülkün kime ait olduğunu, kira tahsilatını kimin yaptığını, giderlerin nasıl düşüldüğünü, boşluk ve bakım riskini, bağımsız değerlemeyi, token sahibinin hukuki alacağını, itfa ve ikincil piyasa koşullarını sorgular. Oracle incelemesi kira ve değer verisinin nasıl doğrulandığını; operasyon incelemesi banka hesabı ile zincir kaydının nasıl mutabık kaldığını test eder.
Karar dosyası yalnız PDF denetim raporundan oluşmamalıdır
- İş, hak ve teknik şartnameler
- Sistem ve sözleşme mimari diyagramı
- Tehdit modeli ve kritik invariants
- Kaynak kod, commit, derleyici ve dağıtım adresi
- Denetim kapsamı, hariç tutulan alanlar ve kapanış raporu
- Admin ve yükseltme yetki matrisi
- Oracle, köprü ve alt sözleşme bağımlılıkları
- Varlık, rezerv, saklama ve mutabakat kanıtları
- Ekonomik stres ve likidite senaryoları
- Olay, pause, rollback, iletişim ve çıkış planı
Teknik denetçi karar sahibi değil, bağımsız kanıt sağlayıcısıdır
Ürün sahibi iş hedefi ve müşteri vaadini; teknoloji ekibi kod ve mimariyi; güvenlik tehdit ve denetimi; finans birim ekonomiyi ve rezervi; operasyon mutabakat ve olay sürecini; hukuk hak ve yükümlülükleri; risk yönetimi birleşik karar matrisini yönetir. Son karar, teknik raporun varlığına değil açık kapıların kapanmasına dayanmalıdır.
- Kritik ve yüksek teknik bulgu kapanış oranı
- İş varsayımları için kanıt kapsamı
- Admin ve upgrade yetkilerinde görev ayrılığı
- Varlık–token mutabakat sapması
- Oracle ve likidite stres sonucu
- Olay ve pause tatbikatı
- Dağıtım sonrası değişikliklerin yeniden inceleme oranı
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.
- 01Ethereum.org — Smart Contract Security
Akıllı sözleşmelerde erişim kontrolü, değişmezlik, güvenli geliştirme ve bağımsız inceleme ihtiyacını açıklar.
- 02Ethereum.org — Formal Verification of Smart Contracts
Belirli güvenlik özelliklerinin matematiksel model ve şartnameye karşı doğrulanmasını açıklar.
- 03IOSCO — Tokenization of Financial Assets
Tokenizasyon düzeneklerinde akıllı sözleşme, yönetişim, operasyon ve varlık bağlantısı risklerini değerlendirir.
- 04IOSCO — Policy Recommendations for Crypto and Digital Asset Markets
Operasyonel risk, çıkar çatışması, müşteri varlığı ve yönetişim için politika önerileri sunar.
- 05BIS — The Crypto Ecosystem: Key Elements and Risks
Akıllı sözleşme, oracle, köprü, yönetişim ve operasyonel risklerin birlikte değerlendirilmesini sağlar.