Blog · 7 Kasım 2026

Bir ödeme cüzdanını enerjide tutmak: stake, transfer başına kiralama ya da her birinden sonra dolum

TRON'da bir ödeme cüzdanı gönderdiği her USDT transferinde enerji harcar: alıcı zaten USDT tutuyorsa yaklaşık 65,000 birim, hiç tutmuyorsa yaklaşık 131,000. Enerji yoksa ağ bunun yerine TRX alır, birim başına 100 sun ile; bu, transfer başına 6.5 TRX ya da 13.1 TRX eder ve cüzdan o TRX'i tuttuğu ve işlemin fee_limit değeri yakmaya izin verdiği sürece ödeme yine de onaylanır (hesabın tamamı). Yani bir sıcak cüzdanın işi, kimse elle sipariş etmeden her gönderimden önce enerjiyi yerinde tutmaktır. Üç örüntü bu işi görür ve her biri kendi yoluyla başarısız olur.

Bir stake en yoğun gün için boyutlandırılır ve her gün için ödenir

Enerji için TRX stake etmek, sabit bir günlük havuzdan bir pay satın alır. Bir cüzdanın günlük hakkı, stake'inin ağın TotalEnergyLimit değeriyle çarpılıp TotalEnergyWeight değerine bölünmesidir ve 3 Eylül 2026'da bu oran 180,000,000,000 bölü 18,770,236,993 idi: stake edilen her TRX için günde ondan biraz az enerji birimi. Bölen, ağın enerji için tuttuğu stake'in tamamıdır, sizinki dâhil; bu yüzden rakam blok blok kayar (formülün işlenmiş hâli).

Harcanan enerji, izleyen 24 saat boyunca yavaş yavaş geri gelir. Gününün çoğunu öğlen tek bir turda ödeyen bir cüzdan, o turu karşılayan bir stake'e ihtiyaç duyar ve stake sakin saatler boyunca ve sakin günler boyunca da dondurulmuş kalır. Çıkmak da yavaştır. Ana ağda bugün stake'ten çıkarılan TRX on dört gün sonra çekilebilir.

Ödemeler stake'i aştığında, hakkı harcanmış bulan transferler eksik için TRX yakar ve cüzdanda TRX ile fee_limit'te yer varsa yine de onaylanır. Hiçbir şey hata döndürmez ve ilk belirti, cüzdanın geçmişindeki bir yakma satırıdır (sınır çok düşük olduğunda ne olur).

Transfer başına kiralamak her gönderimin önüne bir bekleme koyar

İkinci örüntü, her transfer için enerjiyi o geldikçe satın alır. Bir sipariş gönderen cüzdanı ve alıcıyı adlandırır. API 202 ile yanıt verir; siparişin kendi adresini Location içinde, sorgulama aralığını Retry-After içinde taşır ve biz enerjiyi satın alıp cüzdanda onu gözleriz. Devir onaylandığında sipariş send_before taşır ve bu, kodunuzun gönderme sinyalidir. Pencere, kiralamanın üç saniye eksiğidir: beş dakikalık kiralamada 297 saniye, bir saatlik kiralamada 3,597.

Her ödeme bu yüzden bir satın almayı ve bir bloğu bekler. Bu beklemeyi, gönderimi müşterinin kodunun yaptığı kendi siparişlerimiz üzerinde, siparişin oluşturulduğu andan zincirde onaylanan son devre kadar, 8 Eylül 2026'ya kadarki altmış gün boyunca ölçtük.

On üç sipariş küçük bir örnektir ve çoğu erken dönemden. Yedisi canlı siparişlerin ilk haftasından geldi, en yavaşlar da onların arasındaydı ve sonraki haftalar üç ile dört saniyede seyretti. Ölçümü daha büyük bir örnekte tekrarlamadık.

Enerji inmeden gönderilen bir transfer tam oranla yakar ve send_before'dan sonra gönderilen bir transfer enerjiyi gitmiş bulup aynı şekilde yakabilir. Yaktığı TRX geri gelmez. Teslim edilip pencere içinde kullanılmayan enerji expired olarak kapanır ve ücretlendirilir, çünkü teslim edilmiştir (bir kiralamanın üç zamanlayıcısı). Kendi takviminde gönderen bir ödeme kuyruğunun bu sinyal etrafında yeniden kurulması gerekir. Önceden bilinen bir ödeme turu için, 500 transfere kadar tek bir toplu sipariş beklemeyi tek bir yerde toplar: tüm turun enerjisi önce satın alınır ve içindeki her transfer tek bir send_before paylaşır (bir toplu işin içeriden görünüşü).

Cüzdanı her transferden sonra dolduran bir kural

Üçüncü örüntü, cüzdan üzerindeki bir kuraldır; biz onu Auto-refill olarak satıyoruz, TRX tutmadan USDT göndermenin sıcak cüzdan durumu. İki alan alır, address ve daily_budget_trx; tek bir POST /v1/auto-refill-rules çağrısında. O andan itibaren cüzdan, yaptığı her transferden sonra yaklaşık 131,000 birim enerjiye geri getirilir. Bu, bir sonraki herhangi bir transferi karşılar; USDT tutmayan bir adrese yapılanı da. Kural hiçbir sipariş oluşturmaz: GET /v1/orders yalnızca sizin verdiklerinizi listeler.

