FİNTEK FIKHI – 2

Çok Katmanlı Referans Mimari:

Oracle, DID, Akit Motoru ve Tokenizasyon

(Sistem mimarları, geliştiriciler, şer‘î/iç denetim, düzenleyiciler ve Ahilik–tasavvuf ehli için teknik–fıkhî tasarım belgesi)

Özet

Bu makale, “Fintek Fıkhı” yaklaşımını blokzincir üzerinde uygulanabilir kılmak için çok katmanlı bir referans mimari sunar: (i) kimlik ve yetkilendirme (DID/VC), (ii) varlık kaydı ve token ontolojisi (GTİP Token /  Parsel NFT / Dönüm Token), (iii) fıkhî parametrik Akit Motoru, (iv) oracle ve doğrulama altyapısı, (v) denetim/izlenebilirlik ve regülasyon uyumu, (vi) operasyonel risk ve ölçeklenebilirlik stratejileri. Makale-1’de kurulan “güven mimarisi” ve “meta para” tezini, teknik olarak “token arzı = rezerv varlık” ilkesine bağlı, depo/emanet altyapısıyla çipalanmış ve programlanabilir temsil ile fıkhi–fizikî gerçekliğe bağlanmış bir mimaride somutlaştırır.

Bu tasarım, fıkhı “etik etiket” olarak eklemlemek yerine; kural/ilke/istisna/maslahat katmanlarını “kod seviyesinde şeffaf, denetlenebilir ve tartışılabilir” bir mimariye dönüştürmeyi hedefler. Ayrıca, ölçeklenebilirlik, enerji tüketimi, regülasyon (merkez bankaları, AML/CFT), hukuki statü, uyuşmazlık çözümü ve sosyo-ekonomik etki konuları mimari katmanlarda birer “tasarım kısıtı” olarak ele alınır.

Anahtar kavramlar

Fintek Fıkhı, çok-fıkıhlı akit motoru, oracle, DID, verifiable credentials, GTİP Token, Parsel NFT, Dönüm Token, Dijital Süftece, Dijital Selem, murâkabe, reg-tech, auditability, asset-backed token, shariah-by-design.

  1. Giriş: Makale-2’nin seri içindeki yeri ve hedef kitle

Makale-1, epistemolojik çerçeveyi ve “mal–para ontolojisi” tartışmasını kurmuştur; Makale-2 ise bu çerçeveyi teknik bir referans mimariye dönüştürür.

Makale-2’nin başlığı ve kapsamı, Makale-1’de açıkça “Oracle, Akit Motoru ve Tokenizasyon” olarak tanımlanmıştır.

Hedef kitleler (tasarımın çok-dilli paydaş haritası):

  1. Sistem mimarları ve geliştiriciler: zincir, oracle, DID, akit motorunu fıkhî parametrelerle birlikte tasarlamak isteyen mühendisler.
  2. Şer‘î denetim ve iç denetim ekipleri: ürün geliştirmeye “kod seviyesinde” dahil olmak isteyen Mutasavvıf ve fıkıh uzmanları/şer‘î kurul üyeleri.
  3. Regülasyon ve gözetim kurumları: şer‘î uyum, veri izlenebilirliği, operasyonel risklerin teknik yönetimini görmek isteyen politika yapıcılar.
  4. Ahilik mütehassısları ve tasavvuf erbabı: “piyasa ahlakı, emanet, kul hakkı, ihsan” gibi üst değerlerin dijital medeniyet tasarımına nasıl gömüleceğini görmek isteyen normatif rehberlik paydaşları (bu makalede “değer–tasarım arayüzü” olarak ele alınacaktır).

Makale-2’nin problemi:
“Fıkıh ile blokzincir uyumu mümkündür” önermesi Makale-1’de teorik olarak kurulmuştur.

Makale-2’nin görevi, bu uyumu bileşen mimarisi ve kontrol noktaları biçiminde göstermek; teknik/hukukî riskleri mimarinin içine “kısıt ve denetim” olarak yerleştirmektir.

  1. Tasarım ilkeleri: “Şer‘î uyum”u sonradan değil, baştan kodlamak

Bu bölüm, teorik çerçevenin uygulanabilirliğini ve “fıkhı algoritmikleştirmeye indirgeme riski”ne düşmeden mimari yanıtı kurar: fıkıh, mekanik bir if-else listesi değildir; fakat tasarım kararlarının normatif gerekçelerini görünür kılacak bir “kural + ilke + istisna + maslahat” çerçevesi olarak yazılıma taşınabilir.

2.1. Şer‘î uyum seviyeleri (compliance maturity)

  • Seviye-0 (Etiket): Ürün sonradan “şer‘î uygun” diye pazarlanır; kod/denetim izi yoktur.
  • Seviye-1 (Kural seti): Temel yasaklar/şartlar kurala dökülür; ancak istisna ve bağlam yönetimi zayıftır.
  • Seviye-2 (İlke tabanlı tasarım): kavâid-i fıkhiyye, makâsıd ve örf/bölgesel içtihat farklılıkları parametreleşir; denetim izi oluşur.
  • Seviye-3 (Şer‘î + regülasyon + risk entegre): AML/CFT, tüketici koruması, teminat/iflas/uyuşmazlık çözümü ve gözetim arayüzleri birlikte çalışır.

Makale-2, hedef olarak Seviye-2-3’ü benimser.

2.2. Fıkhî “kontrol amaçları” (control objectives)

Mimari, şu kontrol amaçlarını sağlamadıkça “şer‘î uyum” iddiası teknik karşılık kazanmaz:

  1. Ribâ riski kontrolü (fiyatlama, ücret, gecikme, faizleşen hizmet bedeli)
  2. Gharar/maysir kontrolü (belirsizlik, teslim niyeti, spekülatif türevleşme)
  3. Kabz ve teslim izlenebilirliği (hükmî kabz koşulları dâhil)
  4. Mülkiyet ve emanet ayrımı (custody vs. ownership; emanetin suistimali)
  5. Maslahat/zaruret/örf istisnalarının şeffaf yönetimi (kimin, hangi gerekçeyle, hangi log ile istisna verdiği)

