L0-L7 Katmanları, Oracle, Attestation, Tokenization Engine, Audit Pack, Hibrit NFT-Fungible Tasarım ve Parametrik Akit Motoru

Mal Endeksli Tedavül Aracı Dizisi – Makale 3

 

 “Bu makale, GTİP Token’ın teknik mimarisini, kavramsal ve fıkhî öncülleri veri modelleri, imza akışları, yaşam döngüsü kuralları ve denetim paketleri içinde yürütüme dönüştüren bir sistem tasarımı olarak okumaktadır.”

Özet

Bu makale, GTİP Token makale dizisinin üçüncü halkası olarak, ilk iki makalede kurulan kavramsal ve normatif çerçeveyi uçtan uca teknik mimariye dönüştürmektedir. Çalışmanın temel sorusu şudur: tahsis edilmiş ve doğrulanabilir rezerv mala dayalı “programlanabilir ticaret hakkı” hangi veri modeli, kimlik altyapısı, oracle düzeni, akıllı sözleşme mantığı, denetim paketi ve piyasa ara yüzü üzerinden hayata geçirilebilir? Makalenin ana iddiası, GTİP Token’ın teknik başarısının blokzincir seçimi veya token standardı tercihinden önce, neyin tokenleştirildiğinin açıklığına, hangi verinin hangi yetkiyle sisteme yazıldığının belirlenmesine, hangi riskte hangi otomatik müdahalenin devreye girdiğinin tasarlanmasına ve teslim/kabz tamamlanmadan önce dolaşımın hangi kurallarla sınırlandırıldığının gösterilmesine bağlı olduğudur.¹

Bu amaçla makale, yedi katmanlı bir referans mimari önermektedir: reel ekonomi ve saklama katmanı (L0), semantik varlık veri modeli katmanı (L1), kimlik ve yetkilendirme katmanı (L2), oracle ve çoklu attestation katmanı (L3), tokenization engine ve yaşam döngüsü katmanı (L4), parametrik akit motoru ve işlem protokolleri katmanı (L5), audit pack / reg-tech / yönetişim katmanı (L6) ve kontrollü pazar / interoperability katmanı (L7). Makale ayrıca GTİP/HS kodunu varlığın semantik çekirdeği; DID/VC çiftini tarafların ve yetkilerin makinece doğrulanabilir temsili; Parsel NFT’yi benzersiz lot/parsel/parti düzeyindeki ontolojik sabitleyici; fungible GTİP Token’ı ise ticaret ve finansman dolaşımına elverişli temsil katmanı olarak konumlandırmaktadır.²

Çalışma, teknik mimariyi nötr bir altyapı olarak değil, Fintek Fıkhı ile şekillenmiş normatif öncülleri yürüten bir tasarım düzeni olarak ele alır. Bu nedenle metin; veri, kimlik, doğrulama, mint-burn akışları, pause ve rollback mekanizmaları, uyuşmazlık çözüm kancaları, normatif paket seçimi ve operasyonel dayanıklılık eşikleri gibi başlıkları birlikte tartışmaktadır. Hedef, gerçek geliştirme ekiplerinin yol haritasına dönüşebilecek kadar somut, ancak akademik tartışma taşıyabilecek kadar gerekçeli bir referans metin üretmektir.

Giriş

GTİP Token makale dizisinin ilk halkası, banknot endeksli tokenlardan mal temelli dijital tedavüle geçişin kavramsal ve iktisadî gerekçesini ortaya koymuştu; ikinci halka ise bu zemini Fintek Fıkhı, ayn/deyn, kabz, zimmet, takyid ve risk paylaşımı ekseninde normatif sözlüğe dönüştürmüştü. Üçüncü halka olan bu makalenin görevi, artık bu kavramsal ve normatif çerçeveyi veri, kimlik, yetki, doğrulama, akıllı sözleşme, denetim ve pazar tasarımı düzeyine taşımaktır. Başka bir ifadeyle Makale 3’ün sorusu “GTİP Token neden meşrudur?” değil, “GTİP Token nasıl çalışmalıdır?” sorusudur.³

Buradaki “nasıl” sorusu iki düzlem içerir. Birincisi mimarinin teknik tutarlılığıdır: veri nesneleri, imza akışları, token yaşam döngüsü, oracle güven modeli, kimlik yetkisi, metadata standardı ve denetim izi nasıl kurulacaktır? İkincisi ise teknik yürütümün normatif çekirdeğe sadakatidir: tahsis edilmemiş varlığın tokenleştirilmesi nasıl engellenecek, teslim öncesi aşırı devirler nasıl sınırlandırılacak, rehin veya takyid durumu nasıl görünür kılınacak, şer‘î ve düzenleyici kontroller işlem akışına hangi noktalarda gömülecektir? Bu nedenle makale, saf yazılım mimarisi raporu ile normatif tasarım belgesi arasında hibrit bir tür taşımaktadır.

BIS’in 2024 tarihli G20 raporu tokenisation’ı, geleneksel varlıkların programlanabilir platformlarda dijital temsilini ve bu temsilin yaşam döngüsü boyunca piyasa yapısını dönüştürebilen bir altyapı olarak çerçeveler. Rapor, token arrangements’ın maliyet azaltma ve yenilik üretme potansiyelinin ancak sound governance and risk management ile birlikte anlamlı olacağını, klasik piyasa altyapısı risklerinin tokenized yapılarda farklı biçimlerde tezahür edebileceğini vurgular.¹ Project Promissa ise tekil golden record, çok taraflı imza, mahremiyet ve egemenlik dengesini aynı yaşam döngüsü içinde birleştiren somut bir kamusal örnek sunar.⁴ Bu makale, söz konusu kurumsal dersleri GTİP/HS temelli mal tokenizasyonuna uyarlamayı amaçlamaktadır.

W3C DID Core ile Verifiable Credentials Data Model v2.0’ın olgunlaşması, tarafların, rollerin, lisansların ve şahitlik yetkilerinin makinece doğrulanabilir biçimde sisteme taşınması için güçlü bir standart zemini oluşturmuştur. DID Core 1.0, merkezi kayıt otoritesinden bağımsız tanımlayıcı mimarisini; VC 2.0 ise issuer-holder-verifier üçlüsü içinde kriptografik olarak doğrulanabilir iddia setlerini tanımlar.⁵⁶ GTİP Token’ın teknik mimarisi, fiziksel mal gerçekliği ile dijital kimlik ve hak akışını bu standartlar üzerinden bağladığında daha açıklanabilir hale gelmektedir.

USPUM’daki Fintek Fıkhı serisi, bu genel literatüre özgün katkılar eklemektedir: GTİP kodunun varlık semantiğinin çekirdeği olarak alınması, Parsel NFT ile fungible alt tokenların aynı ontolojide birlikte düşünülmesi, DID/VC, oracle, çoklu şahitlik, parametrik akit motoru ve audit pack’in aynı güven mimarisinde toplanması bunların başında gelir.⁷⁸ Bu makale, söz konusu katkıları tekrar etmekle yetinmeyip, onları geliştirici ekiplerin ve denetim birimlerinin kullanabileceği daha ayrıntılı bir teknik referans çerçeveye dönüştürmektedir.

1. Literatürde Boşluk ve Makalenin Konumu

Teknik tokenisation literatürü çoğu zaman iki uç arasında salınmaktadır. Bir uçta zincir seçimi, throughput, mahremiyet, interoperability ve standart arayüzler gibi başlıklara yoğunlaşan mühendislik metinleri vardır. Diğer uçta ise varlığın hukukî niteliği, rezerv rejimi, saklama, gözetim ve tüketici koruması üzerinde duran kurumsal raporlar yer alır. GTİP Token bakımından özgül sorun, bu iki literatürün çoğu zaman malın fiziki doğrulanması, kabz ve takyidin dijital görünürlüğü ve çok-fıkıhlı işlem parametreleri gibi meseleleri aynı tabloda buluşturmamasıdır.

Bu nedenle Makale 3’ün konumu, salt teknik whitepaper olmaktan çok, teknik mimariyi normatif yüküyle birlikte kuran bir referans metin olmaktır. Metin, ne sadece zincir üstü veri yapısı tasarlayan dar bir geliştirici belgesi, ne de teknolojiyi uzaktan seyreden soyut bir teori makalesi olmayı hedeflemektedir. Buradaki tercih, “geliştirilebilir akademik metin” üretmektir: bir yandan ontolojik ve fıkhî farkları veri şemasına indirmek, öte yandan geliştiriciye ne yapması gerektiğini söyleyen kadar somut olmak.

Fintek Fıkhı 1 ve 2 yazıları bu makale için doğrudan zemin üretmektedir. Fintek Fıkhı 1, güven mimarisi ve meta-para ontolojisini kurarken; Fintek Fıkhı 2, çok katmanlı referans mimariyi DID/VC, GTİP Token, Parsel NFT, Akit Motoru ve oracle düzeniyle somutlaştırmaktadır.⁷⁸ Bu yüzden Makale 3, dizide önceki halkaların kurduğu kavramsal ve normatif iddiaları teknik akışa çevirmektedir. Makale 3’ün özgül iddiası, “token arzı = rezerv varlık” ilkesinin yalnız söylemsel değil, veri, imza, mint ve denetim mantığı içinde uygulanabilir hale getirilebileceğidir.

Bunun doğal sonucu şudur: GTİP Token’ın teknik başarısı, hangi blokzincirin “daha hızlı” olduğundan çok, neyin tokenleştirildiğinin açık tanımına; kimin hangi veriyi hangi lisansla sisteme yazabildiğine; hatalı veri geldiğinde sistemin nasıl durduğuna; teslim ve kabz tamamlanmadan önce hangi transferlerin reddedileceğine; uyuşmazlık çıkarsa hangi metarule’a göre pause, escalate, arbitrate veya rollback akışının işletileceğine bağlıdır. Bu çerçeve, teknik mimariyi doğrudan yönetişim ve denetim sorunu haline getirir.

