DeFi'de AML konuşurken çoğu içerik iki uçtan birine düşer: ya "blockchain her şeyi görür, AML çözüldü" ya da "permissionless protokolde AML imkânsız, regülasyon naif". İkisi de yanlış. Gerçek manzara nüanslı — protokol seviyesinde bir DEX'in mimari olarak yapabileceği AML çok sınırlı; front-end seviyesinde (web UI, SDK, aggregator) anlamlı kontroller mümkün; bir merkezi borsa veya custody sağlayıcının DeFi exposure'unu risk skoru olarak ele alması ise zaten standart pratik. Bu makale üç katmanın da gerçekte ne yapabildiğini, hangi açıkları kapatamadığını ve bir kripto varlık hizmet sağlayıcısının (KVHS / VASP) DeFi ile temas eden müşteri akışını nasıl yönettiğini operatör perspektifinden anlatıyor.
Önce kavramlar: protokol, front-end, intermediary
DeFi AML tartışmasını netleştirmek için üç farklı katmandan bahsetmek gerek:
Protokol katmanı. Akıllı sözleşmeler. Bunlar genellikle (her zaman değil) immutable — bir kez deploy edildi mi, kod değişmez. Sözleşmenin swap() veya addLiquidity() fonksiyonunu çağırabilen herhangi bir EOA (Externally Owned Account) işlem yapabilir; protokol kim olduğunu, KYC durumunu, yaptırım listesinde olup olmadığını bilmek için bir mimari yer tutamaz (eklenirse de bypass'ı kolay).
Front-end katmanı. Kullanıcının protokol ile etkileşimi için kullandığı arayüz — Uniswap'in app.uniswap.org sitesi, 1inch'in dApp'i, mobil cüzdan içindeki swap modülleri. Bu katman web2'dir; KYC, IP coğrafi engelleme, adres blocklist gibi kontroller tamamen mümkün.
Intermediary katmanı. Bir merkezi borsa, custody sağlayıcısı veya kripto kabul eden ödeme şirketi DeFi'ye giriş/çıkış akışında "kapı" rolü oynar. Müşterinin DeFi protokolüne ne kadar bağlandığı, çıkışta ne kadar exposure getirdiği bu kapı seviyesinde değerlendirilir.
Bu üç katman karıştırılırsa şu tarz boşlukla biten cümleler çıkar: "Uniswap KYC yapmıyor, bu yüzden AML başarısız." Gerçek: Uniswap protokol KYC yapmıyor ve yapamaz; Uniswap front-end belirli ülkelerden gelen IP'leri engelliyor ve OFAC SDN listesindeki cüzdanları bloklıyor; bir borsanın bu DEX'e çıkış yapan müşterisi merkezi borsa tarafında zaten KYC'li. Üç katman birlikte işleyince DeFi AML bir "açıklık" değil "katmanlı bir mimari" haline gelir — eksiklerle.
Protokol seviyesi AML: mimari sınır
Bir akıllı sözleşmenin AML uygulayabilmesi için en az şunlardan biri gerekir: (a) çağıran adresin bir whitelist'te olup olmadığını kontrol etmek, (b) çağıran adresin bir blacklist'te olup olmadığını kontrol etmek, (c) yatırılan/çekilen fonların on-chain provenance'ını sözleşme içinde değerlendirmek.
Üçü de mümkün ama her birinin DeFi felsefesiyle gerilimi var:
1. Whitelist (KYC'li adresler). Sözleşme sadece bilinen, doğrulanmış adreslere açık olur. Örnek: Aave Arc gibi permissioned DeFi havuzları, kurumsal müşteriler için izole pool'lar kullanır. Bu işliyor — ama açık DeFi'nin değil "KYC'li DeFi'nin" bir alt-segmenti. Pazar payı küçük.
2. Blacklist (sanctioned adresler). Sözleşme OFAC SDN gibi bir listeyle karşılaştırma yapar ve listedeki adreslerden gelen çağrıları reddeder. Teknik sorun: liste off-chain güncellenir; sözleşmenin nasıl on-chain veriye dönüştüreceği bir oracle problemine dönüşür. Circle (USDC) ve Tether (USDT) sözleşme seviyesinde adres dondurma yapıyor (OFAC SDN'e eklenen adreslerin USDC/USDT bakiyelerini bloklar) — bu token-seviyesi AML, protokol-seviyesi değil. Uniswap'in kendisinde böyle bir blocklist yok.
3. On-chain provenance kontrolü. Sözleşme yatırılan fonların kaynağını analiz eder. Teknik olarak sınırlı: cluster heuristikleri, hop-distance hesaplama gibi şeyler on-chain hesaplanamayacak kadar pahalı (gas maliyeti) ve karmaşık. Bazı protokoller "proof of provenance" gibi zero-knowledge tabanlı denemeler yapıyor; henüz olgunlaşmamış.
Bu üç boyutta da protokol seviyesi AML kısıtlı kalmaya mahkûm. DeFi tasarım hedefi (permissionless, censorship-resistant) ile AML hedefi (gatekeeping, identity-binding) arasında doğrudan gerilim var. Bu bir mühendislik açığı değil, mimari bir tercih.
Front-end seviyesi AML: gerçekten ne yapılır?
Front-end seviyesi farklı bir hikâye. Uniswap Labs (Uniswap protokolünü deploy eden şirket) app.uniswap.org'da şunları yapıyor:
Coğrafi engelleme (geofencing). Belirli ülkelerden gelen IP adreslerinden erişim engellenir veya kısıtlanır. Liste zamanla genişledi — Küba, İran, Suriye, Kuzey Kore gibi OFAC yaptırımlı yargı yetkilerinin yanı sıra ABD'de bazı token'lar için engelleme uygulanır.
Adres blocklist. Uniswap Labs Ağustos 2022'de Tornado Cash etkileşimli adresleri ve diğer OFAC SDN'e bağlı adresleri front-end'den blokladığını duyurdu. Yani: bu cüzdanlar app.uniswap.org üzerinden swap yapamaz — ama protokole başka bir front-end'den veya doğrudan kontrat çağrısıyla erişebilir.
Token listing kontrolü. Hangi token'ların arayüzde varsayılan olarak gösterileceği front-end kontrolünde. Yaptırım, scam veya yüksek risk değerlendirilen token'lar listelenmez (gizlenmez, sadece varsayılan olarak görünmez).
SDK ve widget kontrolleri. Üçüncü taraflar Uniswap SDK'sını veya widget'larını kullanarak kendi front-end'lerini inşa ederse, SDK seviyesinde benzer kontroller (geofencing, blocklist) entegre edilebilir; ancak bu opsiyoneldir, SDK kullanan herkes uygulamak zorunda değil.
OFAC'ın Mayıs 2024'te Uniswap Labs'a karşı Wells Notice yayımlaması (sektörü uyaran bir adım — soruşturma açma niyeti sinyali) front-end seviyesi sorumluluğun düzenleyici beklentisinin parçası olduğunu gösterdi. Şubat 2025'te SEC Uniswap soruşturmasını sonlandırdığını duyurdu; ancak yargısal manzara hâlâ açık.
Operatör için pratik çıkarım: bir DeFi protokolüne kendi müşterilerinizi yönlendiriyorsanız (örn. bir cüzdan uygulaması içinden DEX swap, bir borsanın "DeFi mode" özelliği), front-end seviyesi kontrolleri sizin sorumluluğunuzdadır — protokolden bağımsız olarak.
Intermediary seviyesi: borsa ve custody operatörü için DeFi exposure
Çoğu Türk ve AB merkezli operatör için en pratik soru: müşterilerimiz DeFi protokollerine para yatırıyor veya çekiyor, bunu nasıl risk skoru olarak yorumlarım?
DeFi protokol cüzdanları (Uniswap V3 pool, Aave lending pool, Curve, GMX, vb.) cluster veritabanlarında genelde "DeFi protocol" tipinde etiketlenir, doğrudan risk kategorisinde değil. Bu rasyonel — Uniswap havuzu binlerce kullanıcının fonunu temsil eder; bir yaptırımlı adres deposit ettiğinde tüm havuz "yaptırım exposure'lı" olmaz.
Pratik bir risk yorumlama çerçevesi:
| DeFi etiketi | Standart risk yorumu | Ekstra dikkat |
|---|---|---|
| Major DEX havuzu (Uniswap, PancakeSwap, Curve) | Düşük-orta risk | Kullanıcı davranış profili anormal mi? |
| Major lending pool (Aave, Compound) | Düşük risk | Yüksek frekans collateral döngüleri MEV/manipülasyon olabilir |
| Yield aggregator (Yearn, Convex) | Düşük risk | Strateji yatırımı, normal |
| Cross-chain bridge (Stargate, Across) | Orta risk | Bridge'in geçtiği zincirin etiket coverage'ı önemli |
| Privacy odaklı protokol (Railgun, Aztec) | Yüksek risk | Mixer benzeri muamele; politikaya göre manuel review |
| Açıkça yaptırımlı protokol (Tornado Cash) | Çok yüksek risk | 0-1 hop = otomatik decline + STR |
| Bilinmeyen yeni protokol | Orta risk | Behavioral pattern + müşteri profili kararı yönlendirir |
Bu tablo borsanız için bir başlangıç noktası; her operatörün risk iştahına ve regülatör beklentilerine göre kalibre edilmelidir. Blockchain AML pillar rehberimizde hop-mesafesi ve exposure aggregation tablolarıyla bu yorumu daha geniş çerçeveye oturtuyoruz.
MEV, aggregator ve karmaşık akış: exposure'ı kim taşır?
DeFi'nin gerçek karmaşıklığı tek protokol etkileşimde değil, multi-hop swap zincirlerinde. Bir 1inch swap'i Uniswap → Curve → Balancer üzerinden bir tek transaction'da geçebilir; bir DEX aggregator MEV bot'u flash loan ile aynı transaction içinde Aave, Uniswap, ve cross-chain bridge'i ardarda çağırabilir.
Operatör perspektifinden iki spesifik komplikasyon var:
1. Aggregator çıkışında kaynak görünmez. Müşteri 1inch'e ETH gönderir, USDC olarak geri alır. Transaction grafiği yüzeyel olarak "1inch'e gönderdi, 1inch'ten aldı" görünür — ama 1inch arka planda altı farklı havuza dokunmuş olabilir. Bu havuzların birinin yaptırımlı bir cüzdanla yakın geçmişi varsa, naif bir tarama bunu yakalayamaz. Olgun provider'lar aggregator transaction'larını "expand" eder ve alt-route'ları cluster grafiğine ekler.
2. MEV bot'ları yaptırımlı adresleri sandwich edebilir. Bir MEV bot Tornado Cash withdraw'unu front-run veya back-run ettiğinde, bot'un cüzdanı "Tornado Cash exposure'lı" olabilir — ama bu meşru bir piyasa yapıcı aktivite. Provider'ların MEV pattern tanıma kalitesi bu sınır vakaları doğru değerlendirmek için kritik.
Pratik öneri: aggregator ve MEV ağırlıklı akışlarda exposure %'sini yumuşatın — düz hop-distance kuralları yanlış pozitif üretir. Eşik politikanızda "aggregator-mediated exposure" için ayrı bir bant tanımlamak yardımcı olur.
Operatör için pragmatik karar çerçevesi
Bir borsa veya custody operatörü DeFi exposure'unu yönetmek için şu adımları izleyebilir:
1. DeFi etiketleme taksonomisini netleştirin. Provider'ınız hangi protokolleri etiketliyor? Hangi kategorilerde? "DEX havuzu" tek bir bucket mı, yoksa "major DEX havuzu" / "kısa-ömürlü DEX havuzu" / "privacy DEX" gibi alt-ayrım var mı? Bu netleştirme olmadan risk skorunuz gri kalır.
2. Yazılı eşik politikası yazın. Hangi DeFi etiketinde + hangi hop-mesafesi + hangi exposure %'sinde ne yapılacağı yazılı olsun. "Analist takdiri" regülatörce sevilmeyen bir cevaptır.
3. Aggregator akışları için ayrı kural seti. Yukarıda anlattığımız MEV/multi-hop komplikasyonları için ayrı bir politika bandı tanımlayın. Provider'ınızın aggregator-expansion özelliği var mı? Yoksa, ek bir doğrulama katmanı (örn. cüzdanın aggregator-only davranışı varsa yumuşatma) ekleyin.
4. Privacy odaklı protokolleri ayır. Railgun, Aztec gibi yapısal olarak privacy odaklı protokoller mixer benzeri muamele görmeli (manuel review veya politikaya göre decline). Mixer ve darknet AML rehberimizdeki eşik tablosunu privacy odaklı protokoller için aynen uygulamak makul bir varsayılan.
5. Front-end attribution'ı log'la. Müşteri DeFi protokolüne sizin uygulamanızdan mı geçti, kendi cüzdanından mı? Sizin uygulamanızdan geçtiyse front-end seviyesi kontrol sorumluluğu sizdedir; kullanıcı kendi başına geçtiyse intermediary seviyesi exposure yorumu yaparsınız.
6. Düzenli policy review. DeFi protokol landscape'i 6 ayda anlamlı değişir — yeni privacy çözümleri, yeni aggregator'lar, OFAC eylemleri. Eşik politikanızı çeyreklik review'a koyun.
Türkiye için ek bir not: KVHS düzenlemesi yürürlüğe girdiğinde MASAK'ın DeFi etkileşimine dair beklentilerini netleştirmesi bekleniyor. AB tarafında MiCA permissioned DeFi'yi (tokenize edilmiş finansal araçların ticareti) kapsama alıyor; tam permissionless DeFi MiCA Article 2 ile dışarıda — yine de Travel Rule (TFR) yükümlülükleri operatörden VASP'a transfer akışlarında geçerli.
Sıkça Sorulan Sorular
Uniswap kullanmak yasak mı?
Hayır, kullanıcı için yasak değil (yargı yetkisine göre değişebilir — örn. ABD'de bazı eyalet yasakları, AB MiCA dışında bireysel devlet düzenlemeleri). Ancak: Türkiye'de, AB'de veya UK'de bir kripto operatörünüz varsa, müşterilerinizin Uniswap'e yaptığı transferleri counterparty olarak yorumlamak zorundasınız. Yaptırımlı bir token swap'i için Uniswap havuzu kullanılmış olabilir; bu havuza giden müşteri transferi exposure değerlendirmesine girer. Yasak/serbest ayrımı bireysel kullanıcı için, risk değerlendirmesi operatör için.
Bir liquidity provider tüm havuzun risk'ini taşır mı?
Genelde hayır. Bir LP token sahibi havuzdaki tüm fonların orantılı sahibidir; havuza bir yaptırımlı deposit gelirse LP'nin payı bu fonların oranıyla orantılı. Pratik provider yorumu: LP token'ı tutmak doğrudan bir yüksek risk etiketi tetiklemez, ancak LP token withdrawal'ı sırasında alınan composite token'ların exposure'u alt-kategori bazında değerlendirilir. Bu nüans olgun bir provider'da otomatik; daha basit provider'larda manuel kontrol gerekir.
DeFi protokol kontrat sahibi (deployer) AML açısından sorumlu mu?
Karmaşık bir soru, regülatöre göre değişir. ABD'de Roman Storm (Tornado Cash co-founder, 2023'te tutuklandı, 2025'te jüri kararı belirsiz/asılı kaldı) ve Alexey Pertsev (Hollanda'da 2024'te Tornado Cash ile mahkûm edildi) davaları immutable kontrat deployer'ının ceza sorumluluğunu test eden vakalar. AB'de MiCA daha çok hizmet sağlayıcı (CASP) çerçevesine girer; pure protokol deployer'ları doğrudan kapsamda değil. Türkiye'de KVHS taslakları benzer ayrımı izliyor — hizmet sağlayan kuruluş ile sadece kod yayımlayan geliştirici farklı kategoriler. Aktif yorum: yargı yetkisi ve aktivitenin niteliğine göre değişen, hâlâ olgunlaşan bir alan.
Permissioned DeFi (Aave Arc, Compound Treasury) AML'i çözer mi?
Permissioned DeFi (sadece KYC'li adreslerin işlem yapabildiği havuzlar) kurumsal müşteriler için çözüm sağlar, ama tüm DeFi pazarının dar bir dilimi. Open DeFi'nin değil yanı sıra olan bir kategoridir — değiştirmez. Operatör için faydası: kurumsal müşterilerinize "regülatör-uyumlu DeFi getirisi" erişimi sağlayabilirsiniz. Sınırı: TVL ve protokol çeşitliliği open DeFi'ye göre 100x küçük.
MASAK DeFi exposure'u nasıl değerlendirecek?
KVHS düzenlemesi henüz yürürlükte olmadığı için (2026 itibariyle taslak/yayın aşamasında) MASAK'ın DeFi'ye dair formal beklentisi açıklanmadı. Sektör görüşü: minimum eşik (a) yaptırımlı protokol etkileşiminin (Tornado Cash gibi) tespiti ve raporlanması, (b) müşteri DeFi exposure'unun risk skoruna entegre edilmesi, (c) önemli DeFi transferlerinin manuel review akışına alınması. AB MiCA ve FATF DeFi guidance dokümanları MASAK pratiğinin de büyük olasılıkla yöneleceği yön. Türkiye AML/KYC uyum rehberimiz ulusal regülasyon hattını izliyor.
Legichain ile DeFi exposure yönetimi
Legichain blockchain AML altyapısı DeFi protokollerini "DeFi protocol" tipinde alt-kategorilere ayrılmış cluster veritabanında tutar — major DEX havuzu, lending pool, yield aggregator, cross-chain bridge, privacy odaklı protokol ayrımı otomatik etiketlemede mevcut. OFAC SDN'e bağlı protokoller (Tornado Cash dahil) sanctions kategorisiyle bağlanır ve hop-distance/exposure mantığı standart eşik politikalarınızla uyumlu çalışır. Aggregator-expansion özelliği multi-hop swap'lerin alt-route'larını tarama grafiğine ekler — 1inch, Paraswap, 0x gibi büyük aggregator'lar destekleniyor. Türkiye'deki kripto operatörler için KVHS yürürlüğe geçtiğinde MASAK bilgi taleplerine destek veren Türkçe ekip mevcut; AB pazarına açılan operatörler için TFR ve MiCA uyumlu Travel Rule entegrasyonu yan yana çalışır.
Sonraki adımlar
- Blockchain AML rehberimiz (pillar) — dört katmanlı mimari ve genel çerçeve
- Kripto cüzdan taraması nasıl yapılır — uçtan uca tarama akışı
- Mixer, tumbler ve darknet AML sinyalleri — privacy odaklı protokollerin analoji çerçevesi
- MiCA nedir? Kripto sağlayıcılar için yol haritası — AB regülasyon çerçevesi