Yanlış Ağa veya Adrese Kripto Gönderdim: Geri Alma ve Hukuki İade Yolları

Kripto transferinin yanında “başarılı” yazıyor, fakat karşı hesaptaki bakiye değişmiyor. Bu durumda ilk soru, paranın nasıl geri alınacağı değil, gerçekte nereye ve hangi ağda gönderildiğidir. Yanlış ağ seçimi, eksik memo/tag, desteklenmeyen token ve başka kişiye ait adrese transfer aynı sorun değildir. Bazı olaylarda varlık hâlâ sizin kontrolünüzdedir; bazılarında borsanın kayıt düzeltmesi gerekir; bazılarında ise teknik takiple birlikte hukuki iade talebi gündeme gelir.

Zincirde kesinleşen işlemi geçmişten silmekle, o işlemle gönderilen varlığı yeniden hak sahibine aktarmak farklı şeylerdir. Birincisi çoğu ağda kullanıcının tek taraflı yapabileceği bir işlem değildir. İkincisi ise anahtar kontrolü, alıcının kimliği, platformun teknik imkânı ve hukuki yükümlülükleri uygun olduğunda mümkün olabilir. Bu ayrımı yapmadan verilen “kesin kayıp” ve “kesin kurtarırız” cevapları aynı ölçüde yanıltıcıdır.

“Kriptom gelmedi” diyen kişinin önce ayırması gereken altı durum

Transfer sorununun sınıflandırılması, aynı olay için iki borsaya günlerce birbirini tekrar eden mesajlar göndermekten daha yararlıdır. Gönderen platformun işlem geçmişiyle alıcı platformun yatırma ekranı yan yana okunmalıdır. Yalnızca coin adı ve tutar üzerinden inceleme yapılamaz. Ağ adı, tokenın o ağdaki kimliği, alıcı adresi, işlem durumu ve varsa ek tanımlayıcı birlikte değerlendirilir.

Bu tablo bir kurtarma garantisi değildir; hangi sorunun kime sorulacağını gösterir. Örneğin eksik memo nedeniyle eşleşmeyen bir yatırma için ağ geliştiricisine başvurmak sorunu çözmez. Henüz yayınlanmamış çekim için de alıcı borsadan zincir incelemesi istemek erken olabilir. Teknik işlemi yürüten kurumla hukuken sorumluluğu araştırılacak taraf bazen aynı, bazen farklıdır.

İşlem kimliği, borsa referansı ve ekran görüntüsü aynı kanıtı sunmaz

Blockchain işlem kimliği, belirli ağdaki işlemin bulunmasına yarar. Borsanın çekim emrine verdiği iç referans ise kendi sistemindeki kayıttır. İki numara birbirinin yerine yazılamaz. Platform “tamamlandı” diyorsa gerçek zincir işlem kimliğini ve ağı istemek gerekir. Bazı kurum içi transferlerde zincir üzerinde ayrı işlem bulunmaması olağandır; bu durumda kayıt incelemesi platformun hesap sistemi üzerinden yürür.

Ekran görüntüsünde yalnızca “USDT gönderildi” yazması, hangi USDT’nin hangi ağda kime geçtiğini açıklamaz. Aynı isim farklı ağlarda kullanılabilir; aynı sembolle çıkarılmış sahte tokenlar da olabilir. Bu nedenle inceleme, görüntüdeki logodan değil doğrulanmış ağ, varlık ve işlem kaydından başlar. İşlem tarihi ve saat dilimi de korunmalıdır; iki platformun farklı saat gösterimi, olay sırasını olduğundan farklı gösterebilir.

Yanlış ağa gönderilen USDT, ETH veya başka token geri alınabilir mi?

Geri alma ihtimali, gönderilen ağdaki alıcı adres üzerinde kim tarafından hangi kontrolün kurulabildiğine bağlıdır. Aynı adresin iki ağda aynı görünmesi, iki ağdaki bakiyenin tek hesapta birleştiği anlamına gelmez. Varlık, işlemin gerçekten gerçekleştiği ağdadır. Cüzdan uygulamasında görünmemesiyle zincirde bulunmaması birbirinden ayrılmalıdır.

Özellikle Ethereum uyumlu ağlarda benzer adres biçimleri kullanıcıyı yanıltabilir. Bununla birlikte bu benzerlik her cüzdan türü için aynı sonucu doğurmaz. Özel anahtarla kontrol edilen sıradan bir hesap, akıllı sözleşme cüzdanı ve kurumsal saklama mimarisi farklı değerlendirilir. Bir ağdaki sözleşmenin diğer ağda aynı adreste bulunacağı veya aynı yetkilerle çalışacağı varsayılamaz.

Varlığı kendi kişisel cüzdanıma yanlış ağdan gönderdiysem