2. Tasarım İlkeleri: Ontoloji, Tahsis, İzlenebilirlik ve Sınırlı Dolaşım

GTİP Token teknik mimarisinin birinci ilkesi ontolojik açıklıktır. Sistem, neyi tokenleştirdiğini açıkça söylemek zorundadır: fiyatı mı, stok hakkını mı, teslim talebini mi, rehinli malı mı, kapasiteyi mi, parseli mi? Bu soru yanıtlanmadan uygun token standardı da seçilemez. Mislî özellik taşıyan belirli ürün partileri için fungible temsil mantığı işlevsel olabilir; benzersiz arazi, depo hücresi, konteyner, kalite sertifikası veya parsel için ise non-fungible temsil gerekir. ERC-721 tekil ve ayırt edilebilir varlıklar için standart API sunarken, ERC-1155 aynı sözleşme altında hem fungible hem non-fungible türleri taşıyabilen esnek bir yapı sunmaktadır.⁹¹⁰

İkinci ilke tahsistir. Tahsis edilmemiş, depoda fiilen ayrıştırılmamış veya en azından hukukî olarak ring-fence edilmemiş bir rezerv için token üretmek, GTİP Token tasarımının en başında reddedilmelidir. Burada proof-of-reserves, basit görüntü paylaşımı ya da toplu bilanço açıklaması değildir; spesifik mal partisine bağlanan, parti kimliği ve takyid durumunu gösteren bir atıf zinciridir. Tahsis ilkesi teknik veri modeline lot_id, parcel_nft_id, warehouse_id, quantity_locked, encumbrance_status, quality_grade, last_attested_at ve deliverability_window alanları olarak yansır.

Üçüncü ilke izlenebilirliktir. Bir GTİP Token sistemi, malın baştan sona yaşam döngüsünü hem işlemsel hem de ispat üretir biçimde kaydetmelidir. İzlenebilirlik yalnız transfer logundan ibaret değildir; hangi doğrulayıcının hangi anda hangi hash’i imzaladığı, kalite testinin hangi laboratuvardan geldiği, teslim talebinin ne zaman açıldığı ve token’ın hangi durumda dondurulduğu gibi olaylar da izlenebilirliğin parçasıdır. Project Promissa’daki golden record ve multiparty signature yaklaşımı, burada depo, laboratuvar, şer‘î denetçi ve platform operatörünün ortak veri gerçekliğine bağlanması bakımından öğreticidir.⁴

Dördüncü ilke sınırlı dolaşımdır. Mal temsiline dayalı bir yapının tasarım başarısı, sonsuz serbest dolaşıma açılmasında değil; dolaşımın hakikî teslim, takyid ve kabz durumuna duyarlı biçimde sınırlandırılmasında ortaya çıkar. Bu nedenle sistemde transferability_policy, resale_before_qabd, collateral_transfer_allowed, jurisdiction_profile, dispute_hook ve pause_condition gibi alanlar birinci sınıf vatandaş olmalıdır. Böylece GTİP Token, herkese açık ve her durumda devredilebilir bir coin olmaktan çıkar; belirli akit, teslim ve risk şartlarına bağlanan programlanabilir ticaret hakkı haline gelir.

Beşinci ilke açıklanabilir otomasyondur. Teknik mimarinin otomasyonu büyüdükçe, kuralın gerekçesiyle yürütüm arasındaki bağ da görünür olmalıdır. Bir transfer neden reddedildi, mint neden pause edildi, rehin neden devri engelledi, kalite belgesi eksik olduğu için hangi state değişmedi? Sistem bu sorulara cevap üretmiyorsa, yüksek otomasyon aynı zamanda yüksek opaklık üretir. Dolayısıyla Makale 3’ün yaklaşımı, otomasyonu açıklanabilir karar kapıları ile birlikte düşünmektedir.

3. Genel Mimari Çerçeve: L0-L7 Katmanları

Makale boyunca önerilen mimari yedi ana katmana ayrılmaktadır. Bu ayrım yalnız görsel açıklık sağlamak için değil; hata, sorumluluk ve denetim noktalarını ayrıştırmak için gereklidir. L0 fiziksel gerçekliğin, L1 semantik veri modelinin, L2 kimlik ve yetkinin, L3 doğrulama ve attestation’ın, L4 token yaşam döngüsünün, L5 akit ve işlem yürütümünün, L6 denetim ve reg-tech’in, L7 ise kontrollü pazar ve ağlar arası birlikte çalışabilirliğin katmanıdır. Her katman kendi başına gerekli olmakla birlikte, hiçbir katman tek başına güven üretmez. Güven, bu katmanlar arasındaki asgarî tutarlılıktan doğar.

Katman	Ad	Temel Soru	Başlıca Bileşenler
L0	Reel ekonomi ve saklama	Hangi fiziksel mal veya hak temsil ediliyor?	Üretici, depo, lojistik, laboratuvar, sigorta, takyid kayıtları
L1	Semantik veri modeli	Varlık makinece hangi sözlük ve şema ile tanımlanıyor?	GTİP/HS, lot-parsel kimliği, kalite sınıfı, metadata şeması
L2	Kimlik ve yetkilendirme	Kim hangi veriyi hangi lisansla yazabilir?	DID, VC, rol kayıtları, scoped approvals, trust registry
L3	Oracle ve attestation	Fiziksel gerçeklik dijital kayda nasıl bağlanıyor?	IoT, saha eksperi, depo kaydı, laboratuvar sonucu, multiparty signature
L4	Tokenization engine	Hangi şartta mint, lock, burn, split veya rollover olacak?	ERC-721, ERC-1155, state machine, reserve checks
L5	Parametrik akit motoru	Akit hükümleri işlem akışına nasıl gömülüyor?	Selem, murabaha, müşareke, rehin, dispute hooks, norm profilleri
L6	Audit pack ve reg-tech	Hangi olay hangi kanıtla dış denetime açılacak?	Provenance trail, financing trail, oracle trail, API exports
L7	Pazar ve interoperability	Dolaşım, teminatlandırma ve dış sistem bağlantısı nasıl yönetilecek?	OTC, izinli pazarlar, API gateways, custody bridges

 

4. L0 – Reel Ekonomi ve Saklama Katmanı

L0 katmanı, zincir dışı fiziksel gerçekliktir: üretim, depolama, taşıma, laboratuvar analizi, sigorta, gümrükleme ve teslim bu katmanda gerçekleşir. GTİP Token zincirde doğmaz; önce L0’da mallar, partiler, depolar ve teslim pencereleri oluşur. Zincir üstü katmanlar, L0’daki fiilî düzenin güvenilir temsilini kurabildiği ölçüde anlamlıdır. Bu nedenle teknik mimarinin ilk önermesi şudur: L0’da var olmayan şey zincirde varmış gibi gösterilemez.

L0’ın en kritik tasarım unsuru saklama rejimidir. Malların lisanslı depoda, emanet hesabında, bağımsız sigorta koruması altında veya üretici nezdinde olmak üzere farklı saklama senaryoları bulunabilir. Teknik mimari bu farkları yok sayamaz. Çünkü delivery risk, fire risk, substitution risk ve legal encumbrance risk, saklama rejimine göre değişir. Burada TÜRİB/ELÜS pratiği öğreticidir: ELÜS, lisanslı depolarda bulunan ürünleri temsilen çıkarılan elektronik belgedir ve aksi mevzuatta belirtilmedikçe ürünü aynı miktar, cins, sınıf ve kalitede temsil eder.¹¹ GTİP Token için bu mantık, lot bazlı dijital temsilin depo güvencesi ile ilişkilendirilmesinde güçlü bir analoji sunar.

L0 katmanında ayrıca saklama kimliği tanımlanmalıdır. Bir malın hangi depo, hangi hücre, hangi silo, hangi konteyner ya da hangi arazi parselinde bulunduğu makinece takip edilemiyorsa, üst katmanlar yalnızca toplam stok beyanına dayanır ve bu da tahsis ilkesini zayıflatır. Bu sebeple L0 verileri, L1’deki varlık modeline warehouse_id, compartment_id, geo_reference, batch_number, seal_id ve custody_type alanları olarak yansıtılmalıdır.

L0’ın kritik başarısızlık modu şudur: fiziksel mal ile dijital kaydın fiilî ayrışması. Mal başka yere taşındığında, bozulduğunda veya kısmen kayba uğradığında bu durum sistemde zamanında görünmezse, zincir üstü token yanlış bir gerçekliği temsil etmeye başlar. Bu yüzden L0, teknik mimarinin dışında bırakılacak operasyon alanı değil, mimarinin kurucu parçasıdır.

5. L1 – Semantik Varlık Veri Modeli

L1 katmanının görevi, fiziksel malı makinece okunabilir ve zincir üstü / zincir dışı tüm taraflarca paylaşılabilir bir veri sözlüğüne dönüştürmektir. Burada GTİP/HS kodu varlığın semantik çekirdeği olarak işlev görür; ancak tek başına yeterli değildir. HS kodu yalnız mal sınıfını söyler; lot kimliği, kalite derecesi, takyid durumu, teslim penceresi ve saklama hücresi gibi bilgiler ek şemalarla taşınmalıdır. Dolayısıyla L1, çekirdek sınıflandırma artı genişletilmiş işlem şeması mantığı ile kurulmalıdır.

Veri modelinde üç düzey ayırt edilmelidir. Birinci düzey sınıf düzeyidir: GTİP/HS, ürün ailesi, menşe ülke, genel kategori. İkinci düzey parti düzeyidir: lot numarası, hasat/üretim tarihi, kalite sertifikası, laboratuvar sonucu, depolama kimliği. Üçüncü düzey hak düzeyidir: mülkiyet, rehin, sigorta, teslim talebi, rezervasyon ve finansman durumu. GTİP Token teknik mimarisi bu üç düzeyi tek bir name alanına sıkıştırmaz; her düzey için ayrı metadata kümeleri tanımlar.

