Cómo comprar energía de TRON por programa, sin confirmación manual
La energía en TRON se adquiere igual que cualquier otra operación: tu backend construye una transacción sin firmar mediante la API (FreezeBalanceV2 para el staking, DelegateResource para ceder el recurso a una dirección hot), la firma con una clave privada local y la envía a broadcasttransaction. La confirmación manual solo es necesaria cuando la clave está en la wallet del usuario; si tu código guarda la clave, no hay nada que confirmar. Una alternativa al staking es alquilar energía en el Energy Rental Market de JustLend DAO sin congelar ningún TRX.
Respuesta corta: la energía de TRON se compra por programa con el mismo flujo construir → firmar → difundir que una transferencia ordinaria. Tu servicio construye una transacción sin firmar con un método HTTP (wallet/freezebalancev2: staking para energía; DelegateResource: asignar el recurso a una dirección concreta), la firma localmente con la clave privada del pool y la envía a wallet/broadcasttransaction. La confirmación manual solo aparece donde la clave está en la wallet del usuario (TronLink, servidores MCP del ecosistema). Si tu código guarda la clave, no hay nada que confirmar, y la adquisición automatizada pasa a ser un paso más del pipeline de pagos.
De dónde sale la energía
A diferencia de Bandwidth, Energy no tiene cuota diaria gratuita (Bandwidth sí: 600 unidades por día para una cuenta externa). Para ejecutar una transferencia TRC-20, una cuenta debe tener energía en staking o delegada, o recargarla quemando TRX al precio actual de getEnergyFee; la documentación indica 100 sun (0,0001 TRX) por unidad. Es un parámetro de la cadena que cambia por votación de los SR, así que en producción debe leerse de la red en lugar de fijarse en el código.
Hay dos formas habituales de obtener energía:
- hacer staking de TRX (Stake 2.0): congelas TRX y recibes una parte del límite total de la red según la fórmula
TRX en staking / total de TRX en staking para Energy de la red × 180,000,000,000; - alquilar en el Energy Rental Market de JustLend DAO: acceso a energía sin congelar tus propios activos.
La primitiva sobre la que se construyen los pools y los servicios de alquiler es DelegateResourceContract: el titular del stake delega energía a otra cuenta, y el destinatario la gasta directamente, sin hacer staking de nada por su cuenta. Así es exactamente como los exchanges y los operadores de DApps cubren los costes de los usuarios desde un único pool de staking.
La arquitectura «pool + delegación»
- Una cuenta pool dedicada con TRX en staking para ENERGY (el mínimo para una sola operación FreezeBalanceV2 es 1 TRX, es decir, 1 000 000 sun; cualquier cantidad menor se rechaza con
ContractValidateException). - Antes de cada pago, consultar
wallet/getaccountresourcepara la dirección hot: cuánta energía hay disponible ahora mismo. - Si no hay suficiente,
DelegateResourcedesde el pool por la cantidad necesaria, firmar, difundir. - Tras un lote de pagos,
UnDelegateResource, devolviendo el recurso al pool.
El campo resource acepta las cadenas ENERGY o BANDWIDTH. La delegación es reversible, pero admite un bloqueo opcional: hasta que el bloqueo expire, el recurso no se puede recuperar; en el backend hay que tratarlo como «el pool es temporalmente más pequeño», de lo contrario el planificador seguirá chocando con saldos que no puede retirar.
Si tu lógica de asignación de recursos ya está on-chain, lo mismo puede hacerse sin servidor: Stake 2.0 está disponible desde Solidity: freezebalancev2(1000000, 1), receiver.delegateResource(1000000, 0), receiver.unDelegateResource(...), además del método de consulta target.delegatableResource(1) para monitorizar la cantidad disponible para delegar. Los detalles están en la sección Bandwidth and Energy.
Si planeas gestionar la adquisición mediante un agente de IA, ten presente una limitación: las herramientas MCP de TronScan son actualmente de solo lectura, TronGrid puede construir transacciones sin firmar y difundir las ya firmadas, pero no firma ni almacena claves privadas, y los demás servidores del ecosistema requieren autorización explícita del usuario. Un escenario totalmente «manos libres» mediante MCP no está soportado de serie: la firma tiene que quedarse dentro de tu propio código.
Cuánto comprar: cálculo en tiempo de ejecución
No fijes en el código la cantidad de energía por transferencia.
| Paso | Método | Qué te da |
|---|---|---|
| Estimación | /wallet/triggerconstantcontract | ejecución local sin transacción y sin gasto de recursos |
| Refinamiento | estimateenergy | energy_used; más preciso para contratos concretos, requiere tener habilitados vm.estimateEnergy y vm.supportConstant en el nodo |
| Precio | getEnergyFee (parámetro #11) | sun por unidad de Energy |
| Techo | getMaxFeeLimit (parámetro #47) | actualmente 15 000 TRX |
La cuenta es sencilla: fee_limit (sun) = energy_required × getEnergyFee. La estimación refleja el estado del nodo en el momento de la consulta y no garantiza que la transacción posterior on-chain tenga éxito.
El principal riesgo de coste es el modelo de energía dinámica (DEM). El parámetro #75 getDynamicEnergyMaxFactor devuelve 34 000 en mainnet, es decir, max_factor = 3,4, mientras que el multiplicador combinado de energía puede llegar a 4,4. El factor cambia cuando se reinicia el ciclo de mantenimiento, así que cualquier caché de estimaciones que sobreviva al ciclo debe invalidarse. La estrategia de «calcular siempre con max_factor» es segura para que las transacciones pasen, pero presupuesta de más. Hay un desglose en FeeLimit & Energy.
Una transferencia de USDT no activa al destinatario ni cuesta Energy adicional por ello: los 25 000 de Energy adicionales solo se aplican cuando un contrato inteligente envía TRX o TRC-10 a una dirección no activada. Lo que sí cambia el gasto es el saldo de USDT del destinatario: unos 65 000 de Energy si tiene USDT y unos 131 000 si su saldo es cero.
Qué se rompe bajo carga
- El TTL de la transacción es de 60 segundos tras construirla. Puede ocurrir que una difusión sea «exitosa» pero la transacción nunca llegue a un nodo SR; reintentar solo tiene sentido cuando expira el periodo de validez.
- OUT_OF_TIME: el límite global de ejecución de una transacción de contrato es de 80 ms (modificable por votación de los SR). Si se supera, se cobra todo el fee_limit.
- La energía no se reembolsa, ni del stake ni de la quema, aunque la transacción se revierta o falle en otra comprobación.
- La recuperación tarda 24 horas, de forma lineal. Si vuelves a gastar o revocas una delegación durante ese periodo, el sistema fusiona proporcionalmente el progreso de recuperación con el nuevo ciclo: «revocado» no significa «disponible de inmediato».
- Descongelar tarda 14 días:
UnfreezeBalanceV2Contract, esperar y luegoWithdrawExpireUnfreezeContract. No es una herramienta de reequilibrio rápido. - Stake 1.0 en código copiado y pegado: los ejemplos antiguos contienen
frozen_duration: 3yFreezeBalanceContract; si los copias, construirás una transacción para el mecanismo antiguo. - Clave de API: la cabecera
TRON-PRO-API-KEYsolo hace falta para mainnet; Shasta y Nile funcionan sin ella, y Stake 2.0 se comporta allí igual que en mainnet, lo que las convierte en el lugar adecuado para depurar la adquisición automatizada.
La conclusión: la confirmación manual desaparece no por alguna «API de alquiler» especial, sino porque la firma se queda de tu lado. Todo lo demás es disciplina: estimar la energía en tiempo de ejecución, leer los parámetros de la cadena desde la red (wallet/getchainparameters) y recordar que el staking, la delegación y la recuperación de recursos funcionan cada uno con sus propios temporizadores.
Este material es solo informativo y no constituye asesoramiento de inversión.