Blog · 30 de octubre de 2026

Cuánto TRX necesita una cartera para enviar USDT

Una cartera que envía USDT en TRON tiene que acertar con dos números, y es fácil confundirlos. Uno es la comisión: lo que una transferencia le quita a la cuenta. El otro es el TRX que la cuenta tiene que mantener, y el límite que la transacción tiene que llevar, para que la transferencia llegue siquiera a completarse. Con energía en la cartera, necesita TRX solo para los bytes: nada en la primera transferencia del día, unos 0.345 TRX por cada una de las siguientes. Sin energía necesita 6.5 TRX por cada transferencia a un destinatario con USDT y 13.1 TRX a uno que no tiene, además de los mismos bytes. En cualquiera de los dos casos, el fee_limit de la transacción tiene que alcanzar la quema completa. Una cartera con fondos para la comisión y corta del segundo número falla de una manera que sigue costando TRX.

El nodo toma el menor de dos límites

Enviar USDT es una llamada a un contrato inteligente, y antes de que la llamada se ejecute el nodo decide cuánta energía puede gastar. Calcula dos cifras y toma la menor. La primera es lo que la cuenta puede pagar: la energía que ya tiene, más tantas unidades como compraría su TRX a la tarifa del protocolo de 100 sun cada una. La segunda es lo que permite la transacción: su fee_limit, dividido por esos mismos 100 sun.

De ahí salen dos reglas. El TRX de la cuenta tiene que cubrir toda la energía que la transferencia vaya a quemar, porque un saldo que no llega a la quema limita la llamada por debajo de lo que necesita. Y el fee_limit tiene que permitir esa quema, porque un límite bajo limita la llamada igual de fuerte, tenga el TRX que tenga detrás. Si falla cualquiera de las dos, la llamada se detiene a medias con OUT_OF_ENERGY, y el TRX que quemó por el camino queda quemado (qué significa ese resultado).

La segunda cifra sorprende a las carteras que alquilan o ponen TRX en staking. El nodo también cuenta contra el fee_limit la energía que la cuenta ya tiene, igual que cuenta el TRX que quemaría. Una transacción firmada sin fee_limit lleva un límite de cero, y un límite de cero no deja que la llamada gaste nada de energía, ni delegada ni quemada. Diga lo que diga el aviso de una cartera, el nodo hace esta aritmética: la energía propia de la cuenta no cubrirá la llamada, el nodo quemará TRX para el resto, y la transferencia se completa solo si el saldo y el límite llegan los dos hasta ahí.

Tres intentos de una misma cartera en mainnet

La parte de la regla que toca al fee_limit se puede ver en mainnet. El 6 de octubre de 2026, recorriendo el registro público del contrato de USDT, nos topamos con un remitente que intentó la misma transferencia tres veces en menos de cuarenta minutos. La transferencia necesitaba 130,285 unidades de energía, la cifra de un destinatario sin USDT, y la cuenta no tenía energía propia, así que cada unidad había que comprarla quemando TRX. Cada fila es el registro propio de esa transacción.

El primer intento se detuvo exactamente en 11,000 unidades, que es su fee_limit dividido por 100 sun. La cuenta podría haber pagado más: pagó la quema completa en el tercer intento, y su registro no muestra que llegara TRX entre medias. El segundo intento no llevaba fee_limit, y su recibo informa de un límite de cero en la primera instrucción del contrato. No gastó energía, no movió USDT y aun así pagó sus bytes. El tercero se firmó con un fee_limit justo por encima de la quema y se completó.

Ese remitente fue la excepción. De 12,000 llamadas consecutivas a USDT que contamos esa misma tarde, todas llevaban un fee_limit.

A qué fijar el fee_limit

El fee_limit limita la energía que la llamada puede usar, la que ya se tiene o la que se quema, y por sí solo no cobra nada. Una transferencia cuya energía ya está en la cartera no quema nada de ella, así que un límite holgado no cuesta nada en una cartera que tiene su energía. El valor que nunca deja corta una transferencia es la quema mayor, 13.1 TRX. Un límite de 6.5 TRX basta solo mientras el destinatario siga teniendo USDT cuando la transferencia llegue, y un destinatario con el saldo vacío cuesta la cifra mayor haya tenido USDT alguna vez o no (de dónde salen las dos cifras). Un límite por debajo de lo que la transferencia necesita detiene la llamada incluso en una cartera que tenga toda la energía necesaria, porque el nodo cuenta esa energía contra el límite.

Cuando emitimos por usted una transferencia firmada, en el mode B, la sometemos a esta regla antes de comprar ninguna energía. Un fee_limit que no puede pagar la energía de la transferencia al precio actual de la red se rechaza con 400 invalid_request y details.reason en fee_limit_too_low. Una estimación de esa transferencia devuelve su quema como burn_cost_trx, y un límite al menos así de alto siempre pasa.