Bu katmanda veri şemalarının sürüm yönetimi de kritik önemdedir. Ürün sözlüğü, laboratuvar şeması veya encumbrance alanları değiştiğinde sistem eski kayıtları bozmadan yeni şemaya geçebilmelidir. Bu nedenle her temel varlık kaydına schema_version, semantic_profile ve compatibility_status alanları eklenmelidir. Böylece ileride Makale 4’te tartışılacak standardizasyon ve akreditasyon süreçleri için teknik zemin oluşur.

L1’in kritik başarısızlık modu, semantik tutarsızlıktır. Farklı kurumlar aynı ürünü farklı sözlüklerle kaydediyor, kalite sınıflarını aynı isimle ama farklı içerikle kullanıyor veya lot-parsel ayrımını tutarsız yapıyorsa, sistemdeki birlikte çalışabilirlik fiilen bozulur. Bu yüzden L1 yalnız veri tabanı tasarımı değil, ekosistem sözlüğü ve semantik yönetişim problemidir.

6. L2 – Kimlik, Yetki ve Rol Katmanı (DID/VC)

L2 katmanı, GTİP Token mimarisinin en kritik güven eşiklerinden biridir. Çünkü sistemin sorusu sadece hangi veri var değildir; aynı zamanda bu veriyi kim yazdı, hangi lisansla yazdı, hangi kapsam dahilinde yazdı sorusudur. W3C DID Core, merkezi bir otoriteye zorunlu bağımlı olmaksızın tanımlayıcı oluşturmanın ve bunları çözümlemenin çerçevesini sunarken; Verifiable Credentials Data Model v2.0, issuer-holder-verifier düzeninde iddiaların kriptografik olarak doğrulanabilir taşınmasına imkân verir.⁵⁶ Bu ikili, GTİP Token için salt kullanıcı kimliği değil, rol ve yetki mimarisi kurar.

Bu katmanda en az altı temel rol tipi tanımlanmalıdır: üretici/emanetçi, lisanslı depo, laboratuvar/eksper, finansör, platform operatörü ve denetçi/şer‘î kurul. Her rol, bir DID ile tanımlanmalı; ilgili lisans, sertifika veya akreditasyon bilgisi ise VC ile taşınmalıdır. Örneğin bir laboratuvarın kalite sertifikası yazabilmesi için uygun role sahip olması yetmez; geçerli akreditasyon aralığı, yetki kapsamı ve belgenin iptal edilmemiş olması da sistemce doğrulanmalıdır.

L2’nin ikinci unsuru scoped authorization’dır. Her yetkili, sistemde her şeyi yapmamalıdır. Bir depo lot kabul kaydı girebilir; fakat kalite derecesi güncelleyemez. Bir laboratuvar kalite raporu yazabilir; fakat mint kararı veremez. Bir finansör rehin kaydı düşebilir; fakat depo içindeki fiziksel miktarı değiştiremez. Bu nedenle rol yapısı yalnız kimlik doğrulama değil, action-level authorization olarak tasarlanmalıdır. Teknik olarak bu, role_matrix, credential_scope, validity_interval ve revocation_registry alanları ile yürütülür.

L2’de kimlik mahremiyeti ile denetim görünürlüğü arasındaki denge de önemlidir. Tüm veriyi herkese açmak mahremiyet sorunu doğurur; tüm veriyi kapatmak ise audit kabiliyetini zayıflatır. Çözüm, seçici görünürlük ve presentation temelli ispat akışlarıdır. VC 2.0’ın verifiable presentation modeli, belirli bir işlem için sadece gerekli iddianın sunulmasına imkân verir. Böylece örneğin laboratuvarın kim olduğu ve yetkili olduğu doğrulanırken, tüm kurumsal belgeler herkesle paylaşılmak zorunda kalmaz.⁶

L2’nin kritik başarısızlık modu, sahte yetki veya yetki sızıntısıdır. İptal edilmiş bir laboratuvar sertifikasının hâlâ geçerli görünmesi, rolü sona eren operatörün anahtarlarının kullanılmaya devam etmesi veya bir kurumun kapsam dışı alanlarda veri yazabilmesi, tüm mimariyi bozar. Bu yüzden L2 katmanı için düzenli revocation kontrolü, key rotation ve trust registry zorunludur.

7. L3 – Oracle ve Çoklu Attestation Katmanı

L3 katmanı, fiziksel gerçekliğin dijital kayda bağlandığı eştir. GTİP Token bakımından oracle, salt fiyat feed’i anlamına gelmez. Asıl mesele, miktar, kalite, lokasyon, takyid, teslim ve olay gerçekleşmesi gibi farklı doğrulama tiplerinin zincire hangi kanıt biçimiyle ve kim tarafından taşınacağıdır. Bu nedenle oracle mimarisi tekil veri kaynağı yerine çoklu attestation modeli olarak düşünülmelidir.

Oracle tipleri en az dört kümeye ayrılabilir. Birincisi kurumsal oracle’dır: lisanslı depo, gümrük, sigorta, bankalar veya kayıt kuruluşları. İkincisi fiziksel oracle’dır: IoT sensörü, tartı sistemi, sıcaklık kaydı, seal doğrulaması, uydu görüntüsü gibi kaynaklar. Üçüncüsü uzman oracle’dır: laboratuvar, eksper, denetçi. Dördüncüsü ise olay oracle’ıdır: teslim, temerrüt, hasar, tahliye, haciz, sigorta olayı gibi durumları kaydeden işlemci katman. Her oracle tipi için ağırlık, kapsam ve güvenirlik puanı ayrı tanımlanmalıdır.

Project Promissa’nın multiparty signatures ve single source of truth yaklaşımı, GTİP Token için güçlü bir örnek sunar: önemli yaşam döngüsü olayları tek aktör imzasıyla değil, birden fazla yetkili tarafın imza zinciri ile doğrulanmalıdır.⁴ Örneğin mint için yalnız depo kabulü yeterli görülmeyebilir; depo kabulü artı kalite raporu artı takyid kontrolü birlikte aranabilir. Rehinli lotun serbest devri için ise finansör onayı zorunlu kılınabilir. Bu yaklaşım, bir verinin doğruluğunu kurumsal çoğulluk üzerinden güçlendirir.

L3’te attestation nesnesi asgari şu alanları taşımalıdır: attestation_id, subject_reference, attestor_did, attestor_role, evidence_hash, timestamp, confidence_score, scope, expiry, revocation_status ve related_event. Oracle mantığının şeffaflaşması için confidence_score ve evidence_ref alanları kritik önemdedir. Böylece sistem yalnız doğrulandı demez; kimin doğruladığını, neye dayanarak doğruladığını ve ne kadar süreyle geçerli olduğunu da gösterir.

L3’ün kritik başarısızlık modu, senkronize yanlışlık veya tekil oracle hâkimiyetidir. Tüm sistem aynı zayıf kaynağa dayanıyorsa, çok katmanlı görünmesine rağmen fiilen tekil güven modeli oluşur. Bu nedenle oracle bağımsızlık ölçümleri, attestor concentration index, yedek doğrulama akışları ve red-team senaryoları L3 tasarımının ayrılmaz parçası olmalıdır.

8. L4 – Tokenization Engine ve Yaşam Döngüsü

L4 katmanı, tahsis edilmiş ve doğrulanmış varlığın hangi şartta dijital temsile dönüşeceğini belirler. Bu katmanın merkezi unsuru tokenization engine’dir. Engine’in işi yalnız mint yapmak değildir; daha temel görevi state machine işletmektir. Bir varlık taslak, doğrulanıyor, tahsis edildi, mint edildi, rehinli, teslim talebi açıldı, teslim tamamlandı, kısmi burn, rollover veya archive durumlarına geçebilir. Teknik tasarımın başarısı, bu durum değişimlerinin açık, denetlenebilir ve geri çağrılabilir biçimde tanımlanmasına bağlıdır.

L4 için hibrit standart yaklaşımı en rasyonel seçenektir. Benzersiz fiziksel referansı sabitlemek için ERC-721 benzeri Parsel NFT kullanılabilir; bu NFT lot, parsel, konteyner, depo hücresi, kalite sertifika seti veya belirli hak paketini temsil edebilir. Dolaşım ve parçalı finansman için ise ERC-1155 benzeri çoklu token standardı tercih edilebilir; çünkü aynı sözleşme altında hem fungible hem non-fungible ya da semi-fungible türleri birlikte taşımaya imkân verir.⁹¹⁰ Bu, GTİP Token ile Parsel NFT’yi rakip değil tamamlayıcı hale getirir.

Yaşam döngüsü bakımından asgari akış şu biçimde tasarlanabilir: draft_asset -> allocated -> attested -> mintable -> minted -> transferable_limited -> delivery_claim_open -> delivered_and_burned / rolled_over. Her geçiş, ilgili attestation ve yetki kontrollerine bağlanmalıdır. Böylece engine, yalnız token üreten değil; normatif ve operasyonel kapıları yöneten bir karar katmanı haline gelir.

Split ve merge fonksiyonları da L4’ün merkezindedir. Bir büyük lot, kısmi finansman için alt tokenlara bölünebilir; ama bu bölünme Parsel NFT veya lot kimliği ile ilişkisini kaybetmemelidir. Benzer şekilde aynı kalite ve takyid profilini taşıyan alt lotlar, yeni bir toplanmış temsil için merge edilebilir. Bu işlemler sırasında supply consistency, event completeness ve provenance continuity korunmalıdır; aksi halde sistem çok hızlı biçimde muhasebe ve hukukî izini kaybeder.

L4’ün kritik başarısızlık modu, reserve drift’tir. Sistemdeki toplam dolaşan token miktarı ile tahsis edilmiş fiziksel rezerv arasında fark oluşması, GTİP Token mimarisinin kurucu ilkesini bozar. Bu nedenle tokenization engine için invariants tanımlanmalıdır: circulating_supply küçük-eşittir allocated_and_unencumbered_reserve; collateralized_supply küçük-eşittir collateral_capacity; burn_on_delivery eşittir delivered_quantity; no_secondary_mint_without_new_attestation. Bu tür kurallar, zincir üstünde ve audit pack’te birlikte izlenmelidir.