İşlemin gittiği adres gerçekten sizin kontrolünüzdeyse, sorun yalnızca uygulamanın doğru ağı veya varlığı göstermemesi olabilir. Önce ağdaki bakiye bağımsız olarak doğrulanır; sonra cüzdanın ilgili ağı güvenli biçimde destekleyip desteklemediği incelenir. Uygulamaya yeni bir ağ eklenmesi, başka ağdaki varlığı taşımış olmaz; yalnızca o ağdaki kayıtların görüntülenmesini sağlayabilir.

Bu süreçte kurtarma kelimelerinizi bir internet formuna yazmayın. Sizi sosyal medyadan yönlendiren kişinin verdiği cüzdan yazılımını veya ağ ayarlarını doğrulamadan kullanmayın. Teknik yardım almak, özel anahtarı teslim etmeyi gerektiren sınırsız bir izin değildir. Anahtarın dışa aktarılması veya başka yazılıma taşınması ciddi güvenlik sonuçları doğurabilir; somut mimari incelenmeden genel bir “anahtarı buraya yapıştırın” yöntemi önerilemez.

Varlık bulunduğu hâlde gönderilemiyorsa, ağın işlem ücreti, sözleşmedeki kısıtlar veya hesap yetkileri ayrı incelenir. Bazı işlemler için ağın yerel varlığıyla ücret ödenmesi gerekir; fakat bunu bahane ederek tanımadığınız kişiye “aktivasyon parası” göndermek farklıdır. Gerçek ağ ücretiyle dolandırıcının istediği para, alıcısı ve işlemin teknik amacı üzerinden ayırt edilmelidir.

Yanlış ağdan bir borsanın yatırma adresine gönderdiysem

Borsa hesabınıza para yatırırken gördüğünüz adresin özel anahtarı genellikle sizde değildir. Borsanın size yalnızca belirli ağlarda hizmet vermesi, başka bir ağdaki aynı adrese gönderilen varlığı otomatik olarak hesabınıza yazacağı anlamına gelmez. Alıcı kurumdan, yanlış ağdaki varlığın kendi teknik kontrolü altında olup olmadığının incelenmesi istenir.

Burada iki soruyu ayırmak gerekir: kurum teknik olarak erişebilir mi ve erişebildiği varlık hakkında hangi hukuki yükümlülüğü vardır? “Ağı desteklemiyoruz” cevabı, bazen gerçekten erişilemeyen bir mimariyi, bazen ise otomatik yatırma sistemine dahil edilmeyen bir ağı anlatır. Bunlar aynı değildir. Gerekçeli inceleme, bu farkın açıklanmasını sağlar; fakat her desteklenmeyen ağ için yeni altyapı kurma zorunluluğu bulunduğu da peşinen söylenemez.

Kurumsal saklamada anahtar parçaları, donanımsal güvenlik bileşenleri, çoklu onay ve görev ayrılığı bulunabilir. Bu nedenle internette kişisel cüzdan için anlatılan bir kurtarma işleminin kurum tarafından aynı şekilde yapılabileceği varsayılmamalıdır. Kullanıcının borsadan özel anahtarı istemesi de doğru çözüm değildir. Talep, güvenlik mimarisini ihlal etmeyen kurumsal bir inceleme ve mümkünse kontrollü iade olmalıdır.

Akıllı sözleşme adresine gönderim neden farklıdır?

Bir sözleşme adresi her zaman bir kişinin özel anahtarıyla doğrudan yönetilen cüzdan değildir. Gönderilen tokenı geri çıkaracak fonksiyon bulunmayabilir; mevcut fonksiyonun kullanılabilmesi de belirli yetkilere veya koşullara bağlı olabilir. Yanlış ağda aynı adrese sözleşme kurulmamış olması ayrıca incelenir. Adresin görünüşünden hareketle varlığın mutlaka kurtarılacağı sonucuna varılamaz.

Sözleşmenin yükseltilebilir olması, yönetici yetkisi bulunması veya bir köprü sistemiyle bağlantısı ihtimalleri teknik raporda gösterilebilir. Bunların hiçbiri üçüncü kişinin koduna ya da hesabına izinsiz müdahale yetkisi vermez. Varlığın bulunması, yetkili kişinin işlemi yapabilmesi ve iadenin hukuki dayanağı üç ayrı değerlendirme olarak tutulmalıdır.

Memo veya destination tag yazmadım: Para kayboldu mu?

Memo/tag eksikliği, bazı sistemlerde varlığın alıcı kurumun ortak adresine ulaştığı hâlde hangi müşteriye yazılacağının belirlenememesi sonucunu doğurabilir. Bu durumda zincir transferi tamamlanmış, kurum içi hesap eşleşmesi tamamlanmamıştır. Ancak her ağda ve her alıcıda aynı yapı kullanılmaz. Zorunlu etiket kontrolü olan bir hesapta etiketsiz işlem reddedilmiş de olabilir.

Alıcı platformdan, yatırma adresiyle birlikte size tahsis edilen memo/tag bilgisini isteyin; işlemde bulunan değeri bununla karşılaştırın. Etiketin hiç yazılmamasıyla başka müşteriye ait etiketin yazılması farklı sonuçlar yaratabilir. İkinci ihtimalde yanlış iç hesap kaydı da araştırılır. Sadece bakiyenin size yansımadığını görmek, başka müşterinin haksız kazanç elde ettiğini henüz kanıtlamaz.

