ERC-3643 T-REX Protokolü ve RWA Rehberim #1
Selam arkadaşlar, yoğunluktan yazı yazmaya vakit ayırmakta zorlandığım bir dönemdeyim, siz değerli okuyucularımı boşladığımı düşünmeyin lütfen.
Türkiye-Amerika arasında mekik dokuduğum bir süreçten geçiyorum, bir de Ankara Üniversite’si Teknokenti bünyesinde faaliyet gösteren tokenizasyon yazılımları ve legal-tech üzerine çalışan start-up’ımın da iş yoğunluğu arttı epey. Ama daha fazla uzak kalmak istemedim sizinle. Hem Harvard’daki dersimde üzerinde çok durduğum hem de sizin de iyi bilmenizi istediğim bir konu var. O seberple oturdum ve bunu detaylıca açıklayacağım bu konuyu size. Hazırsanız başlayalım, zaten diğer gelişmeleri sonra konuşuruz, asıl mevzuya giriyorum o sebeple hızlıca :)
RWA ve Tokenizasyon
RWA yani real world asset tokenizasyonu dediğimiz zaman, dünyadaki hisseden borçlanma aracına, gayrimenkul payından fon katılım payına kadar her şeyi on-chaine taşıyabildiğimiz bir ekosistem geliyor hepimizin aklına.
Bu tokenize edilecek varlıkların hukuken uyumlu, teknik olarak sorunsuz ve operasyonel olarak da sürdürülebilir biçimde nasıl on-chaine taşınacağını anlatmak istiyorum sizlere.
Bu konuda Türkiye’de ve Orta Doğu’da bilindik bankalarla çok yakından çalışıyoruz bu sebeple direk süreci ve bu konuya bağlı olarak ortaya çıkan bir ERC güncellemesini açıklamak istiyorum.
ERC-3643, nam-ı diğer T-REX, bu alanda bugün elimizdeki en başarılı standart diyebilirim, çünkü yalnızca bir token sözleşmesi değil, kimlik, compliance ve transfer kurallarını protokol seviyesinde bir araya getiren bir çatı aslında, yani yazdığımız smart contractımız hukuken ve teknik olarak uyumlu olabiliyor aynı anda.
Bu standart, ERC-20’nin basit aktarım modelinin ötesine geçiyor ve ne diyor biliyor musunuz, bu token kimden, kime, neyi, hangi şartlarda devredebilir diye soruyor ve cevabı smart contractımızın içine gömüyor :)
Böylece, aslında tam da hukukun yönetebileceği gibi, sadece gereken durumlarda ve yalnız belirli yatırımcı profillerinin alabileceği, belirli ülke/limit/lock-up kurallarına tabi ve gerektiğinde dondurulup (freeze) itfa edilebilen (redeem) izinli (permissioned) tokenlar geliştirebiliyoruz artık. Devrim niteliğinde bir protokol yani, şu yazıyı yazarken ki heyecanımı görmeniizi isterdim :D
Bu yazıda hem developer gözüyle mimariyi ve uygulama detaylarını, hem de hukukçu gözüyle rejim ayrımlarını, risk noktalarını, ispat ve raporlama akışlarını tek tek açıklamak istiyorum (Vedat Hocam her defasında kısa yaz lütfen diyor, o sebeple 2 part ya da 3 part yapabilirim ama söz veremiyorum hocam kızmayın :D).
Kaynaklarını da satır aralarında göstereceğim ki, ders notu olarak dağıttığınızda referanslarıyla birlikte ayakta dursun. (Resmi EIP ve ERC dokümantasyonla başlayın her zaman siz de, mimari, bileşenler ve amaç orada çok net anlatılmıştır, ilk önce asıl kaynaktan öğreniyoruz sonra uygulamalarla tecrübe ediyoruz, kural bu hatırlayın)
Whitepaper’ı buraya ekleyim:
Neden ERC-3643? Sadece ERC-20 yeterli değil miydi diyenlere pratik ve hukuki bir yanıt aslında
Ethereum’daki en yaygın token standardını biliyoruz değil mi, ERC-20 yani? Adresler arasında serbest transfer yapılabiliyor, hiçbir kimlik koşulu yok, kısıt ve kural yok. Serbestlik güzel tabi, fakat menkul kıymet niteliği olan ya da sadece belirli nitelikteki kişilere (örneğin akredite yatırımcı ya da müşteriler vs.) sunulabilen varlıkları taşıyorsanız, bu serbestlik hukuki ve operasyonel risk demektir.
Menkul kıymetler sıkı yasal düzenlemelere tabi dünyanın her yeerinde ve her yatırımcının uygunluğunun doğrulanması (KYC/AML, akredite yatırımcı vb.) gerekiyor.
Dağıtım kurallarını siz ERC20 tokenlar ile belirleyemiyorsunuz, bu neden öenmli, çünkü bazen kara liste&ambargo, ülke bazlı kısıtlar, elde tutma üst sınırları (holding cap), kilit süreleri (lock-up), kaybolan cüzdanların hak sahibi korunarak kurtarılması gibi başlıklarla karşılaşacaksınız, hatta belki çoktan karşılaştınız, biz karşılaştık birçok defa.
Bu durum uygulama tarafında kolay kolay da çözülemiyor. Çünkü zincirdeki asıl hak devri token transferiyle gerçekleşiyor ERC20 tokenlarında. İşte ERC-3643’ün fikri burada çok çok güzel bir şekilde devreye giriyor, bayılacaksınız! :)
Kimlik ve Compliance (ONCHAINID + claim’ler) ile transfer kurallarını (Compliance/Validator) sözleşmenin içine koyuyor, böylece zincirin izin gerektirmeyen doğasına rağmen, yalnızca koşulları sağlayanların token sahibi veya muhatabı olabileceği bir sistemi standart arayüzlerle kuruyorsunuz. MUHTEŞEM DEĞİL Mİ? (felsefi açıdan değil sadece teknik ve hukuki olarak bakın lütfen)
Resmi tanım bunu on-chain kimliklere dayanan otomatik bir doğrulayıcıyla güvenli, uyumlu transfer olarak tarif ediyor, whitepaper’ı okuduğunuzda göreceksiniz :)
Mimariye İçerden Bakalım, Token, Kimlik, Compliance Motoru ve Aralarındaki Konuşma
ERC-3643’ü üç katmanlı bir yapı gibi düşünebilirsiniz. (hepsine yavaş yavaş değineceğim hiç endişeniz olmasın)
1. Token Sözleşmemiz var (T-REX Token)
Arkadaşlar, en altta token var. İlk bakışta ERC-20 gibi duruyor token sözleşmemiz, ama aslında daha farklı. Çünkü
Bu token sözleşmesi, projenin real world/gerçek varlık temsilini barındıran sözleşme ama içindeki yetki ve kurallar başka modüllerde.
2. Identity Registry (Kimlik Rehberimiz )
Orta katta Kimlik/ONCHAINID ve Kayıtlar var.
Orta katman buradı. İşin kimlik boyutu burada devreye giriyor arkadaşlar. Bu sözleşme, kimin zincir üstünde işlem yapmaya “uygun kimliğe” sahip olduğunu biliyor. Her kullanıcı adresini, bir ONCHAINID smart contract’ine bağlıyor. Diğer ERC protokollerinden farkımız bu ONCHAINID aslında.
Yani ERC-3643 sisteminde bir adresin token transferine katılabilmesi için önce bir ONCHAINID kimliği olmalı. Bunu yazdık kenara.
Her adresin, zincirde bir kimlik sözleşmesi (identity smart contract) ile temsil edildiği bilgisine ek olarak buu kimliklerin üzerinde “claim” adı verilen damgalar durduğunu bileceğiz:
Bu verileri verenler, güvenilir, bağımsız Trusted Issuer’lar. İşte bu sistemin kalbinde şu var:
🔐 Kişisel veri asla zincire yazılmaz. Zincirde sadece “sonuçlar” (claim flags) dururlar. Belgeler, KYC raporları vs. off-chain olarak, güvenli depolarda tutulur..
Şimdi geldik üçüncü katmana.
3. Compliance Contract (Kurallar Motoru)
Şimdi burası kritik. Burada bir nefes alalım, Türk çayımızdan bir yudum alalım. Aldık.
Bu sözleşme, regülasyonun kod hali. Her token, kendi compliance contract’ını kullanıyor yani. Yani diyelim ki bir gayrimenkul fonu için bir token var, başka bir menkul kıymet için başka token var, her biri için kurallar farklı olabilir.
Kurallara örnek vermek gerekirse de :
Ve bunlar gerektiğinde güncellenebilir parametreler elbette.
Developer olarak compliance contract kodunu okuduğunuzda aslında bir tık da hukuk metni göreceksiniz. Kodun içindeki transferRules() kısmı resmen yönetmelik maddesi gibi işliyor.
Bu üçlü katman, her transferde birlikte çalışıyor.
4. TokenFactory + Proxy Kullanımı
Sistem aslında baya modüler kurulmuş. Yeni bir token çıkarmak isterseniz mesela,
Bu ne kazandırır?
Zincirde yalnızca sonuç (örneğin KYC Level-2 tamam, ABD’de akredite ya da değil, TR mukimi, PEP değil vs vs) gibi claim topic ve bayrakları var, belgeler, PII ve kanıtlar off-chain güvenli depoda duruyor.
Böylece, uyumlu ve denetlenebilir bir yapı elde ederken GDPR/KVKK ve diğer kişisel veri kanunları açısından da doğru tarafta kalıyoruz diyebilirim. ONCHAINID’nin resmi dokümanları bu yaklaşımı, kimliğin zincirde ama verinin zincir dışında olduğu sonuç odaklı model diye anlatıyor, mutlaka okuyun MUTLAKA.
Bir Transfer Neden Reddedilir?
Bence ERC-3643'ü ilk kez kullanan çoğu kişinin şaşırdığı an şurası oluyor: 📛 TransferWithData çağırdım ama işlem reddedildi!?
Klasik ERC-20 dünyasında bu yok. Orada token varsa, herkes herkese gönderebilir hatırlarsanız. Ama bu dünya farklı. Çünkü bu bir “kurallı transfer” sistemi. Bu nedenle biz şu anda çalıştığımız bankalarda tokenizasyon işlemlerimizi ERC-3643 ile yapıyoruz.
Şimdi bir örnekle açıklayalım:
Eylül , Almanya’da yaşayan sıradan bir yatırımcı hanımefendi olsun. Bir gayrimenkul tokeni almak istiyor olsun. Ama Almanya’daki mevzuat diyor ki:
Bu tür varlıklar ancak belli limitlere kadar prospektüs olmadan satılabilir.
Eylül Hanım bu limiti aşmak üzere. Sistem ne yapar?
🧠 Compliance Katmanımız devreye girer ve şu soruları sorar:
Eğer kurallar bu işlem yapılamaz diyorsa, sistem:
❌ Transfer reddedildi diyor.
Ve sadece reddetmekle kalmıyor, nedenini de açıklıyor. Bu deneyimi kullanıcı için anlaşılır kılmak şarttır. O sebeple Transfer yapmadan önce simülasyon çalıştırın. canTransfer(from, to, amount) gibi gibi..
Yani mesele sadece smart contract yazmak değil burada, hukuki uyumu arayüze de yansıtmak gerekiyor. Harvard’daki öğrencilerime de derste şunu söylüyorum:
🎓 Regülasyona uyum, frontend’de başlar. BURADAN BAŞLAYIN O NEDENLE.
Tabi bu olay zaten neden Karakod’u kurduğumuzu açıklıyor :)
Bu Token Hukuken Ne Peki?? AB’de MiCA ≠ MiFID Ayrımı, Türkiye’de 7518 ve 2025 Tebliğleri
Arkadaşlar, zincir üzerinde bir token var ama bu token neyi temsil ediyor? Bir hisse senedi mi? Borçlanma aracı mı? Yoksa sadece sadakat puanı mı? Nedir yani?? Eşya mı para mı çek mi..
Hukukta asıl belirleyici olan şey temsil edilen hakkın niteliğidir her zaman.
Avrupa Birliği, kripto varlıkları hukuken sınıflandırırken tokenin ne yaptığına bakar, nasıl yapıldığına değil. 2024 sonu ve 2025 başında yayımlanan ESMA Final Report (Aralık 2024) ve Guidelines on MiFID II Classification (Mart 2025) belgeleri bu ayrımı netleştirdi çoktan.
İlke şuydu, eğer token, pay/borç/diğer menkul kıymet benzeri haklar veriyorsa, teknoloji token olsa bile MiFID II’nin finansal araç rejimine giriyor. Bu durumda MiCA kapsamı dışında kalıyot ve klasik menkul kıymet rejimi (prospektüs, dağıtım kuralları, piyasa suiistimali, yatırımcı sınıflandırması vs vs vs) uygulanıyor.
Bu, RWA/senet-benzeri tokenizasyon yapan herkes için kritik bir ayrım. (ESMA’nın 2024 Aralık Final Report’u ve 2025 Mart Guidelines belgesi bu ayrımı çok açık yazar, okuyabilirsiniz)
MiCA Ne Zaman Devreye Giriyor?
MiCA (Markets in Crypto Assets) ise daha çok
gibi, finansal araç olmayan ama kamuya arz edilen kripto varlıkları kapsayan bi regülasyon.
Yani arkadaşlar MiCA = kriptoya özel düzenleme demek, MiFID II = klasik menkul kıymet kurallarının/security token formuna uyarlanması demek.
⚖️ 7518 Sayılı Kanun Ne Diyor?
Bu yasa ile kripto varlık kavramı Türk hukukuna tanıtıldı :)
FAKAT DİKKAT! 7518 sayılı kanun, finansal araç niteliğini belirlemiyor.
Yani yine esas olan şu, token neyi temsil ediyor?
SPK diyor ki Eğer bir varlık, bir şirketten hisse, kâr payı, faiz gibi finansal haklar sağlıyorsa ve yatırım amacıyla alınıyorsa, o artık menkul kıymettir
Bunu nereden biliyoruz? Sermaye Piyasası Kanunu’nun 3. maddesindeki menkul kıymet tanımından. Orada açıkça yazıyor: Paylar, borçlanma araçları ve benzeri kıymetler menkul kıymettir diyor. Çek, bono, nakit gibi şeyler hariç tutuluyor ama tokenlar bu tanımın tam göbeğinde oturabiliyor.
Ne zaman oturur? Eğer bir token şunları yapıyorsa:
O token artık yatırım sözleşmesi değil, düpedüz menkul kıymet oluyor.
Tokenlar Üçe Ayrılıyor
Burada kritik şey şu, tokenin adı değil, sunduğu haklar önemli, bu bilgiyi daha önceki yazılarda da belirttim. ABD’deki Howey testi gibi, Türkiye’de de öz, biçimin önünde.
Yeni düzenlemedeki en çarpıcı madde ile, artık SPK, token’lerin blokzincir üzerinden menkul kıymet olarak ihraç edilmesine açıkça izin verebilecek.
Hem de Merkezi Kayıt Kuruluşu (MKK) gibi geleneksel bir kayıt sistemine gitmeden, doğrudan zincir üstünden takip edilmesini mümkün kılarak :D
Tasarım Gereği Uyum (Compliance by Design) Ne Oluyor? Biz Bunu Nasıl Kullanıyoruz??
Blockchain ekosisteminde bugüne kadar genellikle şu şekilde ilerledik arkadaşlar;
Fakat özellikle menkul kıymet benzeri varlıkların (RWA’ların) tokenizasyonunda bu yaklaşım kesinlikle yeterli değil, çünkü bu tür varlıklar için regülasyonlar baştan belirleyici. Dolayısıyla hukuka uygunluk sonradan eklenen bir filtre olarak gelmiyor, sistemin çekirdeğinde içinde olmak zorunda. Yani protokol seviyesinde bir hukuk gerekli. Buna da biz compliance by design diyoruz.
Bu ilkeye göre, hukuki uyum mekanizmalarımız sistemin sonradan eklenen eklentileri değil, sistemin mimarisinin birinci sınıf bileşenleri olarak başlıyorlar
ERC-3643 tam olarak bu ilkeye göre tasarlanmış bir token standardı zaten, o sebeple anlatıyorum :D
function canTransfer(address from, address to, uint256 amount) public view returns (bool) {
if (!isWhitelisted(to)) return false;
if (getCountry(to) == “IR” || isSanctioned(to)) return false;
if (!hasKYCLevel(to, 2)) return false;
if (amount + balanceOf(to) > MAX_HOLDING[to]) return false;
return true;
}Bakın bu solidity ile bir örnek, bu fonksiyonun varlığı bile ERC-3643’ün compliance by design felsefesini kanıtlıyor.
Yukarıdaki şemadan da anlaşılacağı üzere ERC-3643, bu önceki ERC protokollerimizin üzerine inşa edilmiş olup, düzenlenen security tokenlarımız için kapsamlı bir uyumluluk odaklı mimari sunuyor.
Arkadaşlar, token çıkarmak deyince aklınıza sadece bir smart contract yazmak gelmesin artık. Yukarıda özetlediğim üzere ERC-3643'te durum farklı. Burada her şey uuyumlu, denetlenebilir, revize edilebilir olmak zorunda. O yüzden biz, ERC-3643'te bir token deploy ettiğimizde aslında koca bir altyapı kurmuş oluyoruz.
Adı da: T-REX Suite
Ve bu altyapının kurulumunu yapan şey Factory yapısı (evet bildiğiniz fabrika gibi çalışıyor 😄)
Tüm sistem tek işlemde kuruluyor. Ne var bu sistemde? Hemen anlatayım şöyle toplanın bir:
Ve evet hepsi proxy yapısıyla geliyor. Yani biz deploy ederken hem tek işlemde kuruyoruz, hem de hepsini ileride güncelleyebilecek şekilde kuruyoruz aslında, sorusu olanları göreyim??
Şirket olarak token çıkaracaksınız diyelim (mesela Karakod olarak bankalar adına yapıyoruz ve Trusted Issuerları tamamen biz belirliyoruz). Siz bu suite’in “sahibi” oluyorsunuz. Kim KYC verebilir, kim AML kontrolü yapabilir, siz karar veriyorsunuz. Yani kontrol tamamen sizde :D
Bu konuda hızlı bir Bootcamp veya Workshop vereceğiz, uygun zamanı sizlere duyuracağım sosyal medyamdan. Hukuki kısmı bir sonraki yazıya bırakarak devam ediyorum (Yeterince uzun oldu zaten, Vedat Güven Hocam kızmadan bitirelim) Şimdilik bu kadar diyeyim, serinin ikinci yazısında görüşürüz o halde! Sevgiler!
Sizlerle yakında bir eğitimde buluşmayı dört gözle bekliyorum değerli okuyucularım :) Kitaplarla ve ilimle kalın..
İletişim için:
İçeriklerime YouTube kanalım üzerinden ulaşabilirsiniz. Hakkımda daha fazla bilgi edinmek için websitemi ziyaret edebilir, teknik konularda destek almak için bana ulaşabilirsiniz! 👩🏻💻
— Elif Hilal | Karakod LC³ Build smart. Code clean. Stay compliant.