Blog · 9 de noviembre de 2026

Probar pagos en USDT antes de mainnet: qué cambia Nile y qué simula un entorno de pruebas

Una integración de pagos debería encontrarse con su primer fallo en un sitio más barato que mainnet, y en TRON hay dos así. Nile es una red de pruebas pública: una cadena real donde se firman transacciones y entran en bloques, con parámetros propios. Un entorno de pruebas como el nuestro copia la API sobre una cadena simulada, lo que renuncia a la red real y gana los resultados que una red real no produce a petición. Leímos los parámetros de la cadena de mainnet y de Nile el 3 de septiembre de 2026 y firmamos transacciones en Nile al día siguiente.

Lo que Nile comparte con mainnet

Nile responde a la misma llamada getchainparameters que mainnet, y los parámetros que ponen precio a una transferencia salieron idénticos. La energía cuesta 100 sun por unidad en las dos redes, así que una transferencia que se queda corta de energía quema TRX a la misma tarifa en cada una. El ancho de banda gratuito, la comisión por crear una cuenta, la comisión del memo y los tres parámetros de energía dinámica coinciden también.

Lo que cambia Nile

Para quien maneja energía, la primera diferencia es sacar el TRX del staking: en Nile lleva un día frente a catorce en mainnet, así que una prueba que bloquea TRX y luego lo retira termina trece días antes de lo que lo haría la misma secuencia en producción. El bloqueo más largo que puede llevar una delegación es de 144,000 bloques en Nile, cinco días a tres segundos por bloque, frente a 864,000 bloques, treinta días, en mainnet. Un bloqueo de más de cinco días no se puede ensayar en Nile en absoluto; lo que rechaza un bloqueo es lo mismo en las dos redes.

Ocho de los parámetros que devolvió mainnet llevan un valor distinto en Nile. Además de esos dos, son el intervalo de mantenimiento, el techo de CPU de la tabla, y cuatro que rigen los productores de bloques, las propuestas y las funciones de los contratos. No hemos rastreado ninguno de esos seis hasta un flujo de pagos.

El staking también da una cantidad distinta de energía, porque cada red reparte el mismo límite de energía entre su propio staking total, y el de Nile es mucho menor. En las dos ejecuciones que hicimos en Nile el 4 de septiembre, el staking que delegamos apareció en la cuenta receptora como 7,376 unidades de energía. El mismo staking en mainnet, con el total leído un día antes, da 958 unidades, así que Nile reparte casi ocho veces más. Un staking dimensionado contra Nile dejaría corta a una cartera de mainnet.

El USDT de prueba es otro contrato

El código de pagos lleva la dirección del contrato de USDT al que llama. El 27 de octubre de 2026 le pedimos a un nodo de Nile el contrato que hay en la dirección de USDT de mainnet, TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, y la respuesta fue un objeto vacío, {}: ningún contrato en esa dirección de la red de pruebas. Los tokens de prueba de Nile vienen de otro contrato en otra dirección, así que la dirección del contrato pertenece a la configuración, junto a la URL del nodo, y una versión que la escriba fija en el código llamará a la dirección equivocada en una de las dos redes.

No hemos medido cuánta energía cuesta una transferencia de un token de prueba de Nile. Nile cobra la misma comisión por unidad, pero el token es otro contrato, así que nada en Nile confirma las cifras de mainnet de unas 65,000 unidades hacia una dirección que ya tiene USDT y unas 131,000 unidades hacia una dirección sin USDT. El TRX de prueba sale de faucets, que lo racionan: el que usamos en septiembre permitía una petición por cartera y por IP cada 24 horas.

Una transacción firmada también se queda en la red para la que se construyó. Toda transacción de TRON lleva una referencia a un bloque reciente de su propia cadena, y nuestra API comprueba esa referencia contra mainnet antes de comprar ninguna energía. Una transacción del mode B construida contra Nile se rechaza con un 400 y details.reason en ref_block_unknown. Cuando la cadena no responde a nuestra comprobación, el pedido se acepta sin comprobar y el rechazo del nodo tras la entrega se cobra, así que construya cada transacción contra el bloque actual de mainnet antes de enviarla.