Başvuruda tutar, varlık, ağ, işlem kimliği, gönderen platform ve size ait hesap bilgileri birlikte sunulur. Kurum, aidiyeti doğrulamak için ek belge isteyebilir. Bu kontrol, yanlış kişinin iade almasını önlemek açısından anlamlıdır; ancak açık uçlu belge talepleri yerine hangi belgenin hangi uyuşmazlığı çözmek için istendiği açıklanmalıdır. Kişisel veriler yalnız doğrulanmış güvenli kanaldan paylaşılmalıdır.

İade neden doğrudan gönderen adrese yapılmamalı?

Bir borsadan yaptığınız çekimin zincirdeki gönderen adresi, size özel bir adres olmayabilir. Kurumun çok sayıda müşteriye hizmet veren sıcak cüzdanı kullanılmış olabilir. Alıcı, iade amacıyla parayı bu adrese gönderirse tutar borsaya ulaşsa bile hangi müşteriye ait olduğu anlaşılamayabilir. Dolayısıyla ilk transferdeki gönderen adresini kopyalamak, güvenli iade talimatı oluşturmaz.

İadenin hangi hesaba ve ağ üzerinden yapılacağı iki kurumun kayıtlarıyla uyumlu biçimde belirlenmelidir. Gerekiyorsa yeni yatırma adresi, memo/tag ve desteklenen varlık bilgisi doğrulanır. Alıcı kurumun iade işlem kimliği ile gönderen kurumun iç hesap kaydı eşleştirilir. Kullanıcı hesabına gerçekten yansımayan bir zincir transferi, dosyada tamamlanmış tahsilat gibi gösterilmemelidir.

Borsa “desteklenmeyen ağ, sorumluluk kabul etmiyoruz” diyorsa

Bu cevap, hukuki değerlendirme için başlangıç bilgisidir; kendi başına uyuşmazlığın kesin çözümü değildir. İşlem tarihinde hangi ağların desteklendiği, kullanıcıya hangi uyarıların gösterildiği, transfer ekranının nasıl çalıştığı ve varlığın fiilen kimin kontrolüne geçtiği incelenir. Kullanıcının hatalı seçim yapması ile platformun doğru talimatı farklı uygulaması aynı sorumluluk ilişkisini doğurmaz.

SPK’nın III-35/B.2 sayılı Tebliği, platform işlemlerinin müşteri bazında tam, doğru ve güncel izlenmesini; emirlerin çerçeve sözleşme ve emir gerçekleştirme politikasıyla uyumlu yürütülmesini düzenler. Bu çerçeve, her transfer zararının kurum tarafından karşılanacağı anlamına gelmez. Ancak talimat, kayıt ve gerçekleşen işlem arasındaki farkın araştırılmasını gerektiren somut bir hukuki zemin sağlar.

İşlem anındaki ekran ve sözleşme neden önemlidir?

Bugünkü yatırma ekranında bulunan uyarı, olay tarihinde aynı uyarının bulunduğunu kanıtlamaz. Desteklenen ağ listesi sonradan değişmiş olabilir. Kullanıcı hangi sürümde hangi seçeneği gördü, onay ekranında hangi ağ yazıyordu, talimat ne olarak kaydedildi ve hangi ağa gönderildi? Bunların karşılaştırılması gerekir. Güncel kullanım koşullarını geçmiş olaya otomatik uygulamak doğru değildir.

Genel işlem koşullarında “tüm risk kullanıcıya aittir” yazması da tek başına her sorumluluğu ortadan kaldırmaz. Sözleşmenin içeriği, koşulun sözleşmeye dahil edilmesi, açıklığı ve emredici hukukla ilişkisi değerlendirilir. TBK’nın genel işlem koşulları ve sorumsuzluk anlaşmalarına ilişkin hükümleri bu incelemede önemlidir. Buna karşılık açık uyarıyı görmezden gelmek veya talimatı hatalı vermek de değerlendirme dışında bırakılamaz.

Teknik kurtarma ücreti istenmesi hukuka aykırı mıdır?

Her ücret talebi dolandırıcılık değildir; her ücret talebi de haklı değildir. Ücretin sözleşmesel dayanağı, önceden açıklanıp açıklanmadığı, hangi iş için istendiği, miktarı ve sonucun garanti edilip edilmediği araştırılır. Ağ ücreti, kurumsal inceleme bedeli ve üçüncü kişinin kurtarma hizmeti farklı kalemlerdir. Bunların tek bir belirsiz “masraf” başlığı altında sunulması, kullanıcı açısından karar vermeyi zorlaştırır.

