Şirket Cüzdanından Yetkisiz USDT Transferi: Çoklu İmza ve Sorumluluk

Av. Ahmet Karaca · PEGA Hukuk · Kaynak kontrolü: 18 Ekim 2026

Şirketin cüzdanından USDT çıkmış, fakat finans biriminde bu tutara karşılık gelen bir ödeme talimatı yok. İşlem ekranı başarılı görünüyor; cüzdanın iki onayla çalıştığı biliniyor. Bu kayıtlar, ilk bakışta iki yetkilinin birlikte para aktardığını düşündürebilir. Oysa transferin nasıl gerçekleştiği ve şirket adına hangi yetkiye dayandığı henüz açıklığa kavuşmuş değildir.

Şirket cüzdanından yetkisiz USDT transferinde ilk iş, varlığın çıkışını, kullanılan teknik yetkiyi ve şirketin hukuki onayını ayrı ayrı belirlemektir. Kalan varlıkların güvenliği ve kayıtların korunması bununla birlikte ele alınır. Çoklu imzalı cüzdanda başarılı işlem bulunması, yöneticilerin kusurunu veya varlığın geri alınabileceğini tek başına göstermez.

Bu yazı, Türkiye’deki anonim ve limited şirketlerin kendi hazinesindeki varlıkları esas alır. Teknik örnek Ethereum üzerindeki Safe cüzdanıdır. TRON izinleri, başka cüzdan yazılımları ve müşteri varlığı saklayan düzenlemeye tabi kuruluşlar kendi yapıları içinde ayrıca incelenir.

Transfer gerçekten iki imzayla mı yapıldı?

Safe’te owner, işlem onayına katılabilen kayıtlı adresi ifade eder; şirket ortağı veya ticaret sicilinde yetkili kişi demek değildir. Adres bir başka akıllı hesaba da ait olabilir. Dolayısıyla üç kayıtlı adres, mutlaka üç ayrı gerçek kişiyi göstermez. Olağan işlem yolunda gereken onay sayısını threshold, yani eşik belirler. Safe’in hesap mimarisi bu teknik rolleri açıklar.

İlk iki yol Safe’in işlem ve modül yapısına, üçüncüsü ERC-20 standardındaki approve, allowance ve transferFrom mekanizmasına dayanır. Token harcama izninden yararlanılmışsa, çıkış anında cüzdan sahiplerinin yeniden imza vermiş olması gerekmez. Kullanılmış yetkinin kaynağını bulmadan “iki yönetici bu transferi birlikte yaptı” sonucuna varılamaz.

Bugünkü owner listesi ve eşik, geçmişteki işlemin ayarlarını ispatlamaz. İnceleme ilgili bloktaki duruma ve değişiklik geçmişine dönmelidir. Zincir verisinden insan kimliğine veya hukuki hak sahipliğine geçişin sınırları, cüzdan sahipliği ve mesaj imzasıyla ispat incelemesinde ayrıca ele alınmaktadır.

İlk incelemede hangi kayıtlar korunmalı?

İki çalışma birlikte yürütülür: yeni kayıp ihtimalini azaltmak ve yaşanan işlemi açıklayacak kayıtları korumak. İnceleme bitene kadar her şeyi olduğu gibi bırakmak da, bütün cihazları sıfırlayıp cüzdan ayarlarını rastgele değiştirmek de doğru bir genel kural değildir. Müdahale, mevcut tehlikeye ve şirketin yetki düzenine göre planlanır; yapılan her değişiklik kayda geçirilir.

