Blog · 8 de noviembre de 2026

Cómo leer el recibo de una transacción TRON: energía usada, comisión de energía, ancho de banda y resultado

La página de una transacción en un explorador de bloques muestra una transferencia USDT como una palabra, una comisión y unas pocas cifras de recursos. Un nodo devuelve el recibo de la misma transacción desde gettransactioninfobyid, con un nombre en cada cifra: energy_usage, energy_usage_total, origin_energy_usage, energy_penalty_total, energy_fee, net_usage, net_fee y result. energy_fee es el TRX quemado por la energía que la cuenta no tenía, a 100 sun por unidad, net_fee es el TRX quemado por los bytes, y en todos los recibos de esta entrada el fee de nivel superior es la suma de los dos. Guardamos recibos de mainnet para cada caso que merece lectura: una transferencia con energía alquilada, una pagada en TRX, llamadas en las que el contrato pagó parte de la energía, y transferencias que se detuvieron en OUT_OF_ENERGY o REVERT.

Un campo ausente significa cero

Un recibo omite todo campo cuyo valor es cero. Una transferencia que no quemó TRX por energía no tiene energy_fee, y una cuyos bytes no costaron nada no tiene net_fee. Los importes, energy_fee, net_fee y el fee de nivel superior, están en sun, una millonésima de TRX.

Una transferencia con energía alquilada, una pagada en TRX

Las dos transferencias de abajo consumieron 130,285 unidades, la cifra de un destinatario sin saldo de USDT. La primera es nuestra: el 2 de septiembre de 2026 alquilamos en JustLend DAO energía para una segunda cartera y enviamos un USDT desde ella (lo que costó ese pedido). La segunda es de otro remitente, del 6 de octubre de 2026, sin energía en la cuenta. La leímos de la lista de transacciones del remitente, que escribe los mismos campos en plano junto a la transacción, con los ceros incluidos, y deja fuera energy_penalty_total.

energy_usage_total es lo que consumió la llamada. energy_usage es la parte que el remitente pagó con energía que ya tenía, en staking o delegada, y energy_fee es el resto, comprado quemando TRX a 100 sun por unidad. En nuestra transferencia los dos primeros son iguales y el tercero está ausente, así que la delegación pagó cada unidad. El otro remitente no tenía energía, y 13,028,500 sun se fueron en 130,285 unidades, exactamente 100 sun cada una.

Las filas de ancho de banda coinciden. Ninguna de las dos cuentas cubrió los bytes con ancho de banda propio, así que cada una pagó 345,000 sun: 345 bytes a 1,000 sun el byte, la tarifa de los parámetros de la cadena que leímos el 2 de septiembre de 2026.

Cuando el contrato paga parte de la energía

El desplegador de un contrato puede asumir parte de la energía de cada llamada a él. El recibo lleva entonces origin_energy_usage, la parte del desplegador. Quien llama paga el resto de la manera en que se paga una transferencia, primero con su propia energía y luego quemando. El mercado de energía de JustLend DAO fija la parte de quien llama en una décima (consume_user_resource_percent es 10), y en los 83 recibos suyos de nuestra muestra la parte de quien llama es igual a energy_usage más una centésima de energy_fee.

La segunda cuenta que llama tenía 24 unidades propias y quemó 739,000 sun por las otras 7,390. Nuestra llamada de alquiler no tiene fee, aunque envió al contrato un prepago: ese dinero viaja como el valor de la llamada, y fee cuenta solo lo que tomó la red (adónde fue el prepago). Ninguno de los recibos de USDT de esta entrada lleva un origin_energy_usage: en cada uno, la energía propia del remitente y su quema suman el total entero.

Un origin_energy_usage ausente significa que el desplegador no pagó nada y que quien llama pagó la llamada entera. Es el caso más caro, y se ve exactamente igual que un campo que nadie rellenó. La parte del desplegador sale de la propia energía del desplegador, y solo mientras le quede alguna. Esa misma tarde, menos de tres horas antes de nuestro alquiler, la llamada de alquiler de otro arrendatario en el mismo mercado no llevaba origin_energy_usage y pagó ella sola las 52,672 unidades, 51,492 de ellas quemadas.

Ancho de banda: net_usage frente a net_fee

El ancho de banda se mide en bytes de la transacción firmada (energía y ancho de banda, lado a lado). net_usage cuenta los bytes que una cuenta cubrió con su propio ancho de banda, la asignación diaria gratuita o un staking de ancho de banda. net_fee es lo que pagó en TRX por los bytes que no pudo cubrir. En todos los recibos que tenemos es lo uno o lo otro.

Nuestro pedido de JustLend muestra las dos cosas. La llamada de alquiler de arriba tiene net_usage 383 y ningún net_fee: la cubrió el ancho de banda gratuito de la cartera. Nuestra propia llamada de devolución, desde la misma cartera 144 segundos después y que no está en la tabla de arriba, no tiene net_usage y sí un net_fee de 378,000 sun. La asignación gratuita es de 600 al día según el getFreeNetLimit de la cadena, y lo que el alquiler dejó de ella no cubrió la devolución. De los 83 recibos de JustLend de nuestra muestra, 29 pagaron sus bytes, cada uno a 1,000 sun el byte.

Lo que decide la palabra de resultado