Makale-1’de selem örneği, AAOIFI (İslami Finans Kurumları Muhasebe ve Denetim Teşkilatı) şartlarını “peşin ödeme” ve “nitelik-teslim açıklığı” olarak somutlaştırıp akıllı sözleşmeye taşınabilir görür.

Bu, kontrol amaçlarının çekirdeğini verir.

  1. Referans mimarinin üstten görünümü: Katmanlar ve veri akışları

Makale-1, Makale-2’de ele alınacak bileşenleri açıkça listeler: çok-fıkıhlı akit motoru, oracle mimarisi, GTİP Token / Dönüm Token / Parsel NFT zinciri ve Dijital Süftece–Selem.

Burada bunu katmanlara ayırıyoruz.

3.1. Katmanlar

L0 – Normatif katman: fıkhî parametre setleri + regülasyon kısıtları + “Ahilik–ihsan” etik kontrol hedefleri
L1 – Kimlik ve yetki: DID + Verifiable Credentials (VC) + rol tabanlı yetkilendirme
L2 – Varlık kayıt katmanı: Parsel NFT (arazi), Depo/Emtia NFT (parti), GTİP Token (mislî), Dönüm Token (arazi-kapasite/rezerv)
L3 – Oracle ve doğrulama: depo girişi/çıkışı, kalite sertifikası, GTİP/HS sınıflandırma, lojistik olaylar
L4 – Akit Motoru: akit şablonları (selem, süftece, murabaha, icâre vb.) + fıkhî parametreler + istisna yönetimi
L5 – Mutabakat ve muhasebe: settlement, ücretler (ücret-i amel), teminat/likidasyon, muhasebe kayıtları
L6 – Denetim ve gözetim: şer‘î denetim logları, iç denetim, reg-tech raporlama, uyuşmazlık çözümü
L7 – Ölçek ve güvenlik: L2/L3 rollup, permissioning, anahtar yönetimi, saldırı yüzeyi azaltma

3.2. Mimari hedef: “Fizikî gerçekliğe çipalanmış token”

Makale-1’de GTİP Token yaklaşımı üç şartla bağlanır: standartlaştırma, depo/emanet altyapısı, programlanabilir temsil.

Makale-2’nin temel iddiası: Bu üç şart, tokenizasyonun “spekülatif temsil”e kaymasını engelleyen teknik-hukukî emniyet kemeridir.

  1. Kimlik ve yetkilendirme: DID/VC ile “emanet ehliyeti” ve rol güvenliği

“Hukukî ve operasyonal riskler”in çoğu kimlik ve rol tasarımından başlar. Bu nedenle referans mimaride DID/VC, sadece KYC değil; yetkinlik, ehliyet ve sorumluluk modelidir.

4.1. Rol modeli (örnek)

  • Üretici (Çiftçi/İmalatçı)
  • Alıcı/Yatırımcı
  • Lisanslı depo operatörü (emanetçi)
  • Kalite/sertifikasyon kurumu
  • Oracle operatörü (veri sağlayıcı)
  • Şer‘î denetçi (kural seti yayınlama/inceleme)
  • İç denetçi (operasyonel kontrol)
  • Düzenleyici gözlemci (sınırlı okuma/rapor erişimi)
  • Uyuşmazlık hakemi/heyeti (ihtilaf çözümü)

4.2. VC tipleri (örnek)

  • “Lisanslı Depo Yetki Belgesi” (süreli, iptal edilebilir)
  • “Kalite Sertifikası Yetkisi”
  • “Şer‘î Denetçi Yetkisi” (hangi mezhep/kurul adına)
  • “Oracle Sağlayıcı Yetkisi” (hangi veri tipleri için)

Bu yaklaşım, “kimin hangi veriyi zincire yazabileceği” sorununu çözer; aynı zamanda sorumluluk izini sağlar (murâkabe).

  1. Token ontolojisi ve varlık modellemesi: GTİP Token / Dönüm Token / Parsel NFT

Makale-1, dijital varlıkları fıkhî açıdan mislî (fungible) / kıyemî (NFT) ayrımıyla ele alır.

Makale-2, bu ayrımı mimarinin veri modeline gömer.

5.1. Parsel NFT (kıyemî): Arazi kimliği ve rezerv kapasite

Parsel NFT, belirli bir arazi parselini temsil eder. Bunun kendisi “mülkiyet” mi “kullanım hakkı” mı, ülke hukukuna göre farklı olabilir; mimari bu nedenle Parsel NFT’yi üç seviyeli tanımlar:

  • Seviye A: Bilgi NFT (mülkiyet iddiası değil, kayıt/harita kimliği)
  • Seviye B: Hak NFT (kullanım/ürün üzerinde hak)
  • Seviye C: Mülkiyet NFT (hukuken tanınan tokenize mülkiyet)
  • Seviye D: Ürün deseni, dekara verim, mikro biyolojik analizler, fiziki coğrafi konum

“Hukukî statü belirsizliği” burada tasarım kararı olur: her ülke için Seviye A/B/C/D seçilir.

5.2. GTİP Token (mislî): Emtia sınıflandırması + depo çipası

GTİP/HS kodu “malı tanımlar ama varlığı garanti etmez”; bu nedenle depo/emanet altyapısı gerekir.

GTİP Token tasarımında token arzı = rezerv varlık miktarı ilkesi (meta para tezi) teknik bir “mint/burn” kuralına dönüşür.

Mint koşulu (örnek):

  • Depoya giriş olayı (WMS/ELÜS benzeri) + kalite sertifikası + parti kimliği (NFT) + GTİP kodu doğrulanır
  • Ardından GTİP Token mint edilir (1 token = 1 birim emtia; ölçü birimi net)

Burn koşulu:

  • Depodan çıkış + teslim teyidi + kabz tamamlanması ile token burn edilir

Bu, spekülasyon alanını daraltıp reel teslimi zorunlu kılar (Makale-1’in selem akışında da depo/kalite/GTİP verilerinin parti kimliğine yazılması kurgulanır).

5.3. Dönüm Token: Kapasite/rezerv temsili ve “atıl arazi”nin iktisada katılması

Dönüm Token, Parsel NFT’den türetilen kapasiteyi (ör. hektar başına beklenen verim bandı) temsil eder; ancak burada iki risk vardır:

  1. Gharar: kapasite tahmininin belirsizliği
  2. Aşırı finansallaşma: arazi kapasitesinin türevleşmesi