Lo que simula el entorno de pruebas

Nuestro entorno de pruebas responde en https://sandbox.nrg.market/v1 y ejecuta el mismo código que producción sobre dinero de prueba, una cadena simulada y vendedores de energía simulados. Las claves allí empiezan por nrg_test_ y salen del panel del entorno de pruebas, donde el registro es de autoservicio. Los dos entornos no comparten nada: bases de datos, saldos, webhooks y secretos separados. Cuando la integración funciona allí, usted cambia la URL base y la clave; el flujo de la API es el mismo en los dos.

El dinero de prueba llega sin faucet. Confirmar el correo acredita un saldo inicial, y POST /v1/sandbox/deposit acredita más por el mismo camino que sigue un depósito real: una fila deposit en los movimientos con un txid que empieza por sandbox-, y un webhook deposit.credited real. En producción ese camino no existe y responde 404.

Una red de pruebas no producirá un resultado concreto a petición. El entorno de pruebas asocia unas pocas direcciones a un comportamiento fijo, como funcionan los números de tarjeta de prueba: direcciones TRON válidas sin ninguna clave privada detrás. El destinatario decide el tipo de energía y lo que pasa después de ready; el remitente decide cómo van la compra y la delegación.

Los dos lados se combinan, de modo que un lote que mezcla el remitente que falla con otros normales termina en partially_completed sin pedir nada especial (qué significa ese estado para la factura). Los remitentes de escenario los comparten todos los clientes del entorno, así que cuando lo que se prueba es el tiempo, use una dirección de remitente nueva y propia: recibe los 2 a 8 segundos normales, y sus delegaciones son privadas.

Los precios del entorno son los reales. La tarifa del entorno de pruebas sigue a la de producción con un retraso de unos dos minutos, tres como mucho, así que una estimación ensayada allí devuelve el precio que producción cotizaba dos o tres minutos antes. El mode B no necesita una clave real: la cadena simulada no comprueba las firmas, así que una transacción firmada con cualquier clave desechable se analiza como la analiza producción y pasa por broadcasting, broadcasted y confirmed, con la emisión confirmándose en unos tres segundos.

Lo que solo muestra mainnet

El entorno de pruebas no puede demostrar la parte que hace la cadena: allí la energía nunca llega realmente a ninguna parte, y una delegación confirmada allí es un hecho sobre nuestro simulador. Nile tampoco puede zanjarlo para nuestro servicio, porque no vendemos energía en ninguna red de pruebas. En producción se aprende si la energía real llega a una cartera real, y si la transferencia sale entonces sin quemar TRX.

Algunas ramas no se pueden producir en ninguno de los dos entornos con ninguna petición: 503 capacity_unavailable, y los errores de ítem broadcast_failed, transaction_reverted y broadcast_window_missed. Cada una depende de la oferta de energía, de la cadena, o de que nosotros pausemos el servicio. Escriba ese manejo a partir del contrato y de los cuerpos de los webhooks, y revíselo como código que nunca se ha ejecutado.

Una buena parte de producción no cuesta nada ejercitarla. POST /v1/estimate admite hasta 500 destinatarios y devuelve los mismos kind, energy_units y warnings que calcularía un pedido, y POST /v1/webhooks/{webhook_id}/test envía a su receptor una entrega firmada real. POST /v1/orders cuesta TRX real en todos los modos, lo que hace de un primer pedido real de una transferencia el último ensayo y el único que muestra la energía llegando.

Todas las direcciones de escenario de esta entrada responden en el entorno, con dinero de prueba y su propia clave nrg_test_: abra el panel del entorno de pruebas y emita una →