La palabra aparece dos veces en un recibo. Un recibo fallido lleva un result de nivel superior de FAILED, sea cual sea el motivo del fallo, con un resMessage en hexadecimal. La causa está un nivel más abajo, en receipt.result: SUCCESS, OUT_OF_ENERGY o REVERT. Un recibo exitoso no tiene ningún result de nivel superior, de modo que un script que lee solo el campo exterior archiva todo fallo bajo un mismo nombre.

Tres registros de una misma cartera del 6 de octubre de 2026 muestran cómo se produce OUT_OF_ENERGY. Son una misma transferencia firmada tres veces, leída de la lista de transacciones porque fee_limit pertenece a la transacción firmada. La tercera es la transferencia pagada en TRX de la primera tabla.

El primer intento se detuvo exactamente en 11,000 unidades, su fee_limit dividido por 100 sun: un nodo limita la energía de una llamada a fee_limit entre el precio de la energía, tenga lo que tenga la cuenta. El segundo no llevaba fee_limit, que cuenta como cero, así que no podía gastar nada de energía. Su recibo no tiene campos de energía, y su resMessage se descodifica como «Not enough energy for 'PUSH1' operation executing: curInvokeEnergyLimit[0], …». Tres minutos después la misma cuenta pagó el tercer intento, así que no estaba vacía. La energía delegada cae bajo el mismo tope, y por eso nuestra API rechaza una transferencia del mode B firmada sin fee_limit suficiente, con fee_limit_too_low, antes de que compremos ninguna energía.

Otras dos transferencias USDT de esos mismos minutos muestran las dos palabras de fallo, cada una FAILED en el nivel superior.

El primer remitente tenía 44,165 unidades propias, quemó TRX por 13,834 más, y se quedó sin energía en 57,999, todo lo que su energía y su TRX juntos podían comprar. Su fee_limit firmado permitía 350,000 unidades, así que esta vez el límite era la cuenta. En el segundo el contrato rechazó la transferencia: el resMessage dice «REVERT opcode executed», y USDT no da ningún motivo cuando revierte. Nuestra referencia de la API da dos causas: un remitente que ya no tiene la cantidad, y uno congelado por el emisor del token (los fallos con que se topan las mesas de pagos).

Solo un recibo SUCCESS registra tokens moviéndose: su log contiene el evento Transfer del token, como el de nuestra transferencia alquilada. Los recibos OUT_OF_ENERGY y REVERT no llevan log, porque no se movió ningún token. Su comisión se gasta igualmente, ya que lo que la llamada consumió antes de detenerse queda pagado (por qué el TRX se ha ido tras OUT_OF_ENERGY).

Cuando emitimos la transferencia firmada de un cliente en el mode B, el recibo también decide quién paga la energía. Un recibo OUT_OF_ENERGY que gastó menos que el requisito de la transferencia, 64,285 unidades hacia una dirección con USDT o 130,285 hacia una sin ellos, significa que nuestra energía no estaba en la dirección cuando se ejecutó la llamada. El ítem se cierra como expired y lo cobramos, salvo que nuestros registros muestren que el vendedor retiró la delegación antes del bloque de la transferencia, o que otra transferencia suya desde la misma dirección la gastó. Entonces el déficit es nuestro, igual que cuando un recibo gastó al menos el requisito y aun así se quedó sin energía porque nuestra estimación se quedó corta: el ítem se cierra como failed y devolvemos la reserva. Un recibo que tenemos consumió 108,047 unidades y aun así se detuvo: en una transferencia que habíamos dimensionado para un destinatario con USDT, ese déficit sería nuestro. También cobramos un REVERT.

La penalización forma parte del total

En nuestra transferencia alquilada el total es de 130,285 unidades, la cartera sacó exactamente 130,285 de su delegación, y 100,635 de esas unidades llevan la etiqueta de penalización. Las transferencias fallidas concuerdan: la energía de la cuenta más la energía quemada da el total, penalización incluida.

Los valores que tenemos son 100,635 en una transferencia completada hacia una dirección sin USDT, 25,905 en dos transferencias que se quedaron sin energía y 6,640 en la que rechazó el contrato. La simulación de una transferencia por un nodo informa de un energy_penalty coincidente: 100,635 junto a 130,285 para un destinatario sin USDT, y 49,635 junto a 64,285 para uno que tiene algo. Los parámetros de la cadena que leímos el 2 de septiembre de 2026 tienen la energía dinámica activada (getAllowDynamicEnergy es 1), y el nombre encaja con una penalización que crece con el destinatario más caro. No hemos comprobado la aritmética del nodo contra esos parámetros, así que qué cobra la penalización sigue sin medirse aquí.

Comprobar un alquiler con su recibo

Después de alquilar energía, dos campos del recibo de la transferencia dicen si el alquiler cumplió su función: energy_fee está ausente, y energy_usage, más cualquier origin_energy_usage, es igual a energy_usage_total. Un energy_fee en una transferencia para la que usted alquiló energía significa que parte de su energía se compró con TRX después de todo. La delegación era menor que la llamada, no había llegado cuando se ejecutó la llamada, ya se había retirado, o la gastó antes otra transferencia de la misma cartera (cómo empieza y termina una delegación). La propia cuenta se puede leer antes de enviar (cómo alquilar energía con seguridad).

Entréguenos la transferencia firmada en el mode B y el recibo pasa a ser nuestro para leerlo, ítem por ítem: todos los motivos con los que puede cerrarse un ítem, en la referencia de la API →