El límite importa más en una transferencia cuyo coste cambia después de calcularse su precio. Un destinatario que tenía USDT cuando usted lo comprobó, y que ha vaciado su saldo para cuando la transferencia llega, cuesta la cifra mayor. Si la cartera tiene energía para la menor, el nodo quema la diferencia con TRX. El saldo tiene que cubrir esa diferencia, y el fee_limit tiene que cubrir la cifra mayor entera, porque la energía que la cartera tenía también cuenta contra él. Si falla cualquiera de los dos, la transferencia se detiene con OUT_OF_ENERGY, y lo que quemó por el camino queda quemado.

Con energía en la cartera, lo que queda es el ancho de banda

La energía paga la llamada al contrato y nada más. Los bytes de la transacción se miden aparte, como ancho de banda (los dos contadores, lado a lado). Toda cuenta recibe 600 bytes de ancho de banda gratis cada día, que cubren más o menos una transferencia USDT. Pasado eso, la red quema TRX por todo el ancho de banda que se factura a cada transacción, a diez veces la tarifa de la energía: un byte cuesta lo que cuestan diez unidades de energía.

A una transferencia USDT se le facturan unos cientos de bytes de ancho de banda. A la que enviamos y medimos el 2 de septiembre de 2026 se le facturaron 345, y a los tres intentos de arriba, entre 339 y 345. Así que una vez gastada la asignación gratuita en la primera transferencia del día, cada transferencia siguiente paga sus bytes en TRX, tanto si su energía se alquiló, se puso en staking o se quemó. Una cartera sin nada de TRX aún puede enviar su primera transferencia del día con energía delegada, con la asignación gratuita pagando los bytes; la segunda necesita TRX en la cuenta (enviar sin tener TRX).

Cargos ajenos a la transferencia

Una cartera que envía tiene que existir en la cadena antes de que se le pueda delegar energía (qué es la activación), y enviar TRX a una dirección que la red nunca ha visto es lo que crea su cuenta. Dos parámetros de la cadena fijan el precio de crear una cuenta. No hemos activado ninguna dirección para ver si una transferencia así paga solo el primero de ellos o los dos, así que la tabla enumera ambos, y su suma es la cantidad que hay que guardar para eso. Otros dos parámetros fijan el precio de un memo en una transacción y de una transacción firmada con un permiso multifirma. A diferencia de la activación, los dos se cobran en cada transacción que lleva un memo o un permiso multifirma, de modo que una cartera caliente firmada así suma el parámetro a cada transferencia contada en la tabla de más abajo. No hemos enviado ninguna de las dos, y esas filas dan el parámetro y nada medido.

El colchón para un día de transferencias

En conjunto, el TRX que consume en un día una cartera que envía depende de dónde le llegue la energía y, cuando quema, del tipo de destinatario al que paga. La tabla de abajo supone 345 bytes de ancho de banda facturados por transferencia, la asignación gratuita gastada en la primera transferencia del día y los parámetros de arriba. Una cartera que quema paga 6.5 TRX o 13.1 TRX de energía en cada transferencia, y sus bytes a partir de la segunda. Una cartera con energía solo paga los bytes.

La energía alquilada se paga con su saldo con nosotros, y su precio por transferencia está en la página de precios. La energía en staking cuesta el TRX bloqueado para producirla, que queda fuera de esta tabla (staking frente a alquiler). La cifra diaria es lo que tiene que dejar en la cartera una recarga al día. Antes de cada transferencia suelta, el mínimo es menor: la quema de esa transferencia, si quema, y sus bytes.

La última fila es el margen para la energía comprada a la cifra menor. Auto-refill deja de nuevo una cartera en unas 131,000 unidades después de sus transferencias, suficiente para cualquiera de los dos tipos de destinatario, así que en una cartera así un destinatario que resulta necesitar la cifra mayor queda cubierto en energía y el margen baja a cero (cómo funciona Auto-refill). Sea cual sea la fuente de la energía, el fee_limit sigue teniendo que cubrir toda la energía de la transferencia, que son 13.1 TRX para un destinatario que podría no tener USDT cuando la transferencia llegue.

No medimos con qué rapidez se recupera la asignación gratuita a lo largo de un día; la tabla supone que solo la primera transferencia del día se apoya en ella, así que para una cartera que reparte sus transferencias las cifras de ancho de banda son un límite superior.

Dimensione el límite de cada transferencia según la quema a la que el nodo la va a someter: POST /v1/estimate y su burn_cost_trx, en la referencia de la API →