9. L5 – Parametrik Akit Motoru ve İşlem Protokolleri

L5 katmanı, teknik mimarinin normatif yükünü fiilen yürütür. Burada akit, yalnız PDF sözleşmesi değildir; belirli parametre kümelerinin state machine’e bağlanmış yürütüm mantığıdır. Bu yüzden akit motoru, bir sözleşme türü seç ve çalıştır kadar basit düşünülmemelidir. Asıl mesele, farklı akitlerin izin verdiği dolaşım, teslim, rehin, temerrüt ve ihtilaf davranışlarını teknik kurallara dönüştürmektir.

Selem, murabaha, müşareke, vekâlet, rehin ve emanet ilişkilerinin her biri farklı state ve control requirement üretir. Selem senaryosunda bedelin peşinliği, teslim tanımının açıklığı ve teslim öncesi devrin sınırları önem taşır. Murabaha senaryosunda gerçek kabz, maliyet-kâr ayrımı ve yeniden satış kısıtları belirleyicidir. Müşareke havuzlarında pay sahipliği ve kâr-zarar dağıtımı ayrı iş akışları gerektirir. Rehin senaryosu ise encumbrance kayıtları, temerrüt eşikleri ve paraya çevirme akışını teknik olarak görünür kılmalıdır.⁸

Parametrik akit motorunun ana avantajı, normatif paketleri koddan ayırarak versiyonlanabilir hale getirmesidir. Her akit örneği contract_type, legal_suite, fiqh_profile, trigger_set, permitted_transfers, collateral_rules ve dispute_policy alanlarıyla tanımlanabilir. Böylece sistem, tek bir sert hukuk paketi dayatmak yerine, önceden tanımlanmış normatif profilleri işlem anında seçebilir. Bu, Makale 2’de tartışılan normatif otonomi fikrinin teknik yürütümüdür.

Akit motoru bakımından en kritik nokta, uzlaşma yoksa akit yoktur ilkesinin teknik karşılığıdır. Farklı normatif paket seçen iki taraf, uygulanacak legal suite üzerinde mutabakata varamıyorsa irade beyanı tamamlanmış sayılmaz ve transaction_draft durumu signed_contract durumuna geçemez. Bu binary mantık, akıllı sözleşme tasarımıyla uyumludur: selected_suite_by_party_a eşittir selected_suite_by_party_b şartı sağlanmadan activation olmaz. Böylece uyuşmazlık, işlem sonrasında değil akit kurulmadan önce kesilir.

L5’in kritik başarısızlık modu, işlem akışı ile normatif profil arasındaki kopuştur. Akit metni bir şeyi söylüyor, kod başka şeyi yürütüyor veya kullanıcılar hangi profile girdiğini anlamadan işlem yapıyorsa, sistemde görünürde şeffaf ama fiilen hatalı bir düzen oluşur. Bu yüzden akit motoru çıktıları insan okunabilir sözleşme özeti, makina okunabilir parametre seti ve denetim paketinde birlikte görünmelidir.

10. L6 – Audit Pack, Reg-Tech ve Yönetişim Katmanı

L6 katmanı, GTİP Token mimarisini kurumsal ve düzenleyici olarak yaşatacak dışa aktarılabilir kanıt setlerini üretir. Audit pack, yalnızca log arşivi değildir; belirli bir token veya işlem yaşam döngüsüne ilişkin ispat üretme biçimidir. Asgari olarak provenance trail, ownership trail, financing trail, oracle trail, dispute trail ve governance trail alt kümelerinden oluşmalıdır. Böylece sistem doğru çalıştığını iddia etmek yerine, nasıl çalıştığını gösteren makinece işlenebilir dosya kümeleri sunar.

Audit pack tasarımında olay odaklı yaklaşım tercih edilmelidir. Her kritik olay -mint, split, rehin, devir, teslim açılışı, teslim teyidi, pause, arbitration, burn- kendi event_id’si, önceki ve sonraki state’i, ilgili taraf DID’leri, imzalar, delil referansları ve hash zinciri ile kaydedilmelidir. Bu yapı, dış denetçilerin tam düğüme sahip olmadan belirli işlemleri inceleyebilmesini sağlar. Aynı zamanda reg-tech arayüzleri için standart API üretir.

Reg-tech boyutunda L6, SPK, MASAK veya benzeri uyum mantıklarıyla doğrudan temasa geçer; ancak burada teknik işlev, politika üretmek değil gerekli görünürlük ve raporlama kabiliyetini sağlamaktır. Kimlik bağlı cüzdan, risk skorları, alert kuralları, blacklisted actor revocation akışları, suspicious pattern detection ve court/arbiter hold state’leri L6’de toplanabilir. Teknik sistem, düzenleyici kurumun yerini almaz; ama düzenleyiciyle konuşabilir hale gelir.

Yönetişim bakımından L6 çok seviyeli olmalıdır. Operasyonel yönetişim, günlük olaylara müdahale eder; normatif yönetişim, legal suite ve fiqh_profile sürümlerini yönetir; teknik yönetişim, protokol yükseltmelerini ve anahtar rotasyonlarını yürütür. Üç alanın aynı kurumda toplanması gerekmez; hatta ayrışmaları güçlendirici olabilir. Önemli olan her yönetişim kararının rationale_id, authority_basis, effective_date ve rollback_policy ile kaydedilmesidir.

L6’nın kritik başarısızlık modu, audit pack’in ya çok zayıf ya çok ağır olmasıdır. Çok zayıf bir paket güven üretmez; çok ağır bir paket ise sistemi işlem yapamaz hale getirir. Bu nedenle minimal viable audit pack ile extended audit pack arasında kademeli bir tasarım daha rasyoneldir.

11. L7 – Kontrollü Pazar ve Birlikte Çalışabilirlik

L7 katmanı, token’ın dolaştığı ve başka sistemlerle temas ettiği yüzeydir. Mal temelli tokenizasyon için en rasyonel başlangıç, izinli veya yarı izinli pazar mimarisidir. Çünkü GTİP Token’ın kurucu iddiası, kontrolsüz spekülatif serbest dolaşım değil; teslim ve finansman akışını hızlandıran kontrollü programlanabilir dolaşımdır. Bu nedenle L7’de whitelisting, eligibility rules, jurisdiction profiles, transfer windows ve collateral-only transfer kanalları önem taşır.

Interoperability boyutunda iki düzey ayırt edilmelidir. Birincisi kurumsal entegrasyondur: ERP, depo yazılımı, laboratuvar bilgi sistemi, kimlik cüzdanı, raporlama sistemi. İkincisi zincirler arası veya platformlar arası entegrasyondur: köprüler, API gateway’ler, güvenli veri adaptörleri ve hash referansları. GTİP Token mimarisi bakımından ikinci düzey, ilkinden sonra gelmelidir. ERP ile konuşmayan, laboratuvar sonucu bağlamayan ve kimlik cüzdanı ile role doğrulaması yapmayan bir sistemin chain-to-chain bridge kurması, yalnız hatalı veriyi daha geniş dolaşıma açar.

L7’de pazar mikro-yapısı da önemlidir. Her token her kullanıcıya ve her anda açık olmak zorunda değildir. Örneğin kabz tamamlanmadan önce yalnızca belirli işlem tiplerine izin verilebilir; rehinli lotlar sadece teminat amaçlı devredilebilir; belirli kalite sertifikası süresi dolmuş lotlar otomatik olarak secondary market dışına çıkarılabilir. Böylece pazar, token’ın ontolojisine uygun şekilde davranır.

L7’nin kritik başarısızlık modu, kontrollü dolaşım ile likidite arasında dengenin kaybedilmesidir. Çok sıkı kurallar sistemi işlemez hale getirebilir; çok gevşek kurallar ise mal ile temsil arasındaki bağı çözer. Bu yüzden L7 tasarımı, yalnız düzenleme değil, pazar mühendisliği problemidir.

12. GTİP Token + Parsel NFT Hibrit Mimarisi

GTİP Token ile Parsel NFT’nin aynı mimaride birlikte düşünülmesi, bu makalenin ana teknik katkılarından biridir. Çünkü GTİP/HS düzeyinde sınıflandırılmış mal, çoğu durumda hem mislî dolaşıma hem de benzersiz referansa ihtiyaç duyar. Aynı buğday sınıfı içinde ayrı lotlar bulunabilir; aynı depo içinde farklı kalite dereceleri ve farklı takyid durumları oluşabilir. Eğer sistem yalnız fungible token kullanırsa, benzersiz fiziksel referans zayıflar. Eğer yalnız NFT kullanırsa, parçalı dolaşım ve finansman kabiliyeti daralır. Hibrit mimari bu ikilem için çözüm üretir.

Bu modelde Parsel NFT, benzersiz fiziksel veya hukukî referansı sabitler: belirli lot, belirli silo hücresi, belirli konteyner, belirli arazi parçası, belirli sertifika seti. GTİP Token ise bu referansın ekonomik dolaşıma elverişli kısmını parçalı ve programlanabilir hale getirir. Teknik olarak bir Parsel NFT, parent_asset kimliği olarak davranır; bağlı fungible token id’leri ise child circulation units olarak çalışır. Böylece split ve merge işlemleri parent-child ilişki şemasında izlenir.

Hibrit mimarinin iki avantajı vardır. Birincisi, ayn lehine yorum imkânını güçlendirmesidir; çünkü dolaşan fungible birimlerin arkasında her zaman benzersiz ve referanslanabilir bir parent kayıt bulunur. İkincisi, uyuşmazlık halinde ispat zincirini kolaylaştırmasıdır. Taraflar yalnız token bakiyesine değil, bakiyenin dayandığı lot/parsel kayıtlarına ve ilgili attestation’lara geri dönebilirler. Bu nedenle Parsel NFT kesin hukukî sonuç değil, güçlü dijital kanıt taşıyıcısı ve ontolojik sabitleyicidir.