Ücretin yalnız başarılı iade hâlinde mi yoksa inceleme yapılsa da mı alınacağı netleştirilmelidir. İade edilecek varlık ve yapılacak kesinti aynı hesapta gösterilmelidir. Kurumun resmî sistemi dışında bir çalışanın kişisel hesabına veya sosyal medya üzerinden verilen cüzdana ödeme istenmesi ciddi uyarı işaretidir. Karar verirken kayıp tutarın büyüklüğü, erişim olasılığı ve yapılacak işin belgelenebilirliği birlikte değerlendirilir.

Platforma gönderilecek talep hangi bilgileri içermeli?

Başvurunun başlığı yalnızca “param nerede?” olmamalıdır. Ağ, varlık ve işlem kimliğini açıkça belirtin; hatanın hangi aşamada olduğunu henüz bilmiyorsanız bunu da yazın. Varsayımları gerçek olay diye sunmayın. “Yanlış ağa gönderildiğini düşünüyorum” demekle “platform talimatımı değiştirdi” iddiası farklı araştırma talepleridir.

1. Hesap kimliğiniz, işlem tarihi, saat dilimi, çekim veya yatırma referansı.
2. Gönderilen ağ, varlık adı, varsa token sözleşmesi ve gerçek işlem kimliği.
3. Hedef adres ile gereken ve işlemde kullanılan memo/tag bilgileri.
4. İşlem anındaki desteklenen ağ bilgisi ve mevcut ekran görüntüleri.
5. Varlığın bulunması, teknik kontrolünün açıklanması ve ilgili kayıtların korunması talebi.
6. Mümkünse güvenli iade; mümkün değilse somut teknik gerekçenin ve ücret koşullarının açıklanması.

Bu paket, kuruma şifre veya özel anahtar göndermek anlamına gelmez. Destek ekibinin ihtiyacı olan işlem bilgileriyle hesabınızı kontrol etmeyi sağlayan gizli bilgiler farklıdır. Dosyanızı inceleyen kişiye ekran paylaşmanız gerekse bile kurtarma kelimelerinin veya gizli anahtarların görüntülenmesine izin vermeyin. Başvuruyu kurumun doğrulanmış kanalı üzerinden yürütün ve kayıt numarasını saklayın.

Başkasının cüzdanına yanlışlıkla gönderilen kripto hukuken nasıl istenir?

Yanlış kişiye gönderim söz konusuysa, ilk değerlendirme alıcının varlığı hangi hukuki sebeple tuttuğudur. Bir satış, borç ödemesi, bağış veya başka geçerli ilişki yoksa sebepsiz zenginleşme hükümleri gündeme gelebilir. TBK 77 ve devamındaki düzenleme, haklı sebep olmadan elde edilen zenginleşmenin geri verilmesine ilişkindir. Ancak hangi kişinin zenginleştiği ve talebin kime yöneltileceği somut kayıtlarla belirlenmelidir.

Zincirde bir adresin bakiye kazanmasıyla belirli bir kişinin hukuken sebepsiz zenginleşmesi arasında ispat kurulmalıdır. Adres kuruma ait olabilir; kurum varlığı başka müşteri adına kaydetmiş olabilir; teknik olarak hiç kimsenin erişemediği bir adrese gönderim de söz konusu olabilir. Bu ihtimallerin tamamına aynı davalı ve aynı talep sonucu yazılamaz.

Alıcı, ödemenin borç karşılığı olduğunu ileri sürüyorsa gönderim hatasının nasıl gerçekleştiği ve tarafların önceki ilişkisi araştırılır. Yanlış adresin nereden alındığı, gerçekte kime gönderilmek istendiği ve işlem açıklamaları bu nedenle önemlidir. Sadece “ben gönderdim, geri istiyorum” demek, karşı tarafın her türlü hukuki sebep iddiasını kendiliğinden ortadan kaldırmaz.

İade talebi aynen kripto olarak mı, Türk lirası olarak mı kurulmalı?

Talebin konusu, elde tutulan varlık ve uyuşmazlığın hukuki niteliğiyle uyumlu belirlenmelidir. Belirli miktar ve nitelikteki tokenın iadesi, sözleşmeye uygun ifa veya zarar bedelinin ödenmesi farklı talep biçimleridir. Aynen iade mümkün değilse değer karşılığı talebin hangi tarihteki ve hangi piyasadaki değere göre hesaplanacağı ayrıca tartışılır. Kripto varlığın TL karşılığına ilişkin tek bir ekran görüntüsü bütün bu soruları çözmez.

Aynı sembole sahip iki tokenın, farklı ağlardaki varlıkların veya köprüyle oluşturulmuş temsili tokenların birbirinin yerine geçip geçmediği de incelenmelidir. Kullanıcıya farklı risk taşıyan bir varlığın teslim edilmesi, sırf ekranda benzer dolar tutarı göründüğü için aynı edim sayılmayabilir. Dilekçede miktar, ağ ve varlık kimliğinin açık olması bu belirsizliği azaltır.

İki ve on yıllık süreler her kripto transferine uygulanır mı?