Bu nedenle Dönüm Token doğrudan alım-satım nesnesi değil; belirli akitlerde “teminat/limit” parametresi olarak kullanılır (ör. selemde satılabilecek maksimum miktar, parselin kapasite bandına bağlanır).

  1. Oracle mimarisi: “Şahitlik”in dijitalleştirilmesi ve veri güveni

“Fizikî varlığın dijitalleştirilmesi” ve “oracle güveni” Makale-1’in GTİP Token yaklaşımı zaten depo/emanet altyapısı ve programlanabilir temsil şartını koyarak bunun farkındadır.

Makale-2’de oracle mimarisi, “tek bir veri kaynağı”na değil, çoklu şahitlik (multi-attestation) modeline dayanır.

6.1. Oracle tipleri

  • Durum oracle’ı: depo giriş/çıkış, sevkiyat, sigorta
  • Nitelik oracle’ı: kalite/analiz sertifikası
  • Sınıflandırma oracle’ı: GTİP/HS kodu ve teknik spesifikasyon
  • Fiyat oracle’ı: yalnızca belirli akitlerde ve sınırlı kullanımda (ribâ/garar riskine dikkat)

6.2. Çoklu şahitlik (minimum güven seti)

Bir emtia partisinin zincire “rezerv” olarak kabulü için şu kombinasyon zorunlu tutulur:

  • Lisanslı depo imzası (VC ile doğrulanmış)
  • Kalite kurumu imzası (VC)
  • (Opsiyonel) Sigorta/lojistik imzası
  • Zaman damgası + parti NFT referansı

6.3. Veri bütünlüğü ve mahremiyet

Regülasyon ve ticari sırlar nedeniyle her verinin “açık zincire” yazılması doğru değildir. Referans mimari:

  • Zincire hash/taahhüt yazma
  • Detay veriyi izinli veri kasası (data vault) içinde saklama
  • Denetçi/düzenleyici için kademeli erişim (selective disclosure)

şeklinde bir hibrit desen önerir.

  1. Akit Motoru: “Çok-fıkıhlı” parametrik sözleşme yürütme katmanı

Makale-1, Makale-2’de “çok-fıkıhlı akit motoru”nun ayrıntılandırılacağını söyler.

Buradaki amaç: aynı ekonomik işlemin, farklı mezheplerin şart/istisna setleriyle çalıştırılabilmesi; ve bunun denetlenebilir olmasıdır.

7.1. Akit Motoru bileşenleri

  • Akit şablonları: selem, süftece, murabaha, icâre, vekalet vb.
  • Fıkhî parametre setleri: (Hanefî/Şafiî vb.) şartlar, yasaklar, ihtilaflı alanlar
  • Kural değerlendirme motoru: “izin ver / reddet / insan-onayı iste” kararları
  • İstisna/zaruret modülü: kim verdi, hangi gerekçeyle, hangi süreyle?
  • Denetim izi: kararın dayandığı parametre sürümü + veri kaynakları

7.2. İndirgeme riskine karşı tasarım: Kural + İlke + Gerekçe

Her kuralın yanında “gerekçe” alanı tutulur:

  • Dayandığı kaynak (AAOIFI standardı, kurul kararı vb.)
  • Amaç (ribâyı önleme, ghararı azaltma, kabzı güvenceleme)
  • Tartışmalı mı? (ihtilaf bayrağı)
  • İnsan onayı gerektirir mi?

Bu sayede “fıkıh = mekanik kod” yerine “fıkıh = izah edilebilir normatif karar sistemi” yaklaşımı korunur.

  1. Referans akitler: Dijital Süftece ve Dijital Selem’in uçtan uca akışı

8.1. Dijital Süftece (kripto havale) – Ücretin ribâya dönüşmemesi

Makale-1, blokzincir tabanlı süfteceyi geleneksel SWIFT’e kıyasla hız/maliyet açısından konumlandırır.

Ancak fıkhî sınır nettir: transfer ücreti, paranın miktarı/vadesine göre değil; yapılan işleme ve altyapıya göre “ücret-i amel” olmalıdır.

Mimari kural:

  • Fee = sabit + kaynak tüketimi (gas) + açıkça tanımlı hizmet kalemleri
  • Fee’nin “vade/ miktar”la doğrusal faiz benzeri davranış göstermesi engellenir (rate cap + denetim)

8.2. Dijital Selem (akıllı vadeli işlem) – AAOIFI koşullarının kodlanması

Makale-1, selemde “peşin ödeme” ve “malın nitelik-teslim bilgilerinin açıklığı” şartlarının akıllı sözleşmede uygulanabilir olduğunu söyler.

Uçtan uca akış (Makale-1 ile uyumlu):

  1. Üretici, ekim aşamasında selem sözleşmesi açar.
  2. Alıcı bedeli peşin öder; akıllı sözleşme teyit eder; hükmî kabz oluşur.
  3. Hasatta teslim olmazsa teminat mekanizması devreye girer.
  4. Teslimde GTİP kodu, kalite sertifikası, depo girişi verileri parsel/ürün/parti NFT’ye yazılır.

Bu akış, modern türevlerdeki “teslimsiz bahisleşme” riskine karşı teslimi merkez yapar; Makale-1’in “futures çoğu zaman teslimsiz fiyat farkı bahsine dönüşür” şeklinde eleştiriye açık olması burada izale edilir.

  1. Ölçeklenebilirlik, enerji ve performans

Makale-1’de “Ölçeklenebilirlik, enerji tüketimi, işlem hızı” eksikliği Makale-2’de bu, mimari seçimlerle ele alınır.

9.1. Zincir seçimi stratejisi: “İşlem yoğunluğunu katmanlara dağıt”

  • Ana zincirde: sadece kritik durum değişiklikleri (mint/burn, akit imzaları, teminat kilidi, uyuşmazlık kararları)
  • Yan katmanda (L2/rollup): sık olaylar (lojistik olaylar, depo içi hareketler), toplu hash’leme
  • Off-chain: büyük belgeler (sertifika PDF’i vb.), zincire hash/taahhüt

Bu strateji, hem ölçek hem enerji maliyetini aşağı çeker; ayrıca düzenleyici ve denetim ihtiyaçlarını “doğrulanabilir kayıt” ile karşılar.