• İşlemi sabitleyin: Ağ, cüzdan adresi, işlem kimliği, blok numarası, token sözleşmesi, tutar ve zaman dilimini kaydedin. Ekran görüntüsünün yanında erişilebilen özgün işlem ve olay kayıtlarını da saklayın.
• İmzalanan veriyi koruyun: İşlem önerisi, onay kayıtları, alıcı adresi, çağrı verisi ve varsa işlem simülasyonu birlikte tutulmalı. Arayüzde görülen açıklama ile gerçekten imzalanan veri farklı olabilir.
• Şirket talimatını bulun: Ödeme talebi, yönetim kararı, görev devri, limit, imza düzeni ve işlemle ilgili yazışmaları olay tarihindeki hâlleriyle koruyun.
• Erişim izlerini saklayın: İlgili cihazların, kurumsal hesapların ve kullanılan hizmetlerin kayıtları hukuka uygun şekilde korunmalı. Bir imzacı adresini gören herkesin o kişinin özel hesabına girme yetkisi yoktur.

Kalan varlığın taşınması, imzacı değiştirilmesi veya bir iznin kaldırılması gerekiyorsa güvenilir cihaz, doğrulanmış hedef ve yeterli şirket yetkisi birlikte sağlanmalıdır. Bilinmeyen bir “kurtarma” sayfasına cüzdan bağlamak ya da yeni işlem imzalamak zararı büyütebilir. Özel anahtar ve kurtarma kelimeleri destek başvurusuna, e-postaya veya delil tablosuna eklenmez.

Cüzdan imzası ile şirketi temsil yetkisi neden farklıdır?

Cüzdan yazılımı şirketin esas sözleşmesini, ticaret sicilini veya ödeme limitini kendiliğinden denetlemez. Teknik olarak geçerli bir işlem, şirket içi talimata aykırı olabilir. Bunun tersi de mümkündür: yönetim kararı bulunmasına rağmen cüzdanın teknik yapısı işlemi gerçekleştirmeye yetmeyebilir.

Anonim şirkette temsilin kapsamı ve sınırları TTK m.371 çerçevesinde incelenir. İç onayın eksikliği ile iyi niyetli üçüncü kişiye karşı ileri sürülebilecek temsil sınırlaması aynı değildir. Özellikle tescil ve ilan edilen birlikte temsil düzeni ile yalnız şirket içinde belirlenen parasal limit ayrılmalıdır. “İç limit aşıldı, öyleyse alıcı her durumda parayı iade eder” sonucu kurulamaz.

Limited şirkette temsil bakımından TTK m.629’un bağlantısı; müdürlerin özen ve bağlılık yükümü bakımından m.626 dikkate alınır. Şirket hazine politikasının işlemden önce nasıl kurulacağı ise şirket kripto hazinesi, yönetim kararı ve saklama politikası yazısının konusudur. Buradaki inceleme, gerçekleşmiş çıkışın sebebini ve sonuçlarını belirlemeye yöneliktir.

Delil dosyası nasıl kurulmalı?

Bir adres listesi, şirket zararını açıklamaya yetmez. Dosyada birbirini tamamlayan şu bağlantılar kurulmalıdır:

1. Varlık–şirket bağı: USDT’nin edinilme kayıtları, banka veya borsa çıkışı, muhasebe kaydı ve cüzdanın şirket adına kullanımına ilişkin belgeler. Yöneticinin cihazında cüzdan bulunması tek başına varlığın ona ait olduğunu göstermez.
2. İşlem–yetki bağı: Olay anındaki cüzdan ayarı, kullanılan işlem yolu, önceki izinler ve şirketin işlem talimatı. Şüpheli çıkıştan önce verilmiş geniş bir izin, araştırmanın başlangıcını daha eski tarihe götürebilir.
3. Adres–kişi bağı: Anahtarı kimin fiilen kullandığı; ele geçirilme ihtimali; cihaz, yazışma ve sağlayıcı kayıtları. Aynı adresin görünmesi, her işlemde aynı insanın hareket ettiğini kanıtlamaz.
4. Çıkış–son konum bağı: İlk alıcıdan sonraki hareketler, dönüşüm veya köprü işlemleri ve son doğrulanan adres. Bir analiz hizmetinin borsa etiketi, platformun hesap aidiyeti teyidiyle aynı kanıt değildir.
5. Çıkış–zarar bağı: Olayla bağlantılı net çıkış, varsa geri gelen miktar, masraflar ve değerleme tarihi. Aynı 100.000 USDT’nin üç adresten geçmesi 300.000 USDT zarar yaratmaz.