TBK 82, sebepsiz zenginleşmeden doğan istemler için geri isteme hakkının öğrenilmesinden itibaren iki yıl ve her durumda zenginleşmeden itibaren on yıllık zamanaşımı çerçevesi öngörür. Bu, bütün kripto uyuşmazlıklarının aynı süreye tabi olduğu anlamına gelmez. Sözleşmeye aykırılık, haksız fiil, tüketici işlemi veya suç bağlantılı taleplerin hukuki dayanağı ve süre hesabı farklı olabilir.

Öğrenme tarihi, zamanaşımını kesen veya durduran nedenler ve birden fazla talebin ilişkisi somut dosyada değerlendirilir. Destek birimine mesaj atılması, bütün hukuki sürelerin kendiliğinden durduğu güvencesini vermez. Bu nedenle teknik inceleme sürerken hukuki başvuru süresinin ayrıca takip edilmesi gerekir. “Borsa incelemesi bitmeden hiçbir şey yapılamaz” yaklaşımı riskli olabilir.

Alıcı iade etmiyorsa mutlaka dolandırıcılık mı vardır?

Yanlışlıkla yapılan transfer, tek başına dolandırıcılık fiilini göstermez. Dolandırıcılık bakımından hileli davranış ve diğer suç unsurları araştırılır. Buna karşılık alıcının önce sahte bilgiyle transferi yönlendirmesi, adresi değiştirmesi veya bir hizmeti taklit etmesi farklı bir olaydır. İadeyi reddetmenin ceza hukuku bakımından değerlendirilmesi de yalnız bir cümleye değil, fiilin bütün özelliklerine dayanmalıdır.

Suç şüphesi varsa savcılık veya kolluğa başvuru yapılabilir; fakat özel hukuk uyuşmazlığını çözmek için kanıtlanmamış suç isnadı araç olarak kullanılmamalıdır. Başvuruda gerçek olay, bilinen adresler ve mevcut deliller sunulur. Yanlış transferle dolandırıcılık arasındaki farkı korumak, dosyanın hangi kayıt ve tedbirler üzerinden ilerleyeceğini belirlemeyi kolaylaştırır.

İşlem bekliyor, başarısız görünüyor veya köprüde kaldıysa

Zincire henüz gönderilmemiş çekim talebiyle ağda bekleyen işlem aynı değildir. İlkinde platform içi onay, güvenlik veya uyum kontrolleri incelenir. İkincisinde ağın işlem kuralları ve mevcut durum araştırılır. Ekrandaki genel hata mesajı, varlığın kesin kaybolduğunu göstermez. İşlem kimliği olmayan bir çekimin zincirde tamamlandığı da kabul edilmemelidir.

Bazı ağlarda başarısız işlem için ağ ücreti harcanmasına rağmen asıl varlık transfer edilmez. Kullanıcı toplam bakiyedeki azalmayı görünce bütün gönderimin gerçekleştiğini düşünebilir. Bu durumda işlem sonucu, ücret ve varlık hareketi ayrı okunur. Başarılı işlemlerde de sadece üst düzey durum alanına bakmak yetmeyebilir; token hareketleri ve ilgili sözleşme çağrıları ayrıca incelenir.

Köprü üzerinden transferde kaynak ağdaki işlemle hedef ağdaki teslimat ayrı kayıtlardır. Kaynakta varlığın kilitlenmesi veya yakılması, hedefte beklenen varlığın mutlaka oluştuğunu göstermez. Mesaj kimliği, hedef ağdaki işlem, köprünün desteklediği varlık ve varsa tamamlanmamış talep aşaması araştırılır. Köprü işlemini sıradan borsa çekimi gibi ele almak, doğru muhatabı ve eksik aşamayı bulmayı zorlaştırır.

Bekleyen işlemi düzeltmek için internette önerilen her “iptal”, “hızlandırma” veya “yeniden gönderim” düğmesine güvenilmemelidir. Bunların teknik anlamı ağa ve işlem durumuna bağlıdır. Bir işlem kesinleşmişse, sonradan farklı işlem yayınlamak eski kaydı ortadan kaldırmaz. Özellikle aynı tutarın tekrar gönderilmesi, ilk işlemin daha sonra tamamlanması hâlinde çift ödeme yaratabilir. Önce durum doğrulanmalı, müdahale bunun ardından planlanmalıdır.

Yanlış adres aslında değiştirilmiş bir adres olabilir mi?

Adresin yanlış olması her zaman kullanıcının yazım hatası değildir. Kopyalama sırasında farklı adresin yapıştırılması, sahte destek görevlisinin yönlendirmesi veya işlem geçmişindeki benzer bir adresin seçilmesi dolandırıcılık ihtimalini gündeme getirebilir. Bunun araştırılması, kullanıcı hatası ile üçüncü kişinin müdahalesini ayırmak açısından önemlidir. Suç iddiası, yalnız adreslerin farklı görünmesine değil, değişikliğin nasıl gerçekleştiğine dayanmalıdır.