9.2. İzinli/hibrit yaklaşım: Regülasyon ve ticari sırlar

Tamamen açık zincir bazı sektörlerde mümkün olmayabilir. Bu nedenle:

  • Varlık kaydı ve denetim izleri: izinli konsorsiyum zinciri
  • Kamusal doğrulanabilirlik: periyodik “checkpoint” hash’lerinin kamu zincirine ankrajı

9.3. Operasyonel güvenlik

  • Anahtar yönetimi (HSM/MPC)
  • Rol tabanlı yetki + “dörtlü imza” (depo+kalite+oracle+denetçi) gibi kritik eylemler
  • Olay izleme ve anomali tespiti (iç denetim katmanı)
  1. Regülasyon uyumu ve gözetim arayüzü: “Denetlenebilirlik” bir ürün özelliği değil, mimari zorunluluk

Makale-1, blokzincirin “kayıtlılık ve denetlenebilirlik” prensipleriyle fıkhî çerçeve arasında ontolojik uyum kurar.

Makale-2 bunu reg-tech’e çevirir.

10.1. Denetim izleri (audit trails)

Her kritik işlem şunları loglar:

  • İşlem kimliği, zaman, taraf DID’leri
  • Kullanılan fıkhî parametre seti sürümü
  • Oracle kanıtları (hash + imza)
  • Ücret hesaplama yöntemi (ribâ riskine karşı)
  • İstisna varsa: kim, hangi gerekçeyle?

10.2. AML/CFT ve gözetim

Bu makalede ayrıntılı “yasa uyum metni” yerine, düzenleyicinin görmek isteyeceği teknik mekanizma çizilir:

  • Kademeli kimlik doğrulama (risk bazlı)
  • Şüpheli işlem bayrakları (kural motoru ile)
  • Dondurma/inceleme akışı (hukuki süreçle uyumlu “pause” mekanizması)
  1. Uyuşmazlık çözümü ve hukukî köprü: Zincir üstü icra tek başına yeterli değildir

Makale-1’de “Anlaşmazlık çözümü” eksikliği vardı. Makale-2, bunu mimariye “Arbitration & Appeals” modülü olarak koyar.

  • Zincir üstü otomasyon: teslim/teminat/ödeme gibi objektif olaylar
  • İnsan kararına açık alan: kalite ihtilafı, mücbir sebep, dolandırıcılık iddiası
  • Hakem/heyet kararı zincire “imzalı hüküm” olarak düşer; akit motoru kararı icra eder

Bu yaklaşım, fıkhın bağlam ve maslahat boyutunu korur; “tam otomasyon” iddiasıyla indirgemeciliğe düşmez.

  1. Ahilik ve tasavvuf perspektifi: “Emanet, ihsan, kul hakkı”nın mimariye tercümesi

Bu paydaş grubu için kritik olan nokta şudur: sistem sadece “işler” değil; erdem üretir mi?

12.1. Emanet (custody) tasarımı

Depo/emanet altyapısı Makale-1’de GTİP Token için şarttır.

Burada emanet, teknik olarak:

  • Depo operatörünün keyfî tasarrufunu engelleyen erişim kontrolleri
  • Çift kayıt/çoklu imza
  • Denetçi gözlemi
    ile güçlendirilir.

12.2. İhsan (kalite) tasarımı

Kalite sertifikası sadece ticari veri değil; hakkaniyet ölçüsüdür. Kalite oracle’ları ve sertifika VC’leri, “ölçüde ve tartıda hile” riskini azaltan dijital karşılık olur (Makale-1’in “kayıtlı defter” fikriyle uyum).

12.3. Lonca mantığı ve şer‘î kurullar

Ahilikte “ehliyet–liyakat–meslek ahlakı” kurumsal bir yapıdır. Mimari bunu:

  • Yetki VC’leri
  • Kurul parametre setleri
  • İptal/askı mekanizmaları
    şeklinde “dijital lonca”ya çevirir.
  1. Örnek teknik ek: Veri şemaları ve sözleşme iskeletleri (kısa)

Aşağıdaki parçalar, Makale-2’nin “prototipe giden yol” iddiasını somutlaştırmak için verilmiştir (tam kapsam Makale-2 eklerinde genişletilmiştir. Ayrıntı incelemek isteyenler eklerden devam edebilir.).

13.1. Selem sözleşmesi için örnek JSON şeması (özet)

{

“contract_type”: “SELEM”,

“fiqh_profile”: {

“school”: “AAOIFI_BASELINE”,

“version”: “1.0.0”,

“requires_full_prepayment”: true,

“requires_specification”: [“gtip_code”, “quantity”, “quality_grade”, “delivery_place”, “delivery_date”]

},

“parties”: {

“seller_did”: “did:example:farmer123”,

“buyer_did”: “did:example:buyer789”,

“sharia_auditor_did”: “did:example:sharia456”

},

“asset”: {

“parcel_nft_id”: “PARCELNFT#TR-16-XXXX”,

“gtip_code”: “1001.99”,

“quantity”: {“value”: 10000, “unit”: “kg”},

“quality_grade”: “A”,

“warehouse_required”: true

},

“payment”: {

“amount”: {“value”: 500000, “currency”: “TRY”},

“timing”: “UPFRONT”

},

“collateral”: {

“type”: “WAREHOUSE_RECEIPT”,

“min_ratio”: 1.1

},

“events_required”: [

“WAREHOUSE_INBOUND_ATTESTATION”,

“QUALITY_CERT_ATTESTATION”

],

“dispute_resolution”: {

“arbitration_panel”: “PANEL#001”,

“appeal_window_days”: 7

}

}

13.2. Mint/Burn kontrolünün “rezerv çipası” mantığı (özet)

  • Mint: depo+sertifika+GTİP+parti NFT doğrulanmadan yasak
  • Burn: teslim/kabz doğrulanmadan yasak

Bu, Makale-1’in “depo/emanet + programlanabilir temsil” şartını doğrudan kod kuralına çevirir.

  1. Sonuç: Makale-2’nin çıktısı ve Makale-3’e köprü

