TRON'da yatırma adreslerinden USDT süpürmek: süpürme başına aktivasyon, enerji ve bant genişliği
Her müşteriye kendine ait bir yatırma adresi veren bir ödeme geçidi ya da borsa, herhangi bir kısmını ödeyebilmeden önce, o adreslerdeki TRC-20 USDT'yi tek bir ana cüzdanda, sıcak cüzdanda toplamak zorundadır. TRON'da bu hareketlerin her biri, yatırma adresi tarafından imzalanan olağan bir USDT transferidir. Zincirde bir hesaba, sözleşme çağrısı için enerjiye ve baytlar için bant genişliğine ihtiyaç duyar; yalnızca USDT ile ödeme almış bir yatırma adresinin ise bunların hiçbiri yoktur.
USDT almak bir hesap oluşturmaz
Bir USDT bakiyesi, jeton sözleşmesinin kendi deposundaki bir kayıttır. Gelen bir transfer o kaydı yazar ve hiçbir hesap oluşturmaz; dolayısıyla bir adres USDT tutarken ağın onun için hiçbir hesabı olmayabilir. 7 Eylül 2026 tarihli ölçümümüz ana ağda böyle iki adres buldu: her biri USDT tutuyordu ve okuduğumuz düğüm, arkasındaki hesap sorulduğunda hem deneme çağrımızdan önce hem sonra boş bir nesne döndürdü. 27 Ekim'de ikisi de 7 Eylül'de tuttukları bakiyeleri aynen tutuyordu.
Enerji bir hesaba devredilir ve biz onu hesabı olmayan bir adrese teslim etmeyiz: böyle bir adresi from olarak anan bir mode A ya da mode C siparişi 422 invalid_address ile döner ve details.reason alanı inactive_wallet olur. Zincirin kendisinin böyle bir adrese devri kabul edip etmeyeceğini sınamadık, çünkü bizim retimiz önce gelir. Operasyon notlarımız ayrıca, hiçbir şey almamış bir cüzdandan yapılan göndermeye düğümün verdiği yanıtı da kaydeder: no OwnerAccount. Bu not, kendi sıcak cüzdanımızdan gönderilen TRX ile ilgilidir; bu durumdaki bir adresten bir USDT transferi denemedik. Durumun daha geniş hikâyesi aktive edilmemiş hesaplar yazısındadır.
Bir adresi aktive etmek tek bir TRX transferi alır ve bedelini gönderen öder
Gelen herhangi bir TRX transferi, ne kadar küçük olursa olsun, hesabı oluşturur ve o andan sonra adres, diğerleri gibi bir hesaptır. Bu ölçümün ilk denemesi tam da bu yüzden ters gitti ve onu attık: bir adres hesabı yok olarak okundu ve 22 saniye sonra biri ona tek bir sun gönderdi; bu da bir hesap oluşturdu. Kendi oluşturulma zamanı bunu söylüyordu.
Hesabı oluşturmanın ücreti, TRX'i gönderene düşer: bir süpürme düzeninde aktivasyonları fonlayan cüzdana. Onu iki zincir parametresi belirler. Parametreleri 3 Eylül 2026'da okuduk ve ağ onları değiştirebilir; bu yüzden bütçelemeden önce yeniden okuyun.
| Zincir parametresi | Değer, 3 Eylül 2026'da okundu |
|---|---|
getCreateAccountFee | 0.1 TRX |
getCreateNewAccountFeeInSystemContract | 1 TRX |
İkisinin düz bir TRX transferinde nasıl birleştiğini kendi gönderimizle ölçmedik: bunun için taze bir adrese canlı bir transfer gerekir ve biz hiç yapmadık. Her hâlükârda ücret adres başına bir kez ödenir. Her adresi üretildiğinde aktive eden bir masa onu hiç para yatırılmayabilecek adreslerde öder; ilk para yatırmada aktive eden ise yalnızca süpürülecek bir şey olan yerde öder.
Her süpürme düşük enerji rakamını alır
Bir USDT transferinin enerji olarak harcadığı, alıcıya bağlıdır. Alıcı zaten USDT tutuyorsa transfer yaklaşık 65,000 birim alır; USDT bakiyesi sıfırsa yaklaşık 131,000. Alıcının hesabı olup olmaması işe karışmaz. O iki adresi bulan ölçüm dört kombinasyonu da yan yana koydu ve her seferinde bakiye belirleyici oldu (neden iki rakam var).
Bir süpürme her zaman aynı alıcıya, sıcak cüzdana öder ve sıcak cüzdan USDT tutar. Dolayısıyla yatırma adresi hangi durumda olursa olsun her süpürme ucuz türdendir: single. 7 Eylül çağrıları, gerisini koruyan bir cüzdandan bir birim taşıdı; bir süpürme ise her şeyi taşır ve yatırma adresini sıfırda bırakır. 27 Ekim'de düğümden ikisini de aynı iki adreste, alıcı olarak USDT tutan bir cüzdanla simüle etmesini istedik.
| USDT tutan bir cüzdana simüle edilmiş transfer, 27 Ekim 2026 | Kullanılan enerji |
|---|---|
| Birinci adres, bir birim | 64,285 |
| Birinci adres, tüm bakiyesi | 64,285 |
| İkinci adres, bir birim | 64,285 |
| İkinci adres, tüm bakiyesi | 64,285 |
Yatırma adresini boşaltmak hiçbir şeyi değiştirmedi ve rakam, o ölçümün USDT tutan bir alıcıya yapılan her transfer için verdiği rakamdır. Bunlar düğümün simülasyonlarıdır ve hiçbiri yayınlanmış bir süpürmenin makbuzu değildir; 7 Eylül rakamları da aynı çekinceyi taşır. İki adresin bugün bir hesabı olup olmadığını yeniden okumadık.
Ucuz türü kaybetmenin tek yolu sıcak cüzdanı boşaltmaktır. Alıcıdaki tek bir birim USDT düşük rakam için yeter, ama sıfırda ona yapılan sonraki süpürme yaklaşık 131,000 birim alır; yakılırsa bu 13.1 TRX'tir. Yakılırsa, olağan bir süpürme birim başına 100 sun olan protokol oranıyla 6.5 TRX tutar ve aynı enerjiyi kiralamanın ne tuttuğu piyasayla birlikte hareket eder.
Ücretsiz bant genişliği, adres başına günde yaklaşık bir süpürmeyi karşılar
Bant genişliği bir işlemin baytlarını ölçer; enerji ise hesaplamasını (iki sayaç yan yana). Her hesap bunun ücretsiz bir günlük hakkını alır. 2 Eylül 2026'da ana ağda gönderip ölçtüğümüz USDT transferi bant genişliğinin bedelini TRX ile ödedi ve bu, ona tam olarak ne kadar bant genişliği faturalandığını verir.
| Bir USDT transferinin bant genişliği | Değer | Okunduğu tarih |
|---|---|---|
Baytlar için yakılan (net_fee) | 0.345 TRX | 2 Eylül 2026 |
Bir baytın yakma fiyatı (getTransactionFee) | 1,000 sun | 3 Eylül 2026 |
| Faturalanan bant genişliği, bölmeyle | 345 bayt | hesaplandı |
Hesap başına günlük ücretsiz hak (getFreeNetLimit) | 600 | 3 Eylül 2026 |
Günde 600'e karşı, bu kadar faturalanan bir süpürme sığar, art arda iki tanesi sığmaz. Hakkın ötesinde ağ, baytlar için gönderenin TRX'ini yakar. Yani bir adresin bir gündeki ilk süpürmesi bant genişliği olarak hiçbir şeye mal olmaz ve enerjisini de devirle alan bir yatırma adresinin onu göndermek için kendi TRX'ine ihtiyacı yoktur. İlkinden kısa süre sonraki ikinci bir süpürme, baytlarının bedelini yatırma adresinin TRX'inden öder. Hakkın ikisi arasında ne kadar çabuk geri geldiğini ölçmedik; kendi süpürmemiz ücretsiz haktan adres başına günde yaklaşık bir transferi planlar. Bir adres bundan daha sık süpürülecekse, aktive eden transfer ona aynı anda o baytlar için gereken TRX'i de bırakabilir.
Bir süpürme turu için enerji sipariş etmek
Mode A her transferin iki ucunu da adlandırır: yatırma adresini from, sıcak cüzdanı to olarak; türü sıcak cüzdandan biz okuruz. Mode C yalnızca enerji teslim edilecek cüzdanı adlandırır ve türü sizden alır; bu, süpürmelerini kendi takviminde imzalayan ve enerjinin önceden orada durmasını isteyen bir saklama (custody) sistemine uyar (mode C ayrıntılı). Bir süpürme için bu tür, sıcak cüzdan USDT tuttuğu sürece her zaman single'dır. İki mod da bir siparişte 500 transfere kadar alır, bir ödeme turuyla aynı tavan. Kiralama beş dakika ya da bir saattir ve send_before, sonundan üç saniye önce düşer.
Hesabı olmayan tek bir yatırma adresi tüm siparişi geri çevirtir. 422 onu details.index ve details.address içinde adlandırır ve hiçbir şey satın alınmaz. Bu yüzden turu önce eleyin. POST /v1/estimate aynı 500 transferi alır ve hiçbir şey ayırmaz; siparişin nerede geri çevireceği konusunda da uyarır: her kaleme from verin; hesabı olmayan her yatırma adresi inactive_sender işaretiyle döner. Onları aktive edin, aktivasyonların onaylanmasını bekleyin ve siparişi gönderin. Ret Idempotency-Key anahtarını harcamaz ve bir siparişi aktivasyon yüzünden geri çevirmeden önce aktivasyonu önbelleğimizin dışından yeniden okuruz; bu yüzden aktive eden transfer onaylanır onaylanmaz aynı anahtar ve aynı gövde çalışır.
Kendi süpürmemizden alınmaya değer kurallar
Kendi süpürmemizi işletiyoruz. Müşteriler bizim onlar için tuttuğumuz yatırma adreslerine öder ve arka plandaki bir geçiş, o bakiyeleri satın alımların bedelini ödeyen tek sıcak cüzdana taşır. TRX taşır; bu yüzden bant genişliği harcar, enerji harcamaz ve kayıtları bir USDT süpürmesinin enerji tarafı hakkında hiçbir şey söylemez.
Süpürmemiz tutarı, karar verdiği anda zincirden okur. Kendi kayıtlarımız yakılmış bir ücreti ya da veritabanı satırı çöken bir süreçte kalmayan bir süpürmeyi bilmez; zincir bilir. Aynı kural yeniden denemeyi güvenli kılar: bakiye zaten çıkmışsa gönderilecek bir şey yoktur.
Yayınlanmış bir süpürmeyi, işlemi bir blokta görünene kadar açık tutarız ve onu başarısız olarak ancak, imzalayıcımızın bir işleme koyduğu en uzun son kullanma anından kısa olmayan bir pencereden sonra yazarız. Daha erken kapatırsanız hâlâ inebilecek bir transfer kayıp sayılır ve sonraki geçiş aynı bakiyenin ikinci bir transferini imzalayabilir. Bir süpürme onaylanmamışken adresi sonraki geçişin dışında kalır.
TRX süpürmemiz en fazla bakiyeden bir ücret rezervi düşülmüş tutarı gönderir ve o rezervi yalnızca adresin ücretsiz bant genişliği zaten harcanmışsa tutar. Bir USDT süpürmesi ücretini taşıdığından farklı bir varlıkla öder; bu yüzden USDT bakiyesinin tamamı her seferinde gider ve rezerv, bir yatırma adresinin günde ikinci bir süpürmenin baytları için ihtiyaç duyduğu TRX olur.
Süpürme fiyatlanmadan önce hâlâ aktive edilmesi gereken her yatırma adresini bulun, istek başına beş yüz: POST /v1/estimate, her kalemde from ile →