Hedef adresi hangi kaynaktan aldığınızı koruyun: borsanın yatırma ekranı, e-posta, mesajlaşma veya daha önceki işlem kaydı olabilir. Ekranda gördüğünüz, onayladığınız ve zincire gönderilen adresler karşılaştırılır. Bir adresin yalnız ilk ve son birkaç karakterine bakmak yeterli değildir. Aynı görünen kısa parçalar, bütün adresin aynı olduğunu göstermeyebilir.

Öte yandan adresin bir analiz aracında bir borsayla etiketlenmesi de mutlak kimlik kanıtı değildir. Etiketin dayanağı, tarihi ve güven düzeyi incelenmelidir. Gerçek alıcı müşteri, kurumun iç kayıtlarıyla belirlenebilir. Kripto para dolandırıcılığı incelemesinde açıklanan hile, para akışı ve kişi bağlantısı, yanlış transfer dosyasına ancak somut olay bunu destekliyorsa uygulanır.

Teknik inceleme dosyası nasıl hazırlanır?

Raporun amacı uzun bir işlem grafiği üretmek değil, hukuki soruya cevap verecek doğrulanabilir bulguları ortaya koymaktır. Önce talimatın ne olduğu, sonra fiilen ne gerçekleştiği, son olarak varlık üzerinde kimin hangi kontrol imkânına sahip olduğu araştırılır. Bunlardan biri eksikse rapor eksikliği görünür biçimde belirtmelidir; tahmin, tespit yerine yazılmamalıdır.

İşlem kimlikleri, ağ adları, adresler ve miktarlar açıkça yazılır; tokenın ondalık basamakları nedeniyle oluşabilecek görüntüleme farkları kontrol edilir. Verinin hangi kaynaktan, hangi tarihte alındığı kayda geçirilir. Aynı bulgu mümkün olduğu ölçüde bağımsız veri kaynağıyla doğrulanır. Bir ekran görüntüsünde yer alan tutarın başka bir sistemde farklı görünmesi açıklanmadan rapor sonucuna geçilmez.

Platform kayıtları henüz elde edilmediyse “alıcı müşteri tespit edildi” denilemez. Bunun yerine hangi kurum kaydının gerekli olduğu belirtilir. Örneğin ortak yatırma adresi ve etiket eşleştirmesi, borsa hesabına ait bilgi gerektirebilir. Bu veriyi kullanıcının kendi başına elde edememesi, teknik incelemenin yararsız olduğu anlamına gelmez; yetkili makamın hangi kaydı neden istemesi gerektiği somutlaştırılır.

Teknik uzman raporunda tespit, teknik çıkarım ve hukuki değerlendirme ayrı tutulmalıdır. Tarafça alınan uzman görüşü mahkemenin atadığı bilirkişi raporuyla aynı usulî konumda değildir. HMK 293 çerçevesindeki uzman görüşü, teknik sorunun açıklanmasına katkı sağlayabilir; mahkemenin karar yetkisini devralmaz. Raporun değeri, sıfatlardan çok dayanaklarının denetlenebilirliğiyle ortaya çıkar.

Borsaya dava, tüketici başvurusu veya savcılık şikâyeti nasıl ayrılır?

Başvurunun hedefi, sorunun niteliğine göre seçilir. Bir platformun sözleşmedeki transfer hizmetini gereği gibi yerine getirmediği iddiası, hizmetin ifası veya zarar giderimi talebine konu olabilir. Bir kişinin haklı sebep olmadan aldığı varlığı tutması farklı bir talep doğurur. Hileli yönlendirme veya izinsiz erişim varsa ceza soruşturması ayrıca gündeme gelir. Bu yolların birlikte değerlendirilmesi mümkündür; ancak birbirlerinin yerine geçtikleri varsayılmamalıdır.

Platformun ticaret unvanı, sözleşmedeki taraf ve hizmeti fiilen sunan kuruluş belirlenmelidir. Uygulamanın markası, davalı şirketin tam unvanı olmayabilir. Aynı marka altında Türkiye’de ve başka ülkede farklı şirketler faaliyet gösterebilir. Kullanıcının yatırma veya çekim yaptığı hesap hangi sözleşmeye tabiydi? Bu soru açıklığa kavuşmadan yalnız logoya bakılarak taraf belirlemek ciddi usul sorunları yaratabilir.

Tüketici sıfatı ve tüketici işlemi koşulları varsa ilgili başvuru yolları incelenir. 2026 yılında değeri 186.000 TL’nin altında bulunan tüketici uyuşmazlıkları için hakem heyeti parasal sınırı geçerlidir. Ancak tutarın sınırın altında olması tek başına kripto uyuşmazlığını tüketici uyuşmazlığı yapmaz. İşlemin amacı, tarafların sıfatı ve talep türü değerlendirilmelidir. Mahkemeye gidilecek durumlarda dava şartı arabuluculuk hükümleri ve istisnaları ayrıca kontrol edilir.