Bu makale, Makale-1’in ontolojik tezini “uygulanabilir mimari”ye çevirdi. Makale-2’nin en kritik katkısı şudur:

  1. Tokenizasyonu “spekülatif temsil” olmaktan çıkarıp rezerv çipası + çoklu şahitlik ile fiziki gerçekliğe bağlamak,
  2. Selem ve süftece gibi tarihî akitleri, AAOIFI gibi standardizasyon şartlarını kod seviyesinde uygulayacak şekilde yürütmek,
  3. “çok-fıkıhlı akit motoru” ile mezhep/kurul farklılıklarını şeffaf ve denetlenebilir parametre setlerine dönüştürmek,
  4. Denetim ve regülasyon uyumunu “sonradan rapor” değil, mimarinin asli katmanı yapmak.

Makale-3’te bu mimarinin yönetişim, hukukî uyum, kalkınma iktisadı ve medeniyet tasavvuru açısından ne ifade ettiği tartışılacaktır.

EKLER (GENİŞLETME)

Makale2 burada tamamlanmıştır. Bu genişletilmiş kısım yukarıda kurduğumuz özet paradigmaya yönelik ayrıntılı eleştirel bakışa cevap niteliğindedir.  Analitik eleştirileri ile katkı vereceklere önerilir.

EK–1: Bileşen-bileşen Tehdit Modeli (Threat Model)

Bu tehdit modeli, “şer‘î uyum”un teknik karşılığını güçlendirmek için üç hedefe odaklanır:
(1) Varlık gerçeği (rezerv gerçekten var mı?), (2) Yetki gerçeği (işlemi yapan ehil mi?), (3) Denetim gerçeği (kural/istisna/karar izleri silinemez mi?). “Token arzı = rezerv varlık” ilkesi, tehdit modelinin ana güvenlik varsayımıdır.

1.1. Saldırı yüzeyi haritası (yüksek seviye)

  • Kimlik & Yetki (DID/VC): sahte kimlik, yetki kötüye kullanımı, anahtar hırsızlığı
  • Oracle & Veri kanıtı: manipülasyon, veri gecikmesi, veri çakışması, sahte sertifika
  • Depo/Emanet: hayali stok, çift rehin/çift makbuz, kalite düşürme, zimmet
  • Akit Motoru: kural seti zehirleme, parametre sürümü çarpıtma, “istisna” suistimali
  • Tokenizasyon: mint/burn bypass, re-entrancy, fiyat/ücret faizleşmesi
  • Yönetişim/İçerden tehdit: denetçi/operatör işbirliği, log silme, yetki devri suistimali

1.2. Tehdit kataloğu (STRIDE uyarlaması + kontrol hedefleri)

Aşağıdaki tablo “tehdit → etki → tespit → önleme/azaltma → denetim izi” zinciriyle ilerler.

  1. A) Oracle manipülasyonu
Tehdit Etki Tespit Önleme/Azaltma Denetim izi (şer‘î/iç denetim)
Sahte kalite sertifikası (oracle/sertifikacı ele geçirilir) Gharar artar; teslimde ihtilaf; kul hakkı Çoklu şahitlik tutarsızlığı; sertifika VC iptal listesi Çoklu imzalı attestation (depo+sertifikacı+sigorta); VC revocation; sertifika hash’inin bağımsız arşivi Sertifika VC kimliği, imza zinciri, revocation kontrolü logu
Veri gecikmesi / zaman manipülasyonu Selem teslim/teminat tetiklemeleri yanlış çalışır Olay zaman damgası tutarsızlıkları “time window” kuralı; saat senkronu; gecikme tolerans prosedürü Gecikme nedeni, “manual review” kaydı
Oracle sağlayıcının çıkar çatışması Fiyat/kalite şişirme → spekülasyon Davranış analitiği, korelasyon anomali Oracle’ı ayır: fiyat oracle’ı sınırlı; kalite oracle’ı bağımsız; oracle rotasyonu Oracle sağlayıcı risk puanı, geçmiş performans

Not: Makale-1’in GTİP Token yaklaşımı “mal tanımlanır ama varlık/teslim garanti edilmez” diyerek oracle riskinin kaçınılmazlığını kabul eder; çözümü “depo/emanet + programlanabilir temsil” ile birlikte tasarlar.

  1. B) Depo suistimali (emanet ihlali)
Tehdit Etki Tespit Önleme/Azaltma Denetim izi
Hayali stok (non-existent inventory) Token arzı rezervi aşar; “meta para” tezi çöker Depo giriş/çıkış tutarsızlığı; bağımsız denetim sayımı Mint yalnızca depo+sertifika+ELÜS benzeri kayıt ile; periyodik fiziki sayım attestation Mint işlemi attestation seti + sayım raporu hash’i
Çift rehin / çift makbuz Aynı mal iki akitte teminat olur; ihtilaf Parti NFT’nin teminat durumu kontrolü “encumbrance registry”: parti NFT üzerinde rehin flag’i; rehin kaldırmadan transfer yasak Rehin tesis/kaldırma imzaları
Kalite düşürme / karıştırma Alıcı zarar; ihtilaf; maysirleşme Lot kimliği izleri + kalite tekrar testi Parti NFT “chain-of-custody”; mühür/QR; ikinci test tetikleyici Kimin elinde ne zaman, hangi testle onaylandı

Bu bölüm, GTİP Token’ın “depo/emanet altyapısı” şartını güvenlik kontrolüne çevirir.

  1. C) Kimlik sahteciliği / yetki kötüye kullanımı
Tehdit Etki Tespit Önleme/Azaltma Denetim izi
Sahte DID/kimlik AML/CFT riski, dolandırıcılık KYC/VC doğrulama hataları Risk bazlı KYC; DID bağlama; cihaz/anahtar güvenliği VC doğrulama logları
Yetki devri suistimali (depo operatörü rolü) Mint/burn sahteciliği Yetki değişim anomali Multi-sig + ayrık görev (SoD); yetki için süreli VC Yetki verme/iptal kayıtları
Anahtar hırsızlığı Hesap boşaltma, sözleşme suistimali Anomali tespiti MPC/HSM; “cooldown”; acil durdurma (pause) Pause nedeni + olay kaydı
  1. D) İçerden tehdit (insider threat)