Teknik uygulamada hibrit model için üç kural önerilebilir: no_child_token_without_parent_anchor, no_parent_release_without_child_supply_reconciliation ve no_merge_across_incompatible_parent_profiles. Bu kurallar, child token’ların parent kayıttan kopmasını, parent kaydın child arzı hesaba katılmadan serbest bırakılmasını ve farklı takyid veya kalite profilindeki lotların keyfi biçimde birleştirilmesini önler.

Hibrit mimarinin kritik başarısızlık modu, parent-child kopuşudur. Child token’lar dolaşırken parent kayda erişim, güncelleme veya uyuşmazlık bağı kurulamazsa, sistem tekrar soyut token evrenine döner. Bu yüzden hibrit yaklaşım, yalnız veri modeli tercihi değil; tüm engine ve audit pack boyunca korunması gereken bir ilke olarak düşünülmelidir.

13. Teknik Uyuşmazlık Çözüm Protokolü ve Metarule

Makale 2’de tartışılan normatif otonomi ve sözleşme serbestisi ilkeleri, Makale 3’te teknik uyuşmazlık çözüm protokolüne dönüştürülmelidir. Sistemin merkeziyetsiz karakteri, yalnız teknik altyapıda değil, akdin kurucu iradesinde de tecelli eder. GTİP Token mimarisinde, akitte hangi fıkhî veya normatif kuralların geçerli olacağına dair dışsal bir dayatma yapılmaz; taraflar önceden tanımlı legal suite’lerden birini karşılıklı rıza ile seçer. Eğer seçilen suiteler arasında eşleşme yoksa irade beyanı tamamlanmamış sayılır ve akit kurulmaz. Bu kural, işlem öncesi uyumsuzluğu işlem sonrasına taşımadan keser.

Ancak aynı suit seçilmiş olsa bile yürütüm sırasında uyuşmazlık doğabilir: teslim zamanında gelmeyebilir, kalite attestasyonu itiraz görebilir, oracle’lar çelişebilir, rehin kayıtları ile fiilî durum çatışabilir veya taraflardan biri normatif profilin yanlış uygulandığını ileri sürebilir. Bu durumda sistemin üst kuralı, serbest yorum değil metarule tabanlı karar akışıdır. Önerilen metarule şudur: önce aynı legal suite içindeki dispute_policy uygulanır; çözülemezse cross-checking arbiter pool devreye girer; yine çözülemezse asset state pause edilir ve yalnız audit-preserving actions’a izin verilir; son aşamada off-chain tahkim veya mahkeme kararı sisteme verifiable ruling olarak alınır.

Teknik olarak bu protokol şu state’lerle çalışır: normal -> challenged -> paused -> mediated -> arbitrated -> resumed / partially_burned / unwound. Her geçiş için trigger ve yetkili rol ayrı tanımlanmalıdır. paused durumu, sistemi felç etmek için değil, delil bütünlüğünü korumak için vardır. Bu halde child token transferleri durdurulur; fakat yeni delil ekleme, açıklama kaydı düşme veya mahkeme/tahkim kararı işleme gibi audit-preserving işlemlere izin verilebilir.

Bu protokolün asıl gücü, normatif çoğulculuğu belirsizliğe dönüştürmemesidir. Çok-fıkıhlı ya da çok-hukuklu yapı, herkes kendi yorumunu uygular anarşisine değil; önceden seçilmiş paketler, açık metarule’lar ve uyuşmazlık durumunda kanıt zincirini koruyan pause mantığına dayanır. Böylece sistem, çoğulcu ama keyfi olmayan bir mimari kurar.

Uyuşmazlık çözüm protokolünün kritik başarısızlık modu, sürecin ya tamamen zincir dışı kalması ya da tamamen zincir içine zorlanmasıdır. Tamamen zincir dışı yaklaşım, sistemin denetim izini kaybettirir; tamamen zincir içi yaklaşım ise karmaşık olayları basit if-else mantığına indirger. Bu nedenle önerilen model hibrittir: state ve kanıt izi zincir içinde korunur; maddi uyuşmazlığın nihai çözümü gerektiğinde tahkim veya mahkeme üzerinden alınabilir.

14. Risk, Failure-State ve Olay Müdahale Matrisi

GTİP Token mimarisinin gerçek değeri, yalnız ideal akış kurmasında değil, bozulma akışlarını önceden tanımlamasında ortaya çıkar. Failure-state düşüncesi olmadan tasarlanan sistemler, ilk stres anında ya tamamen manuel müdahaleye döner ya da geri alınamaz biçimde yanlış karar yürütür. Bu yüzden Makale 3, riskleri yalnız genel başlıklar olarak değil, olay-müdahale eşleşmeleri olarak kurgular.

Risk kümeleri asgari olarak şunlardır: reserve mismatch, stale attestation, identity revocation lag, oracle cartelisation, unauthorized mint, encumbrance omission, double-pledge, pre-qabd speculative resale, delivery default, custody breach, key compromise ve bridge contamination. Her risk, tetiklenme sinyali, otomatik aksiyon, insan müdahalesi gereği ve audit impact alanlarıyla birlikte düşünülmelidir.

Olay müdahale mantığında üç seviye ayrımı yararlıdır. Birinci seviye sistemsel otomasyondur: pause, rate limit, mint block, watchlist. İkinci seviye operasyonel müdahaledir: depo kontrolü, yeni attestation, key rotation, scoped privilege revoke. Üçüncü seviye normatif veya hukukî müdahaledir: tahkim, yönetim kurulu kararı, mahkeme kararı veya dış düzenleyici bildirim. Bu hiyerarşi, her problemi zincir üstü kodla çözme yanılsamasını önler.

Risk yönetiminin kritik ilkesi, olay sonrasında kanıt kaybı yaşanmamasıdır. Bu nedenle incident packet adı verilen ayrı bir kayıt kümesi önerilebilir. Incident packet; olay zamanı, etkilediği token kimlikleri, ilgili DID’ler, dondurulan state’ler, ilk bulgu özeti, geçici aksiyonlar ve nihai kapanış kararını içerir. Böylece sistem yalnız işleyen günlerini değil, kriz anlarını da kurumsal hafızaya dönüştürür.

Risk	Tetik	Otomatik Aksiyon	İnsan Müdahalesi	Audit Etkisi
Reserve mismatch	supply > allocated reserve	mint pause + alert	depo/denetçi incelemesi	yüksek
Stale attestation	validity period expired	transfer restricted	yeni attestation talebi	orta
Identity revocation lag	revoked VC still used	role freeze	trust registry update	yüksek
Double pledge	same parent linked twice	collateral lock	arbiter review	yüksek
Delivery default	window passed, no proof	default state	teminat veya tahkim	yüksek
Key compromise	abnormal signature pattern	emergency pause	key rotation + incident report	yüksek

 

15. Pilot Deployment Yol Haritası

Makale 3 teknik mimariyi soyut şema olarak bırakmamak için, sınırlı kapsamlı pilot dağıtım yol haritası da önerir. En rasyonel pilot, standardize edilebilir ve lisanslı depoyla kolay bağ kurulabilen bir emtia sınıfında başlamak olmalıdır. Türkiye’de ELÜS piyasasının 2025 yılında 123,6 milyar TL işlem hacmine, 9,9 milyon ton işlem miktarına ve 14 milyon ton lisanslı depo kapasitesine ulaşmış olması, depo-temsilli dijital mal kayıtları için önemli bir kurumsal zemin bulunduğunu göstermektedir.¹²

Faz 1’de hedef, parent Parsel NFT artı child GTİP Token hibrit modelinin depo kabul, laboratuvar doğrulama, mint ve sınırlı transfer akışı içinde test edilmesidir. Bu fazda secondary market genişliği değil, audit pack bütünlüğü, attestation senkronu ve reserve invariant doğruluğu ölçülmelidir. Faz 2’de finansman modülleri -özellikle selem ve rehin- sisteme eklenebilir. Faz 3’te kontrollü interoperability ve dış sistem entegrasyonları gündeme gelebilir.

Pilot başarı metrikleri yalnız teknik latency ile sınırlı olmamalıdır. Aşağıdaki göstergeler daha öğretici olur: attestation completion ratio, reserve reconciliation accuracy, dispute incidence rate, mean time to pause, mean time to resume, audit pack completeness score, unauthorized action rejection rate ve delivery-proof turnaround. Bu metrikler, teknik mimarinin gerçekten güven üreten bir işleyişe dönüşüp dönüşmediğini gösterir.

Pilot tasarım bakımından son ilke, önce işleyen dar koridor, sonra genişleme yaklaşımıdır. GTİP Token mimarisi kurucu olarak kontrollü dolaşımı savunduğu için, ilk aşamada tüm ürün ve tüm aktör evrenine açılmak yerine dar kapsamlı ama tam kanıtlı bir koridor daha doğrudur. Ölçeklenme, veri modeli ve incident playbook’lar olgunlaştıkça gelebilir.

Sonuç

Bu makale, GTİP Token makale dizisinin üçüncü halkası olarak, ilk iki makalede kurulan kavramsal ve normatif çerçeveyi uçtan uca teknik mimariye dönüştürmüştür. Çalışmanın ana sonucu şudur: mal temelli dijital temsilin başarısı, zincir seçimi veya arayüz parlaklığından önce, varlık ontolojisinin açık tanımına, tahsis edilmiş rezerv ile dolaşan temsil arasındaki bağın korunmasına, kimlik ve yetki katmanının doğru kurgulanmasına, oracle ve attestation düzeninin çoğul ama disiplinli kurulmasına ve akit hükümlerinin state machine mantığına gömülmesine bağlıdır.