Delilin kaybolma riski varsa HMK’nın delil tespitine ilişkin hükümleri; uyuşmazlık konusu hak bakımından şartları varsa geçici hukuki korumalar değerlendirilir. Her teknik destek anlaşmazlığında otomatik hesap blokesi istenmesi doğru yaklaşım değildir. Talebin hangi hakka, varlığa ve riske dayandığı gösterilmelidir. Bir özel rapor veya avukat yazısı, tek başına zincirde bağlayıcı bir dondurma işlemi oluşturmaz.

Yurt dışındaki platformdan iade istemek daha mı zordur?

Yabancı platformla uyuşmazlıkta teknik meseleye uygulanacak hukuk, yetki, tebligat ve kararın icrası soruları eklenir. Türkiye’de dava açılabilmesi ile Türk kararının yabancı ülkede uygulanması aynı aşama değildir. Sözleşmedeki hukuk veya tahkim kaydı da tarafların sıfatı ve emredici hükümler dikkate alınmadan mutlak sonuç doğuruyormuş gibi ele alınmamalıdır.

Yabancı kurumdan kendi hesap ve işlem kayıtlarınızı istemek mümkündür; üçüncü müşterinin kimlik bilgilerinin doğrudan size açıklanması ise ayrı hukuki sınırlamalara tabidir. Koruma talebi, veri talebi, mahkeme kararı ve adli yardımlaşma birbirinden ayrılır. Sınır ötesi varlık dondurma ve iade sürecinde olduğu gibi, doğru muhataba doğru kapsamla başvurmak önemlidir.

Platformun Türkiye’deki düzenleyici konumu da kontrol edilir. SPK listesinde adının bulunması, her hizmet ve işlem için sınırsız yetki veya zarar garantisi anlamına gelmez. Yurt dışından hizmet alınmasına ilişkin kurallar ile Türkiye’ye yönelik izinsiz faaliyet kuralları farklı değerlendirilir. Kullanıcının iade hakkı araştırılırken, hizmetin nerede ve hangi kuruluş tarafından sunulduğu kayıtlara dayanarak belirlenmelidir.

İncelemenin sonunda hangi sonuçlar dürüstçe söylenebilir?

Bir dosya “varlık bulundu ve güvenli iade yapıldı” sonucuyla kapanabilir. Başka bir dosyada varlık bulunur, fakat teknik erişim veya hukuki tahsil imkânı belirsiz kalır. Bazı olaylarda ise yanlış adrese gönderilen varlığa erişmenin mevcut koşullarda mümkün olmadığı anlaşılır. Bu sonuçların birbirinden ayrılması, kullanıcıyı gereksiz masraftan ve ikinci mağduriyetten korur.

Ücretli inceleme başlamadan önce kapsam belirlenmelidir: yalnız zincir tespiti mi, platform kayıtlarının değerlendirilmesi mi, hukuki başvuru hazırlığı mı? Hangi veriler eksik, hangi aşama başka kurumun cevabına bağlı, tahsilat için ek işlem gerekiyor mu? Bu soruların açık cevaplanması, sonuç garantisi veren bir tanıtımdan daha değerlidir. Teknik erişim ihtimaliyle fiilî tahsilat olasılığı aynı oranmış gibi sunulmamalıdır.

Geri gelen tutar, yapılan kesinti ve kalan zarar ayrıca kayıt altına alınmalıdır. Tazminat hesabında aynı kayıp için mükerrer tahsil hedeflenmez. Sonradan yükselen piyasa fiyatının tamamını otomatik zarar saymak da doğru değildir; talep dayanağı, değerleme tarihi ve nedensellik incelenir. İade anlaşması yapılacaksa hangi varlığın hangi ağda teslimiyle hangi taleplerin karşılandığı açıkça yazılmalıdır.

Aynı miktarda iki transfer, neden farklı hukuki sonuç doğurur?

Aşağıdaki iki olay öğretici amaçla kurgulanmıştır; gerçekleşmiş bir dava veya büromuza ait başarı örneği değildir. Her iki olayda da kullanıcı 1.000 birim token göndermek istiyor ve bakiyesi alıcı hesaba yansımıyor. Tutar ve ekrandaki sonuç aynı olsa da sorumluluk değerlendirmesini belirleyen, aradaki işlem zinciridir.

Birinci ihtimal: kullanıcı açıkça desteklenmeyen ağı seçiyor

Alıcı platform yatırma ekranında yalnız A ağını gösteriyor ve diğer ağların desteklenmediğini belirtiyor. Kullanıcı gönderen platformda B ağını seçiyor. Onay ekranı da B ağını gösteriyor; zincir kaydı talimatla uyumlu. Burada önce yanlış ağdaki adresin alıcı kurum tarafından kontrol edilip edilemediği araştırılır. Gönderen platformun sırf talimatı uyguladığı için otomatik olarak kusurlu sayılması doğru olmaz.

Alıcı kurum teknik kontrolü bulunmadığını açıklıyorsa bunun somut gerekçesi incelenir. Kontrol imkânı varsa kurtarma politikasının, sözleşmenin ve iade talebinin değerlendirilmesi gerekir. Kullanıcının hatası önemli olgudur; fakat bu olgu bütün diğer soruları gereksiz kılmaz. Varlığın nerede olduğu, kimin fiilen tasarruf edebildiği ve iade için hangi güvenli yolun bulunduğu yine araştırılır.