Tehdit Etki Tespit Önleme/Azaltma Denetim izi
Depo + sertifikacı işbirliği Sistemin en kritik “rezerv doğruluğu” kırılır Çoklu şahitlik korelasyon analizi Bağımsız üçüncü taraf sayım; rastgele denetim; sigorta şartı Denetim seçimi algoritması + rapor
Şer‘î denetçi/kurul parametre suistimali “İstisna” ile haram/ribâ kapısı açılır Parametre sürüm değişikliği izlemesi Parametre sürüm yönetişimi (imza, oylama, bekleme süresi); açıklama zorunluluğu Kural seti diff + gerekçe
Geliştirici backdoor Sözleşme güvenliği çöker Code audit; formal verification bulguları Reproducible builds; bağımsız audit; kill-switch prosedürü Audit rapor hash’i, sürüm imzası

1.3. Kritik güvenlik tasarım kararları (özet)

  1. Mint/Burn “attestation gate”: depo+sertifika+parti NFT olmadan mint yasak (rezerv çipası).
  2. Çoklu şahitlik: tek oracle’a güvenme; en az iki bağımsız imza + revocation kontrolü.
  3. SoD (segregation of duties): aynı kişi/kurum hem veri üretmesin hem onaylamasın.
  4. Parametre sürüm yönetişimi: fıkhî setler “kod gibi” sürümlenir; değişiklikler gerekçeli ve denetlenebilir.
  5. Uyuşmazlık modülü: kalite/zaruret/örf gibi bağlamsal alanlar için insan-hakem katmanı.

EK–2: Regülasyon Uyum Matrisi (Katman → Kontrol → Çıktı)

Bu matris, düzenleyici otoriteler ve gözetim kurumları için “hangi katman hangi kontrolü sağlıyor?” sorusuna cevap verir. Ayrıca şer‘î/iç denetim ekipleri için de kontrol hedeflerini kod seviyesinde görünür kılar.

2.1. Kontrol alanları (başlıklar)

  • İzlenebilirlik (traceability)
  • Denetim izi (audit trail / immutability)
  • Tüketici/katılımcı koruması (hata, suistimal, şeffaf ücret)
  • Operasyonel risk yönetimi (anahtar, siber risk, iş sürekliliği)
  • Varlık bütünlüğü (rezerv, teminat, teslim)
  • AML/CFT uyumu (risk bazlı kimlik, izleme, raporlama)

2.2. Katman bazlı uyum matrisi

Katman İzlenebilirlik Denetim izi Tüketici koruması Operasyonel risk AML/CFT Varlık bütünlüğü
L1 Kimlik (DID/VC) Rol/ehliyet izi VC doğrulama logu Yetkili taraf garantisi Anahtar yönetimi (MPC/HSM) Risk bazlı KYC Sahte rol engeli
L2 Varlık kayıt (NFT/Token) Parti/parsel zinciri Mint/burn kayıtları Şeffaf varlık tanımı Token sözleşme güvenliği Sahiplik şeffaflığı Rezerv ile arz bağı
L3 Oracle Olay/teslim zinciri Attestation imzaları Yanlış veri itirazı Oracle rotasyonu Şüpheli olay bayrağı Depo+kalite kanıtı
L4 Akit Motoru Akit yaşam döngüsü Parametre sürüm izi Ücret/şart şeffaflığı Kural motoru güvenliği Kurala dayalı izleme Ribâ/garar kontrolü
L6 Denetim/Gözetim Raporlama API İmmutable log + hash Şikâyet/itiraz akışı İş sürekliliği planı SAR benzeri çıktılar Teminat/teslim delili
L7 Ölçek/Güvenlik Olayların bütünlüğü Checkpoint/anchoring Sistem sürekliliği Incident response İzleme altyapısı DDoS/operasyon dayanımı

Bu tabloyu, Makale-1’in “blokzincirin şeffaflık, kayıtlılık, denetlenebilirlik prensipleri” vurgusunun teknik karşılığı olarak okuyabilirsiniz.

2.3. Ücret ve faizleşme riski (Süftece özel kontrolü)

Süftece’de regülasyon + şer‘î uyumun ortak hassasiyeti “ücretin faizleşmesi”dir. Makale-1 bunu açıkça sınırlar: ücret, miktar/vadeye göre değil; hizmete göre alınmalıdır.

Kontrol karşılığı:

  • Fee schedule kamuya açık, formül denetlenebilir
  • Miktar/vade bağımlı oranlar (APR benzeri) yasak
  • Ücret kalemleri (lojistik/saklama/gas) ayrıştırılmış

EK–3: Tam Akit Örnekleri ve Hanefî/Şafiî Parametre Seti Farkları

Aşağıdaki örnekler, “teoriden pratiğe geçiş” eleştirisini doğrudan karşılamak için uçtan uca yürüyebilir şablonlardır. Her örnek:
(i) akdi şema, (ii) kontrol noktaları, (iii) örnek JSON, (iv) parametre farkları, (v) pseudocode içerir.

3.1. Dijital Selem

3.1.1. Fıkhî çekirdek ve kodlanabilir şartlar

AAOIFI Selem standardı: ödeme peşin + malın nitelik/t teslim bilgilerinin açık belirlenmesi.

Makale-1’in uçtan uca akışında da: ekim aşaması, peşin ödeme, hükmî kabz, teslim edilmezse teminat, teslimde GTİP+kalite+depo verisi NFT’ye yazma adımları vardır.

3.1.2. Akit yaşam döngüsü (state machine)

Durumlar:

  1. Draft → 2) ShariahReviewed → 3) Funded(UpfrontPaid) → 4) InProduction → 5) DeliveryWindowOpen → 6) Delivered / Defaulted → 7) Settled

Kritik olaylar:

  • UpfrontPaymentConfirmed (hükmî kabz)
  • WarehouseInboundAttested + QualityCertAttested (teslim kanıtı)
  • DefaultTrigger (teslim gerçekleşmezse teminat)

3.1.3. Selem sözleşmesi JSON (detay)