Bir dolum, ondan önceki transferin kullandığına göre fiyatlanır. O transfer yaklaşık 65,000 birim harcadıysa dolum single oranıyla, yaklaşık 131,000 harcadıysa double oranıyla faturalanır. İki oran da GET /v1/tariff içinde maintenance_price_trx altındadır. Bunlar kendi başına bir fiyattır ve kiralama fiyatlarından ayrı hareket eder; tahsil edilen oran, dolum onaylandığında yürürlükte olandır. Yeni bir kuralın ilk dolumu her zaman double'dır: onu fiyatlayacak daha önceki bir transfer yoktur ve cüzdan tam 131,000'i bir anda alır.

Faturalama, enerji zincirde cüzdanda görünene kadar bekler; bir tedarikçinin teslim ettiğini söylemesi yetmez. Her tahsilat bir maintenance.topup olayı olarak gelir — olay rule_id, address, units ve charged_trx taşır — ve charge satırı olarak, GET /v1/ledger içinde. Hiçbir şey göndermeyen bir cüzdan dolum almaz ve hiçbirinin bedelini ödemez.

Dolum nasıl durur ve cüzdan o zaman ne yapar

Günlük bütçe, daily_budget_trx, kural başladığında ve her UTC gününün başında yeniden kullanılabilir bakiyenizden ayrılır ve kuralın o gün harcayabileceği en fazla tutardır. Dolumlar o rezervden çekilir ve ondan kalan, UTC gece yarısı bakiyeye döner. Kuralın spent_today_trx alanı günün ne kadarının gittiğini gösterir. Bütçeyi öğlen yükseltmek farkı rezerve ekler ve ikinci bir gün açmaz.

Bütçe harcandığında dolumlar bir sonraki UTC gününe kadar durur. Tek bir maintenance.budget_exhausted olayı alırsınız, içinde spent_today_trx ve daily_budget_trx ile; kural active kalır. O andan gece yarısına kadar, cüzdanın enerjiyle karşılayamadığı her transfer eksik için birim başına 100 sun ile TRX yakar. Ortalama bir gün için boyutlandırılmış bir bütçe, yoğun bir günde tükenir.

Bakiyeniz ertesi günün rezervini karşılayamadığında kural durur. status alanı paused olur, paused_reason insufficient_balance olarak ayarlanır ve bir maintenance.paused olayı çıkar. Duraklatılmış bir kural kendiliğinden hiç devam etmez ve bir para yatırma onu yeniden başlatmaz: PATCH /v1/auto-refill-rules/{rule_id} çağrısını, {"status": "active"} ile, bekler ve bakiyenin hâlâ karşılayamadığı bir devam isteği 402 yanıtı alır. Kendi koyduğunuz bir duraklatma gerekçe taşımaz; böylece paused_reason, para bekleyen bir kuralı sizin kararınızı bekleyen birinden ayırt eder.

double oranının altındaki bir bütçe 422 ile, details.reason alanı budget_below_topup_price ve asgari tutar details.min_daily_budget_trx içinde olacak biçimde geri çevrilir: ilk dolum double'dır ve daha küçük bütçeli bir kural devreye girerdi ve onu hiçbir zaman karşılayamazdı.

Cüzdandaki yaklaşık 131,000 birim, USDT tutan adreslere iki transferi ya da hiç tutmayana bir transferi karşılar. Bir önceki transferin dolumu inmeden gönderilen bir transfer, ihtiyacından azını bulabilir ve yolunun bir kısmını, ya da neredeyse tamamını, TRX ile ödeyebilir. Bir transferden ne kadar sonra dolumun indiğini ölçmedik. Bir kuralı, dolumları o cüzdan için peşin ödediğimiz tutarı karşılamadan silmek, karşılanmamış kısma mal olur; peşin ödemeler ve tahsilatlar 6 Kasım 2026'dan itibaren sayılır; duraklatma bunun için hiçbir zaman ücret almaz.

Örnek bir gün, üç yoldan

Üçünü yan yana koymak için tek bir cüzdan ve tek bir gün alalım: zaten USDT tutan adreslere otuz ödeme ve hiç tutmayanlara on. Yakma ve stake ağ aritmetiğidir. Sipariş fiyatı ve dolum oranları bizimdir, GET /v1/tariff'ten 27 Ekim 2026'da 21:46 UTC'de okundu; bugünküler fiyatlar sayfasındadır.

O saatte siparişler dolumlardan daha az tuttu ve olağan durum buydu. Aynı akşama kadarki otuz günlük saatlik geçmiş boyunca dolum oranları bir kez bile değişmedi ve aynı transfer için verilen beş dakikalık bir sipariş, çoğu saatte dolumundan daha az tuttu.

Bir dolumun siparişin üstünde tuttuğu şey, her transfer çıktığında enerjisi zaten hazır olan bir cüzdanı ve bir günde harcayabileceği tutar için sert bir tavanı satın alır. Bütçe, bir stake gibi, yoğun günü karşılamalıdır, ama sakin bir günün ondan bıraktığı UTC gece yarısı bakiyeye döner. Bir kuralın günde kaç dolum yaptığına dair bir üretim rakamımız yok.

Bir ödeme cüzdanını, tek bir istek ve seçtiğiniz bir günlük bütçeyle kendini dolduracak şekilde ayarlayın: API referansında POST /v1/auto-refill-rules →