Makale ayrıca GTİP Token ile Parsel NFT’yi aynı mimaride birlikte düşünmenin, soyut token ile fiziksel referans arasındaki bağı kuvvetlendirdiğini savunmuştur. Parsel NFT benzersiz ontolojik sabitleyici; GTİP Token ise programlanabilir dolaşım katmanı olarak konumlandırıldığında, sistem hem finansman ve takas kabiliyeti kazanmakta hem de ispat zincirini güçlendirmektedir. Bu hibrit yaklaşım, Makale 1’deki mal temsili fikrini ve Makale 2’deki normatif filtreleri teknik düzeyde birbirine bağlar.

Bir diğer temel sonuç, normatif otonominin ancak teknik uyuşmazlık protokolü ile birlikte anlamlı olduğudur. Farklı legal suite’ler ve fiqh profile’lar ancak önceden seçilmiş paketler, açık metarule’lar, pause ve arbitrate kancaları ve audit-preserving state’lerle yönetildiğinde çoğulculuk üretir; aksi halde belirsizlik üretir. Bu nedenle Makale 3, çok-fıkıhlı veya çok-hukuklu mimariyi keyfîlik değil, açıklanabilir seçim ve uyuşmazlık protokolü üzerinden okumaktadır.

Bundan sonraki çalışma aşaması, önerilen L0-L7 referans mimarisinin pilot-ekosistem ve küresel standartlaşma bağlamında nasıl işletileceğini tartışmaktır. Bu görev, dizinin dördüncü halkasında; dağıtım disiplini, akreditasyon, çok-fıkıhlı yönetişim, ekosistem sertifikasyonu ve küresel güven katmanı başlıkları altında devam edecektir.

 

 

Dipnotlar

1. Bank for International Settlements (BIS) and Committee on Payments and Market Infrastructures (CPMI), Tokenisation in the Context of Money and Other Assets: Concepts and Implications for Central Banks, 21 Ekim 2024.
2. BIS/CPMI raporu ile GTİP Token dizisinin önceki makalelerinde geliştirilen mal temelli temsil yaklaşımı birlikte okunmuştur; rapor, token arrangements’ın yaşam döngüsü ve risk yönetimi boyutlarını özellikle vurgulamaktadır.
3. Yüksel Yeni, dizinin önceki halkaları ve GTİP Token’ın kavramsal/normatif çerçevesi üzerine önceki çalışmalar.
4. BIS Innovation Hub, Swiss National Bank and World Bank, Project Promissa: Tokenisation of Promissory Notes, 23 Nisan 2025.
5. W3C, Decentralized Identifiers (DIDs) v1.0, W3C Recommendation, 19 Temmuz 2022.
6. W3C, Verifiable Credentials Data Model v2.0, W3C Recommendation, 15 Mayıs 2025.
7. Yüksel Yeni, “Fintek Fıkhı -1- Blokzincir Teknolojisi ve İslam İktisadı Ekseninde Yeni Bir Epistemolojik Teklif ve Güven Mimarisi,” USPUM, 2025.
8. Yüksel Yeni, “Fintek Fıkhı -2- Çok Katmanlı Referans Mimari: Oracle, DID, Akit Motoru ve Tokenizasyon,” USPUM, 2025.
9. William Entriken vd., “ERC-721: Non-Fungible Token Standard,” Ethereum Improvement Proposals, no. 721, 2018.
10. Witek Radomski vd., “ERC-1155: Multi Token Standard,” Ethereum Improvement Proposals, no. 1155, 2018.
11. Türkiye Ürün İhtisas Borsası A.Ş. (TÜRİB), “Sıkça Sorulan Sorular,” ELÜS tanımı ve temsil mantığı.
12. TÜRİB, “2025 yılı son çeyreğine ait ELÜS Piyasası istatistiklerini açıkladı,” 6 Ocak 2026.

Kaynakça

Bank for International Settlements (BIS) and Committee on Payments and Market Infrastructures (CPMI). Tokenisation in the Context of Money and Other Assets: Concepts and Implications for Central Banks. CPMI Papers, 21 October 2024.

Bank for International Settlements (BIS) Innovation Hub, Swiss National Bank, and World Bank. Project Promissa: Tokenisation of Promissory Notes. 23 April 2025.

Entriken, William, Dieter Shirley, Jacob Evans, and Nastassia Sachs. “ERC-721: Non-Fungible Token Standard.” Ethereum Improvement Proposals, no. 721, 2018.

Radomski, Witek, Andrew Cooke, Philippe Castonguay, James Therien, Eric Binet, and Ronan Sandford. “ERC-1155: Multi Token Standard.” Ethereum Improvement Proposals, no. 1155, 2018.

Türkiye Ürün İhtisas Borsası A.Ş. “Sıkça Sorulan Sorular.”

Türkiye Ürün İhtisas Borsası A.Ş. “TÜRİB, 2025 yılı son çeyreğine ait ELÜS Piyasası istatistiklerini açıkladı.” 6 January 2026.

W3C. Decentralized Identifiers (DIDs) v1.0. W3C Recommendation, 19 July 2022.

W3C. Verifiable Credentials Data Model v2.0. W3C Recommendation, 15 May 2025.

Yeni, Yüksel. “Fintek Fıkhı -1- Blokzincir Teknolojisi ve İslam İktisadı Ekseninde Yeni Bir Epistemolojik Teklif ve Güven Mimarisi.” USPUM, 2025.

Yeni, Yüksel. “Fintek Fıkhı -2- Çok Katmanlı Referans Mimari: Oracle, DID, Akit Motoru ve Tokenizasyon.” USPUM, 2025.

Yeni, Yüksel. “Fintek Fıkhı -3.” USPUM, 2026.

Yeni, Yüksel. “Fintek Fıkhı -4.” USPUM, 2026.

Ekler

Bu ekler, makalenin ana omurgasını tekrar etmek için değil; geliştirici ekiplerin, denetim birimlerinin ve şer‘î/reg-tech çalışma gruplarının ortak çalışma masasına koyabileceği asgari teknik artefaktları görünür kılmak için eklenmiştir.

Ek A. Çekirdek Varlık Metadata Şeması

GTİP Token mimarisinde metadata, yalnız kullanıcıya gösterilen açıklayıcı metin değildir; teknik yürütümün ve normatif kontrolün veri taşıyıcısıdır. Bu nedenle çekirdek şema, hem varlık sınıfını hem de lot, takyid, teslim ve denetim durumunu aynı nesne içinde taşımalıdır. W3C VC 2.0’ın data model ve status kavramları ile ERC-1155’in type-temelli metadata mantığı birlikte okunduğunda, çekirdek şemanın katmanlı kurulması daha anlamlı hale gelir.⁶¹⁰

Aşağıdaki tablo, GTİP Token için önerilen asgarî metadata alanlarını göstermektedir. Bu alanların tamamı her senaryoda herkese açık olmak zorunda değildir; fakat sistemin kendisi bu alanları mantıksal olarak taşımalıdır. Seçici gösterim ve verifiable presentation mantığı, hangi aktöre hangi alanın açılacağını sonradan belirleyebilir.

Alan	Tür	Zorunluluk	Amaç
asset_id	string	zorunlu	Sistemdeki ana varlık kaydı
hs_code	string	zorunlu	Varlığın semantik çekirdeği
lot_id	string	zorunlu	Parti kimliği
parent_parcel_nft	string	koşullu	Benzersiz parent referans
warehouse_id	string	zorunlu	Saklama yeri
quantity	decimal	zorunlu	Miktar
quality_grade	string	zorunlu	Kalite sınıfı
encumbrance_status	enum	zorunlu	Rehin/haciz/serbest durum
deliverability_window	date-range	koşullu	Teslim penceresi
schema_version	string	zorunlu	Şema sürümü
risk_flags	array	koşullu	Pause/uyarı tetikleri

 

Bu şemanın kritik tarafı, rehin ve takyid gibi hukukî alanları “yorum notu” olarak değil, çekirdek veri alanı olarak ele almasıdır. Çünkü encumbrance görünürlüğü olmayan bir sistemde akit motoru ve secondary market filtreleri körleşir. Teknik bakımdan da child token mint akışı, parent_parcel_nft ve encumbrance_status alanları doğrulanmadan ilerlememelidir.

Ek B. Attestation Nesnesi ve İmza Akışı

Attestation nesnesi, fiziksel gerçeklik ile dijital kayıt arasındaki bağın asgarî yapıtaşıdır. L3 katmanında anlatıldığı üzere, sistemin “doğrulandı” demesi tek başına yeterli değildir; kimin doğruladığı, hangi delile dayandığı, hangi süreyle geçerli olduğu ve yetkinin iptal edilip edilmediği de kayda girmelidir. Bu nedenle önerilen attestation nesnesi hem DID/VC mantığına hem de audit pack üretimine elverişli biçimde tasarlanmalıdır.⁵⁶

Aşağıdaki örnek nesne, depo kabulü veya kalite sertifikası gibi olaylar için uyarlanabilir bir şablondur.

{
“attestation_id”: “ATT-2026-000145”,
“subject_reference”: “LOT-TR-1001-2026-09”,
“attestor_did”: “did:web:lab.example.org:accredited-01”,
“attestor_role”: “LABORATORY”,
“scope”: [“quality_grade”, “moisture”, “foreign_matter”],
“evidence_hash”: “0x7f…ad3”,
“confidence_score”: 0.94,
“issued_at”: “2026-03-28T10:15:00Z”,
“valid_until”: “2026-04-11T10:15:00Z”,
“revocation_status”: “active”,
“related_event”: “warehouse_inbound_v2”
}

İmza akışında üç aşama önerilebilir: birincisi payload canonicalization; ikincisi yetki ve kapsam doğrulaması; üçüncüsü çoklu imza eşiğinin sağlanması. Mint gibi yüksek etkili olaylarda iki ya da üç taraflı imza eşiği aranması, tekil sahtekârlık riskini azaltır. Bu mantık, Project Promissa’nın multiparty signatures dersinin emtia bağlamına uyarlanmış halidir.⁴

