Blog · 9 de novembro de 2026

Testar pagamentos em USDT antes da mainnet: o que a Nile muda e o que uma sandbox simula

Uma integração de pagamentos deve encontrar a sua primeira falha em algum lugar mais barato que a mainnet, e na TRON há dois lugares assim. A Nile é uma testnet pública: uma cadeia real em que transações são assinadas e entram em blocos, rodando com parâmetros próprios. Uma sandbox como a nossa replica a API sobre uma cadeia simulada, o que abre mão da rede real e ganha os resultados que uma rede real não produz sob pedido. Lemos os parâmetros de cadeia da mainnet e da Nile em 3 de setembro de 2026 e assinamos transações na Nile no dia seguinte.

O que a Nile tem em comum com a mainnet

A Nile responde à mesma chamada getchainparameters que a mainnet, e os parâmetros que precificam uma transferência voltaram idênticos. A energia custa 100 sun por unidade nas duas redes, então uma transferência que fica sem energia queima TRX à mesma taxa em cada uma. O bandwidth de graça, a taxa de criação de conta, a taxa de memo e os três parâmetros de energia dinâmica também coincidem.

O que a Nile muda

Para quem lida com energia, a primeira diferença é o desfazer do stake: leva um dia na Nile contra catorze na mainnet, então um teste que congela TRX e depois o retira termina treze dias antes do que a mesma sequência terminaria em produção. A maior trava que uma delegação pode carregar é de 144,000 blocos na Nile, cinco dias a três segundos por bloco, contra 864,000 blocos, trinta dias, na mainnet. Uma trava de mais de cinco dias não pode ser ensaiada na Nile de jeito nenhum; o que uma trava recusa é igual nas duas redes.

Oito dos parâmetros que a mainnet devolveu têm um valor diferente na Nile. Além desses dois, são o intervalo de manutenção, o teto de CPU da tabela, e quatro que regem os produtores de bloco, as propostas e os recursos de contrato. Não rastreamos nenhum desses seis até um fluxo de pagamento.

O stake também rende uma quantidade diferente de energia, porque cada rede divide o mesmo limite de energia entre o seu próprio stake total, e o da Nile é bem menor. Nas duas execuções que fizemos na Nile em 4 de setembro, o stake que delegamos apareceu na conta que recebeu como 7,376 unidades de energia. O mesmo stake na mainnet, com o total lido um dia antes, dá 958 unidades, então a Nile distribui quase oito vezes mais. Um stake dimensionado contra a Nile deixaria uma carteira da mainnet sem o suficiente.

O USDT de teste é outro contrato

O código de pagamentos carrega o endereço do contrato do USDT que chama. Em 27 de outubro de 2026 perguntamos a um nó da Nile pelo contrato no endereço do USDT da mainnet, TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, e a resposta foi um objeto vazio, {}: nenhum contrato nesse endereço na testnet. Os tokens de teste da Nile vêm de outro contrato em outro endereço, então o endereço do contrato pertence à configuração, ao lado da URL do nó, e uma build que o fixa no código vai chamar o endereço errado em uma das duas redes.

Não medimos quanto custa em energia uma transferência de um token de teste da Nile. A Nile cobra a mesma taxa por unidade, mas o token é outro contrato, então nada na Nile confirma os valores da mainnet de cerca de 65,000 unidades para um endereço que já tem USDT e cerca de 131,000 unidades para um endereço sem USDT. O TRX de teste vem de faucets, e eles o racionam: o que usamos em setembro permitia uma requisição por carteira e por IP a cada 24 horas.

Uma transação assinada também fica na rede para a qual foi montada. Toda transação TRON carrega uma referência a um bloco recente da sua própria cadeia, e a nossa API confere essa referência contra a mainnet antes de comprar qualquer energia. Uma transação do mode B montada contra a Nile é recusada com um 400 e details.reason em ref_block_unknown. Quando a cadeia não responde à nossa conferência, o pedido é aceito sem conferir e a recusa do nó depois da entrega é cobrada, então monte toda transação contra o bloco atual da mainnet antes de enviá-la.

O que a sandbox simula

A nossa sandbox responde em https://sandbox.nrg.market/v1 e roda o mesmo código da produção sobre dinheiro de teste, uma cadeia simulada e fornecedores de energia simulados. As chaves de lá começam com nrg_test_ e vêm do painel da sandbox, onde o cadastro é por conta própria. Os dois ambientes não compartilham nada: bancos de dados, saldos, webhooks e segredos separados. Quando a integração funciona lá, você troca a URL base e a chave; o fluxo da API é o mesmo nos dois.

O dinheiro de teste chega sem faucet. Confirmar o e-mail credita um saldo inicial, e POST /v1/sandbox/deposit credita mais pelo mesmo caminho de um depósito real: uma linha deposit no extrato com um txid que começa com sandbox-, e um webhook deposit.credited de verdade. Na produção esse caminho não existe e responde 404.

Uma testnet não produz um resultado específico sob pedido. A sandbox liga alguns endereços a um comportamento fixo, do jeito que funcionam os números de cartão de teste: endereços TRON válidos sem chave privada por trás. O destinatário decide o tipo de energia e o que acontece depois de ready; o remetente decide como vão a compra e a delegação.

Os dois lados se combinam, então um lote que mistura o remetente que falha com remetentes comuns termina em partially_completed sem que se peça nada de especial (o que esse status significa para a fatura). Os remetentes de cenário são compartilhados por todo cliente do ambiente, então, quando o tempo é o que está em teste, use um endereço de remetente novo seu: ele recebe os 2 a 8 segundos comuns, e as delegações dele são privadas dele.

Os preços no ambiente são os ao vivo. A tarifa da sandbox segue a da produção com cerca de dois minutos de atraso, três no pior caso, então uma estimativa ensaiada ali devolve o preço que a produção cotou dois ou três minutos antes. O mode B não precisa de chave real: a cadeia simulada não confere assinaturas, então uma transação assinada por qualquer chave descartável é lida como a produção a lê e passa por broadcasting, broadcasted e confirmed, com a transmissão confirmando em cerca de três segundos.

O que só a mainnet mostra

A sandbox não pode provar a parte que a cadeia prova: a energia nunca chega de fato a lugar nenhum nela, e uma delegação confirmada ali é um fato sobre o nosso simulador. A Nile também não resolve isso para o nosso serviço, porque não vendemos energia em testnet nenhuma. Você descobre em produção se energia real chega a uma carteira real, e se a transferência então passa sem queimar TRX.

Alguns ramos não podem ser produzidos em nenhum dos dois ambientes por requisição alguma: 503 capacity_unavailable, e os erros de item broadcast_failed, transaction_reverted e broadcast_window_missed. Cada um depende da oferta de energia, da cadeia, ou de o serviço ser pausado por nós. Escreva esse tratamento a partir do contrato e dos corpos de webhook, e revise-o como código que nunca rodou.

Boa parte da produção não custa nada para exercitar. POST /v1/estimate aceita até 500 destinatários e devolve os mesmos kind, energy_units e warnings que um pedido calcularia, e POST /v1/webhooks/{webhook_id}/test manda ao seu receptor uma entrega assinada de verdade. POST /v1/orders custa TRX real em todo modo, o que faz de um primeiro pedido ao vivo de uma transferência o último ensaio e o único que mostra a energia chegando.

Todo endereço de cenário deste texto responde no ambiente, sobre dinheiro de teste e a sua própria chave nrg_test_: abra o painel da sandbox e emita uma →