Blog · 9 de noviembre de 2026

Energía para un approve TRC-20 y otras llamadas a contratos TRON

La energía es lo que TRON cobra por ejecutar código de contrato, y una transferencia USDT es una llamada a un contrato entre muchas. Un approve también la gasta, y también el transferFrom que más tarde mueve los fondos aprobados. El 28 de octubre de 2026 simulamos ambos en el contrato de USDT: un approve tomó 99,764 unidades de energía cuando la autorización estaba en cero y 33,764 cuando ya había una fijada, y un transferFrom tomó 65,123 contra una autorización ilimitada y 89,325 contra una limitada. Las llamadas a otros contratos tienen cifras propias, y la energía alquilada paga cualquiera de ellas igual que paga una transferencia.

Una delegación sube el límite de energía de la cuenta a la que llega, y toda llamada a un contrato que esa cuenta firma gasta de ese límite antes de que se queme ningún TRX (qué es la energía TRON). Nada en una delegación nombra el contrato ni la función a los que está destinada. Una llamada distinta de una transferencia se diferencia en cuánto gasta, que depende del contrato y la función a los que llama y del estado que encuentra allí, y en algunos contratos en cuánto de eso paga quien firma.

Lo que gastaron las llamadas de USDT en una simulación

Una simulación es una llamada constante: un nodo ejecuta la llamada contra su propia copia de la cadena, informa de la energía que usó y descarta el resultado. No se firma ni se emite nada, y no cuesta nada. Hicimos las nuestras a través de un nodo completo público entre las 08:29 y las 08:34 UTC del 28 de octubre de 2026. Los propietarios eran cuentas reales, escogidas de los bloques más recientes justo después de que cada una hubiera aprobado a un gastador, y las extracciones se simularon desde esos gastadores. El approve desde cero fue a una dirección que generamos para nuestra medición de septiembre, a la que ningún propietario había aprobado. Leímos cada autorización y cada saldo momentos antes de la llamada. Todas las cifras de abajo salieron de una llamada que habría tenido éxito. La transferencia y las dos extracciones movieron una unidad, una millonésima de USDT, a la misma dirección, que tiene USDT.

Los dos tipos de approve vinieron del mismo propietario por la misma cantidad nueva. Un gastador no tenía aún ninguna autorización y el otro tenía una vigente, y la llamada del primero costó 66,000 unidades más. Es la misma diferencia que entre una transferencia a una dirección sin USDT y una a una dirección que lo tiene, que medimos en septiembre en 130,285 y 64,285 (las dos cifras de transferencia). En los dos pares la llamada más barata sobrescribió un número que ya estaba allí y la más cara escribió sobre un cero.

A menos que el desplegador del contrato haya aceptado asumir parte, como ha hecho el de JustLend DAO (más abajo), quien firma una llamada paga su energía. En un flujo en el que un cliente aprueba el contrato de un comercio y el comercio extrae después los fondos, el cliente paga cada approve, y quien firma la llamada de extracción la paga: el transferFrom de la tabla, más el propio código del contrato del comercio cuando la extracción se ejecuta dentro de él. Las dos extracciones que pudimos simular diferían en su autorización. Con una ilimitada, el transferFrom del gastador salió 838 unidades por encima de una transferencia simple de la misma cantidad a la misma dirección, y con una limitada costó 24,202 por encima de eso. Es un par de cada tipo, y los pares también tenían propietarios y gastadores distintos.

Algo más de tres cuartas partes de cada cifra está en un campo que el nodo llama energy_penalty, y la proporción es la misma en las cinco llamadas, tanto en un approve como en un transfer.

Un contrato de préstamos: las dos llamadas de JustLend DAO

Alquilar energía en JustLend DAO es en sí un par de llamadas a un contrato, una que abre la posición y otra que la devuelve (lo que cuesta ese alquiler). Emparejamos 30 alquileres con sus devoluciones a partir del registro público del contrato durante las 24 horas que terminaron en la noche del 2 de septiembre de 2026, y leímos lo que usó cada llamada, en total, de su recibo.

La tabla da totales porque quien firma no siempre paga todo. El contrato está configurado para cobrar a quienes lo llaman una décima parte de la energía y cubrir el resto con la propia energía de su desplegador, hasta 90,000 unidades por llamada, mientras esa energía dure. Nuestro propio alquiler de esa noche usó 84,290 unidades y quien lo firmó pagó 8,429 de ellas. Menos de tres horas antes, el alquiler de un tercero pagó él solo las 52,672, porque la energía del desplegador se había agotado, y su devolución doce segundos después pagó 62,200 de 74,135. Una simulación informa de lo que usa una llamada, mientras que quien firma paga desde la décima parte que el contrato cobra a quienes lo llaman hasta todo, según la energía del desplegador en ese segundo, así que dimensione la llamada para todo.