Attestation nesnesi ile VC aynı şey değildir. VC, role ve lisansın kanıtıdır; attestation ise belirli olay veya ölçümün kanıtıdır. İkisi birlikte çalıştığında sistem “bu ölçümü şu lisanslı aktör yaptı” diyebilir. Bu ayrım yapılmazsa rol belgeleri ile olay kanıtları birbirine karışır.

Ek C. Token Yaşam Döngüsü için Örnek Durum Makinesi

Aşağıdaki örnek sözde kod, teknik mimaride tarif edilen durum geçişlerinin nasıl ifade edilebileceğini göstermektedir. Bu kod, üretim amaçlı bir akıllı sözleşme değildir; kavramsal yürütüm mantığını sadeleştirilmiş biçimde görünür kılmak için verilmiştir.

Örnek, parent Parsel NFT ile child GTİP Token arasındaki asgarî ilişkiyi ve reserve drift’e karşı kontrol kapılarını birlikte göstermektedir.

function mintChildToken(parentId, quantity, attestationSet) {
require(parentExists(parentId));
require(parentState(parentId) == “ALLOCATED”);
require(attestationSet.valid == true);
require(encumbranceStatus(parentId) != “BLOCKED”);
require(circulatingSupply(parentId) + quantity <= allocatableReserve(parentId));
childTokenId = issue1155(parentId, quantity);
linkChildToParent(childTokenId, parentId);
emit Minted(parentId, childTokenId, quantity);
}

function openDelivery(parentId, claimant) {
require(isEligibleClaimant(claimant));
require(noActiveDispute(parentId));
setState(parentId, “DELIVERY_OPEN”);
emit DeliveryWindowOpened(parentId, claimant);
}

function burnOnDelivery(childTokenId, deliveredQty, proofRef) {
require(deliveryProofValid(proofRef));
burn1155(childTokenId, deliveredQty);
emit BurnedOnDelivery(childTokenId, deliveredQty, proofRef);
}

Bu akışta dikkat edilmesi gereken nokta şudur: mint kararı yalnız teknik kaynak kısıtı değil, attestation ve encumbrance kontrolü ile birlikte ilerlemektedir. Böylece L3 ve L4 katmanları fiilen birbirine kilitlenir. Parent-child bağının kopmaması için issue1155 işlemi sonrasında ilişki kaydı zorunlu tutulmaktadır.

Gerçek uygulamada bu sözde kod, role matrix, pause hooks, emergency rotation ve dispute escalation modülleri ile genişletilmelidir. Ancak burada amaç, makalenin ana tezi olan “normatif öncül veri ve state machine içinde yürür” düşüncesini görünür kılmaktır.

Ek D. Parametrik Akit JSON Şablonu ve Normatif Paket Seçimi

Makale 2’de teorik olarak savunulan normatif otonomi ve sözleşme serbestisi, teknik tarafta parametrik akit şablonları ile görünür hale gelir. Aşağıdaki örnek JSON, selem benzeri bir akdin dijital ortamda hangi alanlarla kurulabileceğini göstermektedir. Buradaki legal_suite alanı, tarafların önceden tanımlanmış normatif paket üzerinde uzlaştığını; dispute_policy ise uyuşmazlık çıkması halinde hangi metarule zincirinin devreye gireceğini gösterir.

{
“contract_type”: “SELEM”,
“contract_id”: “SEL-2026-04-0009”,
“legal_suite”: “HANAFI_V3”,
“selected_by”: [“buyer_did”, “seller_did”],
“upfront_payment_required”: true,
“asset_reference”: “PARENT-NFT-7741”,
“child_token_type”: “GTIP-1001-1155”,
“delivery_window”: {“from”: “2026-07-01”, “to”: “2026-07-21”},
“pre_qabd_resale”: “restricted”,
“collateral_policy”: “encumbrance_visible”,
“dispute_policy”: “SUITE_FIRST_THEN_META_ARBITRATION”,
“pause_rule”: “freeze_child_transfer_keep_audit_open”
}

Bu yapı sayesinde tarafların seçmediği bir normatif paket sonradan sisteme dışarıdan dayatılamaz. selected_by alanı eşleşmiyorsa activation başarısız olur. Böylece çok-fıkıhlı ya da çok-hukuklu mimari, teknik düzeyde de rıza ilkesine bağlanmış olur.

Aynı şema, murabaha, rehin veya müşareke için farklı parametre setleriyle genişletilebilir. Burada önemli olan, insan okunabilir sözleşme özeti ile makine okunabilir parametre kümesinin birbiriyle uyumlu üretilmesidir.

Ek E. Audit Pack ve Incident Packet Asgarî İçeriği

Audit pack üretimi, yalnız uyum amacıyla değil, kurumsal öğrenme amacıyla da önemlidir. Pilot sistemlerde en çok eksik kalan nokta, kriz anlarında hangi veri setinin saklanacağı ve daha sonra nasıl okunacağıdır. Bu nedenle audit pack ile incident packet’in ayrı ama ilişkili nesneler olarak tasarlanması önerilir.

Audit pack asgarî olarak şunları içermelidir: token kimliği, parent referans, attestation listesi, role doğrulamaları, state history, encumbrance kayıtları, teslim kanıtları ve hash zinciri. Incident packet ise olaya özgü tetik, etki alanı, geçici aksiyon, sorumlu ekip, kapanış kararı ve lesson learned alanlarını içermelidir.

AUDIT PACK
– asset_summary.json
– parent_child_map.json
– attestation_bundle.json
– role_and_vc_snapshot.json
– state_transition_log.json
– encumbrance_register_snapshot.json
– delivery_and_burn_events.json

INCIDENT PACKET
– incident_id
– triggered_rule
– affected_assets[]
– temporary_actions[]
– evidence_refs[]
– resolver_identity
– final_resolution
– rollback_or_resume_state
– lessons_learned

Bu ayrım sayesinde sistem, her işlemi sonsuza kadar aynı ayrıntıda tutmak zorunda kalmadan; olay anlarında yoğunlaşan kanıtları ayrı klasörleyebilir. Denetim yükünü azaltırken kriz görünürlüğünü artıran bu yaklaşım, özellikle pilot ve erken ölçekleme evrelerinde yararlı olacaktır.

Ekosistem standardına doğru ilerleyen sürümlerde audit pack şemalarının sürüm numarası taşıması da önemlidir. Böylece farklı yazılım ekiplerinin ürettiği paketler karşılaştırılabilir hale gelir.

Ek F. Uygulama Kontrol Listesi ve SLA Önerileri

Teknik mimari, yalnız şema ve sözde kodla değil; işletme kontrol listeleri ve hizmet düzeyi hedefleriyle de tamamlanmalıdır. Aksi halde sistem teorik olarak doğru ama operasyonel olarak dağınık kalır. Aşağıdaki liste, geliştirici ekiple operasyon ve denetim ekiplerinin ortak kullanabileceği asgarî bir uygulama kontrol listesidir.

Kontrol Alanı	Asgarî Hedef	İhlal Aksiyonu	Sorumlu Katman
Role doğrulama	Her kritik işlemde canlı revocation kontrolü	işlem reddi + alert	L2
Mint öncesi rezerv kontrolü	Her mintte parent-child reconciliation	mint pause	L4
Kalite attestation süresi	Süresi dolmuş raporla transfer yok	transfer restrict	L3/L7
Dispute başlatma süresi	< 30 dk ilk pause	incident packet aç	L6
Teslim doğrulama süresi	< 24 saat	yedek oracle devreye al	L3/L5
Audit pack tamlığı	%100 zorunlu alan	export block	L6

 

Bu tablo, mimarinin başarı ölçümünü yalnız throughput ve gas maliyeti gibi geliştirici odaklı metriklere bırakmamaktadır. Çünkü GTİP Token’ın vaadi, ham işlem hızı değil; güvenilir mal temsili, sınırlı dolaşım, kanıt üretimi ve ihtilaf azaltımıdır. Dolayısıyla SLA seti de buna uygun seçilmelidir.

Uygulama kontrol listesinin son maddesi eğitim ve tatbikattır. Pause, key rotation, dispute escalation ve reserve mismatch senaryoları canlıya çıkmadan önce masa başı ve kontrollü tatbikatlarla test edilmelidir. Bu yapılmazsa en iyi teknik mimari bile ilk gerçek olayda zayıflayabilir.

Ek G. Trust Registry ve Yetki Yaşam Döngüsü

DID ve VC temelli mimarinin pratikte çalışabilmesi için trust registry adı verilen ayrı bir kayıt düzeneği gerekir. Trust registry, hangi ihraççıların hangi rol belgelerini verebildiğini, hangi akreditasyon kurumlarının tanındığını, hangi sertifikaların hangi süre boyunca geçerli olduğunu ve hangi iptal mekanizmalarının esas alındığını tanımlar. Başka bir deyişle DID/VC tek başına yeterli değildir; ekosistem, bu belgelerin hangi güven çevresi içinde tanınacağını ayrıca belirlemek zorundadır.

GTİP Token bakımından trust registry özellikle laboratuvar, depo, denetçi ve tahkim kurulu rollerinde kritiktir. Çünkü aynı teknik biçimde düzenlenmiş bir VC, yanlış kurumca verilmişse işlevsel olarak yanıltıcı olabilir. Bu nedenle trust registry nesneleri yalnız issuer_did ve role_type değil; accreditation_chain, jurisdiction_scope, valid_from, valid_until, suspension_status ve emergency_contact alanlarını da içermelidir.

Yetki yaşam döngüsü dört aşamada tasarlanabilir: onboarding, active, suspended ve revoked. Onboarding aşamasında rol belgesi henüz işlem üretmez; active aşamasında kapsam dahilinde veri yazabilir; suspended aşamasında geçmiş kayıtları okunur ama yeni kayıt yazamaz; revoked aşamasında sistem o role bağlı tüm yeni işlemleri reddeder. Bu ayrım yapılmazsa key rotation veya geçici askıya alma gibi olaylarda ya aşırı sert ya da aşırı gevşek davranılmış olur.

