Talep (Claim) Akışı
Talep (claim) akışı, bir PÖT’ün lehtar tarafından talep edilmesi ve sahipliğinin zincir üzerinde devredilmesi sürecini tanımlar. Bu akış, lehtarın düzenleyen bankadan farklı bir banka müşterisi olabileceği varsayımıyla tasarlanmıştır ve bankalar arası birlikte çalışabilirliği (interoperability) mümkün kılar.
Talep akışının temel tasarım ilkesi; lehtar iradesinin kriptografik olarak ispatlanması, buna karşılık nihai karar yetkisinin düzenleyen bankada kalmasıdır. Bu ayrım, regülasyon kapsamında yetki ve sorumlulukların bulanıklaşmasını engeller.
Akışın Genel Özeti
Talep (claim) süreci aşağıdaki aşamalardan oluşur:
Lehtarın talep isteğini kendi bankası üzerinden başlatması
Lehtar iradesinin KEK imzası ile ispatlanması
Talep bilgisinin zincir üzerinde kayıt altına alınması
Düzenleyen bankanın talebi doğrulaması ve değerlendirmesi
PÖT’ün zincir üzerinde lehtar adına devredilmesi
Bu akışta, talep ile transfer işlemleri bilinçli olarak iki ayrı aşamaya bölünmüştür.
1. Lehtar Tarafından Talebin Başlatılması
Lehtar, kendi bankasının mobil veya web uygulaması üzerinden PÖT talep sürecini başlatır. Lehtar, talep etmek istediği PÖT’ü aşağıdaki yöntemlerden biriyle belirtir:
PÖT kimliği (potId) girilerek
Banka arayüzünde listelenen PÖT’lerden seçim yapılarak
Bu aşamada lehtara, PÖT’ün tutarı ve mevcut durumu gibi zincir üzerinden okunabilen sınırlı bilgiler gösterilir. PÖT’ün düzenleyeni veya önceki sahipleri hakkında kimlik bilgisi paylaşılmaz.
2. Talep Mesajının Oluşturulması ve İmzalanması
(Claim Message Signing)
Lehtarın talep isteği alındıktan sonra, lehtar bankasının GoldTag Oracle servisi tarafından standart bir talep mesajı hazırlanır. Bu mesaj, lehtarın KEK cüzdanı aracılığıyla imzalanmak üzere kullanıcıya sunulur.
İmzalanan talep mesajı en az aşağıdaki bilgileri içerir:
İşlem türü (PÖT talebi – ClaimPOT)
PÖT kimliği (potId)
Lehtar kimlik referansı (DTL Sanal Hesap ID veya MOTA)
Lehtar adına tanımlı hedef blokzincir adresi
Talebi ileten banka kimliği
Benzersiz nonce
Geçerlilik süresi (expiry)
Bu imza, lehtarın belirli bir PÖT için hak talebinde bulunduğunun kriptografik kanıtıdır.
3. Talebin Zincir Üzerinde Kayıt Altına Alınması
(Claim Registry Registration)
İmzalı talep mesajı, lehtar bankası tarafından kendi PÖT Servisi aracılığıyla Claim Registry akıllı sözleşmesine kaydedilir. Bu aşamada:
Talep edilen potId
Lehtar kimlik referansının kriptografik özeti (hash)
Hedef blokzincir adresi
Talebi başlatan banka bilgisi
zincir üzerinde kayıt altına alınır.
Önemli bir tasarım kararı olarak, bu aşamada herhangi bir transfer işlemi gerçekleştirilmez. Claim Registry, yalnızca “bu PÖT için şu tarihte bir talep oluşturulmuştur” bilgisini tarafsız şekilde kayda alır.
4. Düzenleyen Bankanın Talebi Tespit Etmesi
Düzenleyen bankanın PÖT Servisi, blokzincir üzerindeki Claim Registry olaylarını (events) sürekli olarak izler. Kendisi tarafından oluşturulmuş bir PÖT’e ilişkin bir talep kaydı tespit edildiğinde, ilgili olay banka içi sistemlere bildirilir.
Bu noktada düzenleyen banka:
Talep edilen PÖT’ün gerçekten kendi sorumluluğunda olup olmadığını
PÖT’ün mevcut sahibinin kendisi olup olmadığını
zincir üzerinden teknik olarak doğrular.
5. Lehtar İmzasının TCMB Tarafından Doğrulanması
Talep kaydı düzenleyen banka tarafından tespit edildikten sonra, imzalı talep mesajı GoldTag Oracle aracılığıyla TCMB Gateway’e iletilir. TCMB KEK İmza Doğrulama Servisi, talep mesajındaki imzanın geçerliliğini teknik olarak doğrular.
Bu doğrulama sürecinde TCMB:
Talep mesajının içeriğini yorumlamaz
Talebin kabul edilip edilmeyeceğine karar vermez
Sadece imzanın geçerliliğini teyit eder
Bu yaklaşım, talep sürecinde TCMB’nin tarafsız ve teknik rolünü korur.
6. Banka Tarafında İçerik ve Bağlam Kontrolleri
TCMB’den “imza geçerli” sonucu alındıktan sonra, düzenleyen bankanın GoldTag Oracle servisi tarafından detaylı içerik ve bağlam kontrolleri yapılır. Bu kontroller kapsamında:
Talep mesajındaki potId ile Claim Registry kaydının tutarlılığı
Hedef blokzincir adresinin doğruluğu
Nonce ve süre aşımı kontrolleri
Talep eden bankanın yetkisi
değerlendirilir.
Bu aşamada nihai karar yetkisi tamamen düzenleyen bankaya aittir.
7. PÖT’ün Zincir Üzerinde Devredilmesi
(On-Chain Transfer)
Talep, düzenleyen banka tarafından geçerli bulunursa, PÖT’ün zincir üzerindeki devri gerçekleştirilir. Bu kapsamda:
Transfer işlemi için zincir çağrısı hazırlanır
İşlem, Cüzdan Yöneticisi aracılığıyla saklama ortamında imzalanır
İmzalı işlem blokzincir ağına gönderilir
İşlem onaylandığında, PÖT’ün sahipliği lehtar adına tanımlanmış blokzincir adresine geçer.
8. Bildirimler ve Son Durum
Transferin başarıyla tamamlanmasının ardından:
Düzenleyen banka, kendi sistemlerinde PÖT’ü devredilmiş olarak işaretler
Lehtar banka, PÖT’ün lehtar hesabına geçtiğini kullanıcıya bildirir
Bu aşamada PÖT, artık lehtarın tasarrufunda olan bir varlık haline gelir.
Regülasyon Perspektifinden Değerlendirme
Talep (claim) akışı; bankalar arası yetki karmaşasını önleyen, kullanıcı iradesini teknik olarak ispatlayan ve nihai karar sorumluluğunu açık şekilde düzenleyen bir yapı sunar. Talep kaydının zincir üzerinde tutulması, sürecin şeffaf ve denetlenebilir olmasını sağlarken; transfer kararının banka tarafından verilmesi, regülasyon uyumunu korur.
Bu yaklaşım, farklı bankalar arasında güvene dayalı ve ölçeklenebilir bir PÖT ekosisteminin temelini oluşturur.
Last updated