{

“contract_type”: “SELEM”,

“contract_id”: “SELEM-2025-0001”,

“fiqh_profile”: {

“madhhab”: “HANAFI”,

“version”: “2.0.0”,

“aaoifi_baseline”: true,

“rules”: {

“full_prepayment_required”: true,

“specification_required”: [“gtip_code”, “quantity”, “unit”, “quality_grade”, “delivery_date”, “delivery_place”],

“price_fixed_upfront”: true,

“no_resale_before_qabd”: true,

“late_penalty_policy”: “CHARITY_ONLY”,

“khiyar_policy”: {

“khiyar_al_ayb”: true,

“khiyar_al_shart”: false

}

}

},

“parties”: {

“seller”: {

“did”: “did:fintek:farmer123”,

“role_vc”: “vc:farmer_registry_v1”

},

“buyer”: {

“did”: “did:fintek:buyer789”,

“role_vc”: “vc:buyer_kyc_v3”

},

“warehouse”: {

“did”: “did:fintek:warehouse555”,

“role_vc”: “vc:licensed_warehouse_v2”

},

“quality_lab”: {

“did”: “did:fintek:lab222”,

“role_vc”: “vc:quality_lab_v1”

},

“shariah_auditor”: {

“did”: “did:fintek:shariah999”,

“role_vc”: “vc:shariah_board_v4”

}

},

“asset”: {

“parcel_nft”: “PARCELNFT#TR-16-000099”,

“gtip_code”: “1001.99”,

“commodity_name”: “BUĞDAY”,

“quantity”: { “value”: 10000, “unit”: “kg” },

“quality_grade”: “A”,

“delivery”: {

“delivery_date”: “2026-07-15”,

“delivery_place”: “WAREHOUSE#555”,

“delivery_window_days”: 14

}

},

“payment”: {

“currency”: “TRY”,

“amount”: 500000,

“timing”: “UPFRONT”,

“escrow”: {

“enabled”: true,

“escrow_account”: “ESCROW#SELEM-2025-0001”,

“release_conditions”: [“UpfrontPaymentConfirmed”]

}

},

“collateral”: {

“enabled”: true,

“type”: “WAREHOUSE_RECEIPT_OR_CASH”,

“min_ratio”: 1.10,

“liquidation”: {

“trigger”: “DefaultTrigger”,

“method”: “AUCTION_OR_BUYBACK”,

“proceeds_distribution”: [“BuyerFirst”, “Costs”, “SellerRemainder”]

}

},

“oracles”: {

“required_attestations”: [

“WarehouseInboundAttested”,

“QualityCertAttested”

],

“attestation_policy”: {

“multi_sig_minimum”: 2,

“revocation_check”: true,

“time_window_hours”: 48

}

},

“dispute_resolution”: {

“panel_id”: “ARBITRATION#001”,

“appeal_window_days”: 7,

“pause_on_dispute”: true

},

“audit”: {

“log_level”: “FULL”,

“store_hashes_onchain”: true,

“store_docs_offchain”: true

}

}

3.1.4. Hanefî vs Şafiî parametre farkları (örnek set)

Aşağıdaki farklar “mutlak mezhep hükmü” iddiasıyla değil, çok-fıkıhlı motorun nasıl parametrik çalışacağını göstermek için verilmiştir. (Nihai parametre seti: sizin seçtiğiniz şer‘î kurul kararlarıyla sürümlenecektir.)

Parametre Hanefî eğilimli set Şafiî eğilimli set Kod etkisi
Kabz yorumu Hükmî kabzı (escrow + teslim kanıtı) daha geniş yorumlayabilir Kabz/teslim ispatında daha sıkı prosedür isteyebilir required_attestations sayısı / teslim doğrulama
Şart muhayyerliği (khiyar al-shart) Bazı senaryolarda sınırlı veya kapalı Daha yapılandırılmış “iptal penceresi” talep edebilir khiyar_policy ve appeal_window
Ayıp muhayyerliği Her iki mezhepte de güçlü; uygulama prosedürü farklı Benzer; delil standardı sıkılaştırılabilir pause_on_dispute + hakem tetikleri
Teslim penceresi Esnek pencere mümkün Pencere şartları daha daraltılabilir delivery_window_days

3.1.5. Selem akıllı sözleşme pseudocode (özet)

function fundSelem() external onlyBuyer {

require(state == ShariahReviewed);

// AAOIFI: full prepayment required

require(msg.value == price);

escrow.deposit(msg.value);

state = Funded;

emit UpfrontPaymentConfirmed();

}

 

function attestDelivery(bytes attestation) external onlyOracleOrWarehouseOrLab {

require(state == Funded || state == DeliveryWindowOpen);

require(verifyAttestation(attestation)); // multi-sig + revocation check

attestations.store(attestation);

 

if (attestations.meetMinimum(“WarehouseInboundAttested”, “QualityCertAttested”)) {

state = Delivered;

// Write GTIP + quality + warehouse inbound to NFT chain

nftRegistry.appendEvidence(parcelNft, attestationHash(attestation));

settle();

}

}

 

function triggerDefault() external {

require(now > deliveryDate + deliveryWindow);

require(state != Delivered);

state = Defaulted;

collateral.liquidate();

emit DefaultTrigger();

}

3.2. Dijital Süftece (Kripto-Havale)

3.2.1. Fıkhî sınır ve tasarım kısıtı

Makale-1 net sınır koyar: transfer ücreti miktar/vadeye göre değil; yapılan işleme ve altyapıya göre “ücret-i amel / gas fee” olmalıdır.

Bu, regülasyon tarafında da “adil ücret/şeffaflık” kontrolü üretir.

3.2.2. Akit şeması

Taraflar: Gönderici, Alıcı, Süftece ağı operatörü (veya stablecoin ihraççısı), denetçi.

Kontrol noktaları:

  • Ücret formülü sabit ve şeffaf
  • Ücretin faizleşmesini engelleyen “cap + kalem ayrıştırma”
  • AML/CFT: risk bazlı eşik/izleme

3.2.3. Süftece JSON (detay)