Trust registry’nin teknik başarısızlık modu, eski yetkinin sistemde canlı kalması veya yeni yetkinin yeterince hızlı tanınmamasıdır. Bu yüzden revocation cache ve freshness interval gibi parametreler de tanımlanmalıdır. Aksi halde en iyi role matrix bile gecikmeli güncelleme nedeniyle fiilen delinir.

Ek H. API Geçitleri ve Dış Sistem Entegrasyonu

GTİP Token mimarisinin saha değeri, çoğu zaman blokzincirin içinde değil blokzincir ile dış kurumsal sistemler arasındaki geçitte ortaya çıkar. ERP, lisanslı depo yönetim sistemi, laboratuvar bilgi sistemi, sigorta hasar uygulaması, kimlik cüzdanı ve denetim portalı birbirinden kopuk kaldığında zincir üstü kayıt güçlü görünse de operasyonel sürtünme düşmez. Bu nedenle API geçitleri, teknik mimarinin tali parçası değil kurucu bileşenidir.

Dış sistem entegrasyonunda üç ilke önerilebilir. Birincisi write minimization’dır: ham veri değil, kanıt değeri taşıyan özet veri ve hash referansları sisteme yazılmalıdır. İkincisi idempotent event design’dır: aynı olay tekrar gönderildiğinde sistem ikinci kez mint veya ikinci kez teslim teyidi üretmemelidir. Üçüncüsü explicit error semantics’tir: dış sistem başarısız olduğunda “sessiz başarısızlık” yerine açık hata kodu ve retry politikası bulunmalıdır.

Bu çerçevede depo kabulü, kalite testi ve teslim teyidi gibi olaylar için standard event payload’ları tanımlanabilir. Böylece farklı yazılım satıcıları aynı kavramları farklı alan adlarıyla değil, ortak payload şemalarıyla taşır. Ekosistem standardına giden yol, tam da bu birlikte çalışabilir event sözlüğünden geçer.

API geçitlerinin kritik başarısızlık modu, veri kaynağı ile zincir arasındaki sessiz uyumsuzluktur. Olay dış sistemde gerçekleşmiş, fakat gateway başarısız olmuşsa sistem yanlış bir sessizlik içinde kalabilir. Bu nedenle gateway’lerde dead-letter queue, retry log ve reconciliation dashboard gibi araçlar bulunmalıdır.

Ek I. Gizlilik, Seçici Gösterim ve Veri Minimizasyonu

Mal temelli dijital temsil sistemlerinde açıklık ile mahremiyet arasında sürekli bir denge kurulur. Çok fazla veri açıklığı, ticari sırları ve kişisel verileri riske atabilir; çok fazla kapalılık ise denetimi anlamsızlaştırabilir. Bu nedenle GTİP Token mimarisinde veri minimizasyonu ve seçici gösterim, isteğe bağlı güvenlik eklentileri değil mimari ilkelerdir.

Verifiable presentations bu denge için önemli bir araç sunar. Belirli bir işlemde karşı tarafın, denetçinin veya reg-tech modülünün tüm belge paketini değil; yalnız gerekli iddia alt kümesini görmesi sağlanabilir. Örneğin bir laboratuvarın tam iç raporu herkese açılmayabilir; ama akreditasyon durumu, geçerlilik tarihi ve ilgili lot için uygun kalite sınıfı sonucu karşı tarafa sunulabilir.

Benzer şekilde public chain veya shared ledger üzerinde mümkün olduğunca veri özeti, hash referansı ve durum kodları tutulmalı; tam belge içerikleri off-chain güvenli depolarda saklanmalıdır. Bu yaklaşım hem ticari sır korumasına hem de gereksiz veri çoğalmasının önlenmesine hizmet eder.

Gizlilik tasarımının kritik başarısızlık modu, seçici gösterimin denetim kaybına yol açmasıdır. Bu nedenle selective disclosure politikaları, her rol için zorunlu asgarî görünürlük setleriyle birlikte tanımlanmalıdır. Mahremiyet ancak denetimin çekirdeği korunuyorsa erdemli bir sonuç üretir.

Ek J. Uygulama Öncesi Kabul Testi Paketi

Canlıya geçiş öncesinde yapılacak kabul testleri, teknik mimarinin teorik bütünlüğünü operasyonel güvene dönüştüren son eşiktir. Bu testler yalnız birim testlerinden ibaret olmamalı; rol iptali, çifte rehin, stale attestation, geç teslim, key compromise, pause-resume ve audit export gibi senaryoları içermelidir.

Asgarî kabul testi paketi için şu set önerilebilir: role revocation test, parent-child reconciliation test, unauthorized mint rejection test, delivery-burn consistency test, dispute escalation test, partial outage reconciliation test ve gateway retry integrity test. Her test yalnız “başarılı/başarısız” sonucu değil, beklenen event zinciri ve audit çıktısı ile birlikte tanımlanmalıdır.

Bu yaklaşım, geliştirici ekip ile denetim ekibi arasında ortak başarı tanımı kurar. Çünkü teknik ekip çoğu zaman fonksiyonların çalışmasını; denetim ekibi ise kanıtın üretilmesini önemser. Kabul testi paketi ikisini aynı masaya oturtur.

Kabul testinin kritik başarısızlık modu, testlerin sadece mutlu yol senaryosuna odaklanmasıdır. Oysa GTİP Token sistemlerinde güven çoğu zaman başarısızlık anındaki davranıştan doğar. Bu yüzden red-team senaryoları ve adversarial testler de kabul paketinin doğal parçası olmalıdır.

Ek K. Geliştirme Backlog’u ve Sürümleme Stratejisi

Teknik mimari ne kadar kapsamlı olursa olsun, gerçek geliştirme süreci her şeyi aynı anda üretemez. Bu nedenle GTİP Token sistemi için sürümleme stratejisi de mimarinin parçası olarak düşünülmelidir. Hangi modülün MVP aşamasında, hangisinin beta aşamasında, hangisinin ise ancak audit ve pilot olgunlaştıktan sonra devreye alınacağı açık biçimde belirlenmezse ekip, mimari bütünlük ile teslim baskısı arasında savrulur.

Önerilen yaklaşım üç halkalı backlog modelidir. Birinci halka kurucu çekirdektir: parent kayıt, temel attestation, role doğrulama, mint-burn ve basit audit export. İkinci halka güven kalınlaştırmadır: dispute hooks, encumbrance engine, incident packet, yedek oracle akışları. Üçüncü halka ise genişleme ve standardizasyondur: interoperability köprüleri, gelişmiş selective disclosure, ekosistem trust registry federasyonu ve çok kurumlu yönetişim panelleri.

Sürümleme stratejisinde en önemli ilke, çekirdek invariants bozulmadan yeni özellik eklemektir. Örneğin secondary market modülü eklenirken parent-child reconciliation, stale attestation kontrolü ve reserve supply eşleşmesi gevşetilmemelidir. Aynı şekilde köprü entegrasyonları devreye alınırken de önce L0-L6 tutarlılığının pilotta kararlı çalıştığı gösterilmelidir.

Bu nedenle backlog yalnız ürün yönetimi aracı değil; teknik-temel ilkeleri koruyan bir yönetişim aracıdır. Sürüm planı ile audit planı birlikte yürümeli; her ana özellik için “hangi yeni risk doğuyor, hangi yeni kanıt üretiliyor?” sorusu ayrıca cevaplanmalıdır.

Sürüm	Ana Bileşenler	Başarı Ölçütü	Bloklayıcı Risk
v0.1 Pilot çekirdek	role doğrulama, parent kayıt, mint-burn	reserve invariant %100	sahte yetki
v0.5 Güven kalınlaştırma	encumbrance, dispute hooks, incident packet	pause-resume süreleri	oracle yoğunlaşması
v1.0 Kontrollü pazar	izinli transferler, collateral flows	uyuşmazlık oranı düşüşü	likidite gerilimi
v1.5 Ekosistem entegrasyonu	API gateway, trust registry federation	interoperability başarısı	şema uyumsuzluğu

 

Backlog ve sürümleme stratejisinin kritik başarısızlık modu, mimarinin sonradan eklenecek modüller tarafından gevşetilmesidir. Bu nedenle her sürüm geçişinde bir “invariant regression review” yapılmalı; parent-child bağları, reserve kontrolleri, role yetkileri ve audit export şemaları değişiklikten sonra yeniden sınanmalıdır.

Ek L. Son Teknik Not: “Çalışan Delil” Olarak Sistem

GTİP Token mimarisinin en ayırt edici tarafı, salt “çalışan yazılım” üretmeyi değil, çalışan delil üretmeyi hedeflemesidir. Bu ifade teknik açıdan şunu anlatır: sistem yalnız transfer gerçekleştiren bir altyapı değil; yaptığı her kritik işlemin nedenini, dayanağını ve yetkisini geriye dönük olarak gösterebilen bir kanıt makinesidir.

Bu nedenle mimarinin başarısı; yalnız başarıyla tamamlanan işlemlerin sayısı, gecikmesi veya maliyetiyle değil; ihtilaf anında hangi kayıtların ne kadar hızla toparlanabildiği, pause kararının ne kadar açıklanabilir olduğu ve parent-child-encumbrance-attestation zincirinin ne ölçüde kopmadan okunabildiği ile de ölçülmelidir.

Makale 3’ün temel önerisi bu çerçevede sadeleştirilebilir: GTİP Token, yazılımın paraya benzemesi için değil; malın, hakkın ve akdin delil üretir biçimde temsil edilmesi için tasarlanmalıdır. Teknik mimari, tam da bu nedenle, veri modeli ile fıkhî öncülü; kimlik ile yetkiyi; token ile parent kaydı; işlem ile denetim izini birbirinden ayırmadan birlikte kurmalıdır.