Dimensionar una llamada que nadie ha medido por usted

Ninguna tabla cubre todos los contratos, y las cifras de arriba se mueven con el estado que encuentra una llamada. El número en el que confiar es una simulación de esa llamada exacta, desde la cuenta que la firmará, hecha poco antes de enviarla. Cualquier nodo completo la responde:

POST /wallet/triggerconstantcontract
{"owner_address": "T… (la cuenta que firmará)",
 "contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
 "function_selector": "approve(address,uint256)",
 "parameter": "… (los argumentos, codificados en ABI)",
 "visible": true}

Compruebe la respuesta antes de tomar el número, porque una llamada que revertiría también informa de energía. Dos de nuestros primeros intentos de transferFrom fueron a pares que ya no podían pagar: una autorización se había consumido en los segundos anteriores a preguntar, y un propietario no tenía nada de USDT. Volvieron con 5,947 y 4,845 unidades por un trabajo que termina en fallo. Su result.result seguía diciendo true. Lo que las distinguía era FAILED en transaction.ret, donde una llamada que tiene éxito deja una entrada vacía.

Deje margen por encima de la cifra, ya que una autorización puede gastarse y un destinatario vaciarse entre la simulación y el bloque. Nosotros también dejamos margen: nuestras cifras estándar de transferencia, 65,000 y 131,000, están 715 unidades por encima de lo que miden las dos transferencias, y cuando una transferencia USDT firmada que se nos entrega en el mode B se simula por encima de lo que mide una transferencia a una dirección vacía, compramos la medición más un margen y juzgamos la entrega frente a la propia medición.

Fije el fee_limit de la transacción para que cubra la cifra entera al precio de la red de 100 sun por unidad, incluso cuando la energía está alquilada. Un nodo limita una llamada a su fee_limit dividido por el precio de la energía y cuenta la energía delegada dentro de ese tope, así que un límite bajo detiene una llamada que tiene en la cuenta todas las unidades que necesita. El ancho de banda es un contador aparte: toda llamada también paga sus bytes, y la energía no los cubre (energía y ancho de banda).

Un swap a través de un contrato de intercambio es la misma aritmética con un contrato más: un approve que deja que el intercambio mueva los tokens, y luego la llamada al intercambio. No simulamos ninguno.

Alquilar energía para una llamada por unidades

Nuestros mode A y mode B están construidos en torno a una transferencia USDT, y el mode B acepta un transfer de USDT firmado y nada más. En el mode A, cuando el destinatario de una transferencia resulta ser un contrato, hacemos la simulación por usted: el ítem vuelve como kind: custom, sus energy_units son la medición, y un aviso contract_recipient dice por qué (los ítems custom, antes de firmar nada).

Para cualquier otra llamada está el mode C. Usted nombra la cartera y el volumen, y nosotros delegamos la energía a esa cartera sin ningún destinatario de por medio (el mode C en el recorrido por la API). El volumen puede ser energy_units, cualquier número entero de 65,000 a 50,000,000 por cartera, y el ítem vuelve como kind: bulk. El mode C no admite custom, porque no hay destinatario que podamos simular, así que la medición es suya. La cartera tiene que estar activada en la cadena, y un pedido para una que no lo esté vuelve rechazado con inactive_wallet.

El alquiler de cinco minutos admite volúmenes de hasta 131,000. Todo lo mayor tiene que ir al alquiler de una hora, y lo rechazamos en el más corto con bulk_needs_longer_lease: un volumen grande se arma con varias fuentes y llega en piezas con segundos de diferencia. Un approve desde cero cabe por debajo de esa línea por sí solo, con margen. Si se le añade una transferencia a una dirección con USDT, el par pasa la línea, así que va a la hora. El volumen más pequeño que vendemos cubre un approve con una autorización vigente y deja casi otro tanto de sobra.

POST /v1/estimate con los mismos energy_units responde cuánto se cobraría ese volumen en este momento y, en coverage, si el mercado lo tiene ahora. Una vez entregado, el ítem se queda en ready hasta send_before y luego pasa a expired, que aquí significa que el alquiler se agotó: el final normal. El cobro es por la entrega, y la energía que la cartera deja sin gastar vuelve con la delegación.

Lo que no medimos: un swap, una llamada a cualquier contrato distinto de USDT y JustLend DAO, un transferFrom a una dirección sin USDT, y si estas cifras se mantienen durante semanas. Cada cifra de USDT de aquí es una llamada constante respondida por un nodo; no enviamos ninguna transacción, así que ninguna se ha contrastado con un recibo.

Simule la llamada y luego ponga ese volumen en la cartera que la firmará: el mode C y energy_units en POST /v1/orders →