Bir cüzdanın USDT göndermek için ne kadar TRX'e ihtiyacı var
TRON'da USDT gönderen bir cüzdanın doğru kurması gereken iki sayı vardır ve bunlar birbirine kolayca karıştırılır. Biri ücrettir: bir transferin hesaptan aldığı. Öbürü, transferin hiç geçebilmesi için hesabın tutması gereken TRX ile işlemin taşıması gereken sınırdır. Cüzdanda enerji varsa TRX yalnızca baytlar için gerekir: günün ilk transferi için hiç, ondan sonraki her biri için yaklaşık 0.345 TRX. Enerji yoksa, USDT tutan bir alıcıya yapılan her transfer için 6.5 TRX, hiç tutmayana 13.1 TRX gerekir; üstüne aynı baytlar. Hangisi olursa olsun işlemin fee_limit değeri yakmanın tamamına ulaşmalıdır. Ücrete kadar fonlanmış ama ikinci sayıda eksik kalan bir cüzdan, yine TRX'e mal olan bir biçimde başarısız olur.
Düğüm iki sınırdan küçüğünü alır
USDT göndermek bir akıllı sözleşmeye yapılan çağrıdır ve çağrı çalışmadan önce düğüm, ne kadar enerji harcayabileceğine karar verir. İki rakam hesaplar ve küçüğünü alır. Birincisi hesabın karşılayabildiğidir: hâlihazırda tuttuğu enerji, artı TRX'inin protokol oranı olan birim başına 100 sun ile satın alacağı kadar birim. İkincisi işlemin izin verdiğidir: fee_limit değerinin aynı 100 sun'a bölünmüşü.
Buradan iki kural çıkar. Hesaptaki TRX, transferin yakacağı enerjinin tamamını karşılamalıdır, çünkü yakmaya yetmeyen bir bakiye çağrıyı ihtiyacının altında bir yerde sınırlar. Ve fee_limit o yakmaya izin vermelidir, çünkü düşük bir sınır, arkasında ne kadar TRX durursa dursun çağrıyı aynı sertlikte sınırlar. İkisinden birinde eksik kalırsanız çağrı yolun ortasında OUT_OF_ENERGY ile durur ve yolda yaktığı TRX yanmış kalır (bu sonucun ne anlama geldiği).
İkinci rakam, enerji kiralayan ya da stake eden cüzdanları yakalar. Düğüm, hesabın hâlihazırda tuttuğu enerjiyi de, yakacağı TRX'i saydığı gibi, fee_limit'e karşı sayar. fee_limit olmadan imzalanan bir işlem sıfır sınır taşır ve sıfır sınır, çağrının devredilmiş de olsa yakılmış da olsa hiç enerji harcamasına izin vermez. Bir cüzdanın kendi uyarısı ne derse desin düğüm şu aritmetiği yapar: hesabın kendi enerjisi çağrıyı karşılamıyorsa düğüm geri kalanı için TRX yakar ve transfer ancak bakiye ile sınır ikisi de o kadar uzanıyorsa geçer.
Bir cüzdanın ana ağda üç denemesi
Kuralın fee_limit tarafı ana ağda izlenebilir. 6 Ekim 2026'da USDT sözleşmesinin herkese açık kaydını tararken, kırk dakikadan kısa sürede aynı transferi üç kez deneyen bir göndericiye rastladık. Transfer 130,285 birim enerji istiyordu — USDT tutmayan bir alıcının rakamı — ve hesabın kendi enerjisi yoktu; dolayısıyla her birimin TRX yakılarak satın alınması gerekiyordu. Her satır o işlemin kendi kaydıdır.
| Deneme, 6 Ekim 2026 | fee_limit | Sonuç | Harcanan enerji | Alınan TRX |
|---|---|---|---|---|
| Birinci | 1.1 TRX | OUT_OF_ENERGY | 11,000 birim | 1.1 TRX |
| İkinci | yok | OUT_OF_ENERGY | 0 birim | 0.339 TRX |
| Üçüncü | 13.046 TRX | SUCCESS | 130,285 birim | 13.3735 TRX |
İlk deneme tam 11,000 birimde durdu; bu, fee_limit değerinin 100 sun'a bölünmüş hâlidir. Hesap daha fazlasını ödeyebilirdi: üçüncü denemede yakmanın tamamını ödedi ve kaydında araya hiç TRX girmediği görülüyor. İkinci deneme hiç fee_limit taşımıyordu ve makbuzu, sözleşmenin ilk komutunda sıfır bir sınır bildiriyor. Hiç enerji harcamadı, hiç USDT taşımadı ve yine de baytları için ödedi. Üçüncüsü, yakmanın hemen üstünde bir fee_limit ile imzalandı ve geçti.
O gönderen istisnaydı. Aynı öğleden sonra saydığımız art arda 12,000 USDT çağrısının her biri bir fee_limit taşıyordu.
fee_limit değeri neye ayarlanmalı
fee_limit, çağrının kullanabileceği enerjiyi — tutulan da olsa yakılan da olsa — sınırlar ve kendi başına hiçbir şey tahsil etmez. Enerjisi zaten cüzdanda olan bir transfer onun hiçbirini yakmaz; bu yüzden enerjisi olan bir cüzdanda cömert bir sınır bedavadır. Bir transferi hiçbir zaman yarıda bırakmayan değer, büyük yakma olan 13.1 TRX'tir. 6.5 TRX'lik bir sınır yalnızca alıcı transferin indiği anda hâlâ USDT tutuyorsa yeter ve boş bakiyeli bir alıcı, hiç tutmuş olsun olmasın, büyük rakama mal olur (iki rakamın nereden geldiği). Transferin ihtiyacının altındaki bir sınır, ihtiyaç duyduğu enerjinin tamamını tutan bir cüzdanda bile çağrıyı durdurur, çünkü düğüm o enerjiyi sınıra karşı sayar.
İmzalanmış bir transferi sizin için yayınladığımızda — mode B'de — herhangi bir enerji satın alınmadan önce onu bu kurala tabi tutarız. Transferin enerjisini ağın o anki fiyatıyla ödeyemeyecek bir fee_limit, 400 invalid_request ile ve details.reason alanı fee_limit_too_low olarak geri çevrilir. O tek transferin bir tahmini, yakmasını burn_cost_trx olarak döndürür ve en az o kadar yüksek bir sınır her zaman geçer.
Sınır en çok, maliyeti fiyatlandıktan sonra değişen bir transferde önem taşır. Kontrol ettiğinizde USDT tutan, transfer indiğinde ise bakiyesini boşaltmış olan bir alıcı büyük rakama mal olur. Cüzdan küçük rakam için enerji tutuyorsa düğüm farkı TRX'ten yakar. Bakiye o farkı karşılamalıdır ve fee_limit büyük rakamın tamamını karşılamalıdır, çünkü cüzdanın tuttuğu enerji de ona karşı sayılır. İkisinden birinde eksik kalırsa transfer OUT_OF_ENERGY ile durur ve yolda yaktığı yanmış kalır.
Cüzdanda enerji varken geriye kalan bant genişliğidir
Enerji sözleşme çağrısının bedelini öder, başka hiçbir şeyin değil. İşlemin baytları ayrıca, bant genişliği olarak ölçülür (iki sayaç yan yana). Her hesap her gün 600 bayt bant genişliğini bedava alır; bu, kabaca bir USDT transferini karşılar. Bunun ötesinde ağ, her işlemin faturalandığı bant genişliğinin tamamı için TRX yakar; oran enerji oranının on katıdır: bir bayt, on birim enerjinin tuttuğuna mal olur.
Bir USDT transferine birkaç yüz bayt bant genişliği faturalanır. 2 Eylül 2026'da gönderip ölçtüğümüz transfere 345 faturalandı, yukarıdaki üç denemeye ise 339 ile 345 arasında. Dolayısıyla ücretsiz hak günün ilk transferinde gittikten sonra her ek transfer baytlarının bedelini TRX ile öder; enerjisi kiralanmış, stake edilmiş ya da yakılmış olsun fark etmez. Hiç TRX tutmayan bir cüzdan, günün ilk transferini devredilmiş enerjiyle yine de gönderebilir; baytları ücretsiz hak öder. İkincisi için hesapta TRX gerekir (TRX tutmadan göndermek).
Transferin dışındaki ücretler
Gönderen bir cüzdanın, kendisine enerji devredilebilmesi için zincirde var olması gerekir (aktivasyonun ne olduğu) ve ağın hiç görmediği bir adrese TRX göndermek, onun hesabını yaratan şeydir. Hesap oluşturmayı iki zincir parametresi fiyatlar. Böyle bir transferin bunlardan yalnızca ilkini mi yoksa ikisini birden mi ödediğini görmek için bir adresi aktive etmedik; bu yüzden tablo ikisini de listeler ve toplamları, bunun için tutulacak tutardır. İki parametre daha, bir işlemdeki memo'yu ve çok imzalı bir yetki altında imzalanmış bir işlemi fiyatlar. Aktivasyonun aksine ikisi de bir memo ya da çok imzalı yetki taşıyan her işlemde tahsil edilir; bu yüzden öyle imzalayan bir sıcak cüzdan, aşağıdaki tabloda sayılan her transfere o parametreyi ekler. İkisini de göndermedik ve o satırlar parametreyi verir, ölçülmüş hiçbir şey vermez.
| Zincir parametresi, 3 Eylül 2026'da okundu | Neyi fiyatlar | Değer |
|---|---|---|
getEnergyFee | Yakılan bir birim enerji | 100 sun |
getFreeNetLimit | Bir hesabın günde aldığı ücretsiz bant genişliği | 600 bayt |
getTransactionFee | Ücretsiz hakkın ötesinde bir bayt bant genişliği | 1,000 sun |
getCreateNewAccountFeeInSystemContract | Bir sistem sözleşmesinde yeni hesap oluşturma | 1 TRX |
getCreateAccountFee | Hesap oluşturma | 0.1 TRX |
getMemoFee | Bir işlemdeki memo | 1 TRX |
getMultiSignFee | Çok imzalı bir işlem | 1 TRX |
Bir günlük transfer için tampon
Hepsi bir araya geldiğinde, gönderen bir cüzdanın bir günde harcadığı TRX, enerjisinin nereden geldiğine ve yakıyorsa ne tür bir alıcıya ödediğine bağlıdır. Aşağıdaki tablo, transfer başına 345 bayt bant genişliği faturalandığını, ücretsiz hakkın günün ilk transferinde harcandığını ve yukarıdaki parametreleri varsayar. Yakan bir cüzdan her transferde 6.5 TRX ya da 13.1 TRX enerji öder, baytlarını da ikinci transferden itibaren. Üzerinde enerji olan bir cüzdan yalnızca baytları öder.
| Günlük transfer | Cüzdanda enerji var, kiralanmış ya da stake edilmiş | Enerji yok, alıcılar USDT tutuyor | Enerji yok, alıcıların USDT'si yok |
|---|---|---|---|
| 1 transfer | 0 TRX | 6.5 TRX | 13.1 TRX |
| 10 transfer | 3.105 TRX | 68.105 TRX | 134.105 TRX |
| 100 transfer | 34.155 TRX | 684.155 TRX | 1344.155 TRX |
| Üstüne, fiyatlandıktan sonra USDT'sini boşaltan bir alıcı için | 6.6 TRX | 6.6 TRX | 0 TRX |
Kiralanan enerjinin bedeli bizdeki bakiyenizden ödenir ve transfer başına fiyatı fiyatlar sayfasındadır. Stake edilmiş enerji, onu üretmek için kilitlenen TRX'e mal olur ve bu, bu tablonun dışında kalır (stake etmek ile kiralamak). Günlük rakam, günde bir kez yapılan bir yüklemenin cüzdanda bırakması gereken tutardır. Tek bir transferden önce taban daha küçüktür: o transferin yakması, yakıyorsa, ve baytları.
Son satır, küçük rakama göre satın alınmış enerji için paydır. Auto-refill, bir cüzdanı transferlerinin ardından yeniden yaklaşık 131,000 birime doldurur; bu, iki tür alıcıya da yeter. Dolayısıyla böyle bir cüzdanda büyük rakama ihtiyacı olduğu ortaya çıkan bir alıcı enerjiyle karşılanır ve pay sıfıra iner (Auto-refill nasıl çalışır). Enerjinin kaynağı ne olursa olsun fee_limit yine transferin enerjisinin tamamını karşılamalıdır; bu, transfer indiğinde USDT tutmuyor olabilecek bir alıcı için 13.1 TRX'tir.
Ücretsiz hakkın gün içinde ne kadar çabuk geri geldiğini ölçmedik; tablo yalnızca günün ilk transferinin ona bindiğini varsayar, dolayısıyla transferlerini güne yayan bir cüzdan için bant genişliği rakamları bir üst sınırdır.
Her transferin sınırını, düğümün onu tabi tutacağı yakmaya göre boyutlandırın: API referansında POST /v1/estimate ve burn_cost_trx →