Tokenın adı da doğrulanmalıdır. Ethereum’daki resmî USDT sözleşmesi 0xdac17f958d2ee523a2206206994597c13d831ec7 adresindedir; kontrol için Tether’in protokol ve sözleşme listesi kullanılır. Aynı sembollü başka token veya köprülenmiş varlık aynı teknik yetkilere sahip kabul edilmez. Yalnız işlem ekranındaki “başarılı” etiketiyle yetinilmez; makbuz, sözleşme olayları ve fiilî token hareketi karşılaştırılır. Safe işlem belgesi ve Ethereum’un işlem makbuzu alanları bu karşılaştırmanın teknik dayanaklarıdır.

Raporun tarihi ve son doğrulanan blok belirtilmelidir. “Şu adreste görüldü”, “bugün hâlâ o adreste”, “bir kişinin kontrolünde” ve “şirkete iade edilebilir” ifadeleri farklı sonuçlardır. Her biri kendi kanıtını gerektirir. Sonraki hareket doğrulanamıyorsa son doğrulanan nokta ve izlenemeyen bölüm açıkça belirtilir.

Borsa, savcılık ve Tether’den ne istenebilir?

Varlık bir borsa hesabına ulaştıysa

Sağlayıcının kimliği ve gerçek başvuru kanalı belirlenir. Kayıtların korunması ile varlığın çekilmesinin kısıtlanması ayrı taleplerdir. Platformun kendi koşullarıyla yapabileceği inceleme, adli elkoymanın yerine geçmez. Yabancı platformlarda uygulanacak hukuk, hesabı işleten tüzel kişi ve yetkili makam prosedürü ayrıca belirlenmelidir; Türkiye’de başvuru yapılması tek başına yabancı hesaba uygulanmış bir tedbir değildir.

Suç şüphesi varsa

CMK m.158, 160 ve 161 çerçevesindeki başvuruda olay, şirketle varlık arasındaki bağ ve korunması gereken kayıtlar somutlaştırılır. Uygun elkoyma talebi de suçun niteliğine, delillere, varlığın bulunduğu yere ve ilgili hükmün koşullarına göre hazırlanır. “Bütün cüzdanlara bloke” şeklindeki belirsiz bir istem, teknik ve hukuki muhatap sorununu çözmez.

CMK m.128/A her şirket içi usulsüz transfer için kullanılabilecek genel bir 48 saatlik bloke kuralı değildir. Hüküm; TCK m.142/2-e, m.158/1-f ve l ile m.245’teki suçlar bakımından makul şüphe hâlinde uygulanır. Banka, ödeme hizmeti sağlayıcısı veya kripto varlık hizmet sağlayıcısı nezdinde veya bunlar aracılığıyla yapılan ya da yapılmaya teşebbüs edilen işlemlerde suçta kullanılan hesabın, ilgili kuruluşça 48 saate kadar askıya alınabilmesini düzenler. TCK m.155’teki güveni kötüye kullanma bu listede yoktur. Buna karşılık CMK m.128’in kendi şartlarıyla değerlendirilmesi mümkündür. Olayı yalnız hızlı tedbir elde etmek için başka bir suç adıyla anlatmak doğru değildir.

Bu 48 saat şirketin şikâyet hakkını kullanma süresi değildir. Askıya alma, adli elkoyma ve iade ayrı işlemlerdir. Sağlayıcının kontrolünde olmayan bir Safe adresi de bu hükümle kendiliğinden kilitlenmiş olmaz.