{

“contract_type”: “SUFTECE”,

“contract_id”: “SUFTECE-2025-0088”,

“fiqh_profile”: {

“madhhab”: “SHAFII”,

“version”: “1.3.0”,

“rules”: {

“fee_must_be_service_based”: true,

“fee_must_not_depend_on_tenor_or_principal”: true,

“disclose_fee_breakdown”: true,

“no_interest_like_features”: true

}

},

“transfer”: {

“asset”: “GTIP_STABLECOIN#TRY”,

“amount”: 25000,

“sender_did”: “did:fintek:sender111”,

“receiver_did”: “did:fintek:receiver222”

},

“fees”: {

“gas_fee”: “NETWORK_ESTIMATE”,

“service_fee”: {

“fixed”: 15,

“variable”: 0,

“breakdown”: [“routing”, “compliance_check”, “settlement”]

},

“caps”: {

“max_total_fee”: 100

}

},

“compliance”: {

“risk_based_kyc”: true,

“threshold_rules”: [

{ “amount_gt”: 50000, “action”: “ENHANCED_DUE_DILIGENCE” }

],

“monitoring”: true

},

“audit”: {

“log_level”: “FULL”,

“fee_formula_hash”: “HASH#FEEFORMULA_v2”

}

}

3.2.4. Hanefî vs Şafiî parametre farkları (örnek)

Parametre Hanefî set Şafiî set Kod etkisi
Ücret kalemleri Daha katı “hizmet kalemi” ayrıştırması isteyebilir Benzer; ancak şeffaflık ve belirsizlik (garar) hassasiyeti daha sıkı olabilir disclose_fee_breakdown zorunluluğu
Emanet/havale yorumu Ağ operatörünün rolü “emin muhatap” olarak daha belirginleştirilebilir “wakala/emanet” ayrımı daha net şema ister Operatör rol şeması

3.3. Opsiyonel şablon: Murabaha veya İcâre (ikisi de verilmiştir)

Bu bölüm, “sadece Selem/Süftece değil, yaygın finansal ürünler” eleştirisini karşılamak için eklenmiştir. Makale-2’nin kapsamı büyümeksizin, akit motorunun genelleştirilebilirliğini gösterir.

3.3.1. Murabaha (maliyet+kar satışı) – Şablon

Kritik fıkhî kontroller (kodlanabilir):

  • Mal önce satıcı/finansör tarafından mülk edinilecek (ownership before sale)
  • Maliyet ve kâr şeffaf bildirilecek
  • Gecikme cezaları faizleşmeyecek (charity-only veya masraf tazmini politikası)

Murabaha JSON (özet)

{

“contract_type”: “MURABAHA”,

“contract_id”: “MUR-2025-0101”,

“fiqh_profile”: {

“madhhab”: “HANAFI”,

“version”: “1.0.0”,

“rules”: {

“ownership_before_sale_required”: true,

“cost_plus_margin_disclosure_required”: true,

“late_penalty_policy”: “CHARITY_ONLY”

}

},

“asset”: {

“gtip_code”: “8471.30”,

“description”: “ENDÜSTRİYEL SENSÖR SETİ”,

“supplier_invoice_hash”: “HASH#INV-7788”

},

“purchase_phase”: {

“financier_buys_first”: true,

“proof_of_ownership”: [“invoice_hash”, “warehouse_receipt_hash”]

},

“sale_phase”: {

“sale_price”: 120000,

“cost”: 100000,

“margin”: 20000,

“installments”: [

{“due”: “2026-02-01”, “amount”: 30000},

{“due”: “2026-05-01”, “amount”: 30000},

{“due”: “2026-08-01”, “amount”: 30000},

{“due”: “2026-11-01”, “amount”: 30000}

]

},

“audit”: { “log_level”: “FULL” }

}

Hanefî/Şafiî farkları (örnek)

Parametre Hanefî set Şafiî set Kod etkisi
Mülkiyet ispat standardı Fatura+depo makbuzu yeterli görülebilir Daha güçlü “kabz/tasarruf” ispatı istenebilir proof_of_ownership listesi genişler
Gecikme yaklaşımı Charity-only sık kullanılır Charity-only + masraf ayrıştırması daha katı olabilir late_penalty_policy alt kalemleri

3.3.2. İcâre (kiralama) – Şablon

Kritik fıkhî kontroller:

  • Kiralanan şey “menfaat”tir; bakım/riske ilişkin yükümlülükler net olmalı
  • Sigorta/onarım masrafları ribâ/garar doğurmayacak şekilde kurgulanmalı
  • Erken fesih/ayıp durumları uyuşmazlık modülüne bağlı

İcâre JSON (özet)

{

“contract_type”: “IJARA”,

“contract_id”: “IJA-2025-0202”,

“fiqh_profile”: {

“madhhab”: “SHAFII”,

“version”: “1.1.0”,

“rules”: {

“usufruct_defined”: true,

“maintenance_obligations_defined”: true,

“insurance_policy_transparent”: true

}

},

“asset”: {

“asset_nft”: “ASSETNFT#TRACTOR-009”,

“description”: “TARIM TRAKTÖRÜ”,

“condition_report_hash”: “HASH#COND-001”

},

“lease_terms”: {

“start”: “2026-01-01”,

“end”: “2026-12-31”,

“rent”: [

{“due”: “2026-02-01”, “amount”: 15000},

{“due”: “2026-03-01”, “amount”: 15000}

],

“usage_limits”: {“hours_per_month”: 120}

},

“obligations”: {

“lessor”: [“major_maintenance”],

“lessee”: [“operational_care”, “minor_maintenance”]

},

“dispute_resolution”: {

“panel_id”: “ARBITRATION#002”,

“pause_on_dispute”: true

}

}

Hanefî/Şafiî farkları (örnek)

Parametre Hanefî set Şafiî set Kod etkisi
Menfaat tanımı/şartlar Standart menfaat tanımı Menfaat sınırlarının daha ayrıntılı yazımı usage_limits ve raporlama
Bakım yükümlülüğü dağılımı Pratik ayrım seti Daha ayrıntılı risk/bakım sınıflaması obligations granular olur

Bu genişletmenin Makale-2’ye etkisi (kısa özet)

  • Tehdit modeli, GTİP Token yaklaşımının üç şartını (standart+depo/emanet+programlanabilir temsil) doğrudan güvenlik kontrollerine çevirdi.
  • Regülasyon matrisi, mimari katmanların “izlenebilirlik/denetim/tüketici/operasyon” çıktısını netleştirdi (düzenleyici okur için).
  • Akit örnekleri, Selem’de AAOIFI şartlarını kodladı

; Süftece’de ücret-i amel ilkesini faizleşmeye karşı teknik kısıt yaptı

; Murabaha/İcâre ile akit motorunun genelleştirilebilirliğini gösterdi.

Yüksel YENİ
Siyasetçi - Yazar