İkinci ihtimal: kullanıcı doğru talimat veriyor, gerçekleşen ağ farklı

Bu kez kullanıcının onay kaydında A ağı bulunuyor; ancak kurumun sunduğu gerçek işlem kimliği B ağındaki transferi gösteriyor. Bu farklılık doğrulanırsa incelemenin odağı değişir. Sorun artık yalnız yanlış ağdan gelen bir yatırmanın desteklenmesi değil, kullanıcının talimatıyla gerçekleşen işlem arasındaki uyumsuzluktur. Ekran görüntüsü, emir veritabanı, uygulama sürümü ve kurumun işlem kayıtları birlikte değerlendirilir.

Tek ekran görüntüsüyle kurumun talimatı değiştirdiği kesinleştirilemez; görüntünün hangi işleme ait olduğu da doğrulanmalıdır. Buna karşılık kurumun genel kullanım koşullarındaki risk uyarısı, farklı talimat uygulanması iddiasını yanıtlamış olmaz. Sorumluluk incelemesi, tespit edilen uyumsuzlukla ortaya çıkan zarar arasındaki bağ üzerinden kurulur. Teknik raporun hangi senaryonun kayıtlarla desteklendiğini göstermesi, hukukî talebin isabetini doğrudan etkiler.

Varlığın size ait olduğunu özel anahtar paylaşmadan nasıl gösterirsiniz?

Bir borsadan gönderimde kullanıcının hesap kaydı, çekim talimatı ve borsanın işlemle hesap arasındaki eşleştirmesi önemli delillerdir. Kişisel cüzdandan gönderimde işlem geçmişi, varlığın edinim kayıtları ve ilgili adres üzerinde kontrolü gösteren güvenli yöntemler değerlendirilebilir. Bunun için kurtarma kelimelerinin dilekçeye yazılması veya e-posta eki yapılması gerekmez. Gizli anahtarın yayılması, tartışılan varlığın dışında başka varlıkları da tehlikeye atabilir.

Mesaj imzalama bazı sistemlerde adres kontrolü hakkında veri sağlayabilir; fakat imzalanan içeriğin ne olduğu bilinmeden işlem yapılmamalıdır. Bir imza, belirli anda kontrol bulunduğunu gösterebilse de geçmişteki bütün işlemlerin hukuki sahibini ve paranın kaynağını tek başına ispatlamaz. Kurumsal veya akıllı sözleşme cüzdanlarında kontrolün gösterilmesi farklı yöntem gerektirebilir. Dolayısıyla tek bir “cüzdan doğrulama” bağlantısı herkes için güvenli çözüm sayılamaz.

Aidiyet incelemesinde belge bütünlüğü de önemlidir. Transferin yalnız son adımını değil, talep edilen varlığın miktarını ve hangi hakka dayanarak istendiğini açıklayan kayıtları sunmak gerekir. Kişiye ait olmayan bir hesabın ekran görüntüsünü temin etmek veya üçüncü kişinin özel verilerini izinsiz toplamak kabul edilebilir delil hazırlığı değildir. Eksik kurumsal kayıt, gerektiğinde usulüne uygun talep üzerinden elde edilir.

Yeni transferden önce uygulanabilecek kontrol düzeni

Bir sonraki işlemde yalnız adresi değil; alıcı kurum, ağ, token, memo/tag ve yatırma koşullarını birlikte doğrulayın. Daha önce çalışan kayıtlı adresin her zaman güncel olduğunu varsaymayın. Platformun ağ veya yatırma koşulu değişmiş olabilir. Büyük tutarın gönderilmesinden önce, koşullara uygun küçük bir test işlemi faydalı olabilir; ancak başarılı test daha sonraki her işlemin risksiz olduğunu garanti etmez.

Testin aynı ağ, aynı token ve aynı hedef bilgileriyle yapılması gerekir. Minimum yatırma tutarı ve ücret nedeniyle çok küçük deneme bakiyeye yansımayabilir. Bu da kullanıcıyı yeniden hatalı işlem yapmaya yönlendirebilir. Transfer ekranındaki uyarıları saklamak, adresin tamamını kontrol etmek ve işlem kimliğini kayıt altına almak hem hatayı azaltır hem sorun çıkarsa incelemeyi kolaylaştırır.

Yanlış transfer dosyasında en yararlı başlangıç cümlesi “blockchain geri döndürülemez” değildir. Doğru başlangıç; hangi talimatın verildiğini, hangi işlemin gerçekleştiğini, varlığın nerede bulunduğunu ve üzerinde kimin kontrol kurabildiğini ortaya koymaktır. Hukuki talep, ancak bu teknik zeminle birleştiğinde doğru kişiye ve doğru sonuca yöneltilebilir.

Av. Ahmet Karaca · İstanbul Barosu