USDT ihraççısı üzerinden dondurma gündeme geliyorsa

Tether’in 20 Şubat 2026 tarihli açıklama belgesinin 2.7 bölümü, belirli koşullarda yetkili makam talepleriyle dış cüzdanlardaki tokenların dondurulmasına yönelik adımlar atılabileceğini açıklar. Bu, her başvuruda işlem yapılacağı veya dondurulan tutarın doğrudan şirkete ödeneceği taahhüdü değildir. Somut ağ, token, mevcut bakiye, hukuki talep ve teknik imkân birlikte değerlendirilir. Dondurma ve iade ayrımının ayrıntıları için USDT kara liste mekanizması incelemesine bakılabilir.

Yönetici ve imzacı ne zaman sorumlu olur?

Anonim şirkette TTK m.369’daki özen ve bağlılık yükümü ile m.553’teki kusurlu yükümlülük ihlali, zarar ve nedensellik bağı birlikte değerlendirilir. Cüzdanda imzacı olmak otomatik tazminat sorumluluğu doğurmaz; imzacı olmamak da yönetim ve gözetim yükümlülüğünü kendiliğinden ortadan kaldırmaz. Kanuna uygun görev devri ve kontrol dışındaki aykırılıklar bakımından m.553/2–3’ün sınırları korunmalıdır. Limited şirkette sorumluluk hükümlerine geçişte TTK m.644 de dikkate alınır.

Örneğin çalışan, kayıtlı alıcıya ilişkin doğru talimatı yerine getirirken cihazı ele geçirilmiş olabilir; yönetici ise alıcı değişikliği uyarısını görmesine rağmen doğrulama yapmamış olabilir. Aynı token çıkışı, bu iki kişiye aynı kusurun yüklenmesini haklı kılmaz. İhlal edilen görev ve kayıpla bağlantısı kişi bazında gösterilir. Çalışan, yönetici, dış saklayıcı ve yazılım hizmeti sağlayıcısının sorumluluğu da aynı hukuki temele dayanmak zorunda değildir.

Şirketin zararı, ortağın kişisel alacağıyla karıştırılmamalıdır. TTK m.555 kapsamındaki şirket zararı için şirket ve pay sahibi dava açabilir; pay sahibi tazminatın şirkete ödenmesini ister. Doğrudan kişisel zarar iddiası farklı değerlendirme gerektirir.

Geçici korumada talebin niteliği belirleyicidir: belirli bir varlık veya hak üzerindeki uyuşmazlıkta HMK m.389’daki ihtiyati tedbir; şartları oluşmuş para alacağını güvenceye almak için İİK m.257–258’deki ihtiyati haciz değerlendirilir. Bu yolların şartları birbirinin yerine kullanılamaz; kripto kaybı yaşanması bütün hesapların otomatik kısıtlanmasını sağlamaz.

Aynı transferin üç farklı açıklaması

Başvuru öncesi şirket adına hazırlık

İlk değerlendirmeye, işlem kimlikleri ve kısa olay sırasının yanında şirketin temsil belgeleri, varlığın şirket kaynağıyla edinildiğini gösteren kayıtlar ve mevcut cüzdan düzeni getirilmelidir. Zarar gören şirket ile işlemi tartışılan yöneticinin menfaatleri çatışıyorsa, şirket adına başvuruyu kimin yapabileceği ayrıca çözülür; şüphe altındaki kişinin bütün delilleri tek başına seçip sunmasına dayanılmaz.

Dosyanın başlangıcında cevaplanması gereken soru yalnız “USDT nereye gitti?” değildir. Hangi yetkiyle çıktığı, şirket talimatından nerede ayrıldığı ve bugün hangi muhataptan somut olarak ne istenebildiği de gösterilmelidir. Kimliği, imzayı ve zararı birbirine bağlayan bu kayıtlar olmadan yüksek tutar tek başına güçlü bir hukuki talep oluşturmaz.