TRON cüzdanında USDT görünmesine rağmen transfer yapılamaması, her zaman TRX veya Energy eksikliği değildir. Hesabın Owner ya da Active izinleri değiştirilmişse, elinizdeki kurtarma kelimeleri o adresten işlem yapmaya artık yetmeyebilir. Önce gerçek token bakiyesini, ardından hesabın güncel imza yetkilerini ve hata kaydını ayırmak gerekir. Yetki sorunu, cüzdana daha fazla TRX göndererek çözülmez.
Buradaki soru, “Ağ ücreti ne kadar?” sorusundan farklıdır: Bakiyenin bulunduğu hesabı bugün hangi anahtarlar, hangi imza eşiğiyle ve hangi işlemler bakımından yönetebiliyor? Bu rehber, bu sorunun salt okunur kayıtlarla incelenmesini, izin değişikliğinin hukuki dosyada nasıl anlatılacağını ve geri kazanımın teknik sınırlarını ele alır.
Bakiye, harcama yetkisi ve işlem kaynağı üç ayrı kontroldür
Bir cüzdan uygulaması adresi ve varlıkları gösterebilir; buna rağmen işlem imzalama yeteneği bulunmayabilir. Yalnız izleme amacıyla eklenmiş adres ile anahtarı kullanılarak açılmış adres de aynı şekilde değerlendirilemez. İlk incelemede uygulamanın adı veya ekrandaki dolar karşılığı yerine tam TRON adresi ve gerçek token kontratı esas alınmalıdır.
| Görünen durum | Önce incelenecek kayıt | Tek başına çıkarılamayacak sonuç |
|---|---|---|
| USDT bakiyesi var; gönderim reddediliyor | Token kontratı, Owner/Active izinleri, hatanın tam metni | “Biraz daha TRX yeter” |
| Kaynak yetersizliği veya işlem maliyeti uyarısı var | Kaynak durumu, ücret tahmini ve varsa işlem makbuzu | “Cüzdan kesin ele geçirilmiş” |
| İmza eşiği tamamlanmıyor | Seçili izin, anahtar ağırlıkları ve toplanmış imzalar | “USDT sahtedir” |
| Yeni bir yetkili adres görünüyor | İzin güncellemesinin işlem kimliği ve önceki yetki düzeni | “Bu adresin sahibi kesin faildir” |
| Uygulama gönderim yapmıyor; zincire işlem ulaşmamış | Yerel hata, kullanılan hesap ve imzalama yöntemi | “Zincirde başarısız transfer gerçekleşmiş” |
TRON’un kaynak modeli Bandwidth ve Energy üzerinden işler; bunlar imza yetkisinden farklıdır. Kaynağı yeterli bir hesap yetkisiz imza nedeniyle işlem yapamayabilir. Geçerli yetkiye sahip bir hesapta ise kaynak yetersizliği bulunabilir. Ücret talebinin gerçekliğine ilişkin ayrı değerlendirme için TRON işlem ücreti dolandırıcılığı rehberine bakılabilir. Kaynak ayrımının teknik dayanağı TRON Resource Model belgesidir.
Owner ve Active neyi değiştirir?
TRON hesabı tek bir anahtara bağlı olmak zorunda değildir. TIP-16 hesap çoklu imza standardı, farklı anahtarlara ağırlık verilmesini ve işlem için bir eşik aranmasını düzenler. Owner hesabın geniş yetkili izin kümesidir. Active ise belirlenmiş işlem türleri için yetki verir. Witness alanı, normal USDT gönderimiyle karıştırılmaması gereken blok üretim yetkisidir.
İznin adı, gerçek kapsamını tek başına anlatmaz. “Güvenli”, “transfer” veya “yedek” gibi bir ad verilmiş olması güvence değildir. Kontrol edilmesi gerekenler anahtar adresleri, her anahtarın ağırlığı, gerekli eşik ve Active için izin verilen işlem türleridir. Örneğin, eşiği iki olan bir izin altında kendi anahtarınızın ağırlığı birse, tek imza yeterli olmaz. Buna karşılık tanımadığınız başka bir anahtar tek başına eşiği karşılıyorsa, sizin imzanız olmadan da o izin kapsamındaki işlemler yapılabilir.
TRX gönderebilmek, USDT gönderebilmek anlamına gelir mi?
Hayır. Yerel TRX transferi ile TRC-20 USDT hareketini gerçekleştiren akıllı sözleşme çağrısı farklı işlem türleridir. Active izinlerinin operations alanı bu ayrımı belirler. Bu nedenle aynı hesapta bir tür işlem çalışırken diğeri reddedilebilir. “Denemek için TRX gönderdim, demek ki tüm yetkiler bende” sonucu doğru değildir.
TRON hesap izin yönetimi belgesinde Owner kimliği 0, Active kimlikleri 2 ve sonrası olarak açıklanır. Akıllı sözleşme çağrısı işlem türü 31; izin güncellemesi işlem türü 46’dır. Güncel belgeye göre uygun Active izni, 46 numaralı işlem açık ve imza eşiği sağlanmışsa izin güncellemesini de yetkilendirebilir. Dolayısıyla yalnız Owner adına bakılarak hesabın kurtarılabilirliği belirlenemez.
Cüzdanı bağlamadan izin incelemesi nasıl yapılır?
Başlangıç incelemesi için kamuya açık adres yeterlidir. Bir siteye kurtarma kelimesi yazmak, cüzdan bağlamak, yeni izin vermek veya “doğrulama” işlemi imzalamak gerekmez. Özellikle arama reklamıyla bulunan “permission repair” hizmetleri, inceleme ile müdahaleyi aynı ekranda sunabilir. Teşhis için gerekli kayıtlar önce ayrı olarak alınmalıdır.
- Adres ve ağı sabitleyin. Uygulamadaki tam adresi, borsa çekim kaydındaki adresle karşılaştırın. İncelemenin TRON ana ağına mı yoksa bir test ağına mı ait olduğunu yazın.
- Varlığı doğrulayın. USDT adı taşıyan her token aynı varlık değildir. Kontrat adresi ve zincirdeki bakiye kayıtları kontrol edilmeden görünür miktarı zarar tutarı saymayın.
- Hesap izinlerinin ham kaydını alın. Owner ile bütün Active izinlerini, anahtarları, ağırlıkları, eşikleri ve işlem kapsamlarını birlikte saklayın.
- Mevcut yetkileri bilinen kayıtla karşılaştırın. Meşru şirket çoklu imzası, önceki kullanıcı tercihi veya kaybedilmiş ortak imzacı ihtimalini araştırın. Farklı bir adresin varlığı tek başına izinsiz değişiklik kanıtı değildir.
- Değişiklik geçmişini bulun. İzin güncellemesi işlemlerinin kimliklerini, bloklarını ve zamanlarını kaydedin; transfer geçmişiyle aynı zaman çizelgesinde eşleştirin.
- Hatayı olduğu gibi koruyun. Ekran görüntüsünün yanında mümkünse uygulamanın verdiği hata metnini alın. Hatanın yerel imzalama aşamasında mı, ağ doğrulamasında mı, sözleşme çalışırken mi çıktığını ayırın.
Resmî getaccount açıklaması, hesap cevabındaki owner_permission ve active_permission alanlarını gösterir. Bu cevap güncel durumu saptamak için kullanılır; önceki gün hangi yetkinin bulunduğunu kendiliğinden göstermez. Alınma zamanı, veri kaynağı ve kullanılan ağ kayda eklenmelidir. Alanların boş görünmesi veya aracın bazı ayrıntıları göstermemesi hâlinde “izinler temiz” sonucu yazılmadan ham cevap ve aracın yorumu karşılaştırılmalıdır.
İzin değişikliği hangi işlemden anlaşılır?
Hesap yetkileri AccountPermissionUpdateContract türündeki işlemle değiştirilebilir. Resmî işlem tanımı, değiştirilen hesap adresini, yeni Owner yapısını ve Active listesini birbirinden ayırır. İşlem içindeki owner_address, değişikliğin konusu olan hesaptır; bu alanı doğrudan “saldırgan adresi” diye etiketlemek hatalıdır.
İncelemede değişiklik işleminin içeriği kadar başarıyla uygulanıp uygulanmadığı da önemlidir. Oluşturulmuş veya paylaşılmış bir işlem nesnesi, değişikliğin zincirde yürürlüğe girdiğini tek başına göstermez. İşlem kimliği üzerinden işlem ve sonuç bilgisi kontrol edilir. GetTransactionById ile işlem içeriği; GetTransactionInfoById ile işlem sonucu birlikte değerlendirilebilir.
Değişiklikten sonra USDT hareket etmemiş olması olayın önemsiz olduğu anlamına gelmez. Kontrol kaybı varlık hareketinden önce gerçekleşmiş olabilir. Bunun tersi de mümkündür: Kullanıcının ulaşamadığı eski bir imzacı nedeniyle hesap kilitlenmiş, üçüncü kişi herhangi bir varlık almamış olabilir. Raporda “kontrol kaybı”, “izinsiz değişiklik iddiası” ve “doğrulanmış varlık çıkışı” ayrı bulgular olmalıdır.
Üç benzer ekran, üç farklı sonuç
1. Kendi hesabınızda tanımadığınız imzacı var
Varsayımsal olarak, düzenli kullandığınız adreste dün tek anahtar görünürken bugün farklı bir adresin ağırlığı tek başına işlem eşiğine yetiyor olsun. Aynı zaman aralığında izin güncellemesi de bulunuyorsa, kontrolün değiştiği yönünde somut teknik dayanak vardır. Bunun rıza dışı olup olmadığı; kullanılan cihaz, onay ekranı, destek yazışması ve sizin yaptığınız işlemlerle araştırılır. Yeni anahtarın arkasındaki kişi ayrıca belirlenmelidir.
2. Şirket hesabında ikinci onay eksik
İki yöneticinin onayı gereken hesapta yalnız bir yönetici imza veriyorsa transferin tamamlanmaması beklenen davranış olabilir. Tek başına bu durum dolandırıcılık sayılmaz. Toplanmış imza ağırlığının değerlendirilmesine yönelik GetSignWeight kaydı, gerekli eşik ile mevcut imzaları karşılaştırmaya yardım eder. İnceleme, imzacıların işten ayrılması, cihaz kaybı veya yanlış izin seçimi gibi ihtimalleri de kapsamalıdır.
3. Başkasının verdiği kelimelerle açılan cüzdanda yüksek bakiye var
Kelimelerin bir cüzdanı açması, görünen varlıkların size ait olduğunu veya onları harcayabileceğinizi kanıtlamaz. Başkasının yönettiği izin düzenine yalnız görüntüleme imkânıyla erişiyor olabilirsiniz. Bu senaryoda sizin gerçek kaybınız, örneğin “işlem ücreti” diye gönderdiğiniz TRX olabilir; ekranda gördüğünüz bütün USDT’yi kendi zararınız diye yazmak delille desteklenmez. Önceden size ait varlıkların bu hesaba aktarılıp aktarılmadığı ayrıca belirlenmelidir.
Hesap izni, token harcama izniyle aynı değildir
Bir sözleşmeye verilen token harcama yetkisi ile hesabın Owner/Active düzeni ayrı katmanlardır. TRC-20 arayüzündeki approve ve allowance, belirli bir token için bir harcayıcıya tanınmış yetkiyle ilgilidir; AccountPermissionUpdateContract ise hesap işlemlerini kimlerin imzalayabileceğini değiştirir. Ayrımın token tarafı resmî TRC-20 arayüzünde görülebilir.
Bu yüzden bir token iznini kaldırdığını gösteren ekran, hesap yetkilerinin düzeldiğinin kanıtı değildir. Aynı şekilde Owner kaydının olağan görünmesi, bütün token harcama izinlerinin güvenli olduğunu göstermez. İnceleme raporu bu iki kontrolü birbirinin yerine kullanmamalıdır. Örneğin izin güncellemesi geçmişte hiç yokken tokenlar başka bir sözleşme üzerinden hareket etmişse, araştırma yalnız Owner değişikliği aramaya sıkışmamalıdır.
Adrese yeni varlık gelebilmesi de sahibinin çıkış yapabildiğini kanıtlamaz. Bakiyenin artması ile geçerli imza üretebilme ayrı olaylardır. Ücret gönderildikten sonra USDT hâlâ yerinde duruyorsa, “varlık kaybolmadı, risk yok” demeden gönderilen ücretin hareketi ve mevcut kontrol yapısı birlikte incelenmelidir.
Yetkiler geri alınabilir mi?
Teknik imkân, halen kullanılabilen izinlere bağlıdır. Güncel yetki düzeninde izin güncellemesini onaylayabilecek yeterli ve güvenilir anahtar mevcutsa müdahale değerlendirilebilir. Owner eşiği sağlanamıyor ve bunu yapabilecek uygun Active yolu da bulunmuyorsa, eski kurtarma kelimelerini başka uygulamaya yüklemek zincirdeki düzeni geri almaz. Cüzdan sağlayıcısının destek personeli de yalnız uygulama şifresini sıfırlayarak bu yetkileri değiştiremez.
Mevcut bir müdahale yolu bulunduğunda bile gelişigüzel izin değişikliği yapılmamalıdır. Yeni anahtarların gerçekten kullanılabildiği, bütün Active izinlerinin etkisi ve saldırganın paralel yetkisi değerlendirilmelidir. Yanlış eşik veya yanlış anahtar seçimi elde kalan erişimi de ortadan kaldırabilir. Kaynak ücretini karşılamak ile hesabın güvenliğini sağlamak ayrı meselelerdir; kurtarma sonucu veya belirli bir ücret karşılığında erişim garantisi verilemez.
Seed’in daha önce paylaşılması veya cihazın ele geçirilmesi şüphesi varsa, yalnız görünen izinleri düzeltmek ilk ihlalin nedenini ortadan kaldırmayabilir. Bu ayrı risk için kurtarma kelimelerinin paylaşılması sonrası güvenlik adımları değerlendirilmelidir. Yeni bir işlem yapmadan önce güvenli cihaz, anahtarların durumu ve kalan varlığın korunması birlikte planlanır.
Hukuki dosyada izin değişikliği nasıl gösterilir?
Bir başvurunun en önemli eki, yalnız “cüzdanım açılmıyor” yazan ekran değil, iznin ne zaman ve nasıl değiştiğini anlatan karşılaştırmadır. Aşağıdaki belgeler olayın teknik olarak yeniden incelenmesini sağlar:
- Önce/sonra yetki tablosu: Her izin için tam anahtar adresi, ağırlık, eşik ve kapsam; önceki durum bulunamıyorsa bu eksiklik.
- Değişiklik işlemi: Tam işlem kimliği, blok yüksekliği, zincir zamanı, işlem türü ve sonuç kaydı.
- Kayıp çizelgesi: Size ait olduğu belgeyle desteklenen varlık, fiilî çıkış, kalan bakiye ve varsa ayrıca ödenen ücretler.
- Rıza ve aldatma kayıtları: İzin istenirken gösterilen açıklama, yönlendiren alan adı, mesajlar ve destek hesapları.
- İnceleme sınırı: Hangi cihazın incelendiği, hangi verinin bulunmadığı ve fail kimliğinin henüz belirlenip belirlenmediği.
CMK m.158 uyarınca suça ilişkin ihbar veya şikâyet Cumhuriyet başsavcılığına ya da kolluğa yapılabilir. CMK m.217, hukuka uygun elde edilen delillerin yargılamada değerlendirilmesinin çerçevesini kurar. İzin kaydı teknik kontrol değişikliğini destekler; suçun hukuki niteliğini, failin kimliğini ve zararın tamamını tek başına belirlemez. Maddelerin resmî metnine Ceza Muhakemesi Kanunu’ndan ulaşılabilir.
İzin değişikliği ile varlık çıkışını ayrı ekler hâlinde sunmak, soruşturma talebini somutlaştırır. Başvuruda ilgili cihaz ve hesap kayıtlarının korunması, değişiklik işleminin teknik incelenmesi ve varsa varlığın ulaştığı hizmet sağlayıcı kayıtlarının istenmesi olayla ilişkilendirilmelidir. Şikâyet hazırlığı için kripto cüzdan suç duyurusu rehberi, varlık hareketi için TRC-20 transfer takibi açıklaması kullanılabilir.
Kaynaklar ve kapsam
Teknik açıklamalar TRON’un yukarıda bağlantıları verilen izin standardı, hesap sorgulama, işlem ve kaynak belgelerine dayanır. Örnekler yöntemi açıklamak için oluşturulmuştur; gerçek bir müşteri dosyası veya kurtarma sonucu değildir. İnceleme tarihi: 6 Ekim 2026. Protokol belgeleri, cüzdan desteği ve ağ parametreleri değişebileceğinden somut hesabın güncel durumu ayrıca kontrol edilmelidir.
