---
url: https://doc.netts.io/changelog.md
---
# Changelog
Welcome to the **Netts Platform Changelog** — a comprehensive technical journal documenting all updates, improvements, and new features implemented across the Netts ecosystem.
This section provides detailed information about:
* **API enhancements** and new endpoints
* **Performance optimizations** and infrastructure improvements
* **Bug fixes** and stability updates
* **New features** and functionality additions
* **Breaking changes** and migration guides
All entries are documented in a professional technical format with implementation details, affected components, and version information.
***
## Latest Updates
### January 21, 2026 - Maximum Energy Order Limit Reduced
**Type:** ⚠️ Breaking Change
**Summary:**
Reduced maximum energy amount per order from 5,000,000 to 3,000,000 units.
**Details:**
* Maximum energy per single order: **5,000,000 → 3,000,000**
* Minimum energy remains unchanged: **61,000**
* Users requiring more than 3M energy should split into multiple orders
**Affected Components:**
* API: `/apiv2/order1h` endpoint validation
* Documentation: [Order 1h](/api/v2/endpoints/order1h)
***
### December 3, 2025 - New Order Check Endpoint
**Type:** Feature
**Summary:**
Added new API endpoint `/apiv2/order_check` for retrieving detailed information about 1-hour energy orders.
**Details:**
* Get order details including cost, energy amount, target address, and transaction hashes
* View activation information if address was activated
* Parent users can see subuser markup breakdown (energy\_markup, activation\_markup, net\_cost)
* Supports ownership validation and parent-subuser access control
**Affected Components:**
* API: New `/apiv2/order_check` endpoint
* Documentation: [Order Check](/api/v2/endpoints/order-check)
***
### December 3, 2025 - Improved Idempotency HTTP Status Codes & Performance Optimization
**Type:** Enhancement
**Summary:**
Updated HTTP status codes for idempotency responses to provide clearer feedback for duplicate requests. Also optimized internal pool processing for sub-second response times.
**Details:**
**HTTP Status Code Changes:**
* **208 Already Reported** - Now returned when a duplicate request is received for an already processed order (previously returned 200)
* **409 Conflict** - Now returned when a duplicate request arrives while the original is still being processed (previously returned 200)
* Response body remains unchanged - only the HTTP status code is different
**Performance Optimization:**
* Internal pool order processing now completes in under 1 second (including address activation)
* Typical response time: 500-700ms for internal pool orders
* External provider fallback maintains existing performance characteristics
**Why This Matters:**
* Clearer distinction between successful first requests (200) and cached/duplicate responses (208/409)
* Clients can now easily detect duplicate responses by checking HTTP status code
* Prevents confusion when receiving 200 OK for requests that were already processed
* Improved processing speed for better user experience
**Affected Components:**
* API: `/apiv2/order1h` endpoint
* Idempotency handling module
* Internal pool order processing
***
### November 19, 2025 - Enhanced Balance Calculation in API and Website
**Type:** ⚡ Enhancement
**Summary:**
Updated balance calculation logic in API endpoint `/apiv2/userinfo` and website Wallet section to show Total Balance TRX that includes all pending transactions.
**Details:**
**API Changes (`/apiv2/userinfo`):**
* The `balance` field in API response now returns **Total Balance TRX** instead of just deposit balance
* Total Balance TRX includes:
* Deposit wallet balance
* Pending payouts (Robot & Sub-users)
* Minus pending withdrawals
**Website Changes (Wallet Section):**
* Updated balance display to show Total Balance TRX from API
* Simplified frontend logic - removed duplicate calculations
* Added informative tooltip explaining balance components
**Important:**
* Robot & Sub-users payout TRX are credited to deposit address **2 times per day**
* Before crediting, Robot & Sub-users payout TRX **cannot be used** for energy purchases
* To withdraw Robot & Sub-users payout TRX/USDT, activate the checkbox in withdrawal form
**Affected Components:**
* API: `/apiv2/userinfo` endpoint
* Website: Wallet (Deposit & Withdraw) page
* Backend: Balance calculation logic
***
### November 19, 2025 - Changelog Initialization
**Type:** 📚 Documentation
**Summary:**
Initial creation of the Netts Platform Changelog. This marks the beginning of our public technical journal where we will document all significant changes, improvements, and new features.
**Details:**
* Established changelog structure and documentation format
* Created dedicated section in the documentation site
* Implemented versioned update tracking system
**Purpose:**
To provide transparency and clear communication about platform evolution to our users, developers, and integration partners.
***
## Archive
Previous updates will be listed here as they occur, organized by date in reverse chronological order.
***
## Update Categories
Updates in this changelog are categorized as:
* **🚀 Feature** - New functionality or capabilities
* **⚡ Enhancement** - Improvements to existing features
* **🐛 Fix** - Bug fixes and error corrections
* **🔧 Maintenance** - Infrastructure and performance updates
* **📚 Documentation** - Documentation updates and additions
* **⚠️ Breaking Change** - Changes that may require code updates
***
*For questions about specific updates or integration support, please contact our technical team or refer to the API documentation.*
---
---
url: https://doc.netts.io/tron/what-is-the-tron-network.md
---
# What Is the Tron Network?
**With this publication, we open a series of articles dedicated to the disruptive network of the TRON (TRX) blockchain platform.**\
This article offers an analysis of the **basics of TRON**, the history of its creation and implementation, with special attention to the **technical aspects** of this decentralized platform.
> ***Key Points:***
>
> * **Understanding TRON:** Explore the disruptive nature and decentralized structure of one of the leading blockchain projects.
> * **Historical Evolution:** Learn how TRON transformed from a platform for digital entertainment into a major blockchain ecosystem.
> * **Technical Deep-Dive:** Detailed insights into its architecture, consensus mechanism, and interoperability with platforms like Ethereum and EOS.
> * **Community & Governance:** Discover how democratic voting via Super Representatives maintains network integrity.
***
## Introduction & Terminology
***Let’s define the terms used in this article:***\
TRON is often hailed as the **disruptor** in the blockchain space. Initially envisioned as a **free, globally accessible entertainment system** using peer-to-peer (P2P) technology, TRON eliminated intermediaries between creators and consumers. This innovation **significantly reduced costs** and enhanced efficiency for both developers and users. It also enabled the use of the **native TRX token** for transactions and various applications.
***
## Technical Foundation & Compatibility
### **Native Token Origins**
* The TRX token was originally based on Ethereum’s cryptocurrency token, showcasing a **productive collaboration** between the Chinese project and Ethereum.
* ***Highlight:*** TRON is **fully compatible** with Ethereum smart contracts and the EOS blockchain, ensuring versatile interoperability.
### **Structural Architecture**
* TRON’s functionality is built on a **three-layer architecture**: **core, storage, and application levels**.
* Each level performs critical functions, and the architecture **eliminates the need for traditional miners**.
* ***Emphasis:*** Understand how **TRONIX (TRX)** is “mined” and utilized within the network.
***
## A Little History
### **TRON's Beginnings**
* **Justin Sun’s Vision:** Initially, the goal was to decentralize digital content in entertainment, drawing inspiration from the Ethereum blockchain.
* **Evolution:** Over time, TRON developed into an **independent blockchain platform** with an optimal three-layer structure.
### **Unique Storage and Consensus**
* **Distributed Storage Protocol:** TRON employs a protocol that enhances throughput and scalability.
* **Consensus Mechanism:**
* ***Key Point:*** TRON replaced the energy-intensive PoW (Proof-of-Work) with **Delegated Proof of Stake (DPoS)**, making it more energy-efficient.
* **DPoS Explained:** Network participants with higher deposits have more voting power, ensuring a **democratic and secure** system.
***
## Decentralization and DApps
**Empowering Decentralization:**\
TRON was created to **disrupt traditional digital entertainment** by enabling creators to independently create, store, distribute, and monetize their content. This **eliminates intermediaries** and provides a direct revenue stream to content creators.
**Decentralized Applications (DApps):**
* TRON’s application layer supports DApps with **open source code** and **transparent transactions**.
* These applications facilitate **secure financial transactions** without third-party involvement, expanding the platform's functionality.
***
## Decentralized Finance (DeFi) on TRON
**Revolutionizing Finance:**\
TRON’s decentralized nature is perfectly aligned with the goals of the DeFi sector:
* **Wide Asset Variety:** Supports cryptocurrencies, NFTs, and other application tokens.
* **Growing Adoption:** TRON-powered DeFi projects have amassed over **$8 billion in digital assets**.
* **Stablecoin Dominance:** With a total stablecoin supply reaching **$59.484 billion**, TRON is a key player in the stablecoin ecosystem.
***
## Additional Features & Interoperability
### **Native Cryptocurrency (TRX)**
* TRX is essential for both transactions and **governance** within the network.
* It facilitates **basic transactions** and empowers users to vote for **Super Representatives**, ensuring a **democratic structure**.
### **Versatility of DApps**
* Developers can build a wide range of applications—from media and games to DeFi—without centralized constraints.
* ***Highlight:*** Enjoy high throughput, minimal fees, and fast transaction speeds that set TRON apart from other blockchain platforms.
### **Wallet Diversity**
* TRON supports various wallet types:
* **Hardware wallets** for secure storage
* **Mobile wallets** for on-the-go access
* **Web wallets** for easy online management
* This ensures **easy access** and flexibility for all users interacting with the TRON blockchain.
***
## Ecosystem and Continuous Development
**Comprehensive Ecosystem:**\
The TRON ecosystem is a **dynamic network** of participants, applications, protocols, and services. It creates an environment where developers, users, and investors can thrive together.
**Continuous Innovation:**
* **Recent Milestones:**\
In late August 2024, the SunPump memecoin generator was launched, quickly overtaking competitors. For example, on August 21, SunPump launched **7,531 tokens** in a single day, generating a daily income of **3.65 million TRX**.
* **Strategic Partnerships:**\
TRON collaborates with global brands like **Poloniex, Samsung, BitTorrent, APENFT Marketplace, Swisscom Blockchain, Opera, and ChainGPT**.
* **Scalability:**\
Capable of processing up to **2000 transactions per second**, TRON’s well-structured architecture ensures it can handle growing transaction volumes and expanding application needs.
***
## TRON Super Representatives
**Governance at Its Core:**
* TRON elects **27 Super Representatives every six hours**, who are TRX holders entrusted with maintaining network integrity and security.
* **Democratic Process:**\
TRX holders who freeze their accounts can vote, ensuring **decentralized and democratic governance**.
* **Incentives for Super Representatives:**\
They secure the network through **block rewards and newly minted TRX tokens**, further emphasizing TRON's commitment to decentralization.
***
**Conclusion:**\
This series is designed for both newcomers and experienced users of the TRON platform. Whether you're interested in **digital content creation**, **decentralized finance**, or exploring the **technical intricacies** of blockchain technology, TRON offers a **robust, secure, and innovative environment** for all your needs. Stay tuned for more in-depth articles and updates on this transformative network.
---
---
url: https://doc.netts.io/tron/which-tokens-are-used-in-the-tron-network.md
---
# Which Tokens Are Used in the Tron Network
**Continuing our series on the Tron platform**, this article introduces the concept of a token and highlights the **most popular tokens** in this rapidly growing blockchain ecosystem. We explain the **opportunities offered by the Tron ecosystem** for owners of various token standards, enabling you to confidently navigate exchange offers, participate in network governance, and create or preserve your visual, audiovisual, and intellectual content without intermediaries.
> **Key Points:**
>
> * **Definition of Tokens:** Understand that a token is a crypto asset used within a blockchain ecosystem for economic, managerial, or other purposes.
> * **Token vs. Cryptocurrency:** Unlike cryptocurrencies which operate on their own blockchains, tokens are built on existing blockchains.
> * **Token Types:** Explore utility, security, governance, and non-fungible tokens (NFTs) and their various uses.
> * **Token Standards:** Learn about TRONIX (TRX) and TRC standards and how they empower developers and content creators.
***
## What Is a Token?
A **token** is a digital representation of value that can be used in a blockchain ecosystem. While not synonymous with cryptocurrency, tokens can serve as:
* **Currency equivalents** (digital money or asset analogues, like an ounce of gold),
* **Access keys** to products and services,
* **Tools for governance** within decentralized organizations (DAOs).
Token development can be **funded through fundraising** (e.g., Initial Coin Offerings - ICOs), and tokens typically carry specific utilities.
> **Main Token Types:**
>
> 1. **Utility Tokens:** Provide access to ecosystem products and services.
> 2. **Security Tokens:** Their value is tied to internal tradable assets.
> 3. **Governance Tokens:** Used in DAOs for decision-making.
> 4. **Non-Fungible Tokens (NFTs):** Unique assets usually linked to visual or audio files.
Each token type may be subject to different regulations, and token holders might enjoy **special privileges**, such as governance participation or early product access.
***
## Token Standards on the Tron Network
**Token standards** are sets of technical rules that define token structure and functionality. They ensure a **unified approach** for token creation, transfer, storage, and management.
### **TRONIX (TRX) and TRC Tokens**
* **TRONIX (TRX):**
* The **native cryptocurrency** of the Tron project.
* Plays a key role in facilitating exchanges and interactions on the blockchain.
* **Highlights:** Fast transactions (as quick as 3 seconds), minimal fees, and a consensus mechanism based on **Delegated Proof-of-Stake (DPoS)** (no mining required).
* **TRC Tokens:**\
Tron supports multiple token standards that expand its ecosystem capabilities:
> **TRC-10:**
>
> * **Simpler Standard:** Created at the blockchain level (not via smart contracts).
> * **Cost-Effective:** Lower transaction commissions compared to TRC-20.
> * **Use Cases:** ICOs, blockchain-based products, and decentralized app payments.
> * **Easy Creation:** Any Tron account with a minimum balance can create TRC-10 tokens.
> * **Key Benefits:** Fast, scalable, and lower transaction costs.
> **TRC-20:**
>
> * **Advanced Standard:** Built for deploying smart contracts on the Tron blockchain.
> * **Interoperable:** Compatible with the Tron Virtual Machine (TVM) and similar to Ethereum's ERC-20.
> * **Popular Among Developers:** Favoured for creating digital tokens and dApps due to low fees and high processing speeds.
> **TRC-721:**
>
> * **NFT Standard:** Designed for the issuance of unique non-fungible tokens.
> * **Unique Attributes:** Each token is identifiable with a unique identifier ensuring immutability and uniqueness.
> **TRC-1155:**
>
> * **Versatile Standard:** Supports the creation of both fungible and non-fungible tokens.
> * **Efficient Management:** Enables the exchange of multiple token types within a single smart contract, expanding asset trading possibilities.
***
## Notable TRC-20 Tokens in the Tron Ecosystem
Below are a few **key TRC-20 tokens** that significantly contribute to Tron’s ecosystem:
* **USDT (TRON Tether):**
* A stablecoin pegged 1:1 to the US dollar.
* Offers **stability and low transaction fees**, ideal for traders.
* **BitTorrent (BTT):**
* Powers the BitTorrent ecosystem.
* Incentivizes sharing of bandwidth and resources for improved network performance.
* **WINkLink (WIN):**
* Native token of WINkLink, a decentralized oracle network.
* Ensures **reliable data feeds** for smart contract execution.
* **JUST (JST):**
* Governance token for the JUST decentralized financial system (DeFi).
* Used for interest payments and voting on network decisions.
* **Sun (SUN):**
* A governance token aimed at expanding DeFi on Tron.
* Enables participation in decision-making processes for the SUN.io platform.
***
## Development and Future of Token Standards
Tron continues to **expand its capabilities** by developing new token standards, including:
* **NFT Enhancements (TRC-721):**
* Creating unique digital assets for art, gaming, and intellectual property.
* **Multi-Standard Support (TRC-1155):**
* Streamlining the management and exchange of different token types within a single smart contract.
These standards offer **vast opportunities for developers** building blockchain applications and provide **robust security** and **interoperability** for token transactions.
> **Final Highlights:**
>
> * **TRON’s native TRX** is central to the ecosystem, powering transactions, governance, and staking.
> * **Versatile token standards (TRC-10, TRC-20, TRC-721, TRC-1155)** cater to a wide range of applications.
> * **Low fees, fast processing, and democratic governance** make Tron a leader in blockchain technology.
> * The **ongoing development** of token standards promises even greater opportunities for innovation and expansion.
Stay tuned for further articles as we continue to explore the dynamic world of Tron tokens and the evolving ecosystem that makes Tron one of the most influential blockchain platforms today.
---
---
url: https://doc.netts.io/tron/what-is-trx.md
---
# What Is TRX?
**TRX (Tronix)** is the native cryptocurrency of the TRON blockchain—a platform originally designed for entertainment content but now evolving into a full-fledged decentralized ecosystem. TRON eliminates intermediaries from both financial and entertainment segments, making its blockchain truly **decentralized**.
> ***Key Highlights:***
>
> * **No Mining Required:** Unlike many cryptocurrencies, TRX is not mined using specialized equipment.
> * **Staking Rewards:** Earn passive income by simply staking your TRX tokens.
> * **High Transaction Speed:** With up to 2000 transactions per second, TRON vastly outperforms Ethereum and Bitcoin.
> * **Decentralized Governance:** Participate in platform management through super representatives.
***
## Introduction: The Essence of TRX
TRON’s native token, **TRX (Tronix)**, plays a pivotal role in decentralizing the network. Its **non-mining mechanism** means that users do not require heavy technical capacities or expensive equipment. Instead, TRX leverages staking—where token holders block their funds to help secure the network and receive rewards.
> ***Main Insight:***\
> Staking TRX can yield approximately **3% per annum**, comparable to Ethereum’s staking rewards. Yet, unlike Ethereum, the barrier to entry is much lower since you don’t have to lock up tens of thousands of dollars.
***
## Staking and Passive Income
* **Staking Mechanism:**\
By freezing TRX on your account, you enable the network to use your tokens, and in return, you earn rewards. This is a **passive income** method that doesn’t require expensive mining setups.
* **Comparative Yields:**\
Although other projects may offer higher annual yields, they often come with higher risks or significant inflation. TRX staking provides a **steady and accessible** alternative.
> ***Remember:***\
> **Staking TRX is simple, cost-effective, and a key way to earn rewards while contributing to network security.**
***
## Decentralization and Governance
TRON was born to **disrupt centralized intermediaries**. Initially focused on the entertainment segment, the platform has expanded into decentralized finance (DeFi) and beyond.
* **Decentralized Governance:**\
TRX holders can participate in the network’s governance through the **Delegated Proof-of-Stake (DPoS)** mechanism. Super representatives are elected by users who freeze their tokens, ensuring quick decision-making and community-driven management.
* **Efficient Decision-Making:**\
With 27 super representatives rotating every 6 hours, TRON rewards active participants both materially and morally, promoting a **democratic and fair** governance structure.
> ***Key Point:***\
> **Active participation in governance empowers users and helps steer the future of the TRON ecosystem.**
***
## Cheap and Fast Transactions
TRON is renowned for its **low transaction fees** and **remarkable speed**:
* **Transaction Fees:**
* **TRX Transfers:** Approximately 0.1 TRX per transaction.
* **Other Tokens:** Slightly higher fees for TRC-10 and TRC-20 tokens.
* **Resource Efficiency:**\
TRON utilizes **Bandwidth and Energy resources** to facilitate free or near-free transactions. For example, every account gets 5,000 Bandwidth Points daily, which can be used to cover transaction costs.
> ***Highlight:***\
> **Fast, low-cost transactions are a cornerstone of the TRON network, making it attractive for everyday users and large-scale exchanges alike.**
***
## TRX in Decentralized Applications (dApps)
The TRON ecosystem is a **factory for dApps** that operate 24/7. These decentralized applications enable:
* **Content Creation & Exchange:**\
Creators can share, monetize, and manage their digital content without intermediaries.
* **Decentralized Finance (DeFi):**\
From lending platforms to decentralized exchanges, TRX fuels a variety of financial applications.
* **Token Interoperability:**\
The use of TRC-20 tokens ensures smooth integration with numerous dApps, boosting the network’s scalability and utility.
> ***Remember:***\
> **TRX is not just a currency—it’s the fuel powering a wide array of decentralized services and innovations.**
***
## Decentralize and Manage
TRON’s unique approach combines **financial freedom** with **entertainment decentralization**:
* **No Intermediaries:**\
All transactions are performed directly between users, cutting out the middleman.
* **Efficient Resource Management:**\
The TRON ecosystem relies on innovative mechanisms (such as Energy and Bandwidth) to keep operations smooth and cost-effective.
> ***Key Insight:***\
> **Decentralization on TRON means more control for users—both in managing finances and in participating in network governance.**
***
## Buy, Sell, and Exchange with TRX
TRX is versatile and can be used for:
* **Payments:**\
Directly pay for digital content, services, or goods without intermediaries.
* **Investment:**\
Use TRX as a store of value or for further investments.
* **Asset Exchange:**\
Trade TRX and other tokens with extremely low fees compared to fiat transactions.
> ***Final Note:***\
> **With TRX, you’re not just transacting; you’re actively participating in an ecosystem that values efficiency, low costs, and true decentralization.**
***
## Summary
TRX is the backbone of the TRON ecosystem—a blockchain designed for **speed, low transaction costs, and democratic governance**. Whether you’re staking, transacting, or developing dApps, TRX offers a **versatile and efficient** solution for a decentralized digital future.
> ***Final Highlights:***
>
> * **TRX empowers fast, low-cost transactions.**
> * **Staking TRX is a simple way to earn rewards.**
> * **Participate in decentralized governance through super representatives.**
> * **Leverage TRX to power innovative dApps and decentralized finance.**
Embrace TRX and join the movement towards a truly **decentralized** digital ecosystem!
---
---
url: https://doc.netts.io/tron/how-does-freezing-trx-help-save.md
---
# How Does Freezing TRX Help Save On Transactions?
**Understanding the Power of Staking (Freezing) TRX**\
When you start using a blockchain platform like TRON, you quickly learn how transaction fees can add up. The good news is, TRON offers a way to reduce—or even eliminate—these fees through a process known as **staking, freezing, or blocking** your TRX tokens.
> ***Key Highlights:***
>
> * **Staking Means Savings:** By freezing your TRX, you gain extra network resources—**Energy and Bandwidth**—that pay for transactions.
> * **No Extra Costs:** Instead of spending crypto on fees, you use the resources earned through staking.
> * **Decentralized Efficiency:** All operations are conducted directly on the TRON platform without third-party intermediaries.
***
## Gaining Energy and Bandwidth
TRON, like other staking-based blockchains, offers **Energy** and **Bandwidth** resources to cover transaction costs:
* **Bandwidth:**
* Provides the capacity for simple transactions like transfers and exchanges.
* **Restored Daily:** Each account receives a free daily allocation, sufficient for basic operations.
* **Ideal for TRC-10 Tokens:** Created and managed directly on the blockchain, they incur lower fees.
* **Energy:**
* Required for more complex operations, such as executing smart contracts (e.g., TRC-20, TRC-721 tokens).
* Must be purchased or earned through staking, as it is **not restored automatically**.
* **Boosts Smart Contract Efficiency:** Enables multiple transactions without extra fee expenses.
> ***Main Insight:***\
> By freezing TRX, you boost your Energy and Bandwidth reserves, allowing you to conduct transactions—especially those involving smart contracts—at little or no cost.
***
## The Staking (Freezing) Process
**How It Works:**
1. **Register and Link Your Wallet:** Use a non-custodial wallet like TronLink.
2. **Freeze Your TRX Tokens:** Block a portion of your TRX from being used for transactions for a set period.
3. **Earn Resources:** The network then uses your frozen TRX to generate additional Energy and Bandwidth.
4. **Reap Rewards:** In return, you get enough resources to cover transaction fees, and you may also receive extra rewards in TRX.
> ***Key Point:***\
> **The more TRX you freeze, the greater the resource reserves you receive—translating into lower or even zero transaction fees.**
***
## Reduced Costs for Active Users
**Why It’s Beneficial:**
* **For Developers:**
* DApp creators and smart contract developers save significantly on costs.
* Increased Energy reserves mean complex operations won’t burn through your funds.
* **For Frequent Transactors:**
* Large crypto holders who conduct many transactions can minimize fees.
* Active staking also opens opportunities to participate in network governance through voting.
> ***Highlight:***\
> **Staking TRX is economically advantageous, as it reduces fees for both simple and complex transactions, enhancing profitability.**
***
## Reusing the Resources
Unlike traditional mining—which consumes vast amounts of non-renewable energy—**staking TRX is eco-friendly**:
* **Bandwidth** is replenished daily, allowing repeated use.
* **Energy**, though it must be earned or purchased, is dynamically distributed, making it a renewable resource within the ecosystem.
* **Environmental Impact:**
* Staking minimizes the need for excessive computing power and reduces overall energy consumption.
> ***Takeaway:***\
> **Staking not only saves money but also supports a greener, more sustainable blockchain network.**
***
## Cost Control and Strategic Staking
Properly managing the amount of TRX you freeze is crucial:
* **Simple Transactions:**
* Easier to calculate the required TRX for everyday transfers.
* **Complex Operations:**
* For smart contracts or batch transactions, careful planning ensures you don’t run out of resources.
* Tools and calculators are available to help determine the optimal freezing volume.
> ***Essential Insight:***\
> **By freezing the right amount of TRX—often in the range of 5-6 thousand tokens—you can eliminate transaction fees for both routine and advanced operations.**
***
## Conclusion: Maximizing Benefits with Freezing TRX
Staking (or freezing) your TRX tokens is a powerful way to:
* **Save on Transaction Fees:** Gain free Energy and Bandwidth for your operations.
* **Support Decentralization:** Participate in network governance and validation.
* **Enhance Efficiency:** Develop and deploy smart contracts and dApps without high costs.
* **Enjoy Passive Rewards:** Earn additional TRX and resources simply by contributing to the network’s stability.
> ***Final Takeaway:***\
> **Freezing TRX is an effective strategy for both passive and active users, ensuring low-cost, efficient, and environmentally friendly transactions across the TRON ecosystem.**
---
---
url: https://doc.netts.io/tron/resources/what-are-resources-in-the-tron-network.md
---
# What Are Resources in the Tron Network?
The **Tron blockchain** was originally designed as a decentralized platform for developers and users of entertainment content via decentralized applications. Initially, it utilized tokens from the Ethereum blockchain, but as the Tron ecosystem evolved into a separate blockchain, it transitioned to using its own token standards. Now, alongside tokens following the **TRC-10, TRC-20, TRC-721,** and **TRC-1155** standards (which mirror their Ethereum counterparts), the network also features its native cryptocurrency—**Tronix (TRX)**.
> ***Key Highlights:***
>
> * **Multiple Token Standards:** TRC-10 for simple transactions; TRC-20 for smart contracts and dApp development; TRC-721 for NFTs; TRC-1155 for multi-token transfers.
> * **Two Critical Resources:** **Bandwidth** and **Energy** are used to pay for transaction costs, instead of spending TRX tokens directly.
> * **Cost Control:** With proper resource management, transaction fees can be reduced to zero.
***
## Understanding Resources: Bandwidth & Energy
Almost every interaction on the Tron network—whether transferring tokens or executing smart contracts—requires payment. Instead of always using TRX, you can pay with **special resources** that compensate for the network's costs:
### Energy
* **Purpose:**
* Functions like the gas fee in other blockchains.
* Acts as the **fuel** for executing smart contracts and complex dApp interactions.
* **Impact:**
* **Sufficient Energy:** Transactions can be executed without additional TRX fees.
* **Insufficient Energy:** The network will burn TRX tokens to cover the shortfall, resulting in higher costs.
### Bandwidth
* **Purpose:**
* Used for simple transactions such as transferring TRC-10 tokens or other data-related operations.
* Compensates for the network capacity needed to process these operations.
* **Impact:**
* **Daily Replenishment:** Each account receives a set amount of free Bandwidth daily.
* **Exhaustion:** Once Bandwidth is used up, the network charges a fee in TRX to cover additional transactions.
> ***Main Insight:***\
> **By managing Energy and Bandwidth effectively, you can significantly reduce—and even eliminate—transaction fees.**
***
## How to Obtain Resources
### Freezing TRX (Staking)
* **Process:**
* **Freeze (or stake) your TRX tokens** in your TronLink (or other non-custodial) wallet.
* Select the resource you need—**Energy, Bandwidth, or both**—to receive in return.
* **Benefits:**
* **Free Resources:** Earn additional Energy and Bandwidth without spending extra TRX.
* **Flexibility:** Choose the resource type based on your most common transaction needs (smart contracts vs. simple transfers).
> ***Essential Point:***\
> **The more TRX you freeze, the greater the reserves of Energy and Bandwidth you accumulate, lowering your transaction costs.**
### Restoring Bandwidth
* **Automatic Replenishment:**
* Bandwidth is credited automatically on a daily basis, regardless of whether your TRX is frozen.
* **Recommendation:**
* Monitor your Bandwidth usage to avoid unexpected TRX charges when reserves run out.
***
## Impact on Transaction Costs
Efficient use of resources directly affects your transaction expenses:
* **Sufficient Reserves:**
* Ensures free or low-cost transactions for both simple transfers and complex smart contracts.
* **Resource Shortage:**
* Leads to extra TRX being burned to compensate for lacking Energy or Bandwidth, thus increasing costs.
> ***Final Takeaway:***\
> **Effective resource management—via regular TRX freezing—allows you to plan and reduce transaction fees, sometimes even to zero.**
***
## Example Scenarios
1. **Simple TRX Transfer:**
* **With Adequate Bandwidth:**
* The free daily allocation covers the transaction, making it virtually free.
* **With Depleted Bandwidth:**
* Additional fees in TRX will be charged to compensate for the shortfall.
2. **Smart Contract Deployment:**
* **With Sufficient Energy:**
* The smart contract runs without incurring extra fees.
* **With Insufficient Energy:**
* The network compensates by burning TRX tokens, increasing the transaction cost.
***
## Summary
Both **Bandwidth** and **Energy** are vital resources in the Tron network. They allow users to control transaction costs effectively by:
* **Reducing or Eliminating Fees:** Proper planning and resource accumulation can make transactions free.
* **Optimizing dApp and Smart Contract Operations:** Ensuring enough Energy prevents costly TRX deductions.
* **Managing Costs Proactively:** Freezing TRX to receive these resources is key to minimizing unnecessary expenditure.
> ***In Conclusion:***\
> **Mastering resource management on the Tron network—by strategically freezing your TRX—enables you to minimize fees and optimize the performance of both simple transactions and complex decentralized applications.**
---
---
url: https://doc.netts.io/api/v2.md
---
# NETTS API v2 Documentation
Welcome to the NETTS API v2 documentation. This API provides comprehensive access to our energy rental platform, enabling developers and enterprises to integrate TRON energy optimization into their applications.
## Quick Start
1. **Get API Key**: Register at - your API key will be automatically generated
2. **Whitelist Your IP**: Add your IP address to the whitelist in the API section of workspace
3. **Fund Your Account**: Deposit funds in the Wallet section of workspace
4. **Set up Authentication**: Include your API key in request headers
5. **Start Integration**: Begin with [userinfo](./endpoints/userinfo.md) and [prices](./endpoints/prices.md) endpoints to rent energy via API
## Core Features
* **Real-time Energy Pricing**: Get live market rates for optimal cost efficiency
* **Automated Energy Orders**: Programmatic energy delegation with instant delivery
* **Multi-Wallet Management**: Host Mode for managing multiple wallet addresses
* **USDT Cost Calculator**: Accurate transfer cost estimation
## Enterprise Integration
Our API is designed for:
* **Cryptocurrency Exchanges**: Reduce operational costs on USDT transactions
* **DeFi Platforms**: Optimize smart contract interactions
* **Payment Processors**: Minimize transaction fees
* **Trading Bots**: Automated energy management for high-frequency operations
## Getting Started
Visit our [Core Endpoints](./endpoints/userinfo.md) section to begin integration, or explore [Host Mode Management](./host-mode.md) for advanced multi-wallet automation.
For questions and support, join our [Telegram support](https://t.me/netts_io).
---
---
url: https://doc.netts.io/api/mcp.md
---
# MCP server
NETTS publishes its documentation as an [MCP](https://modelcontextprotocol.io)
server, so an AI agent can search these docs and the API specification itself
instead of guessing or being fed a 700 KB text dump.
```
https://doc.netts.io/mcp
```
The server is **read-only**. It knows nothing about your account, keys or
balance — only what is published on this site.
## What the agent gets
| Tool | What it does |
|---|---|
| `search_docs` | Full-text search over the documentation pages |
| `get_doc` | Full Markdown of one page |
| `list_docs` | Index of every page |
| `search_api` | Search operations of NETTS API v2 |
| `get_endpoint` | Parameters, schemas, responses and error codes of one operation |
| `get_openapi_schema` | A reusable schema from the specification |
The blog is deliberately not indexed: those are articles for people, and for an
agent they are noise.
## Connect
**Cursor and VS Code** — use the *Connect to Cursor* and *Connect to VS Code*
items in the menu at the top of any documentation page. They install the server
in one click.
**Claude Code**
```bash
claude mcp add --transport http netts-docs https://doc.netts.io/mcp
```
**Anything else** — the transport is Streamable HTTP, no authentication:
```json
{
"mcpServers": {
"netts-docs": {
"type": "http",
"url": "https://doc.netts.io/mcp"
}
}
}
```
## Without MCP
If your tool does not speak MCP, the same content is available as plain files:
* [`/llms.txt`](https://doc.netts.io/llms.txt) — structured index of the documentation
* [`/llms-full.txt`](https://doc.netts.io/llms-full.txt) — the whole documentation in one file
* [`/openapi.yaml`](https://doc.netts.io/openapi.yaml) — the API specification
* any page with `.md` appended, for example
[`/api/v2/endpoints/order1h.md`](https://doc.netts.io/api/v2/endpoints/order1h.md)
---
---
url: https://doc.netts.io/api/v2/endpoints/activator.md
---
# Activator — address activation
Activate a TRON address that has never been used on-chain. A brand-new address has no account
record, so it cannot receive delegated energy or bandwidth until it is activated. This endpoint
creates the account for you and returns the activation transaction hash.
Activation is a **one-time** operation per address. If the address is already active, the endpoint
tells you so and **charges nothing**.
## Endpoint base URL
```
https://netts.io/apiv2/activator
```
The legacy path `https://netts.io/apiv2/activation` is served by the same service and behaves
identically. New integrations should use `/apiv2/activator`.
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| Content-Type | Yes | application/json |
| X-API-KEY | Yes | Your API key from the Netts dashboard |
| X-Real-IP | Yes | IP address from your whitelist |
Your `user_id` is derived from the API key — you never pass it.
***
## Activate — `POST /apiv2/activator`
### Request body
```json
{ "targetAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE" }
```
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `targetAddress` | string | Yes | TRON address to activate. Must match `^T[A-Za-z0-9]{33}$` (34 chars, starts with `T`). |
### Response — activated (200, code `10000`)
```json
{
"detail": {
"code": 10000,
"msg": "Address activated successfully, 1.1 TRX deducted",
"data": {
"orderId": "A123456",
"targetAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"activation_cost": 1.1,
"user_balance_before": 500.00,
"user_balance_after": 498.90,
"hash": "0000000000000000000000000000000000000000000000000000000000000000"
}
}
}
```
| Field | Type | Description |
|-------|------|-------------|
| `orderId` | string | Activation order number, always `A` + digits. Use it for reconciliation. |
| `targetAddress` | string | The address that was activated |
| `activation_cost` | float | Amount deducted from your balance, in TRX |
| `user_balance_before` | float | Balance before the deduction |
| `user_balance_after` | float | Balance after the deduction |
| `hash` | string | Activation transaction hash. Verify it on any TRON explorer. |
### Response — already active (200, code `2001`)
Returned when the address already exists on-chain. **Nothing is charged.**
```json
{
"detail": {
"code": 2001,
"msg": "Address is already activated",
"data": {
"targetAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"status": "already_activated",
"user_balance": 500.00,
"activation_cost": 0,
"activation_required": false
}
}
}
```
Check `code` before assuming a charge occurred: `10000` means you paid, `2001` means you did not.
### Example
```bash
curl -X POST https://netts.io/apiv2/activator \
-H "Content-Type: application/json" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip" \
-d '{"targetAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"}'
```
***
## Price
| Item | Amount |
|------|--------|
| Activation | **1.1 TRX** |
| Address already active | 0 |
The amount is fixed and does not depend on the address or on network conditions. It is deducted
from your Netts balance at the moment the activation succeeds — never before. A failed activation
costs nothing.
Your balance must cover the cost, otherwise the request is rejected with **403** (`1004`) and no
order is created.
***
## When you need this
* **Before renting energy or bandwidth for a fresh address.** Delegation to a non-existent account
fails. Activate first, then order.
* **Before the first incoming transfer** to an address you generated yourself.
You do **not** need to call this endpoint for an address that has ever received TRX or a token — it
is already active, and the call would simply return `2001`.
::: tip Ordering energy for a new address
The 1-hour energy endpoint activates a non-active receiver on its own as part of the order, and the
activation cost is added to that order. Call the activator explicitly when you want the address
active **before** any rental — for example to top up bandwidth first, which does require an active
account.
:::
***
## Timing
Activation is a real on-chain transaction. The endpoint returns after it is broadcast and the
activation record is written, typically within a few seconds.
The address becomes usable only once the transaction is **included in a block** — up to ~3 seconds
after the response, since that is the TRON block interval. If your next step depends on the address
being active (ordering bandwidth, for instance), confirm the state on-chain by the returned `hash`
instead of calling immediately.
***
## Error Code Reference
| Code | Description | HTTP Status |
|------|-------------|-------------|
| `10000` | Address activated, balance deducted | 200 |
| `2001` | Address already activated, nothing charged | 200 |
| `-1` | Invalid API key / IP not in whitelist | 401 |
| `1004` | Insufficient funds — the message states what is required and what you have | 403 |
| `-` | Invalid `targetAddress` format (must be 34 chars, start with `T`) | 422 |
| `5003` | Activation failed or service temporarily unavailable — retry later | 503 |
| `5000` | Internal server error | 500 |
A `503` means no charge occurred and no address was activated: the request may be retried safely.
## Rate Limits
Limited **per source IP**:
| Period | Limit |
|--------|-------|
| **1 second** | 5 requests |
| **1 minute** | 60 requests |
### Rate Limit Exceeded (429)
```json
{ "message": "API rate limit exceeded" }
```
## Notes
* **Idempotency is on you.** The endpoint has no idempotency key. Repeating a request for an address
that is already active is safe and free (`2001`), but two simultaneous requests for the same
brand-new address may both proceed. Serialise activation per address on your side.
* **`orderId` format is `A` + digits** and is unique across activations.
* **No webhook is sent for activation** today — the response and the `hash` are the confirmation.
Webhooks currently cover confirmed energy delegations only, see
[Webhooks](./webhooks.md).
---
---
url: https://doc.netts.io/api/v2/endpoints/energy-reclaim.md
---
# Energy Reclaim — return rented energy early
Return delegated energy to the pool before the rental period ends. Useful when the transaction
you rented for is already sent: the energy stops sitting idle on the address, and the pool can
serve someone else.
Reclaim is **voluntary**. Rentals expire on their own — you never have to call this endpoint.
## Endpoint base URL
```
https://netts.io/apiv2/energy/reclaim
```
Bandwidth has its own endpoint, see [Bandwidth](/api/v2/endpoints/bandwidth).
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| X-API-KEY | Yes | The API key **the order was placed with** |
| X-Real-IP | Yes | IP address from your whitelist |
Your `user_id` is derived from the API key — you never pass it.
::: warning The key must be the one used for the order
An order can only be reclaimed with the key that created it. A different key of the same account
will not work.
:::
***
## Reclaim — `POST /apiv2/energy/reclaim/{orderId}`
`orderId` is the order number returned when the energy was ordered — for example `1H…` for
1-hour rentals or `5M…` for 5-minute rentals. No request body.
```bash
curl -X POST "https://netts.io/apiv2/energy/reclaim/1Hb252feadcc" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip"
```
### Response — reclaimed (200, code `10004`)
```json
{
"detail": {
"code": 10004,
"status": "reclaimed",
"msg": "Energy reclaimed",
"data": {
"orderId": "1Hb252feadcc",
"reclaimHash": "51fa77da06e8fbebf504fbf088d1d9611059398d…"
}
}
}
```
`reclaimHash` is the on-chain transaction that returned the energy. Typical time from request to
response is a few seconds.
### Response — already reclaimed (200, code `10004`)
```json
{
"detail": {
"code": 10004,
"status": "reclaimed",
"msg": "Energy already reclaimed",
"data": {
"orderId": "1Hb252feadcc",
"reclaimHash": "51fa77da06e8fbebf504fbf088d1d9611059398d…"
}
}
}
```
Calling the endpoint twice is safe: the second call returns the same hash and changes nothing.
This also covers rentals that already expired on their own.
### Response — external provider (400, code `5006`)
```json
{
"detail": {
"code": 5006,
"status": "failed",
"msg": "Reclaim is available only for internal pool orders",
"data": { "orderId": "1H47eac983af", "provider": "…" }
}
}
```
Orders served by an external provider cannot be reclaimed: the resources are not ours to return.
Which provider served an order is visible in the order response.
### Response — nothing to reclaim (400, code `5005`)
The order never resulted in a delegation, or the delegation is not active. Nothing is charged and
nothing changes.
### Response — not completed yet (503, code `5003`)
```json
{
"detail": {
"code": 5003,
"status": "failed",
"msg": "Reclaim not completed yet — try again shortly",
"data": { "orderId": "1Hb252feadcc" }
}
}
```
The reclaim was accepted but the on-chain transaction had not appeared within the wait window.
It will most likely complete on its own — repeat the call in a few seconds to get the hash.
### Response — order not found (404)
```json
{ "detail": { "code": -1, "msg": "Order not found" } }
```
Returned both when the order does not exist and when it belongs to a different account.
***
## One order, not one address
Reclaim works **per order**, not per address. This is deliberate: an order identifies exactly what
is being returned — the same address may hold energy from several orders, including orders of
other accounts.
Two consequences worth planning for:
* A batch order for many addresses produces **one order number per address**. You reclaim any of
them individually; the rest keep working.
* A large amount for a single address may be split into several orders. To free that address
completely, reclaim each of them.
## Reclaiming orders placed through the Orchestrator
Works the same way. Ask the [Orchestrator](/api/v2/endpoints/orchestrator) for the status of your
request, take the order number from the `energy.orderIds` field of the address you want, and call
reclaim with it:
```json
"energy": {
"requested": 65570,
"delegated": 65570,
"status": "done",
"orderIds": ["1Hb252feadcc"]
}
```
## Money
Reclaim does **not** refund anything. Renting and returning are separate operations: you paid for
the rental when you placed the order, and returning the resource early does not undo that payment.
## Rate limit
10 requests per second per IP.
## Error codes
| Code | HTTP | Meaning |
|------|------|---------|
| 10004 | 200 | Reclaimed, or already reclaimed — hash included |
| 5003 | 503 | Accepted, hash not confirmed yet — retry shortly |
| 5005 | 400 | Nothing to reclaim for this order |
| 5006 | 400 | External provider order — reclaim unavailable |
| −1 | 404 | Order not found, or belongs to another account |
| −1 | 401 | Missing or invalid API key, or IP not whitelisted |
---
---
url: https://doc.netts.io/api/v2/endpoints/orchestrator.md
---
# Orchestrator — batch orders in one call
Send **up to 100 addresses in a single request** and let Netts do the whole sequence for each one:
activate the address if needed, top up its bandwidth if it is short, then rent the energy — splitting
large amounts into chunks automatically.
You get an immediate **202 Accepted** with a tracking key and never wait on the connection. Progress
is then read from the status endpoint.
## Why use it
Ordering energy for a fresh address normally takes three separate calls, in the right order, with
your own retry logic between them. The orchestrator collapses that into one request and runs the
sequence per address:
```
probe → activation (if the address is not active) → bandwidth (if free < 400) → energy
```
A failure in activation or bandwidth **does not** stop the energy order for that address, and one
address failing never affects the others.
## Endpoint base URL
```
https://netts.io/apiv2/orchestrator
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| Content-Type | Yes | application/json |
| X-API-KEY | Yes | Your API key from the Netts dashboard |
| X-Real-IP | Yes | IP address from your whitelist |
| X-Idempotency-Key | Yes\* | Your key for this order, 12–128 chars of `A-Z a-z 0-9 . _ : -` |
\* Either the `X-Idempotency-Key` header **or** the `clientRequestId` field in the body is required.
If you send neither, the request is rejected with `5010`.
The key identifies the whole order. Repeating a request with the same key returns the original
result instead of creating a second order — see [Idempotency](#idempotency).
***
## Create an order — `POST /apiv2/orchestrator`
### Request body
```json
{
"clientRequestId": "my-batch-2026-01-01-001",
"defaults": {
"bandwidth": true,
"bandwidthAmount": 400,
"bandwidthPeriod": "1h",
"check": true,
"trx_send": false
},
"items": [
{ "receiveAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE", "amount": 65000 },
{ "receiveAddress": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "amount": 131000 },
{ "receiveAddress": "TYYyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy", "amount": 61000, "bandwidth": false }
]
}
```
### Top-level fields
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `items` | array | Yes | 1 to 100 addresses. Duplicates within one order are rejected. |
| `clientRequestId` | string | No | Your order reference, 8–128 chars of `A-Z a-z 0-9 . _ : -`. Doubles as the idempotency key if the header is absent. |
| `defaults` | object | No | Values applied to every item that does not override them. |
### Item fields
Every field except `receiveAddress` and `amount` may also be set in `defaults`. A value on the item
wins over the default.
| Field | Type | Default | Description |
|-------|------|---------|-------------|
| `receiveAddress` | string | — | TRON address receiving the energy |
| `amount` | int | — | Energy for this address, 61 000 … 50 000 000 |
| `bandwidth` | bool | `true` | Order bandwidth for this address when it is short |
| `bandwidthAmount` | int | `400` | `400` or `5000` |
| `bandwidthPeriod` | string | `1h` | `5m` or `1h` |
| `check` | bool | see below | Check free bandwidth first and skip the order if there is enough |
| `trx_send` | bool | `false` | Passed through to the bandwidth service |
| `activation` | bool | `true` | Activate the address if it is not active. Set `false` to skip the step for an address you know is already active. |
`check` defaults to `true` when `bandwidthAmount` is `400`, and to `false` otherwise — ordering
5 000 units usually means you want them regardless of what is already there.
**Amounts are per address.** One request may mix different amounts freely; the only ceiling is the
total.
### Limits
| Limit | Value |
|-------|-------|
| Addresses per order | 100 |
| Energy per address | 61 000 … 50 000 000 |
| **Total energy per order** | 50 000 000 |
| Orders in flight per account | 3 |
| Addresses in flight per account | 300 |
| Minimum balance to be accepted | 4 TRX |
The 50 000 000 ceiling applies to the **sum over all addresses** in the request, not to each one.
### Response — accepted (202, code `10202`)
```json
{
"detail": {
"code": 10202,
"status": "accepted",
"msg": "Order accepted for processing",
"data": {
"idempotencyKey": "my-batch-2026-01-01-001",
"requestId": 1234,
"itemsAccepted": 3,
"statusUrl": "/apiv2/orchestrator/status/my-batch-2026-01-01-001",
"items": [
{
"deliveryKey": 5001,
"trackingId": "my-batch-2026-01-01-001:TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"receiveAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"amount": 65000,
"energyChunks": 1,
"activation": "planned",
"bandwidth": "planned",
"status": "queued"
}
]
}
}
}
```
`202` means **queued, not executed**. Nothing has been charged yet. Poll `statusUrl` for the result.
`trackingId` is the pair *idempotency key + address* — the identity of one address inside your
order. Use it in your own logs and reconciliation.
### Example
```bash
curl -X POST https://netts.io/apiv2/orchestrator \
-H "Content-Type: application/json" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip" \
-H "X-Idempotency-Key: my-batch-2026-01-01-001" \
-d '{
"items": [
{"receiveAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE", "amount": 65000}
]
}'
```
***
## Check progress — `GET /apiv2/orchestrator/status/{idempotencyKey}`
Add `?address=T…` to get a single address instead of the whole order.
```json
{
"detail": {
"code": 10000,
"status": "processing",
"data": {
"idempotencyKey": "my-batch-2026-01-01-001",
"requestId": 1234,
"clientRequestId": "my-batch-2026-01-01-001",
"summary": {
"total": 3, "queued": 1, "processing": 1, "completed": 1,
"partial": 0, "failed": 0, "insufficient_balance": 0,
"credentials_revoked": 0, "cancelled": 0
},
"items": [
{
"deliveryKey": 5001,
"trackingId": "my-batch-2026-01-01-001:TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"receiveAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"status": "completed",
"energy": {
"requested": 65000,
"delegated": 65000,
"status": "done",
"chunks": { "total": 1, "done": 1 },
"orderIds": ["1Hxxxxxxxxxx"],
"hashes": ["0000000000000000000000000000000000000000000000000000000000000000"]
},
"activation": { "status": "not_needed", "orderId": null, "hash": null },
"bandwidth": {
"status": "enough", "orderId": "B1Hxxxxxxxxxxxxxx",
"amount": 400, "period": "1h", "hashes": [], "skipReason": null
},
"attempts": 1,
"startedAt": "2026-01-01T00:00:00+00:00",
"finishedAt": "2026-01-01T00:00:03+00:00"
}
]
}
}
}
```
An unknown key, or one belonging to another account, returns **404**.
### Address status values
| Status | Meaning |
|--------|---------|
| `queued` | Waiting to be picked up |
| `processing` | In progress |
| `completed` | All requested energy delegated |
| `partial` | Some chunks delivered, some failed |
| `failed` | Nothing delivered |
| `insufficient_balance` | Stopped — your balance fell below the minimum |
| `credentials_revoked` | Your API key was removed or disabled while the order was running |
| `cancelled` | Removed from the queue by your cancel request |
### Step status values
| Step | Values |
|------|--------|
| `activation` | `not_needed`, `done`, `failed`, `skipped`, `skipped_unavailable` |
| `bandwidth` | `enough`, `done`, `failed`, `skipped` |
| `energy` | `done`, `partial`, `failed` |
`bandwidth.skipReason` explains a `skipped`: `option_off` (you disabled it), `energy_gt_600000`
(large energy orders do not need a bandwidth top-up).
### Delegation hashes
`energy.hashes` is your proof of delivery. When the energy comes from an external provider the hash
is not known at order time — it is filled in about a minute later, and the address is not reported
as finished until the hashes are collected or the wait window expires. An address in `completed`
with a hash present is fully settled.
***
## Cancel — `POST /apiv2/orchestrator/cancel/{idempotencyKey}`
Removes from the queue every address that has **not been picked up yet**.
```json
{
"detail": {
"code": 10005,
"status": "cancelled",
"msg": "Order cancelled: 7 addresses removed from queue",
"data": { "cancelled": 7 }
}
}
```
Addresses already in `processing` are **not** interrupted: part of their energy may already be paid
for. Cancel is best-effort on the remainder.
***
## Idempotency
The order is identified by your key — the `X-Idempotency-Key` header, or `clientRequestId` when the
header is absent.
| Repeat request | Result |
|----------------|--------|
| Same key, **same body** | **208** with the original order and `originalAcceptedAt` — no second order |
| Same key, **different body** | **409** `4090 IDEMPOTENCY_CONFLICT` |
So a network timeout on your side is safe to retry verbatim. Changing the payload under an already
used key is rejected rather than silently applied.
Inside the order, each address carries its own internal key, so a repeat never double-charges a
single address either.
***
## Billing
The orchestrator itself charges nothing. Each step is billed by the service that performs it, at its
normal price:
| Step | Charged as |
|------|-----------|
| Activation | separate deduction, order number `A…` |
| Bandwidth | separate deduction, order number `B1H…` — only when actually delegated |
| Energy | one deduction per chunk, order number `1H…` |
`check: true` with enough free bandwidth costs nothing — the status is `enough` and no order is
placed. Large energy amounts skip bandwidth entirely.
If your balance runs out mid-batch, the remaining addresses end as `insufficient_balance` without
being attempted.
***
## Error Code Reference
| Code | Description | HTTP Status |
|------|-------------|-------------|
| `10202` | Order accepted / already accepted | 202 / 208 |
| `10000` | Status returned | 200 |
| `10005` | Order cancelled | 200 |
| `5004` | Invalid field: address format, `amount` out of range, `bandwidthAmount` not 400/5000, `bandwidthPeriod` not 5m/1h, body not a JSON object | 400 |
| `5005` | `items` missing or empty | 400 |
| `5006` | Duplicate `receiveAddress` in one order | 400 |
| `5009` | Malformed `X-Idempotency-Key` or `clientRequestId` | 400 |
| `5010` | Neither `X-Idempotency-Key` nor `clientRequestId` provided | 400 |
| `5012` | Total energy in the request exceeds 50 000 000 | 400 |
| `-1` | Invalid API key / IP not in whitelist | 401 |
| `1004` | Balance below the 4 TRX minimum | 402 |
| `-1` | Order not found (or not yours) | 404 |
| `4090` | `IDEMPOTENCY_CONFLICT` — same key, different body | 409 |
| `4220` | Request validation failed (details in `data.errors`) | 422 |
| `429` / `5011` | Too many orders, addresses or chunks in flight | 429 |
| `5003` | Order was **not** accepted — service temporarily unavailable, safe to retry | 503 |
A `503` on create is fail-secure: nothing was stored and nothing was charged.
## Rate Limits
Limited **per source IP**:
| Period | Limit |
|--------|-------|
| **1 second** | 20 requests |
### Rate Limit Exceeded (429)
```json
{ "message": "API rate limit exceeded" }
```
## Notes
* **202 is not a delivery receipt.** Treat it as "queued". The result lives in the status endpoint.
* **Addresses run in parallel**, up to 5 at a time within one order, so a large batch does not wait
on a single slow address. Order of completion is not guaranteed.
* **Chunking is automatic**: amounts above 1 000 000 are split into even chunks, each becoming its
own energy order. `energy.orderIds` and `energy.hashes` list them all.
* **No webhook for orchestrator orders as a whole.** Each energy delegation still produces the usual
`delegation.confirmed` webhook, see [Webhooks](./webhooks.md).
* **Related endpoints:** [Activator](./activator.md), [Bandwidth](./bandwidth.md),
[Order 1H](./order1h.md).
---
---
url: https://doc.netts.io/api/v2/endpoints/webhooks.md
---
# Webhooks — order notifications
Register an HTTPS endpoint to receive a **signed webhook** the moment one of your orders is
**fulfilled and verified on-chain**. Instead of polling, you continue your flow (e.g. release USDT)
as soon as the notification arrives.
Three events are delivered:
| Event | Sent when |
|-------|-----------|
| `delegation.confirmed` | An **energy** rental (`1h` / `5m`) is confirmed on-chain |
| `bandwidth.delegated` | A **bandwidth** order is fulfilled |
| `activation.confirmed` | An **address activation** is executed on-chain |
This page covers the **management API** (create / list / edit / rotate-secret / delete your
endpoints) and the **format of the webhooks** we deliver to you.
> ℹ️ **Roles.** You manage your endpoints here. Delivery is performed by Netts asynchronously after
> the order is verified — there is nothing to poll. Only success events are sent; failures and
> timeouts are never delivered.
> 🔒 **Every hash we send is verified on-chain first.** A webhook is dispatched only after each
> transaction hash in it is found in a block. If a hash is not in a block yet, delivery is held and
> re-checked every 30 seconds for up to 5 minutes; if it never lands, **nothing is sent** for that
> order. You will never receive a hash that does not exist on-chain.
## Endpoint base URL
```
https://netts.io/apiv2/webhooks
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| Content-Type | Yes (for POST/PATCH) | application/json |
| X-API-KEY | Yes | Your API key from the Netts dashboard |
| X-Real-IP | Yes | IP address from your whitelist |
Your `user_id` is derived from the API key — you never pass it. You can see and modify **only your
own** endpoints.
***
## Primary and backup endpoint
You register **at most two** endpoints, and each one has a `role`:
| Role | Purpose |
|------|---------|
| `primary` | The address every webhook is delivered to. |
| `backup` | Fallback. Used only when delivery to `primary` fails after its retries are exhausted. |
A single confirmed order produces a **single** webhook. It is **not** fan-out: the same event is
never sent to both addresses at once. The `backup` endpoint exists for resilience — if your primary
host is unreachable or keeps returning non-2xx, delivery moves to the backup instead of being
dropped.
The first endpoint you create becomes `primary`, the second becomes `backup`. You can pass `role`
explicitly, or swap them later with `PATCH`.
> **Why not a separate URL per operation type?** Because the event type travels **inside the body**,
> in the `event` field. One handler, one signature check, and new event types start arriving without
> you registering anything new.
***
## Manage endpoints
### Create — `POST /apiv2/webhooks`
Registers a new endpoint and returns a **`secret` shown only once** (store it — it signs every
webhook you receive).
```json
// request body — role is optional
{
"url": "https://your-server.example/netts/delegation-hook",
"role": "primary"
}
```
If you omit `role`, the first free one is assigned: `primary`, then `backup`.
```json
// response 201
{
"detail": {
"code": 10000,
"status": "created",
"data": {
"id": 1,
"url": "https://your-server.example/netts/delegation-hook",
"secret": "whsec_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"role": "primary",
"is_active": true,
"created_at": "2026-01-01T00:00:00"
}
}
}
```
**URL requirements** (validated on create and on every edit):
* must be **`https`**;
* must **resolve to a public address** — loopback, private (RFC1918), link-local
(incl. `169.254.169.254`), and other non-routable ranges are rejected;
* no credentials in the URL (`user:pass@…`);
* length up to 2048 chars.
A rejected URL returns **400**.
You may have **two** endpoints — one `primary` and one `backup`. A third returns **409** (`4090`).
Asking for a `role` that is already taken returns **409** (`4091`) — swap roles with `PATCH` or
delete the existing one first.
```bash
curl -X POST https://netts.io/apiv2/webhooks \
-H "Content-Type: application/json" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip" \
-d '{"url": "https://your-server.example/netts/delegation-hook", "role": "primary"}'
```
### List — `GET /apiv2/webhooks`
Returns your endpoints (the `secret` is **never** returned here).
```json
{
"detail": {
"code": 10000,
"status": "ok",
"data": {
"endpoints": [
{
"id": 1,
"url": "https://your-server.example/netts/delegation-hook",
"role": "primary",
"is_active": true,
"created_at": "2026-01-01T00:00:00",
"updated_at": "2026-01-01T00:00:00"
},
{
"id": 2,
"url": "https://backup.example/netts/delegation-hook",
"role": "backup",
"is_active": true,
"created_at": "2026-01-01T00:00:00",
"updated_at": "2026-01-01T00:00:00"
}
],
"count": 2,
"max_endpoints": 2,
"roles": ["primary", "backup"]
}
}
}
```
### Get one — `GET /apiv2/webhooks/{id}`
Same shape as a list item (no `secret`). A foreign or non-existent `id` returns **404**.
### Edit — `PATCH /apiv2/webhooks/{id}`
Change the `url`, `is_active` and/or `role`. Send any subset; an empty body returns **422**. A
changed `url` is re-validated (https / SSRF). A foreign or non-existent `id` returns **404**.
```json
// request body (any subset)
{ "url": "https://your-server.example/netts/new-hook", "is_active": false }
```
```json
// response 200
{
"detail": {
"code": 10000,
"status": "updated",
"data": {
"id": 1,
"url": "https://your-server.example/netts/new-hook",
"role": "primary",
"is_active": false,
"created_at": "2026-01-01T00:00:00",
"updated_at": "2026-01-01T00:00:01"
}
}
}
```
**Promoting the backup.** Sending `{"role": "primary"}` to your backup endpoint **swaps** the two
roles in a single transaction — the old primary becomes the backup. You are never left without a
primary address, and no separate call is needed for the other endpoint.
```bash
curl -X PATCH https://netts.io/apiv2/webhooks/2 \
-H "Content-Type: application/json" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip" \
-d '{"role": "primary"}'
```
> Set `is_active: false` to pause delivery without deleting the endpoint; `true` to resume. Pausing
> your `primary` does not promote the backup — delivery still targets the primary. Swap the roles if
> you want the backup to take over.
### Rotate secret — `POST /apiv2/webhooks/{id}/rotate-secret`
Generates a new `secret` and returns it **once**. The new secret takes effect immediately for
subsequent deliveries — no further action needed. Each endpoint has its **own** secret: rotating the
primary's secret does not change the backup's.
```json
// response 200
{
"detail": {
"code": 10000,
"status": "rotated",
"data": {
"id": 1,
"secret": "whsec_yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
}
}
}
```
### Delete — `DELETE /apiv2/webhooks/{id}`
Hard-deletes the endpoint and frees its role. Returns **204** (no body); a foreign or non-existent
`id` returns **404**.
```bash
curl -X DELETE https://netts.io/apiv2/webhooks/1 \
-H "X-API-KEY: your_api_key" -H "X-Real-IP: your_whitelisted_ip"
```
***
## The webhooks we deliver
When one of your orders is fulfilled, Netts sends a `POST` to your `primary` endpoint. Every body is
`application/json` (UTF-8); addresses and hashes are always **full** values.
**Fields common to all events:**
| Field | Type | Description |
|-------|------|-------------|
| `event` | string | Event type — routing key for your handler |
| `delivery_id` | int | Delivery ID — **dedup key** on your side. Also sent in the `X-Netts-Delivery` header. |
| `order_id` | string | Your order ID |
| `order_type` | string | `1h`, `5m`, `bandwidth` or `activation` |
| `tx_hashes` | string\[] | All transaction hashes of the operation, each verified on-chain |
| `confirmed_at` | string | UTC ISO-8601 |
### `delegation.confirmed` — energy rental
```json
{
"event": "delegation.confirmed",
"delivery_id": 1,
"order_id": "1Hxxxxxxxxxx",
"order_type": "1h",
"receive_address": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"energy_amount": 65000,
"tx_hash": "0000000000000000000000000000000000000000000000000000000000000000",
"tx_hashes": ["0000000000000000000000000000000000000000000000000000000000000000"],
"delegation_timestamp": 1700000000000,
"confirmed_at": "2026-01-01T00:00:00Z"
}
```
| Field | Type | Description |
|-------|------|-------------|
| `order_type` | string | `1h` or `5m` |
| `receive_address` | string | TRON address that received the energy |
| `energy_amount` | int | Energy amount delegated |
| `tx_hash` | string | **Legacy field**, kept for compatibility: same as `tx_hashes[0]` |
| `delegation_timestamp` | int? | **Optional** — present only when confirmed via the Mongo path |
> Prefer `tx_hashes` in new integrations — an order may in principle be fulfilled by more than one
> transaction. `tx_hash` will keep working.
### `bandwidth.delegated` — bandwidth order
```json
{
"event": "bandwidth.delegated",
"delivery_id": 2,
"order_id": "B1Hxxxxxxxxxxxxx",
"order_type": "bandwidth",
"rental_label": "1h",
"rental_seconds": 3600,
"receive_address": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"bandwidth_amount": 400,
"fulfillment": "delegated",
"tx_hashes": ["0000000000000000000000000000000000000000000000000000000000000000"],
"confirmed_at": "2026-01-01T00:00:00Z"
}
```
| Field | Type | Description |
|-------|------|-------------|
| `rental_label` / `rental_seconds` | string / int | Rental duration, e.g. `1h` / `3600` |
| `receive_address` | string | TRON address that received the bandwidth |
| `bandwidth_amount` | int | Bandwidth units (net) |
| `fulfillment` | string | How the order was fulfilled — see below |
`fulfillment` values:
| Value | Meaning | `tx_hashes` |
|-------|---------|-------------|
| `delegated` | Bandwidth delegated from our pool | 1+ hashes |
| `trx_send` | Fulfilled by sending TRX to the address instead of delegating | 1+ hashes |
| `already_enough` | The address already had enough free bandwidth — nothing was sent on-chain | **empty** |
`already_enough` is the only case where `tx_hashes` is empty: the order is closed successfully, but
there is no transaction because none was needed.
### `activation.confirmed` — address activation
```json
{
"event": "activation.confirmed",
"delivery_id": 3,
"order_id": "123456",
"order_type": "activation",
"address": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"activation_type": "ACC_CREATE",
"source": "telegram_bot",
"tx_hashes": ["0000000000000000000000000000000000000000000000000000000000000000"],
"confirmed_at": "2026-01-01T00:00:00Z"
}
```
| Field | Type | Description |
|-------|------|-------------|
| `order_id` | string | Activation order ID (numeric string) |
| `address` | string | TRON address that was activated |
| `activation_type` | string | `ACC_CREATE` (AccountCreateContract) or `DIRECT` (TRX transfer) |
| `source` | string | Origin marker. Either a service tag, or the ID of the energy order that required the activation |
**Only real activations are delivered.** If the address turned out to be already active and no
transaction was made, no webhook is sent at all.
> An energy order that also required an activation produces **two** webhooks — one
> `activation.confirmed` and one `delegation.confirmed`. They are separate events with separate
> `delivery_id`s; route them by the `event` field.
**Headers we send:**
| Header | Value |
|--------|-------|
| `X-Netts-Event` | Event type: `delegation.confirmed`, `bandwidth.delegated` or `activation.confirmed` |
| `X-Netts-Delivery` | `delivery_id` (dedup) |
| `X-Netts-Timestamp` | unix seconds at send time |
| `X-Netts-Signature` | `sha256=`, `hex = HMAC_SHA256(secret, "." + raw_body)` |
| `User-Agent` | `netts-webhook/1.0` |
### Verifying the signature
The signature follows the Stripe scheme (`timestamp.body`), computed over the **raw bytes** we send.
Recompute it with your `secret`, compare constant-time, and reject if `X-Netts-Timestamp` is outside
a **±5 minute** window (replay protection).
Sign with the secret of the endpoint that **received** the request: primary and backup have separate
secrets. If both your addresses are served by the same handler, pick the secret by the URL the
request arrived at.
```python
import hmac, hashlib, time
def verify(raw_body: bytes, sig_header: str, ts_header: str, secret: str) -> bool:
# freshness (anti-replay)
if abs(time.time() - int(ts_header)) > 300:
return False
signed = f"{ts_header}.".encode() + raw_body
expected = "sha256=" + hmac.new(secret.encode(), signed, hashlib.sha256).hexdigest()
return hmac.compare_digest(expected, sig_header)
# Flask example:
# ok = verify(request.get_data(),
# request.headers["X-Netts-Signature"],
# request.headers["X-Netts-Timestamp"], SECRET)
```
### Delivery semantics (important — at-least-once)
Delivery is **at-least-once**: a dropped response can cause a retry, so you may receive the same
event twice. Because the business action (releasing USDT) is money-sensitive:
1. **Dedup is mandatory** — process each event idempotently by `delivery_id` (and/or `order_id`);
a repeat is a no-op.
2. **Verify HMAC before any money action** — don't trust the body until the signature matches and
`X-Netts-Timestamp` is fresh.
3. **Return 2xx only after you've durably stored the event** — otherwise we (correctly) retry.
Respond **2xx** to acknowledge; any non-2xx / timeout triggers a retry.
**Order of attempts:**
1. Retries go to your `primary` endpoint. The window depends on order type: `5m` orders retry for
\~1 minute, all other types for ~10 minutes.
2. If the window is exhausted and you registered a `backup`, delivery moves there and the retry
schedule starts over — signed with the **backup's own secret**.
3. Only after the backup is exhausted too is the delivery marked dead.
The same `delivery_id` is used throughout, so a message that first failed on the primary and then
succeeded on the backup is still **one** event for your dedup logic.
***
## Error Code Reference
| Code | Description | HTTP Status |
|------|-------------|-------------|
| `10000` | Success (created / ok / updated / rotated) | 200 / 201 |
| `-` | Deleted (no body) | 204 |
| `4000` | Invalid / unsafe webhook URL (not https, private/loopback, credentials, too long) | 400 |
| `-1` | Invalid API key / IP not in whitelist | 401 |
| `-1` | Endpoint not found (or not yours) | 404 |
| `4090` | Endpoint limit reached (max 2: primary, backup) | 409 |
| `4091` | Requested role is already taken — swap with `PATCH` or delete the existing endpoint | 409 |
| `4220` | Nothing to update (PATCH with empty body) | 422 |
| `5003` | Failed to create endpoint (try again) | 503 |
## Rate Limits
Limited **per API key** (header `X-API-KEY`):
| Period | Limit |
|--------|-------|
| **1 second** | 5 requests |
| **1 minute** | 150 requests |
### Rate Limit Exceeded (429)
```json
{ "message": "API rate limit exceeded" }
```
## Notes
* **Secret is shown once** — on create and on rotate. It is never returned by `GET`/`LIST`. Lost it?
rotate to get a new one.
* **Two endpoints, not fan-out:** one `primary` and one `backup`. Each confirmed order produces one
webhook, delivered to the primary; the backup is used only if the primary is exhausted.
* **Zero-downtime URL change:** register the new address as `backup`, verify it, then `PATCH` it to
`primary` — the swap is atomic.
* **Pausing:** `PATCH … {"is_active": false}` stops delivery without losing the endpoint.
* **Success events only:** `delegation.confirmed`, `bandwidth.delegated`, `activation.confirmed`.
There is no failure event — a failed or timed-out order produces no webhook.
* **New event types may be added** over time. Route by the `event` field and ignore types you do not
handle yet — you never need to register anything new to start receiving them.
* **Hashes are verified on-chain before delivery** (see the note at the top): a webhook either
carries hashes that are all in a block, or is not sent at all.
* **URLs are validated** for SSRF safety at registration and on every edit; the delivery side
re-validates at send time.
---
---
url: https://doc.netts.io/api/v2/endpoints/address-rotate.md
---
# POST /apiv2/address/rotate
Request a deposit address rotation. The current deposit address will be replaced with a new one. The request is placed in a processing queue and completed automatically within 5 minutes.
## Endpoint URL
```
POST https://netts.io/apiv2/address/rotate
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| Content-Type | Yes | application/json |
| X-API-KEY | Yes | Your API key from Netts dashboard |
| X-Real-IP | Yes | IP address from your whitelist |
## Request Body
```json
{
"user_id": 1234,
"address_type": "web"
}
```
### Parameters
| Parameter | Type | Required | Default | Description |
|-----------|------|----------|---------|-------------|
| user\_id | integer | No | Authenticated user | Target user ID. Omit to rotate your own address. Parent users can specify their SUB-user's ID |
| address\_type | string | No | "web" | Address type to rotate: `web` or `tg` |
## Authentication & Authorization
This endpoint requires both **authentication** and **authorization**:
1. **Authentication**: Valid API key + IP from whitelist (same as other endpoints)
2. **Authorization**:
* Rotate **your own** address — always allowed
* Rotate **your SUB-user's** address — allowed for parent users
* Rotate another user's address — rejected with `403 Forbidden`
## Example Requests
### cURL
```bash
# Rotate own address
curl -X POST https://netts.io/apiv2/address/rotate \
-H "Content-Type: application/json" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip" \
-d '{"address_type": "web"}'
```
```bash
# Rotate SUB-user's address (parent user only)
curl -X POST https://netts.io/apiv2/address/rotate \
-H "Content-Type: application/json" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip" \
-d '{"user_id": 1234, "address_type": "web"}'
```
### Python
```python
import requests
url = "https://netts.io/apiv2/address/rotate"
headers = {
"Content-Type": "application/json",
"X-API-KEY": "your_api_key",
"X-Real-IP": "your_whitelisted_ip"
}
# Rotate own address
response = requests.post(url, headers=headers, json={"address_type": "web"})
data = response.json()
if response.status_code == 200:
print(f"Rotation ID: {data['rotation_id']}")
print(f"Old Address: {data['old_address']}")
print(f"Status: {data['status']}")
print(f"Estimated Completion: {data['estimated_completion']}")
else:
print(f"Error: {data.get('detail', 'Unknown error')}")
```
### Node.js
```javascript
const axios = require('axios');
async function rotateAddress(apiKey, whitelistedIp, addressType = 'web', userId = null) {
const url = 'https://netts.io/apiv2/address/rotate';
const body = { address_type: addressType };
if (userId) body.user_id = userId;
const response = await axios.post(url, body, {
headers: {
'Content-Type': 'application/json',
'X-API-KEY': apiKey,
'X-Real-IP': whitelistedIp
},
timeout: 30000
});
const data = response.data;
console.log(`Rotation ID: ${data.rotation_id}`);
console.log(`Status: ${data.status}`);
console.log(`Old Address: ${data.old_address}`);
return data;
}
// Rotate own address
rotateAddress('your_api_key', 'your_whitelisted_ip')
.then(result => console.log('Submitted:', result.message))
.catch(err => console.error('Error:', err.response?.data || err.message));
```
### PHP
```php
'web'
]);
$options = [
'http' => [
'header' => implode("\r\n", [
"Content-Type: application/json",
"X-API-KEY: your_api_key",
"X-Real-IP: your_whitelisted_ip"
]),
'method' => 'POST',
'content' => $data,
'timeout' => 30
]
];
$context = stream_context_create($options);
$response = file_get_contents($url, false, $context);
$result = json_decode($response, true);
echo "Rotation ID: {$result['rotation_id']}\n";
echo "Old Address: {$result['old_address']}\n";
echo "Status: {$result['status']}\n";
echo "Message: {$result['message']}\n";
?>
```
## Response
### Success Response (200 OK)
```json
{
"rotation_id": 42,
"user_id": 1234,
"address_type": "web",
"old_address": "TCurrentAddress1234567890123456789",
"status": "pending",
"message": "Address rotation request submitted. New address will be assigned within 5 minutes.",
"estimated_completion": "2026-03-14T12:35:00Z"
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| rotation\_id | integer | Unique rotation request ID (use for status checks) |
| user\_id | integer | User whose address is being rotated |
| address\_type | string | Address type being rotated (`web` or `tg`) |
| old\_address | string | Current TRON deposit address before rotation |
| status | string | Request status: `pending` |
| message | string | Human-readable status message |
| estimated\_completion | string | Estimated completion time in ISO 8601 format |
## Check Rotation Status
### GET /apiv2/address/rotate/status/{rotation\_id}
Check the status of a previously submitted rotation request.
```bash
curl https://netts.io/apiv2/address/rotate/status/42 \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip"
```
**Response:**
```json
{
"rotation_id": 42,
"user_id": 1234,
"address_type": "web",
"status": "completed",
"old_address": "TOldAddress1234567890123456789012",
"new_address": "TNewAddress1234567890123456789012",
"created_at": "2026-03-14T12:30:00Z",
"completed_at": "2026-03-14T12:34:15Z"
}
```
### Status Values
| Status | Description |
|--------|-------------|
| `pending` | Request submitted, waiting to be processed |
| `processing` | Currently being processed |
| `completed` | New address assigned successfully |
| `failed` | Error occurred during rotation |
## Check Pending Rotation
### GET /apiv2/address/rotate/pending
Check if a user has a pending rotation request (useful for disabling the rotation button).
```bash
curl "https://netts.io/apiv2/address/rotate/pending?address_type=web" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip"
```
**Response:**
```json
{
"user_id": 1234,
"address_type": "web",
"has_pending": true,
"pending_rotation": {
"rotation_id": 42,
"status": "pending",
"created_at": "2026-03-14T12:30:00Z"
}
}
```
## Important Notes
::: warning Address Change
After rotation is completed, your **current deposit address will no longer accept deposits**. Make sure to:
1. Withdraw any remaining balance from the current address before requesting rotation
2. Update any external systems that reference your old deposit address
3. Use the new address for all future deposits
:::
::: tip Processing Time
Rotation requests are processed automatically. A new address is typically assigned within **5 minutes** of submission.
:::
* Only **one pending rotation** per user per address type is allowed within a 7-day window
* If you already have a pending rotation, the request will be rejected with `409 Conflict`
* Both `web` and `tg` addresses can be rotated independently
* Parent users can rotate their SUB-users' addresses by specifying the `user_id` parameter
## Error Responses
### Conflict (409)
```json
{
"detail": "User 1234 already has a pending web address rotation request"
}
```
### Bad Request (400)
```json
{
"detail": "User 1234 has no web deposit address"
}
```
```json
{
"detail": "address_type must be 'web' or 'tg'"
}
```
### Not Found (404)
```json
{
"detail": "User 9999 not found"
}
```
### Forbidden (403)
```json
{
"detail": "Not authorized to rotate this user's address"
}
```
### Authentication Error (401)
```json
{
"detail": "X-API-KEY header required"
}
```
## Error Code Reference
| HTTP Status | Description |
|-------------|-------------|
| `200` | Rotation request submitted successfully |
| `400` | Invalid request (no address, invalid type) |
| `401` | Missing API key header |
| `403` | Not authorized / Invalid API key or IP |
| `404` | User not found / Rotation not found |
| `409` | Pending rotation already exists |
| `500` | Internal server error |
## Related Endpoints
* [POST /apiv2/subusergen](/api/v2/endpoints/subusergen) — Create a new SUB-user
* [DELETE /apiv2/subuserdel](/api/v2/endpoints/subuserdel) — Delete a SUB-user
* [GET /apiv2/userinfo](/api/v2/endpoints/userinfo) — Get user information
---
---
url: https://doc.netts.io/api/v2/endpoints/userinfo.md
---
# GET /apiv2/userinfo
Retrieve user information, including balance and usage statistics.
## Endpoint URL
```
GET https://netts.io/apiv2/userinfo
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| X-API-KEY | Yes | Your API key |
| X-Real-IP | Yes | IP address from whitelist |
## Request Parameters
No parameters required - user information is determined from the API key.
## Example Requests
### cURL
```bash
curl -X GET https://netts.io/apiv2/userinfo \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip"
```
### Python
```python
import requests
url = "https://netts.io/apiv2/userinfo"
headers = {
"X-API-KEY": "your_api_key",
"X-Real-IP": "your_whitelisted_ip"
}
response = requests.get(url, headers=headers)
data = response.json()
if response.status_code == 200:
print(f"Status: {data.get('status')}")
print(f"User ID: {data.get('user_id')}")
user_info = data.get('user_info', {})
print(f"Email: {user_info.get('email')}")
print(f"Name: {user_info.get('name')}")
print(f"Deposit Address: {user_info.get('deposit_address')}")
stats = data.get('stats', {})
print(f"Balance: {stats.get('balance')} TRX")
print(f"Total Delegations: {stats.get('total_delegations')}")
print(f"Total Energy Delegated: {stats.get('total_energy_delegated')}")
print(f"Total TRX Spent: {stats.get('total_trx_spent')} TRX")
print(f"Average Rate: {stats.get('avg_rate_sun_energy')} Sun/Energy")
print(f"Savings: {stats.get('save_by_netts_percent')}%")
print(f"Savings in USD: ${stats.get('save_in_dollars')}")
network_info = data.get('network_info', {})
print(f"TRX Price: ${network_info.get('trx_price')}")
print(f"Network Energy Fee: {network_info.get('network_energy_fee')}")
else:
print(f"Error: {data.get('message', 'Unknown error')}")
```
## Response
### Success Response (200 OK)
```json
{
"status": "success",
"timestamp": "2025-09-02 05:56:11",
"user_id": 6,
"user_info": {
"email": "user@example.com",
"name": "User Name",
"deposit_address": "TDepositAddress1234567890123456789"
},
"stats": {
"balance": 28361.15,
"total_delegations": 96756,
"total_energy_delegated": 21687058023,
"total_trx_spent": 832181.95,
"total_deposit": 0,
"avg_rate_sun_energy": 38.37,
"save_by_netts_percent": 61.63,
"save_in_dollars": 453267.36
},
"network_info": {
"trx_price": 0.3391,
"network_energy_fee": 100.0
}
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| status | string | Always "success" for successful requests |
| timestamp | string | Server timestamp in YYYY-MM-DD HH:MM:SS format |
| user\_id | integer | Internal user ID |
| user\_info.email | string | User email address |
| user\_info.name | string | User display name |
| user\_info.deposit\_address | string | TRON address for deposits |
| stats.balance | number | **Total Balance TRX** - includes deposit wallet balance + pending payouts (Robot & Sub-users) - pending withdrawals |
| stats.total\_delegations | integer | Total number of energy delegations |
| stats.total\_energy\_delegated | integer | Total energy units delegated |
| stats.total\_trx\_spent | number | Total TRX spent on energy |
| stats.total\_deposit | number | Total deposits made |
| stats.avg\_rate\_sun\_energy | number | Average rate in Sun per energy unit |
| stats.save\_by\_netts\_percent | number | Percentage saved using Netts vs burning TRX |
| stats.save\_in\_dollars | number | Dollar value of savings |
| network\_info.trx\_price | number | Current TRX price in USD |
| network\_info.network\_energy\_fee | number | Current network energy fee |
## Error Responses
### Authentication Error (401)
```json
{
"status": "error",
"code": 401,
"message": "Invalid API key or IP not in whitelist"
}
```
### Internal Server Error (500)
```json
{
"status": "error",
"message": "Internal server error"
}
```
## Rate Limits
The following rate limits apply to this endpoint (per IP address):
| Period | Limit | Description |
|--------|-------|-------------|
| **1 minute** | 6 requests | Maximum 6 requests per minute |
### Rate Limit Headers
The API returns rate limiting information in response headers:
```http
RateLimit-Limit: 6
RateLimit-Remaining: 5
RateLimit-Reset: 45
X-RateLimit-Limit-Minute: 6
X-RateLimit-Remaining-Minute: 5
Retry-After: 45
```
### Rate Limit Exceeded (429)
```json
{
"message": "API rate limit exceeded",
"request_id": "70257e0476dc396a11875532a45ce037"
}
```
When rate limit is exceeded, wait for the time specified in `Retry-After` header before making the next request.
## Balance Calculation Details
### Total Balance TRX Includes:
The `stats.balance` field returns **Total Balance TRX** which is calculated as:
```
Total Balance TRX = Deposit Wallet Balance + Pending Payouts - Pending Withdrawals
```
**Components:**
* **Deposit Wallet Balance**: TRX balance in user's deposit address
* **Pending Payouts**: TRX earnings from Robot and Sub-users awaiting crediting
* **Pending Withdrawals**: TRX amounts in pending withdrawal requests
### Important Notes:
::: warning Important
* Robot & Sub-users payout TRX are credited to deposit address **2 times per day**
* Before crediting, Robot & Sub-users payout TRX **cannot be used** for energy purchases
* To withdraw Robot & Sub-users payout TRX/USDT, activate the checkbox in withdrawal form on the website
:::
## Notes
* No request body required - this is a GET request
* User information is determined from the provided API key
* All TRX values are in decimal format
* Energy values are in standard TRON energy units
* Timestamp is in server time (UTC)
* **Rate limiting**: Enforced per IP address with multiple time windows
* **Error code 429**: Returned when rate limits are exceeded
---
---
url: https://doc.netts.io/api/v2/endpoints/withdraw.md
---
# POST /apiv2/withdraw
Withdraw **TRX** from your Netts balance to any TRON address. The request returns an **order
number immediately**; the actual on-chain payout is performed asynchronously by the backend
(within ~5 minutes). Track the result by **polling the status endpoint** or by configuring a
**webhook**.
> ℹ️ **How it works.** Placing a withdrawal **reserves the amount from your balance right away**
> (balance is debited the moment the order is accepted). A backend daemon then sends the TRX and
> marks the order `completed` or `failed`. There is **no synchronous on-chain result** in the
> initial response — you always get a `pending` acknowledgement first.
## Endpoint URL
```
POST https://netts.io/apiv2/withdraw
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| Content-Type | Yes | application/json |
| X-API-KEY | Yes | Your API key from the Netts dashboard |
| X-Real-IP | Yes | IP address from your whitelist |
| X-Idempotency-Key | No | Optional client-generated key (base64) to safely retry without a double withdrawal. If omitted, the server derives one automatically. This value **becomes your `orderId`**. |
## Request Body
```json
{
"amount": 15,
"address": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
```
### Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| amount | number | Yes | **Gross** amount in TRX (minimum **3**). The fee is deducted from this amount — the recipient gets `amount − fee` (`net`). |
| address | string | Yes | Destination TRON address (`T…`, 34 chars, base58). |
| sub\_and\_robot\_out | boolean | No | Robot/sub payout mode: applies the **2 TRX** fee instead of **1 TRX**. Default `false`. |
> **Fee.** A flat fee is withheld from the gross `amount`: **1 TRX** normally, or **2 TRX** when
> `sub_and_robot_out = true`. The order is rejected if `amount − fee ≤ 0`.
## Example Requests
> The examples below also **build and send the `X-Idempotency-Key`** so an accidental repeat
> does not create a second withdrawal. See [Idempotency](#idempotency) for the full rules.
### cURL
```bash
API_KEY="your_api_key"
ADDR="TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
AMOUNT=15
NONCE=$(( $(date +%s) / 2 )) # stable for retries within a 2s window; or your own order UUID
# X-Idempotency-Key = base64url( HMAC-SHA256( API_KEY, "addr:amount:nonce" ) )
IDEMP=$(printf '%s' "${ADDR}:${AMOUNT}:${NONCE}" \
| openssl dgst -sha256 -hmac "$API_KEY" -binary | basenc --base64url | tr -d '=')
curl -X POST https://netts.io/apiv2/withdraw \
-H "Content-Type: application/json" \
-H "X-API-KEY: $API_KEY" \
-H "X-Real-IP: your_whitelisted_ip" \
-H "X-Idempotency-Key: $IDEMP" \
-d "{\"amount\": $AMOUNT, \"address\": \"$ADDR\"}"
```
### Python
```python
import time, hmac, hashlib, base64, requests
API_KEY = "your_api_key"
url = "https://netts.io/apiv2/withdraw"
payload = {"amount": 15, "address": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}
# X-Idempotency-Key = base64url( HMAC-SHA256( API_KEY, "addr:amount:nonce" ) ), padding stripped.
# Generate ONCE per order and resend the same value on every retry.
nonce = str(int(time.time() // 2)) # 2s bucket; or your own order UUID
message = f"{payload['address']}:{payload['amount']}:{nonce}"
idem_key = base64.urlsafe_b64encode(
hmac.new(API_KEY.encode(), message.encode(), hashlib.sha256).digest()
).decode().rstrip("=")
headers = {
"Content-Type": "application/json",
"X-API-KEY": API_KEY,
"X-Real-IP": "your_whitelisted_ip",
"X-Idempotency-Key": idem_key,
}
resp = requests.post(url, headers=headers, json=payload)
detail = resp.json().get("detail", {})
if resp.status_code == 202 and detail.get("status") == "pending":
d = detail["data"]
print(f"Order ID: {d['orderId']}") # use it for the status endpoint / webhook
print(f"Net to recipient: {d['net']} TRX (fee {d['fee']})")
else:
print(f"Code {detail.get('code')}: {detail.get('msg', detail)}")
```
## Response
### Accepted — withdrawal queued (202 Accepted)
The amount is reserved from your balance and the payout is scheduled. Poll the status endpoint
(or wait for the webhook) until it becomes `completed` / `failed`.
```json
{
"detail": {
"code": 10000,
"status": "pending",
"msg": "Withdrawal request accepted, processing within 5 minutes.",
"data": {
"orderId": "EXAMPLEorderId0000000000000000000000000000Aa",
"amount": 15.0,
"fee": 1.0,
"net": 14.0,
"address": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| detail.code | integer | `10000` accepted |
| detail.status | string | `pending` |
| detail.data.orderId | string | Order number — a 43-char URL-safe string. Use it for the status endpoint and it identifies the order in webhook payloads. |
| detail.data.amount | number | Gross amount requested (TRX) |
| detail.data.fee | number | Fee withheld (1 or 2 TRX) |
| detail.data.net | number | Amount the recipient receives (`amount − fee`) |
| detail.data.address | string | Destination address |
## Status Endpoint
```
GET https://netts.io/apiv2/withdraw/status/{orderId}
```
Headers: `X-API-KEY` + `X-Real-IP` (the order must belong to the authenticated user).
`orderId` is URL-safe — pass it **as-is**, no URL-encoding needed.
| Order state | HTTP | code | status |
|---|---|---|---|
| Completed (TRX sent) | 200 | 10000 | `completed` (with `processed_at`) |
| Queued / sending | 200 | 10001 | `pending` |
| Failed | 200 | 5003 | `failed` (with `error_message`) |
| Not found / not yours | 404 | -1 | — |
```json
{
"detail": {
"code": 10000,
"status": "completed",
"data": {
"orderId": "EXAMPLEorderId0000000000000000000000000000Aa",
"amount": 15.0, "fee": 1.0, "net": 14.0,
"address": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"processed_at": "2026-01-01 00:00:00+00:00"
}
}
}
```
## Sub-user accounts
**Sub-user withdrawals work exactly the same as for regular users — just with the sub-user's own
API key.** A sub-user calls this same `POST /apiv2/withdraw` endpoint, authenticated with its own
key; the withdrawal is debited from **that sub-user's own balance** and sent to whatever `address`
the request specifies. Same minimum, same fee (1 TRX), same flow. There is **no separate sub-user
endpoint** — each account, parent or sub-user, only ever withdraws its own balance with its own key.
## Webhooks
Instead of polling, configure a webhook **once** and Netts will POST a signed notification when
each of your withdrawals reaches a terminal state (`completed` / `failed`). The webhook is stored
**per user** and applies to that account's withdrawals. If no webhook is configured,
just poll the status endpoint.
### Configure / view / remove
```
POST https://netts.io/apiv2/withdraw/webhook # create or update
GET https://netts.io/apiv2/withdraw/webhook # view current config (secret is never returned)
DELETE https://netts.io/apiv2/withdraw/webhook # unsubscribe
```
Headers: `X-API-KEY` + `X-Real-IP`.
```json
// POST body
{
"callback_url": "https://your-server.example/netts/withdraw-hook",
"secret": "your_shared_secret_min_8_chars",
"enabled": true
}
```
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| callback\_url | string | Yes | `http(s)` URL (≤ 2048 chars) that receives the POST |
| secret | string | Yes | Shared secret (8…256 chars) used to sign each payload |
| enabled | boolean | No | Turn delivery on/off without deleting the config. Default `true` |
`GET` returns `{ callback_url, enabled, secret_set, updated_at }` — the secret itself is **never**
echoed back.
### Delivery payload
Netts sends a `POST` to your `callback_url` with header
**`X-Netts-Signature: base64( HMAC-SHA256( secret, raw_body ) )`** and this JSON body:
```json
{
"orderId": "EXAMPLEorderId0000000000000000000000000000Aa",
"status": "completed",
"amount": 15.0,
"fee": 1.0,
"net": 14.0,
"address": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"processed_at": "2026-01-01 00:00:00+00:00",
"error_message": null
}
```
* `status` is `completed` or `failed` (on `failed`, `error_message` is populated).
### Verifying the signature
The signature is computed over the **canonical JSON** of the body: keys **sorted**, no spaces
(`separators=(",", ":")`). Recompute it the same way and compare.
```python
import hmac, hashlib, base64, json
def verify(raw_body: bytes, signature_header: str, secret: str) -> bool:
expected = base64.b64encode(
hmac.new(secret.encode(), raw_body, hashlib.sha256).digest()
).decode()
return hmac.compare_digest(expected, signature_header)
# Flask example: verify against the EXACT bytes received, then parse.
# if verify(request.get_data(), request.headers["X-Netts-Signature"], SECRET): ...
```
> Always verify against the **raw received bytes**. If you re-serialize the parsed JSON, reproduce
> the canonical form: `json.dumps(payload, ensure_ascii=False, separators=(",",":"), sort_keys=True)`.
### Delivery guarantees
* Respond with **HTTP 2xx** to acknowledge. Any other response (or a timeout) is treated as a
failed attempt.
* Up to **3 attempts** per order, within a **21-minute** window from the moment the order was
created (retry backoff ≈ 5 minutes). After that, delivery is given up — fall back to the status
endpoint.
* Deliveries are **de-duplicated**: each order is delivered at most once successfully.
* Make your handler **idempotent** on `orderId`.
## Error Responses
### Authentication Error (401)
```json
{ "detail": { "code": -1, "msg": "Invalid API key or IP not in whitelist" } }
```
### Insufficient Balance (403)
```json
{ "detail": { "code": 1004, "status": "failed", "msg": "Insufficient balance: 2.0 < 15 TRX" } }
```
### Pending Withdrawal Exists (409)
You may have **only one pending withdrawal at a time** on your own balance. Wait until the current
one is processed.
```json
{ "detail": { "code": 4090, "status": "failed", "msg": "You have a pending withdrawal. Wait until it is processed." } }
```
### Validation Error (400)
```json
{ "detail": { "code": 5004, "status": "failed", "msg": "Minimum withdrawal is 3 TRX" } }
```
## Error Code Reference
| Code | Description | HTTP Status |
|------|-------------|-------------|
| `10000` | Accepted (withdrawal queued) / Completed (status endpoint) | 202 / 200 |
| `10001` | Pending — queued or sending (status endpoint) | 200 |
| `208` | Duplicate of an already-accepted request — cached response | 208 |
| `-` | Same request still being processed (do not retry yet) | 409 |
| `4090` | You already have a pending withdrawal | 409 |
| `-1` | Invalid API key / IP not in whitelist, or order not found | 401 / 404 |
| `1004` | Insufficient balance | 403 |
| `5004` | Validation error (amount < 3, fee ≥ amount, bad address, bad idempotency key) | 400 |
| `5003` | Withdrawal failed / service unavailable | 200 (status) / 503 |
| `5000` | Internal server error | 500 |
## Rate Limits
Limited **per API key** (header `X-API-KEY`):
| Period | Limit |
|--------|-------|
| **1 second** | 5 requests |
| **1 minute** | 150 requests |
### Rate Limit Exceeded (429)
```json
{ "message": "API rate limit exceeded" }
```
## Idempotency
Send the optional `X-Idempotency-Key` header so an accidental repeat does **not** create a second
withdrawal — the original response is returned with HTTP **208**. If you do not send the header,
the server derives a key automatically from your request parameters within a short time window.
**The key is also your `orderId`.**
### How to form the key
The key is **`base64url( HMAC-SHA256( secret, message ) )` with `=` padding removed** — a 43-char
URL-safe string, where:
* **secret** = your API key (`X-API-KEY`);
* **message** = the fields joined with `:` — `address:amount:nonce`.
`nonce` is any value that is **stable across retries of the same logical order but different
between distinct orders** — e.g. a UUID you keep for that order, or a coarse timestamp bucket.
**Generate the key once per order and resend the exact same value on every retry.**
```python
import hmac, hashlib, base64, time
def make_idempotency_key(api_key, address, amount, nonce=None):
if nonce is None:
nonce = str(int(time.time() // 2)) # 2-second bucket; or your own order UUID
message = f"{address}:{amount}:{nonce}"
digest = hmac.new(api_key.encode(), message.encode(), hashlib.sha256).digest()
return base64.urlsafe_b64encode(digest).decode().rstrip("=") # 43-char URL-safe
```
> **Validation.** A supplied `X-Idempotency-Key` must be **16–64 characters** from the charset
> `A–Z a–z 0–9 + / = _ -`. A malformed or over-long key is rejected with **HTTP 400** (`code 5004`).
| Status Code | Meaning |
|---|---|
| 202 | Accepted (first request) |
| 208 | Already accepted — cached response returned (no second withdrawal) |
| 409 | The same request is currently being processed — wait, do not retry yet |
> **Retrying after a failure.** Only **accepted** results are cached. If the previous attempt
> **failed** (e.g. insufficient balance, validation), you may safely **retry with the same key** —
> the request is attempted again rather than returning the old error. While an attempt is still in
> progress you get `409`; wait and retry.
## Notes
* **Asynchronous payout.** The response is always a `pending` acknowledgement; the TRX is sent by a
backend daemon, typically within ~5 minutes. Use the status endpoint or a webhook for the result.
* **Balance is reserved immediately** when the order is accepted (not when the TRX is finally sent).
* **Minimum**: 3 TRX. **Fee**: 1 TRX (or 2 TRX with `sub_and_robot_out`), withheld from the gross
`amount`; the recipient receives `net = amount − fee`.
* **One pending at a time** on your own balance (`code 4090`).
* **Sub-users withdraw exactly like regular users** — same `POST /apiv2/withdraw` endpoint, same
rules, but authenticated **with the sub-user's own API key**. A sub-user withdraws **its own
balance** to any `address` it specifies. There is no separate sub-user endpoint.
* **orderId** is a 43-char URL-safe string; pass it as-is in the status URL (no encoding required).
* **Webhooks**: per-user, signed with `X-Netts-Signature`; up to 3 attempts within a 21-minute
window. Configure via `POST /apiv2/withdraw/webhook`.
---
---
url: https://doc.netts.io/api/v2/endpoints/prices.md
---
# GET /apiv2/prices
::: warning Deprecated
This endpoint is deprecated and will be removed in a future release. Please migrate to the new [`GET /apiv2/pricing`](/api/v2/endpoints/pricing) endpoint which provides dynamic periods, service filtering, duration discounts, and a unified response format.
:::
Get current energy rental prices for different time periods throughout the day.
::: warning Price may change during fulfillment
The price returned by this endpoint may change while an order is being processed. An energy provider can decline a delegation request, in which case Netts automatically routes the order to the next available provider. Netts is committed not only to offering the most competitive price, but also to ensuring a reliable energy supply — therefore an order may be fulfilled at a higher price than quoted. **This applies only to orders of 300,000 energy units and above.**
:::
## Endpoint URL
```
GET https://netts.io/apiv2/prices
```
## Request Headers
| Header | Required | Description | Values |
|--------|----------|-------------|--------|
| X-API-KEY | Yes | Your API key | string |
| X-Real-IP | Yes | IP address from whitelist | IP address |
| X-Format | No | Response format (default: extended JSON) | `now`, `compact`, `short`, `short1h`, `count` |
## Request Parameters
No parameters required - returns all current pricing information.
## Example Requests
### cURL
```bash
curl -X GET https://netts.io/apiv2/prices \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip"
```
### Python
```python
import requests
url = "https://netts.io/apiv2/prices"
headers = {
"X-API-KEY": "your_api_key",
"X-Real-IP": "your_whitelisted_ip"
}
response = requests.get(url, headers=headers)
data = response.json()
if response.status_code == 200:
print(f"Status: {data.get('status')}")
print(f"Current UTC time: {data.get('current_utc_time')}")
print(f"Active period: {data.get('active_period')}")
print(f"Host price: {data.get('host_price')} TRX")
print("\nPrice periods:")
for period in data.get('periods', []):
is_active = period.get('is_active', False)
active_marker = " *ACTIVE*" if is_active else ""
print(f"\n{period.get('label')}{active_marker}:")
print(f" Time: {period.get('period')}")
prices = period.get('prices', {})
print(f" < 200k energy: {prices.get('less_than_200k', {}).get('price_sun')} sun")
print(f" = 131k energy: {prices.get('equal_131k', {}).get('price_sun')} sun")
print(f" > 200k energy: {prices.get('more_than_200k', {}).get('price_sun')} sun")
else:
print(f"Error: {data.get('message', 'Unknown error')}")
```
## Compact Response Format
**New in v2.1**: Use the `X-Format` header to get a compact text response instead of the full JSON structure.
### When to Use
* Integration with monitoring systems
* Simple price displays
* Automated price tracking
* Minimal bandwidth requirements
### Example Request
```bash
curl -X GET https://netts.io/apiv2/prices \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip" \
-H "X-Format: now"
```
### Compact Response Example
```text
Daytime Hours (11:00-21:00 UTC): price=27 sun, 65k=1.755 TRX (0.52$), 131k=3.537 TRX (1.05$), 1m=27.000 TRX (7.99$)
```
### Response Format Explanation
The compact format provides:
| Component | Description | Example |
|-----------|-------------|---------|
| **Period label** | Active pricing period | `Daytime Hours (11:00-21:00 UTC)` |
| **price=X sun** | Price per energy unit in SUN | `price=27 sun` |
| **65k=X.XXX TRX (X.XX$)** | Cost for 65,000 energy units | `65k=1.755 TRX (0.52$)` |
| **131k=X.XXX TRX (X.XX$)** | Cost for 131,000 energy units | `131k=3.537 TRX (1.05$)` |
| **1m=X.XXX TRX (X.XX$)** | Cost for 1,000,000 energy units | `1m=27.000 TRX (7.99$)` |
### Calculation Formula
```
TRX cost = (price_sun / 1,000,000) × energy_amount
USD cost = TRX_cost × current_TRX_USD_rate
```
**Note**: TRX/USD exchange rate is retrieved from the `chain_param` table and cached for 30 minutes.
### Content Type
* **Extended format**: `application/json`
* **Compact format**: `text/plain`
### Python Example
```python
import requests
url = "https://netts.io/apiv2/prices"
headers = {
"X-API-KEY": "your_api_key",
"X-Real-IP": "your_whitelisted_ip",
"X-Format": "now" # Request compact format
}
response = requests.get(url, headers=headers)
if response.status_code == 200:
print("Compact price data:")
print(response.text)
# Output: Daytime Hours (11:00-21:00 UTC): price=27 sun, 65k=1.755 TRX (0.52$), ...
else:
print(f"Error: {response.status_code}")
```
## Ultra-Compact Response Format (short1h)
**New in v2.2**: Use the `X-Format: short1h` header to get an ultra-compact text response with only energy calculations, without the period label and price per unit.
### When to Use
* Monitoring dashboards with limited space
* Mobile applications
* Minimal bandwidth requirements
* Focus on final costs only
### Example Request
```bash
curl -X GET https://netts.io/apiv2/prices \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip" \
-H "X-Format: short1h"
```
### Ultra-Compact Response Example
```text
65k=1.755 TRX (0.52$), 131k=3.537 TRX (1.05$), 1m=27.000 TRX (7.99$)
```
### Response Format Explanation
The ultra-compact format provides only the essential cost calculations:
| Component | Description | Example |
|-----------|-------------|---------|
| **65k=X.XXX TRX (X.XX$)** | Cost for 65,000 energy units | `65k=1.755 TRX (0.52$)` |
| **131k=X.XXX TRX (X.XX$)** | Cost for 131,000 energy units | `131k=3.537 TRX (1.05$)` |
| **1m=X.XXX TRX (X.XX$)** | Cost for 1,000,000 energy units | `1m=27.000 TRX (7.99$)` |
**Note**: This format excludes the period label and price per energy unit for maximum compactness.
### Content Type
* **Ultra-compact format**: `text/plain`
### Python Example
```python
import requests
url = "https://netts.io/apiv2/prices"
headers = {
"X-API-KEY": "your_api_key",
"X-Real-IP": "your_whitelisted_ip",
"X-Format": "short1h" # Request ultra-compact format
}
response = requests.get(url, headers=headers)
if response.status_code == 200:
print("Ultra-compact price data:")
print(response.text)
# Output: 65k=1.755 TRX (0.52$), 131k=3.537 TRX (1.05$), 1m=27.000 TRX (7.99$)
else:
print(f"Error: {response.status_code}")
```
## Count Response Format (count)
**New in v2.3**: Use the `X-Format: count` header to get bulk order pricing calculations showing costs for 1, 2, 3, 5, 10, and 20 orders.
### When to Use
* Bulk order pricing displays
* Volume discount calculators
* Price comparison tools
* Order quantity planning
* Cost estimation for multiple orders
### Example Request
```bash
curl -X GET https://netts.io/apiv2/prices \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip" \
-H "X-Format: count"
```
### Count Response Example
```text
1-1.690 TRX (0.50$), 2-3.380 TRX (1.00$), 3-5.070 TRX (1.50$), 5-8.450 TRX (2.50$), 10-16.900 TRX (5.00$), 20-33.800 TRX (10.00$)
```
### Response Format Explanation
The count format provides calculated pricing for different order quantities:
| Component | Description | Example |
|-----------|-------------|---------|
| **1-X.XXX TRX (X.XX$)** | Cost for 1 order (65,000 energy units) | `1-1.690 TRX (0.50$)` |
| **2-X.XXX TRX (X.XX$)** | Cost for 2 orders (131,000 energy units) | `2-3.380 TRX (1.00$)` |
| **3-X.XXX TRX (X.XX$)** | Cost for 3 orders (3 × 65,000 energy) | `3-5.070 TRX (1.50$)` |
| **5-X.XXX TRX (X.XX$)** | Cost for 5 orders (5 × 65,000 energy) | `5-8.450 TRX (2.50$)` |
| **10-X.XXX TRX (X.XX$)** | Cost for 10 orders (10 × 65,000 energy) | `10-16.900 TRX (5.00$)` |
| **20-X.XXX TRX (X.XX$)** | Cost for 20 orders (20 × 65,000 energy) | `20-33.800 TRX (10.00$)` |
### Calculation Formula
```
1 order: TRX cost = (price_sun_65k / 1,000,000) × 65,000
2 orders: TRX cost = (price_sun_131k / 1,000,000) × 131,000
3+ orders: TRX cost = (price_sun_65k / 1,000,000) × 65,000 × quantity
USD cost = TRX_cost × current_TRX_USD_rate
```
**Note**: TRX/USD exchange rate is retrieved from the `chain_param` table and cached for 30 minutes.
### Content Type
* **Count format**: `text/plain`
### Python Example
```python
import requests
url = "https://netts.io/apiv2/prices"
headers = {
"X-API-KEY": "your_api_key",
"X-Real-IP": "your_whitelisted_ip",
"X-Format": "count" # Request count format
}
response = requests.get(url, headers=headers)
if response.status_code == 200:
print("Bulk order pricing:")
print(response.text)
# Output: 1-1.690 TRX (0.50$), 2-3.380 TRX (1.00$), 3-5.070 TRX (1.50$), ...
else:
print(f"Error: {response.status_code}")
```
## Response
### Success Response (200 OK)
```json
{
"status": "success",
"current_utc_time": "2025-09-02 06:50:39",
"current_utc_hour": 6,
"active_period": "05:00-07:00",
"last_update": "2025-09-02 08:05:03",
"host_price": 2.989,
"periods": [
{
"label": "Early Morning Hours (05:00-07:00 UTC)",
"period": "05:00-07:00",
"is_active": true,
"prices": {
"less_than_200k": {
"price_sun": 17
},
"equal_131k": {
"price_sun": 17
},
"more_than_200k": {
"price_sun": 17
}
}
},
{
"label": "Morning Hours (07:00-11:00 UTC)",
"period": "07:00-11:00",
"is_active": false,
"prices": {
"less_than_200k": {
"price_sun": 17
},
"equal_131k": {
"price_sun": 17
},
"more_than_200k": {
"price_sun": 17
}
}
}
]
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| status | string | Always "success" for successful requests |
| current\_utc\_time | string | Current server time in UTC |
| current\_utc\_hour | integer | Current UTC hour (0-23) |
| active\_period | string | Currently active pricing period |
| last\_update | string | Last time prices were updated |
| host\_price | number | Current host price in TRX |
| periods | array | Array of all pricing periods |
| periods\[].label | string | Human-readable period name |
| periods\[].period | string | Time range (HH:MM-HH:MM) |
| periods\[].is\_active | boolean | Whether this period is currently active |
| periods\[].prices.less\_than\_200k.price\_sun | integer | Price in SUN for energy < 200,000 units |
| periods\[].prices.equal\_131k.price\_sun | integer | Price in SUN for exactly 131,000 units |
| periods\[].prices.more\_than\_200k.price\_sun | integer | Price in SUN for energy > 200,000 units |
### Energy Amount Categories
| Category | Description | Energy Range |
|----------|-------------|--------------|
| **less\_than\_200k** | Small orders | < 200,000 energy units |
| **equal\_131k** | Standard orders | Exactly 131,000 energy units |
| **more\_than\_200k** | Large orders | > 200,000 energy units |
### Time Periods
The API returns prices for 5 different time periods:
| Period | Time Range (UTC) | Description |
|--------|------------------|-------------|
| **Early Morning** | 05:00-07:00 | Lower demand period |
| **Morning** | 07:00-11:00 | Business hours start |
| **Daytime** | 11:00-21:00 | Peak business hours |
| **Evening** | 21:00-23:00 | Evening activity |
| **Night** | 23:00-05:00 | Lowest demand period |
## Rate Limits
The following rate limits apply to this endpoint (per IP address):
| Period | Limit | Description |
|--------|-------|-------------|
| **1 minute** | 1 request | Maximum 1 request per minute |
| **1 hour** | 60 requests | Maximum 60 requests per hour |
### Rate Limit Headers
```http
RateLimit-Limit: 1
RateLimit-Remaining: 0
RateLimit-Reset: 21
X-RateLimit-Limit-Minute: 1
X-RateLimit-Remaining-Minute: 0
X-RateLimit-Limit-Hour: 60
X-RateLimit-Remaining-Hour: 59
Retry-After: 21
```
### Rate Limit Exceeded (429)
```json
{
"message": "API rate limit exceeded"
}
```
## Error Responses
### Authentication Error (401)
```json
{
"status": "error",
"code": 401,
"message": "Invalid API key or IP not in whitelist"
}
```
### Internal Server Error (500)
```json
{
"status": "error",
"message": "Internal server error"
}
```
## Notes
* No request body required - this is a GET request
* All prices are in SUN (1 TRX = 1,000,000 SUN)
* Prices vary by energy amount and time of day (UTC)
* **Active period**: Changes throughout the day based on demand
* **Rate limiting**: Strict limits due to database-intensive operations
* **Price updates**: Prices are refreshed from database periodically
* **Time zones**: All times are in UTC
---
---
url: https://doc.netts.io/api/v2/endpoints/pricing.md
---
# GET /apiv2/pricing
Universal pricing endpoint that returns all service prices in a single response with dynamic time periods.
::: warning Price may change during fulfillment
The price returned by this endpoint may change while an order is being processed. An energy provider can decline a delegation request, in which case Netts automatically routes the order to the next available provider. Netts is committed not only to offering the most competitive price, but also to ensuring a reliable energy supply — therefore an order may be fulfilled at a higher price than quoted. **This applies only to orders of 300,000 energy units and above.**
:::
::: tip Recommended
This is the recommended pricing endpoint. It replaces the legacy [`/apiv2/prices`](/api/v2/endpoints/prices) endpoint which will be deprecated.
:::
## Endpoint URL
```
GET https://netts.io/apiv2/pricing
```
## Request Headers
| Header | Required | Description | Values |
|--------|----------|-------------|--------|
| X-API-KEY | Yes | Your API key | string |
| X-Real-IP | Yes | IP address from whitelist | IP address |
| X-Format | No | Response format (default: full JSON) | `now`, `compact`, `short`, `short1h`, `count` |
## Query Parameters
| Parameter | Type | Default | Description |
|-----------|------|---------|-------------|
| services | string | all | Comma-separated filter of services to include |
### Available Services
| Service | Description |
|---------|-------------|
| `energy_1h` | 1-hour energy delegation prices |
| `energy_5m` | 5-minute energy delegation prices |
| `host` | Host energy delegation rates |
| `aml` | AML address check prices |
| `bandwidth` | Bandwidth rental prices — **opt-in**: returned only when explicitly requested via `?services=bandwidth` (not part of the default response) |
## Example Requests
### cURL — Full Response
```bash
curl -X GET https://netts.io/apiv2/pricing \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip"
```
### cURL — Filter by Services
```bash
# Only energy 1h prices
curl -X GET "https://netts.io/apiv2/pricing?services=energy_1h" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip"
# Energy 1h + AML
curl -X GET "https://netts.io/apiv2/pricing?services=energy_1h,aml" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip"
# Host prices only
curl -X GET "https://netts.io/apiv2/pricing?services=host" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip"
# Bandwidth rental prices (opt-in — must be requested explicitly)
curl -X GET "https://netts.io/apiv2/pricing?services=bandwidth" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip"
```
### Python
```python
import requests
url = "https://netts.io/apiv2/pricing"
headers = {
"X-API-KEY": "your_api_key",
"X-Real-IP": "your_whitelisted_ip"
}
response = requests.get(url, headers=headers)
data = response.json()
if data.get("success"):
print(f"API version: {data['version']}")
print(f"TRX/USD rate: {data['data']['trx_rate_usd']}")
services = data["data"]["services"]
for svc_name, svc_data in services.items():
pricing_type = svc_data.get("pricing_type")
print(f"\n--- {svc_name} ({pricing_type}) ---")
if pricing_type == "periodic":
for period in svc_data["periods"]:
marker = " <-- current" if period["is_current"] else ""
print(f" {period['label']}: {period['price']} {svc_data['unit']}{marker}")
elif pricing_type == "flat_rates":
for rate, price in svc_data["rates"].items():
print(f" {rate}: {price} {svc_data['unit']}")
elif pricing_type == "provider_based":
for name, info in svc_data["providers"].items():
status = "available" if info["available"] else "unavailable"
print(f" {name}: {info['price']} {svc_data['unit']} - {status}")
```
### Python — Filter Services
```python
params = {"services": "energy_1h,aml"}
response = requests.get(url, headers=headers, params=params)
```
## Response Structure
### Top-Level Fields
| Field | Type | Description |
|-------|------|-------------|
| success | boolean | `true` for successful requests |
| version | string | API version (e.g. `"2.1"`) |
| timestamp | string | Server time in ISO 8601 UTC |
| data | object | Response payload |
### Data Fields
| Field | Type | Description |
|-------|------|-------------|
| data.trx\_rate\_usd | number | Current TRX/USD exchange rate |
| data.units\_meta | object | Machine-readable unit conversion info |
| data.services | object | Map of requested services with pricing data |
### Units Meta
Allows clients to programmatically convert between units:
```json
{
"units_meta": {
"sun": {"base": "trx", "multiplier": 1000000},
"trx": {"base": "trx", "multiplier": 1},
"usdt": {"base": "usdt", "multiplier": 1}
}
}
```
To convert from SUN to TRX: `trx_price = sun_price / units_meta.sun.multiplier`
### Service Common Fields
Every service includes these fields:
| Field | Type | Description |
|-------|------|-------------|
| unit | string | Price unit (`sun`, `trx`, `usdt`) |
| pricing\_type | string | How to parse this service (see below) |
| description | string | Human-readable description |
| cache\_ttl | integer | How often this data refreshes (seconds) |
### Pricing Types
The `pricing_type` field tells clients how to parse each service:
| Type | Structure | Used by |
|------|-----------|---------|
| `periodic` | `periods[]` array with time-based prices | `energy_1h`, `energy_5m` |
| `flat_rates` | `rates{}` object with named rate keys | `host` |
| `provider_based` | `providers{}` object with provider data | `aml` |
| `tiered_by_amount_and_period` | `tiers[]` by amount range, each with `periods[]` | `bandwidth` |
***
## Service: energy\_1h / energy\_5m
**pricing\_type:** `periodic`
| Field | Type | Description |
|-------|------|-------------|
| current\_period | string | Slug of the currently active period |
| periods\[] | array | All pricing periods (dynamic, loaded from DB) |
| periods\[].id | string | Unique period identifier (slug) |
| periods\[].label | string | Human-readable period name |
| periods\[].start | string | Period start time (HH:MM UTC) |
| periods\[].end | string | Period end time (HH:MM UTC) |
| periods\[].is\_current | boolean | Whether this period is currently active |
| periods\[].price | integer | Price per energy unit in SUN |
| periods\[].tiers | array|null | Volume-based pricing tiers (see [Tiers](#tiers)) |
::: info Dynamic periods
The number of periods, their time ranges, labels, and prices are all dynamic and managed server-side. Do not hardcode period IDs or counts. Always iterate over the `periods` array.
:::
***
## Service: host
**pricing\_type:** `flat_rates`
| Field | Type | Description |
|-------|------|-------------|
| rates.standard\_65k | number | Standard rate for 65k energy (TRX) |
| rates.standard\_131k\_initial | number | Standard rate for 131k energy, initial activation (TRX) |
| rates.frequent\_65k | number | Frequent rate for 65k energy (TRX) |
| rates.frequent\_131k | number | Frequent rate for 131k energy (TRX) |
***
## Service: aml
**pricing\_type:** `provider_based`
| Field | Type | Description |
|-------|------|-------------|
| providers | object | Map of AML providers (dynamic, may change) |
| providers\[name].price | number | Check price in USDT |
| providers\[name].price\_trx | number | Check price converted to TRX at current rate |
| providers\[name].available | boolean | Whether provider has available quota |
::: info Dynamic providers
AML providers are loaded from the database. New providers may appear or existing ones may become unavailable. Always iterate over the `providers` object.
:::
***
## Service: bandwidth
**pricing\_type:** `tiered_by_amount_and_period`
::: info Opt-in & access
Bandwidth pricing is returned **only** when explicitly requested via `?services=bandwidth` — it is
not part of the default response. The bandwidth rental endpoint itself is available **by request**;
contact support for access. See [Bandwidth rental](/api/v2/endpoints/bandwidth).
:::
Bandwidth rental price depends on the order **amount** (unit tier), the **rental period**
(e.g. `5m` / `1h`), the **time-of-day window** (UTC) and the **day of week**. Base prices are in
**SUN per unit**; on top of the base, fixed **surcharges** (in TRX) may apply — all values are
returned in the response.
The response provides both a **convenience view** (`tiers` — prices for the **current** window/day)
and the **full grid** (`windows` + `schedule` — every window across every weekday).
::: warning Adaptive format — do not hardcode
The pricing grid is fully **data-driven and may change at any time**: the **number** of time
windows, their **labels**, their **start/end** times, the set of **rental periods** (new periods
may be added or removed), the amount **tiers**, the **weekday** breakdown and the **prices**
themselves. Clients must **iterate** over the returned arrays (`windows`, `schedule`, `tiers`,
`periods`) and match by value — never assume a fixed count, fixed labels, fixed times or fixed
period ids. Code written this way keeps working when the schedule changes.
:::
| Field | Type | Description |
|-------|------|-------------|
| unit | string | `sun_per_unit` |
| window | string | **Current** time-of-day window label (UTC) |
| current\_day\_of\_week | integer | Current weekday, ISO `1`=Mon … `7`=Sun (UTC) |
| tiers\[] | array | Amount tiers for the **current** window/day (convenience; same shape as inside `schedule`) |
| windows\[] | array | Directory of all time-of-day windows (may grow/shrink/shift) |
| windows\[].label | string | Window label |
| windows\[].start / .end | string | Window start/end `HH:MM` UTC (a window may cross midnight, i.e. start > end) |
| schedule\[] | array | **Full grid** — one entry per (weekday × window) |
| schedule\[].day\_of\_week | integer | ISO weekday `1`…`7` |
| schedule\[].window | string | Window label (matches a `windows[].label`) |
| schedule\[].period\_start / .period\_end | string | `HH:MM` UTC |
| schedule\[].is\_current | boolean | `true` for the segment active right now |
| schedule\[].tiers\[] | array | Amount tiers for this segment |
| tiers\[].amount\_min | integer | Tier lower bound (inclusive) |
| tiers\[].amount\_max | integer|null | Tier upper bound (exclusive). `null` = unlimited |
| tiers\[].periods\[] | array | Prices per rental period within the tier |
| tiers\[].periods\[].id | string | Rental period id (e.g. `5m`, `1h`) — **may change/extend** |
| tiers\[].periods\[].rental\_seconds | integer | Period length in seconds |
| tiers\[].periods\[].price | integer | Price per bandwidth unit in **SUN** |
| surcharges | object | Fixed additions to the client price (TRX) — see below |
| limits | object | Order limits: `min_units`, `max_units` |
### Surcharges
| Field | Type | Description |
|-------|------|-------------|
| surcharges.small\_order\_threshold\_units | integer | Orders with `amount` **below** this value get the small-order surcharge |
| surcharges.small\_order\_surcharge\_trx | number | Added (TRX) for small delegation orders — compensation for on-chain delegation + reclaim |
| surcharges.trx\_send\_surcharge\_trx | number | Added (TRX) when the order is fulfilled by sending TRX — compensation for the TRX transfer |
### Example Response
```json
{
"bandwidth": {
"unit": "sun_per_unit",
"pricing_type": "tiered_by_amount_and_period",
"description": "Bandwidth delegation rental",
"cache_ttl": 30,
"window": "",
"current_day_of_week": 7,
"tiers": [
{
"amount_min": 400,
"amount_max": 1000,
"periods": [
{"id": "5m", "rental_seconds": 300, "price": ""},
{"id": "1h", "rental_seconds": 3600, "price": ""}
]
},
{"amount_min": 1000, "amount_max": 3000, "periods": ["..."]},
{"amount_min": 3000, "amount_max": null, "periods": ["..."]}
],
"windows": [
{"label": "", "start": "01:00", "end": "09:00"},
{"label": "", "start": "14:00", "end": "00:00"}
],
"schedule": [
{
"day_of_week": 1,
"window": "",
"period_start": "01:00",
"period_end": "09:00",
"is_current": false,
"tiers": [
{"amount_min": 400, "amount_max": 1000, "periods": [
{"id": "5m", "rental_seconds": 300, "price": ""},
{"id": "1h", "rental_seconds": 3600, "price": ""}
]}
]
}
],
"surcharges": {
"small_order_threshold_units": 1000,
"small_order_surcharge_trx": "",
"trx_send_surcharge_trx": ""
},
"limits": {"min_units": 400, "max_units": 5000}
}
}
```
`schedule` contains one entry for **every (weekday × window)** combination — iterate it to render
a full price calendar. Exactly one entry has `is_current: true`.
### Client Logic (compute the order price)
Use `tiers` for "the price right now". To look up a price for another time, pick the matching
`schedule` entry by weekday + the window whose `[period_start, period_end)` contains the time
(remember a window may cross midnight when `start > end`), then use its `tiers`.
```
# price for the current moment:
for tier in bandwidth.tiers:
if tier.amount_min <= amount < (tier.amount_max or infinity):
for p in tier.periods:
if p.id == requested_period: # match by value, not by index
base_trx = (p.price / units_meta.sun.multiplier) * amount
if amount < surcharges.small_order_threshold_units:
base_trx += surcharges.small_order_surcharge_trx # delegation orders
# TRX-send fulfillment branch instead:
# trx_branch_trx = base_trx_for_smallest_tier_shortest_period + surcharges.trx_send_surcharge_trx
# price for an arbitrary weekday/time: same logic, but first select the schedule[] entry
# where day_of_week matches and the time falls in [period_start, period_end).
```
::: info Centralized & dynamic
Bandwidth prices, windows, weekday breakdown and surcharges are managed server-side (DB) and may
change. Always **iterate** `windows`, `schedule`, `tiers` and `periods` from the response and match
by value — do not hardcode counts, labels, times or period ids. SUB-user markups do **not** apply
to bandwidth.
:::
***
## Tiers
Currently `tiers` is `null` for all periods. When volume-based pricing is enabled, the field will contain an array of tier objects:
```json
{
"tiers": [
{
"min_energy": 0,
"max_energy": 64999,
"price": "",
"label": "standard"
},
{
"min_energy": 65000,
"max_energy": 130999,
"price": "",
"label": "65k"
},
{
"min_energy": 131000,
"max_energy": 131000,
"price": "",
"label": "131k"
},
{
"min_energy": 131001,
"max_energy": null,
"price": "",
"label": "bulk"
}
]
}
```
### Tiers Schema
| Field | Type | Description |
|-------|------|-------------|
| min\_energy | integer | Minimum energy amount for this tier (inclusive) |
| max\_energy | integer|null | Maximum energy amount for this tier (inclusive). `null` = unlimited |
| price | integer | Price per energy unit in SUN for this tier |
| label | string | Tier identifier |
### Client Logic
```
if tiers != null:
find the tier where min_energy <= order_amount <= max_energy
use that tier's price
else:
use the flat price field for all order amounts
```
***
## Compact Response Formats
Use the `X-Format` header to get compact text responses. These return the **current active period** price from `energy_1h`.
### X-Format: now / compact / short
```bash
curl -H "X-API-KEY: your_key" -H "X-Format: now" https://netts.io/apiv2/pricing
```
```text
: price= sun, 65k= TRX ($), 131k= TRX ($), 1m= TRX ($)
```
### X-Format: short1h
Same but without period label and per-unit price.
```bash
curl -H "X-API-KEY: your_key" -H "X-Format: short1h" https://netts.io/apiv2/pricing
```
```text
65k= TRX ($), 131k= TRX ($), 1m= TRX ($)
```
### X-Format: count
Bulk order pricing for 1, 2, 3, 5, 10, 20 orders.
```bash
curl -H "X-API-KEY: your_key" -H "X-Format: count" https://netts.io/apiv2/pricing
```
```text
1- TRX ($), 2- TRX ($), ...
```
### Calculation Formula
```
TRX cost = (price_sun / units_meta.sun.multiplier) x energy_amount
USD cost = TRX_cost x trx_rate_usd
```
***
## SUB-User Markup
SUB-users automatically receive prices with their parent's markup applied. The API always returns the final price for the authenticated user — no client-side calculation needed.
## Error Responses
Errors may come from **two layers** with different formats. Your client should handle both.
### Application Errors (from API)
Application-level errors use the standard `success`/`error` format:
#### Invalid Service (400)
```json
{
"success": false,
"error": {
"code": 4002,
"message": "Unknown services: invalid_service"
}
}
```
#### Authentication Error (401)
Returned by the application when API key is missing or IP is not whitelisted:
```json
{
"detail": {
"code": -1,
"msg": "Invalid API key or IP not in whitelist"
}
}
```
::: warning Different format
Authentication errors use FastAPI's native `detail` format, not the `success`/`error` structure. This is because the error is raised before the request reaches application logic.
:::
#### User Not Found (404)
```json
{
"detail": {
"code": -1,
"msg": "User not found"
}
}
```
#### Internal Server Error (500)
```json
{
"success": false,
"error": {
"code": 5001,
"message": "Failed to retrieve pricing data"
}
}
```
### Gateway Errors (from Kong)
These errors are returned by the API gateway **before** the request reaches the application. They use Kong's own format:
#### Rate Limit Exceeded (429)
```json
{
"message": "API rate limit exceeded"
}
```
#### Gateway Timeout (504)
```json
{
"message": "An invalid response was received from the upstream server"
}
```
### Error Code Reference
| Code | Description | HTTP Status | Source |
|------|-------------|-------------|--------|
| `-1` | API key not provided | 401 | App |
| `-1` | Invalid API key or IP not in whitelist | 401 | App |
| `-1` | User not found | 404 | App |
| `4002` | Unknown service in `?services=` parameter | 400 | App |
| `5000` | Internal server error | 500 | App |
| `5001` | Failed to retrieve pricing data | 500 | App |
| `5002` | Price data unavailable for compact format | 500 | App |
| `-` | API rate limit exceeded | 429 | Kong |
### Recommended Client Error Handling
```python
response = requests.get(url, headers=headers)
data = response.json()
if response.status_code == 200 and data.get("success"):
# Success — process data
services = data["data"]["services"]
elif response.status_code == 429:
# Kong rate limit — back off and retry
retry_after = response.headers.get("Retry-After", "60")
time.sleep(int(retry_after))
elif "detail" in data:
# FastAPI auth/validation error
detail = data["detail"]
if isinstance(detail, dict):
print(f"Error {detail.get('code')}: {detail.get('msg')}")
else:
print(f"Error: {detail}")
elif "error" in data:
# Application error
err = data["error"]
print(f"Error {err.get('code')}: {err.get('message')}")
else:
print(f"Unexpected response: {response.status_code}")
```
## Migration from /apiv2/prices
| Aspect | `/apiv2/prices` (old) | `/apiv2/pricing` (new) |
|--------|----------------------|------------------------|
| Periods | 5 fixed | Dynamic from DB |
| Price tiers | 3 hardcoded | Single price + future `tiers` |
| Duration variants | Not available | `energy_5m` |
| AML prices | Separate endpoint | Included via `?services=aml` |
| Host prices | Mixed in response | Separate `host` service |
| Service filtering | Not available | `?services=` parameter |
| Unit conversion | Undocumented | `units_meta` in response |
| Cache info | Undocumented | `cache_ttl` per service |
| Response format | `{"status": "success", ...}` | `{"success": true, "version": "2.1", "data": {...}}` |
## Rate Limits
Same rate limits as `/apiv2/prices` apply (configured in Kong gateway).
## Notes
* All energy prices are in SUN — use `units_meta` for conversion
* Host prices are in TRX
* AML prices are in USDT with TRX conversion included
* All times are in UTC
* Use `cache_ttl` per service to know how often data refreshes
* Use `pricing_type` to determine how to parse each service
* Periods, providers, rates, and all values are dynamic — do not hardcode them
* Bandwidth pricing is **opt-in** (`?services=bandwidth`), uses `tiered_by_amount_and_period` with `surcharges`, and is not subject to SUB-user markup
---
---
url: https://doc.netts.io/api/v2/endpoints/order-check.md
---
# GET /apiv2/order\_check
Retrieve detailed information about a specific 1-hour energy order, including cost breakdown, activation details, and subuser markup information.
## Endpoint URL
```
GET https://netts.io/apiv2/order_check
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| X-API-KEY | Yes | Your API key from Netts dashboard |
## Query Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| order\_id | string | Yes | Order ID in format `1H{hash}` (e.g., `1Ha1b2c3d4e5`) |
## Example Requests
### cURL
```bash
curl -X GET "https://netts.io/apiv2/order_check?order_id=1Ha1b2c3d4e5" \
-H "X-API-KEY: your_api_key"
```
### Python
```python
import requests
url = "https://netts.io/apiv2/order_check"
headers = {
"X-API-KEY": "your_api_key"
}
params = {
"order_id": "1Ha1b2c3d4e5"
}
response = requests.get(url, headers=headers, params=params)
data = response.json()
if data.get("success"):
order = data.get("order", {})
print(f"Order ID: {order.get('id')}")
print(f"Total Cost: {order.get('cost')} TRX")
print(f"Energy: {order.get('energy')}")
print(f"Rate: {order.get('rate_sun')} sun/energy")
print(f"Target Address: {order.get('target_address')}")
# Check if activation was performed
activation = data.get("activation")
if activation:
print(f"Activation Cost: {activation.get('cost')} TRX")
print(f"Activation Hash: {activation.get('tx_hash')}")
else:
print(f"Error: {data.get('msg')}")
```
### JavaScript (Node.js)
```javascript
const axios = require('axios');
const url = 'https://netts.io/apiv2/order_check';
const headers = {
'X-API-KEY': 'your_api_key'
};
const params = {
order_id: '1Ha1b2c3d4e5'
};
axios.get(url, { headers, params })
.then(response => {
const data = response.data;
if (data.success) {
console.log('Order:', data.order);
console.log('Activation:', data.activation);
} else {
console.log('Error:', data.msg);
}
})
.catch(error => console.error('Request failed:', error));
```
## Response
### Success Response (200 OK)
```json
{
"success": true,
"code": 10000,
"order": {
"id": "1Ha1b2c3d4e5",
"cost": 2.535,
"target_address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"energy": 65000,
"duration": "1 hour",
"tx_hashes": ["a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef12345678"],
"timestamp": "2025-12-03T15:21:34.182127",
"rate_sun": 39.0,
"comments": null
},
"activation": null,
"subuser_payout": null
}
```
### Success Response with Activation (200 OK)
When the target address required activation:
```json
{
"success": true,
"code": 10000,
"order": {
"id": "1Ha1b2c3d4e5",
"cost": 3.635,
"target_address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"energy": 65000,
"duration": "1 hour",
"tx_hashes": ["a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef12345678"],
"timestamp": "2025-12-03T15:21:34.182127",
"rate_sun": 39.0,
"comments": "Includes activation: 1.1 TRX"
},
"activation": {
"cost": 1.1,
"tx_hash": "b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456789a"
},
"subuser_payout": null
}
```
### Success Response with Subuser Payout (200 OK)
For parent users viewing subuser orders:
```json
{
"success": true,
"code": 10000,
"order": {
"id": "1Ha1b2c3d4e5",
"cost": 3.93,
"target_address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"energy": 65000,
"duration": "1 hour",
"tx_hashes": ["c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456789abc"],
"timestamp": "2025-12-03T16:55:16.525118",
"rate_sun": 60.5,
"comments": "Includes activation: 1.1 TRX"
},
"activation": {
"cost": 1.1,
"tx_hash": "b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456789a"
},
"subuser_payout": {
"parent_id": 12,
"gross_cost": 3.93,
"energy_markup": 0.195,
"activation_markup": 0.1,
"total_markup": 0.295,
"net_cost": 3.635,
"subuser_rate_sun": 43.5,
"parent_rate_sun": 39.0
}
}
```
## Response Fields
### Main Response
| Field | Type | Description |
|-------|------|-------------|
| success | boolean | `true` if request was successful |
| code | integer | `10000` for successful requests |
| order | object | Order details |
| activation | object | null | Activation details (if address was activated) |
| subuser\_payout | object | null | Subuser markup details (only for parent users) |
### Order Object
| Field | Type | Description |
|-------|------|-------------|
| id | string | Order ID in format `1H{hash}` |
| cost | number | Total cost paid by user (TRX) |
| target\_address | string | Address that received energy |
| energy | integer | Energy amount delegated |
| duration | string | Delegation duration (always "1 hour") |
| tx\_hashes | array | List of delegation transaction hashes |
| timestamp | string | Order creation time (ISO 8601 format) |
| rate\_sun | number | Energy rate in sun per energy unit |
| comments | string | null | Additional information (e.g., activation notice) |
### Activation Object
| Field | Type | Description |
|-------|------|-------------|
| cost | number | Activation cost (TRX) |
| tx\_hash | string | Activation transaction hash |
### Subuser Payout Object
::: info Parent Users Only
The `subuser_payout` field is only included for parent users viewing their subusers' orders. Subusers (mock users) will not see this field.
:::
| Field | Type | Description |
|-------|------|-------------|
| parent\_id | integer | Parent user ID |
| gross\_cost | number | Total cost paid by subuser (TRX) |
| energy\_markup | number | Energy markup amount (TRX) |
| activation\_markup | number | Activation markup amount (TRX) |
| total\_markup | number | Total markup (energy + activation) |
| net\_cost | number | Cost minus markup (parent's actual cost) |
| subuser\_rate\_sun | number | Rate paid by subuser (sun/energy) |
| parent\_rate\_sun | number | Actual rate without markup (sun/energy) |
## Error Responses
### Missing Order ID (400)
```json
{
"success": false,
"code": -2,
"msg": "order_id parameter required"
}
```
### Authentication Error (401)
```json
{
"success": false,
"code": -1,
"msg": "API key not provided"
}
```
```json
{
"success": false,
"code": -1,
"msg": "Invalid API key or IP not in whitelist"
}
```
### Access Denied (403)
When trying to view an order that belongs to another user:
```json
{
"success": false,
"code": -4,
"msg": "Order does not belong to this user"
}
```
### Order Not Found (404)
```json
{
"success": false,
"code": -3,
"msg": "Order not found"
}
```
### Internal Server Error (500)
```json
{
"success": false,
"msg": "Internal server error"
}
```
## Error Code Reference
| Code | Description | HTTP Status |
|------|-------------|-------------|
| `10000` | Success | 200 |
| `-1` | Authentication failed | 401 |
| `-2` | Missing order\_id parameter | 400 |
| `-3` | Order not found | 404 |
| `-4` | Access denied (not your order) | 403 |
## Rate Limits
The following rate limits apply to this endpoint (per IP address):
| Period | Limit | Description |
|--------|-------|-------------|
| **1 second** | 50 requests | Maximum 50 requests per second |
### Rate Limit Headers
```http
RateLimit-Limit: 50
RateLimit-Remaining: 49
RateLimit-Reset: 1
X-RateLimit-Limit-Second: 50
X-RateLimit-Remaining-Second: 49
```
### Rate Limit Exceeded (429)
```json
{
"message": "API rate limit exceeded"
}
```
## Access Control
### Order Ownership
Users can only view their own orders. The API checks ownership based on:
* **Google users**: Matches `google_user_id` from order with user's Google ID
* **Telegram users**: Matches `tg_user_id` from order with user's Telegram ID
### Parent-Subuser Access
Parent users can view orders created by their subusers. In this case:
* The `subuser_payout` field is included in the response
* Parent can see markup breakdown and their actual cost
### Subuser (Mock) Access
Subusers viewing their own orders will see:
* Their actual cost (including markup) in `order.cost`
* Their rate (including markup) in `order.rate_sun`
* The `subuser_payout` field is **not** included
## Use Cases
### 1. Verify Order Completion
After placing an order with `/apiv2/order1h`, use this endpoint to verify:
* Order was processed successfully
* Energy was delegated to correct address
* Correct amount was charged
### 2. Get Transaction Hash
Retrieve the delegation transaction hash for blockchain verification:
```python
response = requests.get(
"https://netts.io/apiv2/order_check",
headers={"X-API-KEY": "your_api_key"},
params={"order_id": "1Ha1b2c3d4e5"}
)
data = response.json()
if data["success"]:
tx_hashes = data["order"]["tx_hashes"]
if tx_hashes:
print(f"Verify on Tronscan: https://tronscan.org/#/transaction/{tx_hashes[0]}")
```
### 3. Track Subuser Costs (Parent Users)
Parent users can monitor their subusers' orders and markup earnings:
```python
response = requests.get(
"https://netts.io/apiv2/order_check",
headers={"X-API-KEY": "parent_api_key"},
params={"order_id": "1Ha1b2c3d4e5"}
)
data = response.json()
if data["success"] and data.get("subuser_payout"):
payout = data["subuser_payout"]
print(f"Subuser paid: {payout['gross_cost']} TRX")
print(f"Your markup: {payout['total_markup']} TRX")
print(f"Your actual cost: {payout['net_cost']} TRX")
```
## Notes
* Orders can be queried immediately after creation
* Transaction hashes may be empty if the provider doesn't return them
* The `rate_sun` field shows the effective rate per energy unit in sun
* Activation cost is included in total `cost` when applicable
* The `comments` field provides additional context (e.g., activation notice)
* This endpoint only returns 1-hour orders created via `/apiv2/order1h`
---
---
url: https://doc.netts.io/api/v2/endpoints/order1h.md
---
# POST /apiv2/order1h
Create a 1-hour energy rental order through multiple energy providers with automatic failover.
## Endpoint URL
```
POST https://netts.io/apiv2/order1h
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| Content-Type | Yes | application/json |
| X-API-KEY | Yes | Your API key from Netts dashboard |
| X-Real-IP | Yes | IP address from your whitelist |
## Request Body
```json
{
"amount": 131000,
"receiveAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"
}
```
### Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| amount | integer | Yes | Energy amount to rent (minimum: 61000, maximum: 3000000) |
| receiveAddress | string | Yes | TRON address that will receive the energy (TRC-20 format) |
### Provider Selection
The API automatically selects the optimal energy provider based on:
* **Cost efficiency** - Always finds the lowest available price
* **Availability** - Ensures sufficient energy reserves
* **Reliability** - Uses providers with high success rates
* **Speed** - Prioritizes fastest delivery times
## Example Requests
### cURL
```bash
curl -X POST https://netts.io/apiv2/order1h \
-H "Content-Type: application/json" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip" \
-d '{
"amount": 131000,
"receiveAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"
}'
```
### Python
```python
import requests
url = "https://netts.io/apiv2/order1h"
headers = {
"Content-Type": "application/json",
"X-API-KEY": "your_api_key",
"X-Real-IP": "your_whitelisted_ip"
}
payload = {
"amount": 131000,
"receiveAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"
}
response = requests.post(url, headers=headers, json=payload)
data = response.json()
if response.status_code == 200:
detail = data.get('detail', {})
order_data = detail.get('data', {})
print(f"Order ID: {order_data.get('orderId')}")
print(f"Transaction Hash: {order_data.get('hash')}")
print(f"Energy Delivered: {order_data.get('energy')}")
print(f"Cost: {order_data.get('paidTRX')} TRX")
print(f"Delegate Address: {order_data.get('delegateAddress')}")
else:
error_detail = data.get('detail', data)
print(f"Error Code: {error_detail.get('code', 'N/A')}")
print(f"Error Message: {error_detail.get('msg', error_detail)}")
```
## Response
### Success Response (200 OK)
```json
{
"detail": {
"code": 10000,
"msg": "Successful, 2.23 TRX deducted",
"data": {
"orderId": "1H123456",
"paidTRX": 2.23,
"hash": "a1b2c3d4e5f6789...",
"delegateAddress": "TDelegatePoolAddress...",
"energy": 131050
}
}
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| detail.code | integer | Always `10000` for successful orders |
| detail.msg | string | Success message with deducted amount |
| detail.data.orderId | string | Unified order ID (format: `1H{request_id}`) |
| detail.data.paidTRX | number | Total cost in TRX (includes activation fee if address was not activated) |
| detail.data.hash | string | null | Transaction hash. **Field is always present but may be empty** - some providers don't return hash immediately. Use [/apiv2/order\_check](/api/v2/endpoints/order-check) after 1 minute to get the hash |
| detail.data.delegateAddress | string | Pool address that delegated energy |
| detail.data.energy | integer | Energy amount + buffer (typically +50) |
## Error Responses
### Authentication Error (401)
```json
{
"detail": "Invalid API key or IP not in whitelist"
}
```
### Insufficient Balance (403)
```json
{
"code": 1004,
"msg": "Insufficient funds. Required: 2.23 TRX, Available: 1.50 TRX"
}
```
### Service Unavailable (503)
```json
{
"code": 5003,
"msg": "Service temporarily unavailable. All energy providers are currently unavailable."
}
```
### Provider Errors (503)
```json
{
"code": 5001,
"msg": "Energy provider temporarily unavailable"
}
```
```json
{
"code": 5002,
"msg": "Energy provider temporarily unavailable"
}
```
```json
{
"code": 5004,
"msg": "Energy provider requires higher minimum amount"
}
```
### Internal Server Error (500)
```json
{
"code": 5000,
"msg": "Internal server error occurred"
}
```
## Error Code Reference
| Code | Description | HTTP Status |
|------|-------------|-------------|
| `10000` | Success | 200 |
| `10000` | Success (cached response) | 208 |
| `-` | Duplicate request still processing | 409 |
| `1004` | Insufficient balance | 403 |
| `5000` | Internal server error | 500 |
| `5001` | Energy provider unavailable | 503 |
| `5002` | Energy provider unavailable | 503 |
| `5003` | Energy service unavailable | 503 |
| `5004` | Energy provider minimum not met | 503 |
## Rate Limits
The following rate limits apply to this endpoint (per IP address):
| Period | Limit | Description |
|--------|-------|-------------|
| **1 second** | 50 requests | Maximum 50 requests per second |
### Rate Limit Headers
```http
RateLimit-Limit: 50
RateLimit-Remaining: 49
RateLimit-Reset: 1
X-RateLimit-Limit-Second: 50
X-RateLimit-Remaining-Second: 49
```
### Rate Limit Exceeded (429)
```json
{
"message": "API rate limit exceeded"
}
```
## Idempotency
The API supports idempotency to prevent duplicate order processing. When you send multiple identical requests, the system ensures the order is processed only once.
### How Idempotency Works
Request uniqueness is determined by a combination of:
* **Request timestamp** (1-second window)
* **Energy amount**
* **Receiver address**
* **API key**
Each request is given a **1-second uniqueness window**. To protect the system from abuse and ensure proper processing, requests with identical parameters cannot be sent more frequently than once per second.
**Current behavior:** The system automatically protects clients from erroneous retries on already ordered energy. If you accidentally send the same request twice, you won't be charged twice.
**Coming soon:** An optional `idempotency_key` parameter will be added to the request. When provided, the system will use this key to determine request uniqueness instead of auto-generated parameters. This gives clients full control over idempotency, since only the client knows whether a request is truly unique or a retry.
### HTTP Status Codes for Duplicate Requests
| Status Code | Name | Description |
|-------------|------|-------------|
| **200** | OK | Order processed successfully (first request) |
| **208** | Already Reported | Order was already processed, returning cached response |
| **409** | Conflict | Request is currently being processed, do not retry |
### Duplicate Request - Already Processed (208)
When a duplicate request is received for an already completed order:
```json
{
"detail": {
"code": 10000,
"msg": "Successful, 2.54 TRX deducted",
"data": {
"hash": "9e4c20e21e01e4c39b21b670d1ea1fc1e4b0de94d8fbd4c190d5378ba911dfae",
"energy": 65050,
"orderId": "1H70bcc7962a",
"paidTRX": 2.535,
"delegateAddress": "TNp5gsJhBmZFXgCdgjMgr8pEZ8fHgXUHDq"
}
},
"idempotency": {
"status": "completed",
"cached": true,
"original_created_at": "2025-12-03T10:34:49.104896"
}
}
```
The response body is identical to the original successful response, with an additional `idempotency` object indicating this is a cached response.
### Duplicate Request - Still Processing (409)
When a duplicate request arrives while the original is still being processed:
```json
{
"success": false,
"error": "duplicate_request_processing",
"message": "This request is currently being processed. Please wait and do not retry.",
"idempotency_key": "b9e67b2412d33c92...",
"retry_after_seconds": 3
}
```
**Recommendation:** Wait for the specified `retry_after_seconds` before checking the order status.
### Best Practices
* **Do not send parallel requests** with the same parameters - wait for each response
* **Use unique idempotency keys** for different orders
* **Handle 409 responses** by waiting, not by immediately retrying
* **Check `idempotency.cached`** field to identify cached responses
## Notes
* Energy is delivered instantly upon successful order (typically within 0.5-10 seconds)
* **API response timeout**: Maximum 10 seconds, typically responds in up to 2 seconds
* **Address activation**: If receiver address is not activated, Netts activates it at cost price
* **Activation delay**: For non-activated addresses, API response may take up to 6 seconds due to activation process
* Orders are processed 24/7 with automatic provider failover
* **Minimum energy amount**: 61,000 units
* **Maximum energy amount**: 3,000,000 units per order
* **Energy buffer**: +50 units added automatically for provider compensation (free of charge)
* **Transaction hash**: Field is always present but **may be empty** if provider doesn't return it immediately. To retrieve the hash, call [/apiv2/order\_check](/api/v2/endpoints/order-check) no earlier than **1 minute** after placing the order
* **Provider selection**: Automatic based on cost and availability
* **Order ID format**: `1H{request_id}` for unified tracking
* **Pricing**: Dynamic based on time of day and energy amount
* **Duration**: Fixed 1 hour (3600 seconds)
* **Rate limiting**: 50 requests per second per IP address
---
---
url: https://doc.netts.io/api/v2/endpoints/order5m.md
---
# POST /apiv2/order5m
Create a 5-minute energy rental order through Netts internal energy pools.
## Endpoint URL
```
POST https://netts.io/apiv2/order5m
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| Content-Type | Yes | application/json |
| X-API-KEY | Yes | Your API key from Netts dashboard |
| X-Real-IP | Yes | IP address from your whitelist |
## Request Body
```json
{
"amount": 65000,
"receiveAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"
}
```
### Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| amount | integer | Yes | Energy amount to rent (minimum: 61,000, maximum: 650,000) |
| receiveAddress | string | Yes | TRON address that will receive the energy (TRC-20 format) |
::: warning Energy Limits
The 5-minute endpoint accepts energy amounts between **61,000** and **650,000** units per order. Requests outside this range will be rejected with HTTP 400.
:::
## Provider Information
5-minute energy orders are fulfilled exclusively through **Netts internal energy pools**. Unlike the 1-hour endpoint, external providers are not used.
::: tip Availability & Retry Strategy
Since delegations come only from internal pools, temporary unavailability is possible during high-demand periods. If you receive a `503` error, **retry the request after a short delay** or fall back to the [1-hour endpoint](/api/v2/endpoints/order1h) which has access to multiple external providers.
:::
## Example Requests
### cURL
```bash
curl -X POST https://netts.io/apiv2/order5m \
-H "Content-Type: application/json" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip" \
-d '{
"amount": 65000,
"receiveAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"
}'
```
### Python
```python
import requests
url = "https://netts.io/apiv2/order5m"
headers = {
"Content-Type": "application/json",
"X-API-KEY": "your_api_key",
"X-Real-IP": "your_whitelisted_ip"
}
payload = {
"amount": 65000,
"receiveAddress": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"
}
response = requests.post(url, headers=headers, json=payload)
data = response.json()
if response.status_code == 200:
detail = data.get('detail', {})
order_data = detail.get('data', {})
print(f"Order ID: {order_data.get('orderId')}")
print(f"Transaction Hash: {order_data.get('hash')}")
print(f"Energy Delivered: {order_data.get('energy')}")
print(f"Cost: {order_data.get('paidTRX')} TRX")
print(f"Delegate Address: {order_data.get('delegateAddress')}")
elif response.status_code == 503:
# Pool temporarily unavailable - retry or fallback to 1h
print("Pool busy, retrying in 2 seconds...")
else:
error_detail = data.get('detail', data)
print(f"Error Code: {error_detail.get('code', 'N/A')}")
print(f"Error Message: {error_detail.get('msg', error_detail)}")
```
## Response
### Success Response (200 OK)
```json
{
"detail": {
"code": 10000,
"msg": "Successful, 1.430 TRX deducted",
"data": {
"orderId": "5Mb4ee11ef86",
"paidTRX": 1.43,
"hash": "3636f97dde244fca17cdc0b2cf7fd157...",
"delegateAddress": "TNp5gsJhBmZFXgCdgjMgr8pEZ8fHgXUHDq",
"energy": 65050
}
}
}
```
### Success with Address Activation (200 OK)
When the receiver address has not been activated on the TRON network, Netts activates it automatically. The activation cost is added to the total:
```json
{
"detail": {
"code": 10000,
"msg": "Successful, 1.430 TRX for energy + 1.100 TRX for address activation",
"data": {
"orderId": "5Mb4ee11ef86",
"paidTRX": 2.53,
"hash": "3636f97dde244fca17cdc0b2cf7fd157...",
"delegateAddress": "TNp5gsJhBmZFXgCdgjMgr8pEZ8fHgXUHDq",
"energy": 65050,
"activationHash": "bab38070a64b237acc9110ecf5135acc..."
}
}
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| detail.code | integer | Always `10000` for successful orders |
| detail.msg | string | Success message with deducted amount |
| detail.data.orderId | string | Unified order ID (format: `5M{id}`) |
| detail.data.paidTRX | number | Total cost in TRX (includes activation fee if applicable) |
| detail.data.hash | string | Delegation transaction hash |
| detail.data.delegateAddress | string | Pool address that delegated energy |
| detail.data.energy | integer | Energy amount + buffer (typically +50) |
| detail.data.activationHash | string | Only present if address activation was performed |
## Error Responses
### Invalid Energy Amount (400)
```json
{
"code": 1003,
"msg": "Energy amount must be between 61000 and 650000. Requested: 50000"
}
```
### Authentication Error (401)
```json
{
"detail": "Invalid API key or IP not in whitelist"
}
```
### Insufficient Balance (403)
```json
{
"code": 1004,
"msg": "Insufficient funds. Required: 1.43 TRX, Available: 0.50 TRX"
}
```
### Service Unavailable (503)
```json
{
"code": 5003,
"msg": "Service temporarily unavailable. Energy delegation failed after retries."
}
```
::: tip Handling 503 Errors
A `503` response means internal pools are temporarily at capacity. Recommended strategy:
1. Wait 2-3 seconds and retry the 5-minute order
2. If still unavailable, fall back to the [1-hour endpoint](/api/v2/endpoints/order1h) which uses multiple providers
:::
### Internal Server Error (500)
```json
{
"code": 5000,
"msg": "Internal server error occurred"
}
```
## Error Code Reference
| Code | Description | HTTP Status |
|------|-------------|-------------|
| `10000` | Success | 200 |
| `10000` | Success (cached response) | 208 |
| `-` | Duplicate request still processing | 409 |
| `1003` | Energy amount out of range | 400 |
| `1004` | Insufficient balance | 403 |
| `1005` | User payer address not configured | 400 |
| `5000` | Internal server error | 500 |
| `5003` | Energy service unavailable | 503 |
## Rate Limits
The following rate limits apply to this endpoint (per IP address):
| Period | Limit | Description |
|--------|-------|-------------|
| **1 second** | 50 requests | Maximum 50 requests per second |
### Rate Limit Headers
```http
RateLimit-Limit: 50
RateLimit-Remaining: 49
RateLimit-Reset: 1
X-RateLimit-Limit-Second: 50
X-RateLimit-Remaining-Second: 49
```
### Rate Limit Exceeded (429)
```json
{
"message": "API rate limit exceeded"
}
```
## Idempotency
The API supports idempotency to prevent duplicate order processing. When you send multiple identical requests, the system ensures the order is processed only once.
### How Idempotency Works
Request uniqueness is determined by a combination of:
* **Request timestamp** (2-second window)
* **Energy amount**
* **Receiver address**
* **API key**
Each request is given a **2-second uniqueness window**. Requests with identical parameters within this window are treated as duplicates.
### HTTP Status Codes for Duplicate Requests
| Status Code | Name | Description |
|-------------|------|-------------|
| **200** | OK | Order processed successfully (first request) |
| **208** | Already Reported | Order was already processed, returning cached response |
| **409** | Conflict | Request is currently being processed, do not retry |
### Duplicate Request - Already Processed (208)
```json
{
"detail": {
"code": 10000,
"msg": "Successful, 1.430 TRX deducted",
"data": {
"hash": "3636f97dde244fca17cdc0b2cf7fd157...",
"energy": 65050,
"orderId": "5Mb4ee11ef86",
"paidTRX": 1.43,
"delegateAddress": "TNp5gsJhBmZFXgCdgjMgr8pEZ8fHgXUHDq"
}
},
"idempotency": {
"status": "completed",
"cached": true,
"original_created_at": "2026-03-21T08:53:52.498000"
}
}
```
### Duplicate Request - Still Processing (409)
```json
{
"success": false,
"error": "duplicate_request_processing",
"message": "This request is currently being processed. Please wait and do not retry.",
"retry_after_seconds": 3
}
```
### Best Practices
* **Do not send parallel requests** with the same parameters - wait for each response
* **Handle 409 responses** by waiting, not by immediately retrying
* **Check `idempotency.cached`** field to identify cached responses
## Comparison: 5-Minute vs 1-Hour Orders
| Feature | 5-Minute Order | 1-Hour Order |
|---------|---------------|--------------|
| Endpoint | `/apiv2/order5m` | `/apiv2/order1h` |
| Duration | 5 minutes | 1 hour |
| Energy range | 61,000 - 650,000 | 61,000 - 3,000,000 |
| Providers | Netts internal pools only | Internal pools + external providers |
| Price | Lower (5-minute rate) | Standard hourly rate |
| Availability | May be limited during peak | High (multiple provider fallback) |
| Best for | Frequent small transactions | Large or guaranteed delivery |
## Notes
* Energy is delivered instantly upon successful order (typically within 0.5-2 seconds)
* **API response timeout**: Maximum 10 seconds (includes internal retry attempts)
* **Address activation**: If receiver address is not activated, Netts activates it at cost price. Activation cost is charged only once per address
* **Duration**: Fixed 5 minutes (300 seconds)
* **Minimum energy amount**: 61,000 units
* **Maximum energy amount**: 650,000 units per order
* **Energy buffer**: +50 units added automatically (free of charge)
* **Order ID format**: `5M{id}` for unified tracking
* **Pricing**: Dynamic based on time of day via [Pricing API](/api/v2/endpoints/pricing)
* **Rate limiting**: 50 requests per second per IP address
* **Internal pools only**: If pools are at capacity, retry after a short delay or use the [1-hour endpoint](/api/v2/endpoints/order1h) as fallback
---
---
url: https://doc.netts.io/api/v2/endpoints/bandwidth.md
---
# POST /apiv2/bandwidth
Rent TRON **bandwidth** and delegate it to a recipient address for a fixed period (5 minutes or 1 hour).
> ⚠️ **Access tiers.**
>
> * **Accredited accounts** rent **any amount** (up to 5000) within the pool size and maximum
> limits, with **multiple concurrent orders**. Accreditation is granted by **Netts support**.
> * **Without accreditation** you can rent **400 units once** — the next order is allowed only
> **after the previous rental ends**. Requests for amounts other than 400, or a second order
> while the first is still active, are rejected.
## Endpoint URL
```
POST https://netts.io/apiv2/bandwidth
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| Content-Type | Yes | application/json |
| X-API-KEY | Yes | Your API key from Netts dashboard |
| X-Real-IP | Yes | IP address from your whitelist |
| X-Idempotency-Key | No | Optional client-generated key (base64) to safely retry without double-ordering. If omitted, the server generates one automatically |
## Request Body
```json
{
"amount": 1500,
"receiveAddress": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"period": "5m"
}
```
### Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| amount | integer | Yes | Bandwidth units to rent (minimum: **400**, maximum: **5000**) |
| receiveAddress | string | Yes | TRON address that will receive the bandwidth (`T…`, 34 chars, base58) |
| period | string | Yes | Rental duration: `"5m"` (5 minutes) or `"1h"` (1 hour) |
| trx\_send | boolean | No | **Guaranteed transaction**: if no bandwidth is available, send TRX to the address instead so the transaction still goes through. **Works only when `amount = 400`** (ignored otherwise). Default `false` |
| check | boolean | No | If `true` and the recipient already has more than 400 bandwidth, the order is **not** delegated and **no funds are charged** (status `enough`). Default `false` |
| test | boolean | No | **Dry run.** If `true`, the full order flow is simulated — the response tells you the **outcome** that would occur and the **price** that would be charged — **without any on-chain action and without charging**. Default `false` |
## Example Requests
> The examples below also **build and send the `X-Idempotency-Key`** so an accidental repeat
> does not create a second order. See [Idempotency](#idempotency) for the full rules.
### cURL
```bash
API_KEY="your_api_key"
ADDR="TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
AMOUNT=1500
PERIOD="5m"
NONCE=$(( $(date +%s) / 2 )) # stable for retries within a 2s window; or your own order UUID
# X-Idempotency-Key = base64( HMAC-SHA256( API_KEY, "addr:amount:period:nonce" ) )
IDEMP=$(printf '%s' "${ADDR}:${AMOUNT}:${PERIOD}:${NONCE}" \
| openssl dgst -sha256 -hmac "$API_KEY" -binary | base64)
curl -X POST https://netts.io/apiv2/bandwidth \
-H "Content-Type: application/json" \
-H "X-API-KEY: $API_KEY" \
-H "X-Real-IP: your_whitelisted_ip" \
-H "X-Idempotency-Key: $IDEMP" \
-d "{\"amount\": $AMOUNT, \"receiveAddress\": \"$ADDR\", \"period\": \"$PERIOD\"}"
```
### Python
```python
import time, hmac, hashlib, base64, requests
API_KEY = "your_api_key"
url = "https://netts.io/apiv2/bandwidth"
payload = {
"amount": 1500,
"receiveAddress": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"period": "5m",
}
# X-Idempotency-Key = base64( HMAC-SHA256( API_KEY, "addr:amount:period:nonce" ) )
# Generate ONCE per order and resend the same value on every retry.
nonce = str(int(time.time() // 2)) # 2s bucket; or your own order UUID
message = f"{payload['receiveAddress']}:{payload['amount']}:{payload['period']}:{nonce}"
idem_key = base64.b64encode(
hmac.new(API_KEY.encode(), message.encode(), hashlib.sha256).digest()
).decode()
headers = {
"Content-Type": "application/json",
"X-API-KEY": API_KEY,
"X-Real-IP": "your_whitelisted_ip",
"X-Idempotency-Key": idem_key,
}
response = requests.post(url, headers=headers, json=payload)
data = response.json()
detail = data.get("detail", {})
if response.status_code == 200 and detail.get("status") == "completed":
d = detail["data"]
print(f"Order ID: {d['orderId']}")
print(f"Hashes: {d['hash']}") # array of delegation tx hashes
print(f"Bandwidth: {d['bandwidth']} for {d['period']}")
print(f"Cost: {d['paidTRX']} TRX")
else:
print(f"Code: {detail.get('code')} | {detail.get('msg', detail)}")
```
A full client example (Python + cURL) is provided with the service package
(`handler_bandwidth/doc/client_example/`).
## Response
### Success — bandwidth delegated (200 OK)
```json
{
"detail": {
"code": 10000,
"status": "completed",
"msg": "Successful",
"data": {
"orderId": "B5M",
"paidTRX": "",
"fulfilledBy": "bandwidth",
"hash": ["a1b2c3...", "d4e5f6..."],
"bandwidth": 1500,
"period": "5m"
}
}
}
```
### Success — TRX sent instead of bandwidth (200 OK, only `amount=400` + `trx_send=true`)
When the pool has no bandwidth and `trx_send` is enabled, TRX is sent to the address so the
transaction still passes. A fixed charge applies in this case, regardless of the requested period.
```json
{
"detail": {
"code": 10000,
"status": "completed",
"msg": "Successful (sent TRX, bandwidth unavailable)",
"data": {
"orderId": "B5M",
"paidTRX": "",
"fulfilledBy": "trx",
"trxSendHash": [""],
"hash": [],
"bandwidth": 400,
"period": "5m"
}
}
}
```
### Already enough — not charged (200 OK, only with `check=true`)
```json
{
"detail": {
"code": 10002,
"status": "enough",
"msg": "enough band for 1 transfer",
"data": { "orderId": "B5M", "paidTRX": 0, "bandwidth": 400, "period": "5m" }
}
}
```
### Processing — external provider (202 Accepted)
Returned when the order is handed to an external provider asynchronously. Poll the status
endpoint (below) using `orderId` until it completes.
```json
{
"detail": {
"code": 10001,
"status": "processing",
"msg": "Order accepted, processed by an external provider. Poll the status endpoint.",
"data": { "orderId": "B5M", "bandwidth": 1500, "period": "5m" }
}
}
```
### Test run (200 OK, only with `test=true`)
The whole order flow is simulated. `testAction` tells you what **would** happen and
`wouldCostTRX` what **would** be charged. Nothing is delegated, no TRX is sent, **nothing is
charged** (`paidTRX: 0`).
```json
{
"detail": {
"code": 10003,
"status": "test",
"msg": "Test run — no on-chain action, no charge",
"data": {
"orderId": "B5M<...>",
"testAction": "would_delegate",
"wouldCostTRX": "",
"paidTRX": 0,
"bandwidth": 400,
"period": "5m",
"receiverFreeBandwidth": 600
}
}
}
```
`testAction` values: `would_delegate` (bandwidth would be delegated), `would_trx_send`
(no bandwidth, `amount=400` + `trx_send` → TRX would be sent), `enough` (recipient already has
enough, with `check=true`), or `would_error:` (e.g. `no_bandwidth`, `not_whitelisted`).
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| detail.code | integer | `10000` delegated/TRX, `10002` enough, `10001` processing |
| detail.status | string | `completed` / `enough` / `processing` / `failed` |
| detail.data.orderId | string | Order ID, format `B5M…` (5m) / `B1H…` (1h) — use it for the status endpoint |
| detail.data.paidTRX | number | Amount charged in TRX (`0` when `enough`) |
| detail.data.fulfilledBy | string | `bandwidth` (delegated) / `trx` (TRX sent) |
| detail.data.hash | array | Delegation transaction hashes (up to 10). Always an array (empty for the TRX branch) |
| detail.data.trxSendHash | array | TRX transfer hash(es), present only when `fulfilledBy = trx` |
| detail.data.bandwidth | integer | Bandwidth units delegated |
| detail.data.period | string | Rental period (`5m` / `1h`) |
## Status Endpoint
```
GET https://netts.io/apiv2/bandwidth/status/{orderId}
```
Headers: `X-API-KEY` + `X-Real-IP` (the order must belong to the authenticated user).
| Order state | HTTP | code | status |
|---|---|---|---|
| Completed | 200 | 10000 | `completed` (with `hash` / `trxSendHash`) |
| In progress | 200 | 10001 | `processing` |
| Already enough | 200 | 10002 | `enough` |
| Failed | 200 | 5003 | `failed` |
| Not found / not yours | 404 | -1 | — |
## Reclaim Endpoint
Voluntarily reclaim (undelegate) the bandwidth of one of your **delegated** orders before its
period expires. The bandwidth is undelegated automatically and the transaction hash is returned.
```
POST https://netts.io/apiv2/bandwidth/reclaim/{orderId}
```
Headers: `X-API-KEY` + `X-Real-IP` (the order must belong to the authenticated user).
| Order state | HTTP | code | status | Result |
|---|---|---|---|---|
| Delegated → reclaimed now | 200 | 10004 | `reclaimed` | `reclaimHash` (undelegate tx hashes) |
| Already reclaimed | 200 | 10004 | `reclaimed` | `reclaimHash` + msg "already reclaimed" |
| Not in a delegated state (nothing to reclaim) | 400 | 5005 | `failed` | — |
| Reclaim did not complete yet | 503 | 5003 | `failed` | retry shortly |
| Not found / not yours | 404 | -1 | — | — |
```bash
curl -X POST https://netts.io/apiv2/bandwidth/reclaim/B5M<...> \
-H "X-API-KEY: your_api_key" -H "X-Real-IP: your_whitelisted_ip"
```
```json
{
"detail": {
"code": 10004,
"status": "reclaimed",
"msg": "Bandwidth reclaimed",
"data": { "orderId": "B5M<...>", "reclaimHash": [""] }
}
}
```
```python
import requests
order_id = "B5M..." # the orderId from your rental response
url = f"https://netts.io/apiv2/bandwidth/reclaim/{order_id}"
headers = {"X-API-KEY": "your_api_key", "X-Real-IP": "your_whitelisted_ip"}
resp = requests.post(url, headers=headers)
detail = resp.json()["detail"]
if resp.status_code == 200 and detail["status"] == "reclaimed":
print(f"Reclaimed: {detail['data']['reclaimHash']} ({detail['msg']})")
else:
print(f"Code {detail.get('code')}: {detail.get('msg', detail)}")
```
> The rental charge is **not** refunded on a voluntary early reclaim — reclaiming only returns
> the delegated bandwidth to the pool ahead of the period.
## Error Responses
### Authentication Error (401)
```json
{ "detail": { "code": -1, "msg": "Invalid API key or IP not in whitelist" } }
```
### Insufficient Balance (403)
```json
{ "detail": { "code": 1004, "status": "failed", "msg": "Insufficient funds" } }
```
### Validation Error (400)
```json
{ "detail": { "code": 5004, "status": "failed", "msg": "Bandwidth amount out of range (400..5000)" } }
```
### Delegation Failed / Service Unavailable (503)
```json
{ "detail": { "code": 5003, "status": "failed", "msg": "Bandwidth delegation failed" } }
```
## Error Code Reference
| Code | Description | HTTP Status |
|------|-------------|-------------|
| `10000` | Success (delegated, or TRX sent) | 200 |
| `10000` | Success (cached response) | 208 |
| `10001` | Accepted, processing by external provider | 202 |
| `10002` | Recipient already has enough bandwidth (not charged) | 200 |
| `10003` | Test run — outcome + price preview, nothing charged (`test=true`) | 200 |
| `10004` | Bandwidth reclaimed (voluntary undelegate) — `reclaimHash` returned | 200 |
| `-` | Duplicate request still processing | 409 |
| `-1` | Invalid API key / IP not in whitelist | 401 |
| `1004` | Insufficient balance | 403 |
| `1005` | No payer address for user | 400 |
| `5004` | Invalid amount/period (validation) | 400 |
| `5005` | Nothing to reclaim (order is not in a delegated state) | 400 |
| `5007` | Without accreditation — only one rental at a time; previous order still active (wait until it ends) | 503 |
| `5008` | Without accreditation — only 400-unit orders allowed; accreditation required for larger amounts | 503 |
| `5003` | Bandwidth delegation failed / unavailable | 503 |
| `5000` | Internal server error | 500 |
## Rate Limits
| Period | Limit | Description |
|--------|-------|-------------|
| **1 second** | 50 requests | Maximum 50 requests per second per IP |
### Rate Limit Exceeded (429)
```json
{ "message": "API rate limit exceeded" }
```
## Idempotency
Send the optional `X-Idempotency-Key` header so an accidental repeat does **not** create a second
order — the original response is returned with HTTP **208**. If you do not send the header, the
server derives a key automatically from your request parameters within a short time window.
### How to form the key
The key is **`base64( HMAC-SHA256( secret, message ) )`** — a 44-character base64 string, where:
* **secret** = your API key (`X-API-KEY`);
* **message** = the fields joined with `:` — `receiveAddress:amount:period:nonce`.
`nonce` is any value that is **stable across retries of the same logical order but different
between distinct orders** — e.g. a UUID you keep for that order, or a coarse timestamp bucket.
**Generate the key once per order and resend the exact same value on every retry.**
```python
import hmac, hashlib, base64, time
def make_idempotency_key(api_key, receive_address, amount, period, nonce=None):
if nonce is None:
nonce = str(int(time.time() // 2)) # 2-second bucket; or your own order UUID
message = f"{receive_address}:{amount}:{period}:{nonce}"
digest = hmac.new(api_key.encode(), message.encode(), hashlib.sha256).digest()
return base64.b64encode(digest).decode() # 44-char base64
```
```bash
# then send it as a header:
-H "X-Idempotency-Key: "
```
Including `period` in the message is important: renting the **same address for 5m and for 1h**
are different orders and must produce different keys.
> **Validation.** A supplied `X-Idempotency-Key` must be a base64 string of **16–64 characters**
> (charset `A–Z a–z 0–9 + / = _ -`). A malformed or over-long key is rejected with **HTTP 400**
> (`code 5004`).
| Status Code | Meaning |
|---|---|
| 200 | Processed successfully (first request) |
| 208 | Already processed successfully — cached response returned (no second charge) |
| 409 | The same request is currently being processed — wait, do not retry yet |
> **Retrying after a failure.** Only **successful** results (`completed` / `enough`) are cached.
> If the previous attempt **failed or timed out** (no funds were charged), you may safely
> **retry with the same `X-Idempotency-Key`** — the order is attempted again rather than
> returning the old error. While an attempt is still in progress you get `409`; wait and retry.
## Notes
* **Access tiers:** accredited accounts rent any amount within pool/maximum limits with concurrent
orders; without accreditation — **400 units once** (next order only after the previous rental ends).
Contact Netts support for accreditation.
* **Minimum**: 400 units. **Maximum**: 5000 units per order (current configuration).
* **Periods**: `5m` (300 s) and `1h` (3600 s). The bandwidth is automatically reclaimed when the period expires.
* **No buffer**: exactly the requested amount is delegated.
* **hash is an array**: a single order may produce up to 10 delegation hashes — all are returned.
* **Pricing**: charged in TRX, based on the requested amount and period; rates may vary by time of day. Contact support for current pricing.
* **Small-order compensation (delegation)**: for orders **under 1000 units**, a fixed **0.372 TRX** is added to the price as compensation for the on-chain delegation and reclaim. Orders of 1000 units or more have no such addition.
* **TRX-send compensation**: when the order is fulfilled by sending TRX (`fulfilledBy = trx`), a fixed **0.268 TRX** is added instead (compensation for the on-chain TRX transfer).
* **trx\_send**: only for `amount = 400`; if no bandwidth is available, TRX is sent to the address so the transaction still passes.
* **check**: skips delegation (and charging) when the recipient already has more than 400 bandwidth.
* **Order ID format**: `B5M…` (5 minutes) / `B1H…` (1 hour).
* **Response timeout**: up to ~12 seconds while waiting for delegation; typically 1–2 seconds.
---
---
url: https://doc.netts.io/api/v2/host-mode.md
---
# Host Mode - Continuous Energy Management
Host Mode is an automated energy-management system that keeps a TRON address supplied with energy for USDT (TRC-20) transfers, delegating energy for each cycle and re-delegating automatically after the address consumes it.
## Overview
Once an address is in Host Mode, the system delegates energy to it and watches the address for USDT transfers. After a transfer consumes the delegated energy, the energy is reclaimed and a new cycle is delegated automatically — as long as the address has cycles left (or is in infinity mode).
### Key Features
* **Automatic energy**: energy is delegated for each cycle without manual action
* **Auto re-delegation**: after a USDT transfer consumes energy, the next cycle is delegated automatically
* **Cycle system**: you pay per delegation cycle
* **Infinity mode**: continuous operation until you stop it
## How It Works
1. **Add address**: register the address in Host Mode (`/apiv2/time/add`).
2. **Buy cycles**: order a fixed number of cycles (`/apiv2/time/order`) or enable infinity mode (`/apiv2/time/infinitystart`). This activates the address.
3. **Delegation**: energy is delegated to the address for the current cycle.
4. **Usage**: when the address makes a USDT transfer and consumes the energy, the system reclaims it and delegates the next cycle.
5. **Completion**: when all ordered cycles are used, the address is stopped automatically. In infinity mode it keeps running until you stop it.
### Cycles and Pricing
* **1 cycle = 1 delegation**: each delegation is 131,000 energy and consumes one cycle.
* **Pay as you go**: ordering cycles does **not** charge you upfront. Each cycle is charged at the moment its energy is delegated, so the first charge appears right after the mode is switched on, before your first transfer.
* **Cycle price**: the first delegation of an activation costs **4 TRX**. Every next one costs **2 TRX** if your previous transfer consumed 65,000 energy or less, and **4 TRX** if it consumed more. An activation is the period that starts when an address with no open orders and no active delegation is switched on. Buying more cycles while it is already running continues the same activation. Stopping the address ends it — switch the address on again and the count starts over, so that first delegation is 4 TRX again. The `amount` returned when you order cycles is an estimate, not the final total.
* **Daily minimum** (effective 2026-08-29): if an address spends less than **8 TRX** over a UTC calendar day, the difference is charged at the end of that day. Two exceptions: the rule does not apply to an address making **3 or more transfers a day**, and it does not apply on the first day if the mode was switched on at **16:00 UTC or later** — for such an address it starts from the next day.
* **Delegation lifetime**: 24 rolling hours from the moment energy is delegated. If no transfer happens within that window, the energy is reclaimed, the next cycle is delegated for the following day and charged at the **4 TRX** rate.
* **Idle shutdown**: after **2 consecutive idle days** — two 24-hour cycles closed without a transfer — the mode switches itself off and the open orders are closed.
* **An extra transfer inside a paid cycle**: a second transfer sent in the seconds before the energy is reclaimed reuses that same energy. It does not start a new cycle and does not reduce your remaining cycles, but it is charged separately at the rate matching what it consumed. Leave about a minute between transfers to avoid it.
* **Bandwidth**: up to 400 bandwidth is delegated together with the energy if the address is short of it. It is free and already included in the cycle price.
* **Infinity mode**: cycles are effectively unlimited until you stop the address. Everything above still applies — each delegation is charged as it happens, and the daily minimum and idle shutdown work the same way.
### Good Fit For
* Active traders making frequent USDT transfers
* Users who do not stake TRX for their own energy
* Services that need energy available on an address without manual top-ups
## Management Endpoints
* **[Time Add](./endpoints/time-add.md)** — add an address to Host Mode (and register a callback URL)
* **[Time Order](./endpoints/time-order.md)** — buy a specific number of cycles (activates the address)
* **[Time Infinity Start](./endpoints/time-infinitystart.md)** — enable infinity (unlimited) mode
* **[Time Stop](./endpoints/time-stop.md)** — stop Host Mode and close open orders
* **[Time Delete](./endpoints/time-delete.md)** — remove an address from Host Mode
* **[Time Status](./endpoints/time-status.md)** — check addresses, modes and cycle counts
## Authentication
Every request requires:
1. **API key** — passed in the JSON body (`api_key`) or the `X-API-KEY` header.
2. **Whitelisted IP** — the request IP must be in the whitelist configured for your API key.
All endpoints return a JSON envelope:
```json
{ "code": 0, "msg": "…", "data": { } }
```
`code = 0` means success; a negative `code` means an error (see `msg`).
## Callbacks (webhooks)
When you register a `callback_url` for an address (via `/apiv2/time/add`), the system notifies your URL each time energy is delegated to that address. The callback carries the delegation hash, the amount charged for the cycle (`charged`, TRX, always present) and — only when the cycle was born from your transfer — the tariff band of that transfer's energy consumption (`energy_used`: `65k` or `131k`, otherwise the parameter is omitted). See [Time Add → Callbacks](./endpoints/time-add.md#callbacks-webhooks) for the exact request format.
## Best Practices
1. **Verify the address** is correct and activated on the TRON network before adding it.
2. **Keep enough balance** — cycles are charged as they are delegated, not when you order them.
3. **Start small** with a few cycles before enabling infinity mode.
4. **Monitor** your addresses, cycle counts and actual spend with the Time Status endpoint.
5. **Leave about a minute between transfers** from the same address, so the second one does not reuse energy that is already being reclaimed.
6. **Stop addresses you are not using** — an idle address still costs the daily minimum until it shuts itself off.
7. **Protect your API key** — never expose it in client-side code; keep your IP whitelist up to date.
## Getting Started
1. Obtain an API key and whitelist your server IP.
2. Add the address with `/apiv2/time/add`.
3. Order cycles with `/apiv2/time/order` or enable infinity mode with `/apiv2/time/infinitystart`.
4. Monitor status with `/apiv2/time/status`.
---
---
url: https://doc.netts.io/api/v2/endpoints/time-add.md
---
# POST /apiv2/time/add
Add a TRON address to Host Mode and, optionally, register a callback URL for delegation notifications.
## Endpoint URL
```
POST https://netts.io/apiv2/time/add
```
## Authentication
Provide your API key in the request body (`api_key`) or the `X-API-KEY` header. The request IP must be in the whitelist configured for your API key.
## Request Body
```json
{
"api_key": "your_api_key",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"callback_url": "https://your-server.com/webhook",
"infinity": true
}
```
### Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| api\_key | string | Yes\* | API key. Can also be sent in the `X-API-KEY` header. |
| address | string | Yes | TRON (TRC-20) address, must match `^T[1-9A-HJ-NP-Za-km-z]{33}$` (starts with `T`, 34 characters). |
| callback\_url | string | No | Public HTTP/HTTPS URL to notify when energy is delegated to the address. Max 2048 characters. |
| infinity | boolean | No | `true` — also switch the address straight into infinity mode, saving a separate call to `/apiv2/time/infinitystart`. Defaults to `false`. |
\* Required in the body unless the `X-API-KEY` header is used.
**callback\_url validation:** must be `http`/`https`, a public host only (localhost, private RFC1918 ranges, link-local `169.254.0.0/16`, IPv6 private/link-local, reserved and multicast addresses are rejected), and at most 2048 characters.
## Behaviour
* If the address is new, it is added to Host Mode with status **inactive** (`status = 0`, `cycle_set = 0`). Activate it later with `/apiv2/time/order` or `/apiv2/time/infinitystart`.
* If the address already exists under your account, the call updates its callback URL.
* If `callback_url` is provided, it is stored (or updated) for that address.
### infinity
With `"infinity": true` the address is added **and** activated in infinity mode in one call — the same result as calling `/apiv2/time/add` and then `/apiv2/time/infinitystart`. Billing is identical to the separate call: nothing is charged at this point, and cycles are charged one by one as energy is delegated. See [Host Mode → Cycles and Pricing](../host-mode.md#cycles-and-pricing).
**Adding the address and switching it on are two separate steps, and only the first one is guaranteed.** The response reports the result of adding. If the address was added but could not be switched on, the call still returns `code: 0` with the usual message — the address is simply left inactive, exactly as if you had not passed the flag. Switching on is skipped when:
* your balance does not cover one cycle at the current price;
* the address is already active;
* the address already has an open order.
**The response is the same with and without the flag** — no extra fields, no extra error codes, and it does not tell you whether infinity mode was actually switched on. Confirm it with [Time Status](./time-status.md): the address reports `status: "active"` and `mode: "infinity"`, and the order id is in that response. Do not treat `code: 0` from this endpoint as proof that the mode is running.
## Example Requests
### cURL
```bash
curl -X POST https://netts.io/apiv2/time/add \
-H "Content-Type: application/json" \
-d '{
"api_key": "YOUR_API_KEY_HERE",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"callback_url": "https://your-server.com/webhook"
}'
```
### Python
```python
import requests
url = "https://netts.io/apiv2/time/add"
data = {
"api_key": "YOUR_API_KEY_HERE",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"callback_url": "https://your-server.com/webhook", # optional
# "infinity": True, # optional: also switch the address into infinity mode
}
resp = requests.post(url, json=data, timeout=30)
result = resp.json()
if result["code"] == 0:
print("Added:", result["data"]["address"])
else:
print("Error:", result["msg"])
```
### Node.js
```javascript
const axios = require('axios');
const data = {
api_key: 'YOUR_API_KEY_HERE',
address: 'TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE',
// callback_url: 'https://your-server.com/webhook', // optional
// infinity: true, // optional: also switch the address into infinity mode
};
axios.post('https://netts.io/apiv2/time/add', data)
.then(({ data: result }) => {
if (result.code === 0) console.log('Added:', result.data.address);
else console.error('Error:', result.msg);
})
.catch(err => console.error('Request failed:', err.response?.data || err.message));
```
## Response
### Success (new address)
```json
{
"code": 0,
"msg": "Address added to Host Mode successfully",
"data": {
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"callback_url": "https://your-server.com/webhook",
"timestamp": "2026-07-13T05:30:15.123456"
}
}
```
### Success (callback URL updated for an existing address)
```json
{
"code": 0,
"msg": "Address callback URL updated successfully",
"data": {
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"callback_url": "https://new-webhook.com/endpoint",
"timestamp": "2026-07-13T05:35:20.789012"
}
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| code | integer | `0` = success, negative = error |
| msg | string | Human-readable message |
| data.address | string | The address that was added/updated |
| data.callback\_url | string | null | The registered callback URL (`null` if none) |
| data.timestamp | string | ISO timestamp of the operation |
## Error Responses
All errors use `code = -1` and describe the problem in `msg`:
| msg | Cause |
|-----|-------|
| `API key required in X-API-KEY header or request body` | No API key provided |
| `Invalid API key or IP not in whitelist` | Authentication failed |
| `Invalid TRC-20 address format` | Address does not match the required format |
| `Invalid callback URL. Only public HTTP/HTTPS URLs are allowed` | Callback URL rejected by validation |
| `Address belongs to another user` | The address is registered under a different account |
| `Database error adding/updating address` | Temporary server-side error — retry |
| `Internal server error` | Unexpected error — retry or contact support |
```json
{ "code": -1, "msg": "Invalid API key or IP not in whitelist", "data": null }
```
### HTTP status codes
Endpoint errors are returned with **HTTP 200** and a negative `code` — check `code`, not the HTTP status. Error bodies always include `"data": null`.
Some errors are returned **before** the request reaches the endpoint. They use a non-200 status and a different body shape:
| HTTP | Body | Cause |
|------|------|-------|
| 402 | `{"detail": {"code": 1004, "msg": "Insufficient funds. Minimum balance is 4 TRX. Please top up your account."}}` | Account balance is too low |
| 403 | `{"detail": {"code": 1005, "msg": "API key is blocked. Contact support."}}` | The API key is blocked — contact support |
| 422 | `{"detail": [ … ]}` | Request body failed validation: a required field is missing or has the wrong type. Note there is no `code` field in this response |
## Callbacks (webhooks)
If you registered a `callback_url`, the system calls it each time energy is **delegated** to the address (i.e. once per delegation cycle as it is processed).
### Request format
The system sends an HTTP **GET** request with query parameters:
A cycle born from a USDT transfer — `energy_used` present:
```
GET https://your-server.com/webhook?address=TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE&order_id=T149936&hash=97b4eb0257088aefcb286229aa42ec750f27554390dd4e186f55efe273666577&balance_after=142.3500&idle_cycle=0&energy_used=65k&charged=2.0000
```
A cycle with no preceding transfer — `energy_used` omitted:
```
GET https://your-server.com/webhook?address=TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE&order_id=T149937&hash=97b4eb0257088aefcb286229aa42ec750f27554390dd4e186f55efe273666577&balance_after=138.3500&idle_cycle=0&charged=4.0000
```
| Parameter | Description |
|-----------|-------------|
| address | The TRON address that received the energy delegation |
| order\_id | Delegation identifier (`T` + internal delegation id) — unique per delegation |
| hash | On-chain transaction hash of the energy delegation |
| balance\_after | Your account balance in TRX right after this charge (snapshot at charge time; it may have changed by the moment the callback arrives) |
| idle\_cycle | `1` — this delegation was issued after 24 hours with no transfer (idle re-delegation), `0` — a regular cycle born from your transfer or activation |
| energy\_used | Tariff band of the energy consumed by the transfer that produced this cycle: `65k` (65,000 energy or less → 2 TRX) or `131k` (more than 65,000 → 4 TRX). **Optional — the key is omitted from the query string entirely** (not sent empty) when there was no preceding transfer to measure: the first delegation of an activation, every idle re-delegation, and an address with no consumption history yet. All of those are charged at the 4 TRX rate |
| charged | Amount in TRX charged for this cycle — `2.0000` or `4.0000`, matching the tariff in `energy_used`. Always present, including when `energy_used` is omitted. See [Host Mode → Cycles and Pricing](../host-mode.md#cycles-and-pricing) |
Use `order_id` and `hash` to distinguish one delegation from another and to reconcile with your own records — two callbacks for the same address differ by these values. Use `charged` to track spend per cycle without polling `/apiv2/time/status`, and `energy_used` to see which tariff the previous transfer fell into. Read `energy_used` as an optional parameter — a missing key means "no transfer to measure", not an error, and never assume a default value for it.
### Example handler (Python / Flask)
```python
from flask import Flask, request, jsonify
app = Flask(__name__)
@app.route('/webhook', methods=['GET'])
def energy_delegation_webhook():
address = request.args.get('address')
order_id = request.args.get('order_id')
tx_hash = request.args.get('hash')
charged = request.args.get('charged') # TRX charged for this cycle
energy_used = request.args.get('energy_used') # '65k' | '131k' | None (key may be absent)
if not address:
return jsonify({"error": "Missing address parameter"}), 400
# Your business logic (idempotent by order_id / hash)
print(f"Energy delegated: address={address} order_id={order_id} hash={tx_hash} "
f"charged={charged} energy_used={energy_used}")
return jsonify({"status": "success"}), 200
```
### Delivery behaviour
* **Method:** GET, timeout ~10 seconds. Return HTTP 200 to acknowledge.
* **Retries:** up to 3 attempts are made if the request fails; if all fail, the callback is dropped (energy delegation still happens regardless).
* **No signature:** the request is not signed by Netts. The secret (if any) is whatever you embedded in your own `callback_url`.
* **Reconciliation:** because callbacks can be missed, also poll `/apiv2/time/status` and make your handler idempotent.
### Updating / removing the callback
* **Update:** call `/apiv2/time/add` again with the same address and a new `callback_url`.
* **Remove:** call `/apiv2/time/delete` to remove the address (this also removes its callback); re-add without `callback_url` if needed.
## Related Endpoints
* [POST /apiv2/time/order](./time-order.md) — buy cycles (activates the address)
* [POST /apiv2/time/infinitystart](./time-infinitystart.md) — enable infinity mode
* [POST /apiv2/time/status](./time-status.md) — check status and cycles
* [POST /apiv2/time/stop](./time-stop.md) — stop Host Mode
* [POST /apiv2/time/delete](./time-delete.md) — remove the address
## Notes
* New addresses start **inactive**; activate them with an order, with infinity start, or by passing `"infinity": true` here.
* The same address cannot be registered under two different accounts.
* The address should be activated on the TRON network before adding it.
---
---
url: https://doc.netts.io/api/v2/endpoints/time-delete.md
---
# POST /apiv2/time/delete
Remove a TRON address from Host Mode entirely. By default the address must already be inactive (stopped) and have no open orders; pass `"stop": true` to stop it and delete it in one call.
## Endpoint URL
```
POST https://netts.io/apiv2/time/delete
```
## Authentication
Provide your API key in the request body (`api_key`) or the `X-API-KEY` header. The request IP must be in the whitelist configured for your API key.
## Request Body
```json
{
"api_key": "your_api_key",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"stop": true
}
```
### Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| api\_key | string | Yes | API key (or `X-API-KEY` header). |
| address | string | Yes | TRON (TRC-20) address, `^T[1-9A-HJ-NP-Za-km-z]{33}$`. Must belong to your account. |
| stop | boolean | No | `true` — stop Host Mode on the address before deleting it, instead of refusing the call. Saves a separate request to `/apiv2/time/stop`. Defaults to `false`. |
## Behaviour
* Without `stop`, the address must be **inactive** — stop it first with `/apiv2/time/stop` if it is active — and must have **no open orders**. Otherwise the call is refused with the errors below and nothing is changed.
* On success, the address is removed from Host Mode and its registered callback URL (if any) is deleted.
* The same address can be added again later with `/apiv2/time/add`.
### stop
With `"stop": true` an active address is stopped and deleted in one call — the same result as calling `/apiv2/time/stop` and then `/apiv2/time/delete`, and exactly the same actions: all open orders for the address are closed, Host Mode is switched off, the cycle counter is reset, and the stop is written to your action history. Only then is the address deleted.
Both steps run in **one transaction**: either the address is stopped and deleted, or nothing changes at all. There is no state where the address ends up stopped but still registered.
The flag only matters when there is something to stop. On an address that is already inactive and has no open orders it changes nothing — the call behaves exactly as without it, and the response is the plain delete response.
Billing is unaffected: stopping does not refund anything and deleting does not charge anything. Cycles already delegated stay charged, and energy currently delegated to the address is reclaimed on its normal schedule. See [Host Mode → Cycles and Pricing](../host-mode.md#cycles-and-pricing).
## Example Requests
### cURL
```bash
curl -X POST https://netts.io/apiv2/time/delete \
-H "Content-Type: application/json" \
-d '{
"api_key": "YOUR_API_KEY_HERE",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"
}'
```
Stop and delete in one call:
```bash
curl -X POST https://netts.io/apiv2/time/delete \
-H "Content-Type: application/json" \
-d '{
"api_key": "YOUR_API_KEY_HERE",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"stop": true
}'
```
### Python
```python
import requests
resp = requests.post(
"https://netts.io/apiv2/time/delete",
json={
"api_key": "YOUR_API_KEY_HERE",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
# "stop": True, # optional: stop Host Mode on the address instead of failing
},
timeout=30,
)
result = resp.json()
if result["code"] == 0:
print("Deleted:", result["data"]["address"])
else:
print("Error:", result["msg"])
```
### Node.js
```javascript
const axios = require('axios');
axios.post('https://netts.io/apiv2/time/delete', {
api_key: 'YOUR_API_KEY_HERE',
address: 'TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE',
// stop: true, // optional: stop Host Mode on the address instead of failing
}).then(({ data: result }) => {
if (result.code === 0) console.log('Deleted:', result.data.address);
else console.error('Error:', result.msg);
}).catch(err => console.error('Request failed:', err.response?.data || err.message));
```
## Response
### Success (200 OK)
```json
{
"code": 0,
"msg": "Address deleted from Host Mode successfully",
"data": {
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"timestamp": "2026-07-13T05:30:15.123456"
}
}
```
### Success when the address was stopped first (`"stop": true`)
```json
{
"code": 0,
"msg": "Address stopped and deleted from Host Mode successfully",
"data": {
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"stopped": true,
"orders_closed": 1,
"timestamp": "2026-07-13T05:30:15.123456"
}
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| code | integer | `0` = success, negative = error |
| msg | string | Human-readable message. `Address stopped and deleted from Host Mode successfully` when the address was stopped as part of the call |
| data.address | string | The address that was removed |
| data.stopped | boolean | Present **only** when Host Mode was stopped as part of this call. Absent on a plain delete |
| data.orders\_closed | integer | Number of open orders closed by that stop. Present only alongside `stopped` |
| data.timestamp | string | ISO timestamp |
## Error Responses
All errors use `code = -1`:
| msg | Cause |
|-----|-------|
| `API key required in X-API-KEY header or request body` | No API key provided |
| `Invalid API key or IP not in whitelist` | Authentication failed |
| `Invalid TRC-20 address format` | Bad address format |
| `Address not found or does not belong to you` | Address is not registered under your account |
| `Cannot delete an active address. Stop Host mode first` | Address is active and `stop` was not set — call `/apiv2/time/stop` first, or repeat with `"stop": true` |
| `Cannot delete address with active orders` | The address still has open orders and `stop` was not set — repeat with `"stop": true` |
| `Failed to delete address` | The address could not be removed — retry |
| `Database error deleting address` | Temporary server-side error — retry |
| `Internal server error` | Unexpected error — retry or contact support |
```json
{ "code": -1, "msg": "Cannot delete an active address. Stop Host mode first", "data": null }
```
### HTTP status codes
Endpoint errors are returned with **HTTP 200** and a negative `code` — check `code`, not the HTTP status. Error bodies always include `"data": null`.
Some errors are returned **before** the request reaches the endpoint. They use a non-200 status and a different body shape:
| HTTP | Body | Cause |
|------|------|-------|
| 403 | `{"detail": {"code": 1005, "msg": "API key is blocked. Contact support."}}` | The API key is blocked — contact support |
| 422 | `{"detail": [ … ]}` | Request body failed validation: a required field is missing or has the wrong type. Note there is no `code` field in this response |
Deleting an address is always available regardless of your account balance.
## Related Endpoints
* [POST /apiv2/time/stop](./time-stop.md) — stop the address before deleting
* [POST /apiv2/time/status](./time-status.md) — check status and open orders
* [POST /apiv2/time/add](./time-add.md) — add the address again later
## Notes
* Deleting also removes the address's callback URL.
* Delete is only allowed for inactive addresses with no open orders — stop it first with `/apiv2/time/stop`, or pass `"stop": true` here to have it stopped for you.
* The same address can be re-added at any time.
---
---
url: https://doc.netts.io/api/v2/endpoints/time-infinitystart.md
---
# POST /apiv2/time/infinitystart
Enable infinity (unlimited) mode for an address already in Host Mode — energy keeps being delegated cycle after cycle until you stop it.
## Endpoint URL
```
POST https://netts.io/apiv2/time/infinitystart
```
## Authentication
Provide your API key in the request body (`api_key`) or the `X-API-KEY` header. The request IP must be in the whitelist configured for your API key.
## Request Body
```json
{
"api_key": "your_api_key",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"
}
```
### Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| api\_key | string | Yes | API key (or `X-API-KEY` header). |
| address | string | Yes | TRON (TRC-20) address, `^T[1-9A-HJ-NP-Za-km-z]{33}$`. The address must already be in Host Mode (add it first). |
## Behaviour
* The address must already exist in Host Mode and be **inactive** (stopped).
* Your balance must cover at least one cycle at the current price (checked before activation).
* The endpoint activates the address, creates an open infinity order, and Host Mode keeps delegating energy cycle after cycle until you call `/apiv2/time/stop`.
Cycles are billed as they are delegated (one cycle per delegation). The first delegation of an activation costs 4 TRX; every next one costs 2 or 4 TRX depending on the energy your previous transfer actually consumed (≤ 65,000 → 2 TRX, more → 4 TRX). The 8 TRX daily minimum (effective 2026-08-29) and the 2-day idle shutdown apply in infinity mode too — see [Host Mode → Cycles and Pricing](../host-mode.md#cycles-and-pricing).
In [Time Status](./time-status.md) an infinity address reports `cycles_ordered` and `cycles_remaining` as `null` — there is no limit to count down. Read `null` as “unlimited”, not as “no cycles left”.
## Example Requests
### cURL
```bash
curl -X POST https://netts.io/apiv2/time/infinitystart \
-H "Content-Type: application/json" \
-d '{
"api_key": "YOUR_API_KEY_HERE",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"
}'
```
### Python
```python
import requests
resp = requests.post(
"https://netts.io/apiv2/time/infinitystart",
json={"api_key": "YOUR_API_KEY_HERE", "address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"},
timeout=30,
)
result = resp.json()
if result["code"] == 0:
print("Infinity mode active, order:", result["data"]["order_id"])
else:
print("Error:", result["msg"])
```
### Node.js
```javascript
const axios = require('axios');
axios.post('https://netts.io/apiv2/time/infinitystart', {
api_key: 'YOUR_API_KEY_HERE',
address: 'TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE',
}).then(({ data: result }) => {
if (result.code === 0) console.log('Infinity mode active, order:', result.data.order_id);
else console.error('Error:', result.msg);
}).catch(err => console.error('Request failed:', err.response?.data || err.message));
```
## Response
### Success (200 OK)
```json
{
"code": 0,
"msg": "Infinity mode activated successfully",
"data": {
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"order_id": 5427,
"mode": "infinity",
"status": "active",
"timestamp": "2026-07-13T05:30:15.123456"
}
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| code | integer | `0` = success, negative = error |
| msg | string | Human-readable message |
| data.address | string | The address activated in infinity mode |
| data.order\_id | integer | Internal order identifier |
| data.mode | string | `"infinity"` |
| data.status | string | `"active"` |
| data.timestamp | string | ISO timestamp |
## Error Responses
| code | msg | Cause |
|------|-----|-------|
| -1 | `API key required in X-API-KEY header or request body` | No API key provided |
| -1 | `Invalid API key or IP not in whitelist` | Authentication failed |
| -1 | `Invalid TRC-20 address format` | Bad address format |
| -1 | `Failed to activate host mode` | The address could not be activated — retry |
| -1 | `Database error activating infinity mode` | Temporary server-side error — retry |
| -1 | `Internal server error` | Unexpected error — retry or contact support |
| -2 | `Insufficient balance. Required: X TRX, Available: Y TRX` | Balance below one cycle price |
| -4 | `Address not found. Please add address first` | Address not in Host Mode |
| -5 | `Host mode is already active for this address` | Address is already running |
| -6 | `There is already an open order for this address` | An open order already exists |
```json
{ "code": -4, "msg": "Address not found. Please add address first", "data": null }
```
### HTTP status codes
Endpoint errors are returned with **HTTP 200** and a negative `code` — check `code`, not the HTTP status. Error bodies always include `"data": null`.
Some errors are returned **before** the request reaches the endpoint. They use a non-200 status and a different body shape:
| HTTP | Body | Cause |
|------|------|-------|
| 402 | `{"detail": {"code": 1004, "msg": "Insufficient funds. Minimum balance is 4 TRX. Please top up your account."}}` | Account balance is too low |
| 403 | `{"detail": {"code": 1005, "msg": "API key is blocked. Contact support."}}` | The API key is blocked — contact support |
| 422 | `{"detail": [ … ]}` | Request body failed validation: a required field is missing or has the wrong type. Note there is no `code` field in this response |
## Related Endpoints
* [POST /apiv2/time/add](./time-add.md) — add the address first
* [POST /apiv2/time/order](./time-order.md) — buy a fixed number of cycles instead
* [POST /apiv2/time/stop](./time-stop.md) — stop infinity mode
* [POST /apiv2/time/status](./time-status.md) — check status
## Notes
* Infinity mode runs until you stop it with `/apiv2/time/stop`.
* Keep enough balance available — cycles are charged as they are delegated.
* Use this endpoint to resume an address that was previously stopped (it must be inactive).
---
---
url: https://doc.netts.io/api/v2/endpoints/time-order.md
---
# POST /apiv2/time/order
Buy a specific number of energy delegation cycles for an address and activate Host Mode for it.
## Endpoint URL
```
POST https://netts.io/apiv2/time/order
```
## Authentication
Provide your API key in the request body (`api_key`) or the `X-API-KEY` header. The request IP must be in the whitelist configured for your API key.
## Request Body
```json
{
"api_key": "your_api_key",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"cycles": 10
}
```
### Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| api\_key | string | Yes | API key (or `X-API-KEY` header). |
| address | string | Yes | TRON (TRC-20) address, `^T[1-9A-HJ-NP-Za-km-z]{33}$`. |
| cycles | integer | Yes | Number of cycles to buy. Must be **≥ 1**. |
## Pricing and billing
* **Ordering cycles does not charge you upfront.** Each cycle is billed at the moment its energy is delegated: the first delegation of an activation costs 4 TRX, every next one costs 2 or 4 TRX depending on the energy your previous transfer actually consumed (≤65,000 → 2 TRX, more → 4 TRX). See [Host Mode → Cycles and Pricing](../host-mode.md#cycles-and-pricing) for the full rules, including the 8 TRX daily minimum (effective 2026-08-29).
* The `amount` in the response is an **estimate** (`cycles × reference price`), not the final total.
* Your balance is checked before the order is accepted; if it cannot cover the order, the order is rejected (error `-2`).
Placing an order sets the address to **active** and creates an open order for the requested number of cycles. The address then starts receiving energy delegations cycle by cycle, and each delegation is charged when it happens.
## Example Requests
### cURL
```bash
curl -X POST https://netts.io/apiv2/time/order \
-H "Content-Type: application/json" \
-d '{
"api_key": "YOUR_API_KEY_HERE",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"cycles": 10
}'
```
### Python
```python
import requests
resp = requests.post(
"https://netts.io/apiv2/time/order",
json={
"api_key": "YOUR_API_KEY_HERE",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"cycles": 10,
},
timeout=30,
)
result = resp.json()
if result["code"] == 0:
d = result["data"]
print(f"Order {d['order_id']}: {d['cycles']} cycles for {d['amount']} TRX")
else:
print("Error:", result["msg"])
```
### Node.js
```javascript
const axios = require('axios');
axios.post('https://netts.io/apiv2/time/order', {
api_key: 'YOUR_API_KEY_HERE',
address: 'TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE',
cycles: 10,
}).then(({ data: result }) => {
if (result.code === 0) {
const d = result.data;
console.log(`Order ${d.order_id}: ${d.cycles} cycles for ${d.amount} TRX`);
} else {
console.error('Error:', result.msg);
}
}).catch(err => console.error('Request failed:', err.response?.data || err.message));
```
## Response
### Success (200 OK)
```json
{
"code": 0,
"msg": "Cycles purchased and host mode activated successfully",
"data": {
"order_id": 5426,
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"cycles": 10,
"amount": 23.5,
"status": "active",
"timestamp": "2026-07-13T05:30:15.123456"
}
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| code | integer | `0` = success, negative = error |
| msg | string | Human-readable message |
| data.order\_id | integer | Internal order identifier |
| data.address | string | The address the cycles were bought for |
| data.cycles | integer | Number of cycles purchased |
| data.amount | number | Estimated order total, in TRX (reference only — billing is per delegation) |
| data.status | string | `"active"` after a successful order |
| data.timestamp | string | ISO timestamp of the order |
## Error Responses
| code | msg | Cause |
|------|-----|-------|
| -1 | `Invalid API key or IP not in whitelist` | Authentication failed |
| -1 | `Invalid TRC-20 address format` | Bad address format |
| -1 | `Cycle count must be 1 or more` | `cycles` < 1 |
| -1 | `Database error processing order` | Temporary server-side error — retry |
| -2 | `Insufficient balance. Required: X TRX, Available: Y TRX` | Balance below order total |
| -6 | `Cannot buy cycles: There is an open order with … cycles for this address` | An open order already exists (including infinity) |
```json
{
"code": -2,
"msg": "Insufficient balance. Required: 23.5 TRX, Available: 10.0 TRX"
}
```
## Related Endpoints
* [POST /apiv2/time/add](./time-add.md) — add the address first
* [POST /apiv2/time/infinitystart](./time-infinitystart.md) — unlimited cycles instead of a fixed count
* [POST /apiv2/time/status](./time-status.md) — check remaining cycles
* [POST /apiv2/time/stop](./time-stop.md) — stop and close the order
## Notes
* If the address is not yet in Host Mode, ordering also registers it and activates it.
* Only one open order per address is allowed at a time.
* Purchased cycles are consumed one per delegation; when they run out the address stops automatically.
---
---
url: https://doc.netts.io/api/v2/endpoints/time-status.md
---
# Time Status API
Get status information for addresses in Host Mode — all addresses for your account, or a single address.
There are two endpoints:
1. **POST /apiv2/time/status** — status for all your addresses (with optional pagination and account-level summary).
2. **GET /apiv2/time/status/{address}** — status for one specific address.
***
## POST /apiv2/time/status
### Endpoint URL
```
POST https://netts.io/apiv2/time/status
```
### Authentication
Provide your API key in the request body (`api_key`) or the `X-API-KEY` header. The request IP must be in the whitelist configured for your API key.
### Request Body
```json
{
"api_key": "your_api_key",
"page": 1,
"page_size": 50
}
```
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| api\_key | string | Yes | API key (or `X-API-KEY` header). |
| page | integer | No | Page number, ≥ 1. Requires `page_size`. |
| page\_size | integer | No | Addresses per page, 1–100. Requires `page`. |
**Pagination:** if `page` and `page_size` are both provided, results are paginated and a `pagination` object is included. Without them, all addresses are returned (up to 1000), sorted by creation time (newest first).
### Example Requests
**cURL (all addresses):**
```bash
curl -X POST https://netts.io/apiv2/time/status \
-H "Content-Type: application/json" \
-d '{ "api_key": "YOUR_API_KEY_HERE" }'
```
**cURL (paginated):**
```bash
curl -X POST https://netts.io/apiv2/time/status \
-H "Content-Type: application/json" \
-d '{ "api_key": "YOUR_API_KEY_HERE", "page": 1, "page_size": 50 }'
```
**Python:**
```python
import requests
resp = requests.post(
"https://netts.io/apiv2/time/status",
json={"api_key": "YOUR_API_KEY_HERE"}, # add "page"/"page_size" to paginate
timeout=30,
)
result = resp.json()
if result["code"] == 0:
for a in result["data"]["addresses"]:
# cycles_remaining is None in infinity mode — no limit to count down
left = "unlimited" if a["cycles_remaining"] is None else f"{a['cycles_remaining']} left"
print(a["address"], a["mode"], a["status"], left,
f"spent {a['total_spent']} TRX")
else:
print("Error:", result["msg"])
```
**Node.js:**
```javascript
const axios = require('axios');
axios.post('https://netts.io/apiv2/time/status', { api_key: 'YOUR_API_KEY_HERE' })
.then(({ data: result }) => {
if (result.code === 0) {
result.data.addresses.forEach(a => {
// cycles_remaining is null in infinity mode — no limit to count down
const left = a.cycles_remaining === null ? 'unlimited' : `${a.cycles_remaining} left`;
console.log(a.address, a.mode, a.status, left, `spent ${a.total_spent} TRX`);
});
} else {
console.error('Error:', result.msg);
}
})
.catch(err => console.error('Request failed:', err.response?.data || err.message));
```
### Response
```json
{
"code": 0,
"msg": "Status retrieved successfully",
"data": {
"summary": {
"total_addresses": 3,
"active_addresses": 2,
"infinity_mode_count": 1,
"total_cycles_ordered": 25,
"total_open_orders": 3
},
"order_statistics": {
"total_orders": 12,
"open_orders": 3,
"closed_orders": 9,
"total_cycles_in_open_orders": 25,
"total_delegations": 340,
"total_amount_spent": 1502.4471
},
"addresses": [
{
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"status": "active",
"mode": "normal",
"cycles_ordered": 25,
"cycle_set": 25,
"cycles_completed": 10,
"cycles_remaining": 15,
"cycles_total_lifetime": 214,
"current_cycle_no": 3,
"open_orders": 1,
"total_spent": 962.1184,
"bandwidth_delegated": true,
"created_at": "2026-07-08T12:00:00.000000",
"updated_at": "2026-07-09T10:00:00.000000"
},
{
"address": "TYn8Y3khEsLJW2ChVWFMSMeRDow6KcbMTF",
"status": "active",
"mode": "infinity",
"cycles_ordered": null,
"cycle_set": 0,
"cycles_completed": 83,
"cycles_remaining": null,
"cycles_total_lifetime": 115,
"current_cycle_no": 5,
"open_orders": 1,
"total_spent": 519.1234,
"bandwidth_delegated": true,
"created_at": "2026-07-08T08:00:00.000000",
"updated_at": "2026-07-09T09:30:00.000000"
}
],
"timestamp": "2026-07-09T12:34:50.123456"
}
}
```
**With pagination**, `data` also contains:
```json
"pagination": {
"page": 1,
"page_size": 50,
"total_items": 150,
"total_pages": 3,
"has_next": true,
"has_prev": false
}
```
#### Summary fields
| Field | Description |
|-------|-------------|
| total\_addresses | Number of addresses under your account |
| active\_addresses | Addresses currently active |
| infinity\_mode\_count | Active addresses running in infinity mode |
| total\_cycles\_ordered | Sum of ordered cycles across open orders (infinity orders excluded) |
| total\_open\_orders | Number of open orders across all addresses |
#### order\_statistics fields
| Field | Description |
|-------|-------------|
| total\_orders | All orders ever created |
| open\_orders | Currently open orders |
| closed\_orders | Closed orders |
| total\_cycles\_in\_open\_orders | Cycles across open orders (infinity excluded) |
| total\_delegations | Delegations actually performed across all your addresses |
| total\_amount\_spent | **Actually charged**, in TRX — the sum really deducted from your balance |
#### Address object fields
| Field | Type | Description |
|-------|------|-------------|
| address | string | TRON address |
| status | string | `"active"` or `"inactive"` |
| mode | string | `"normal"`, `"infinity"`, or `"off"` (when inactive) |
| cycles\_ordered | integer | null | Ordered cycles in open orders. `null` in infinity mode |
| cycle\_set | integer | `cycle_set` value stored for the address |
| cycles\_completed | integer | Cycles used since the address was last started. Resets when you stop the mode or the ordered cycles run out |
| cycles\_remaining | integer | null | `cycles_ordered − cycles_completed`. `null` in infinity mode |
| cycles\_total\_lifetime | integer | All delegations for this address over its whole history. Never reset |
| current\_cycle\_no | integer | null | Position of the current delegation since the address was last started. `null` when no delegation is active |
| open\_orders | integer | Number of open orders for the address |
| total\_spent | number | Actually charged for this address, in TRX |
| bandwidth\_delegated | boolean | Whether bandwidth is currently delegated. Bandwidth is free and included in the cycle price |
| created\_at | string | ISO timestamp when added |
| updated\_at | string | ISO timestamp of last update |
> **Infinity mode.** `cycles_ordered` and `cycles_remaining` are `null`, not `0` — there is no limit to count down. Treat `null` as “unlimited”, and do not read it as “no cycles left”. `cycles_completed` still reports a real number.
> **Three cycle counters, three meanings.** `cycles_completed` counts only since the address was last started, `cycles_total_lifetime` counts its whole history, and `current_cycle_no` is the position of the current delegation. They are expected to differ — for one address you may see `83`, `115` and `5` at the same time.
### Errors
All errors use `code = -1`:
| msg | Cause |
|-----|-------|
| `API key required in body or X-API-KEY header` | No API key provided |
| `Invalid API key or IP not in whitelist` | Authentication failed |
| `Page number must be >= 1` | `page` is below 1 |
| `Page size must be >= 1` | `page_size` is below 1 |
| `Page size must be <= 100` | `page_size` is above 100 |
| `Database error getting status` | Temporary server-side error — retry |
| `Internal server error` | Unexpected error — retry or contact support |
***
## GET /apiv2/time/status/{address}
Status for a single address.
### Endpoint URL
```
GET https://netts.io/apiv2/time/status/{address}
```
### Authentication
Send your API key in the **`X-API-KEY` header**. The request IP must be whitelisted.
### Example Request
```bash
curl -X GET "https://netts.io/apiv2/time/status/TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE" \
-H "X-API-KEY: YOUR_API_KEY_HERE"
```
```python
import requests
address = "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"
resp = requests.get(
f"https://netts.io/apiv2/time/status/{address}",
headers={"X-API-KEY": "YOUR_API_KEY_HERE"},
timeout=30,
)
print(resp.json())
```
### Response
```json
{
"code": 0,
"msg": "Address status retrieved successfully",
"data": {
"address_info": {
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"status": "active",
"mode": "normal",
"cycles_ordered": 25,
"cycle_set": 25,
"cycles_completed": 10,
"cycles_remaining": 15,
"cycles_total_lifetime": 214,
"current_cycle_no": 3,
"open_orders": 1,
"total_spent": 962.1184,
"bandwidth_delegated": true,
"created_at": "2026-07-08T12:00:00.000000",
"updated_at": "2026-07-09T10:00:00.000000"
},
"timestamp": "2026-07-09T12:34:50.123456"
}
}
```
`address_info` uses the same fields as the address object above.
### Errors
`code = -1`, for example:
| msg | Cause |
|-----|-------|
| `API key required in X-API-KEY header` | Missing header |
| `Invalid API key or IP not in whitelist` | Authentication failed |
| `Address not found or doesn't belong to user` | Unknown address for this account |
| `Database error getting address status` | Temporary server-side error — retry |
| `Internal server error` | Unexpected error — retry or contact support |
***
## HTTP status codes
Both endpoints return their errors with **HTTP 200** and a negative `code` — check `code`, not the HTTP status. Error bodies always include `"data": null`.
Some errors are returned **before** the request reaches the endpoint. They use a non-200 status and a different body shape:
| HTTP | Body | Cause |
|------|------|-------|
| 402 | `{"detail": {"code": 1004, "msg": "Insufficient funds. Minimum balance is 4 TRX. Please top up your account."}}` | Account balance is too low |
| 403 | `{"detail": {"code": 1005, "msg": "API key is blocked. Contact support."}}` | The API key is blocked — contact support |
| 422 | `{"detail": [ … ]}` | **POST only** — request body failed validation: a field has the wrong type, or `page`/`page_size` were sent without `api_key`. Note there is no `code` field in this response |
***
## Related Endpoints
* [POST /apiv2/time/add](./time-add.md) — add an address
* [POST /apiv2/time/order](./time-order.md) — buy cycles
* [POST /apiv2/time/infinitystart](./time-infinitystart.md) — enable infinity mode
* [POST /apiv2/time/stop](./time-stop.md) — stop an address
* [POST /apiv2/time/delete](./time-delete.md) — remove an address
## Notes
* The status endpoints are read-only.
* Only addresses belonging to your account are returned.
* Timestamps are ISO 8601 strings.
---
---
url: https://doc.netts.io/api/v2/endpoints/time-stop.md
---
# POST /apiv2/time/stop
Stop Host Mode for a TRON address: close its open orders and deactivate it. The address stays registered in Host Mode and can be re-activated later.
## Endpoint URL
```
POST https://netts.io/apiv2/time/stop
```
## Authentication
Provide your API key in the request body (`api_key`) or the `X-API-KEY` header. The request IP must be in the whitelist configured for your API key.
## Request Body
```json
{
"api_key": "your_api_key",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"
}
```
### Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| api\_key | string | Yes | API key (or `X-API-KEY` header). |
| address | string | Yes | TRON (TRC-20) address, `^T[1-9A-HJ-NP-Za-km-z]{33}$`. Must be in Host Mode and currently active. |
## Behaviour
Stopping an address:
* Closes all of its open orders.
* Sets Host Mode to **inactive** (`status = 0`, `cycle_set = 0`).
* Resets the used-cycle counter for the address.
* No new energy is delegated until you re-activate it (with `/apiv2/time/order` or `/apiv2/time/infinitystart`).
The address itself stays in Host Mode; to remove it entirely use `/apiv2/time/delete`.
## Example Requests
### cURL
```bash
curl -X POST https://netts.io/apiv2/time/stop \
-H "Content-Type: application/json" \
-d '{
"api_key": "YOUR_API_KEY_HERE",
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"
}'
```
### Python
```python
import requests
resp = requests.post(
"https://netts.io/apiv2/time/stop",
json={"api_key": "YOUR_API_KEY_HERE", "address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"},
timeout=30,
)
result = resp.json()
if result["code"] == 0:
print("Stopped. Orders closed:", result["data"]["orders_closed"])
else:
print("Error:", result["msg"])
```
### Node.js
```javascript
const axios = require('axios');
axios.post('https://netts.io/apiv2/time/stop', {
api_key: 'YOUR_API_KEY_HERE',
address: 'TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE',
}).then(({ data: result }) => {
if (result.code === 0) console.log('Stopped. Orders closed:', result.data.orders_closed);
else console.error('Error:', result.msg);
}).catch(err => console.error('Request failed:', err.response?.data || err.message));
```
## Response
### Success (200 OK)
```json
{
"code": 0,
"msg": "Host mode stopped successfully, closed 1 order(s)",
"data": {
"address": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE",
"orders_closed": 1,
"status": "inactive",
"timestamp": "2026-07-13T05:30:15.123456"
}
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| code | integer | `0` = success, negative = error |
| msg | string | Human-readable message |
| data.address | string | The address that was stopped |
| data.orders\_closed | integer | Number of open orders that were closed |
| data.status | string | `"inactive"` |
| data.timestamp | string | ISO timestamp |
## Error Responses
| code | msg | Cause |
|------|-----|-------|
| -1 | `API key required in X-API-KEY header or request body` | No API key provided |
| -1 | `Invalid API key or IP not in whitelist` | Authentication failed |
| -1 | `Invalid TRC-20 address format` | Bad address format |
| -1 | `Database error stopping host mode` | Temporary server-side error — retry |
| -1 | `Internal server error` | Unexpected error — retry or contact support |
| -4 | `Address not found` | Address is not in Host Mode under your account |
| -7 | `Host mode is already inactive` | The address is already stopped |
```json
{ "code": -7, "msg": "Host mode is already inactive", "data": null }
```
### HTTP status codes
Endpoint errors are returned with **HTTP 200** and a negative `code` — check `code`, not the HTTP status. Error bodies always include `"data": null`.
Some errors are returned **before** the request reaches the endpoint. They use a non-200 status and a different body shape:
| HTTP | Body | Cause |
|------|------|-------|
| 403 | `{"detail": {"code": 1005, "msg": "API key is blocked. Contact support."}}` | The API key is blocked — contact support |
| 422 | `{"detail": [ … ]}` | Request body failed validation: a required field is missing or has the wrong type. Note there is no `code` field in this response |
Stopping an address is always available regardless of your account balance.
## Stop vs Delete
| | Stop | Delete |
|--|------|--------|
| Host Mode registration | Kept | Removed |
| Open orders | Closed | Must be none |
| Re-activation | `order` / `infinitystart` | Must `add` again |
| Callback URL | Kept | Removed |
## Related Endpoints
* [POST /apiv2/time/infinitystart](./time-infinitystart.md) — re-activate the address (infinity)
* [POST /apiv2/time/order](./time-order.md) — re-activate with a fixed number of cycles
* [POST /apiv2/time/status](./time-status.md) — check status
* [POST /apiv2/time/delete](./time-delete.md) — remove the address entirely
## Notes
* Stopping keeps the address in Host Mode; it can be re-activated at any time.
* Remaining ordered cycles are not carried over — the used-cycle counter is reset on stop.
---
---
url: https://doc.netts.io/api/v2/endpoints/aml-check.md
---
# POST /apiv2/aml
Submit an address for AML (Anti-Money Laundering) screening. Returns risk score, risk level, and detailed exposure analysis.
## Endpoint URL
```
POST https://netts.io/apiv2/aml
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| Content-Type | Yes | application/json |
| X-API-KEY | Yes | Your API key from Netts dashboard |
## Request Body
```json
{
"address": "YOUR_ADDRESS_HERE",
"network": "trx",
"provider": "elliptic",
"wait": true
}
```
### Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| address | string | Yes | Blockchain address to check (10-100 characters) |
| network | string | Yes | Blockchain network identifier (see [Supported Networks](#supported-networks) below) |
| provider | string | No | AML provider: `elliptic` (default) |
| wait | boolean | No | If `true`, wait for result synchronously (up to 15 seconds). If `false` or omitted, return immediately with `pending` status and `client_order_id` — use it to poll result via [GET /apiv2/aml/{order\_id}](/api/v2/endpoints/aml-status) |
| response\_format | string | No | Response detail level: `rate` (score only), `full` (default, complete data) |
| report\_language | string | No | Language for report: `en` (default) |
### Providers
| Provider | Score Range | Description |
|----------|-----------|-------------|
| `elliptic` | 0 — 10 | Elliptic risk score. 0 = no risk, 10 = maximum risk. `null` = no triggers detected |
## Example Requests
### cURL (synchronous)
```bash
curl -X POST https://netts.io/apiv2/aml \
-H "Content-Type: application/json" \
-H "X-API-KEY: your_api_key" \
-d '{
"address": "YOUR_ADDRESS_HERE",
"network": "trx",
"provider": "elliptic",
"wait": true
}'
```
### cURL (asynchronous)
```bash
curl -X POST https://netts.io/apiv2/aml \
-H "Content-Type: application/json" \
-H "X-API-KEY: your_api_key" \
-d '{
"address": "YOUR_ADDRESS_HERE",
"network": "trx",
"provider": "elliptic"
}'
```
### Python
```python
import requests
url = "https://netts.io/apiv2/aml"
headers = {
"Content-Type": "application/json",
"X-API-KEY": "your_api_key",
}
payload = {
"address": "YOUR_ADDRESS_HERE",
"network": "trx",
"provider": "elliptic",
"wait": True
}
response = requests.post(url, headers=headers, json=payload)
data = response.json()
if response.status_code == 200:
result = data.get("data", {})
print(f"Order ID: {result.get('client_order_id')}")
print(f"Status: {result.get('status')}")
print(f"Risk Score: {result.get('risk_score')}")
print(f"Risk Level: {result.get('risk_level')}")
print(f"Sanctioned: {result.get('is_sanctioned')}")
else:
print(f"Error: {data}")
```
## Response
### Success — Pending (200 OK)
When `wait` is not set or check is still processing:
```json
{
"success": true,
"data": {
"client_order_id": "A4C666ABE24BD4A",
"status": "pending",
"address": "T...example...",
"provider": "elliptic",
"price_usdt": 0.98,
"price_trx": 4.136286,
"currency": "TRX",
"message": "AML check order accepted. Use GET /apiv2/aml/A4C666ABE24BD4A to check status."
},
"timestamp": "2026-03-10 09:56:31"
}
```
### Success — Elliptic Completed (200 OK)
Full Elliptic response with all data structures:
```json
{
"success": true,
"data": {
"client_order_id": "A019540900E55CA",
"status": "completed",
"address": "T...example...",
"provider": "elliptic",
"report_language": "en",
"risk_score": 0.802904,
"risk_level": "low",
"is_sanctioned": true,
"created_at": "2026-03-10 15:56:28",
"completed_at": "2026-03-10 15:56:28",
"result": {
"risk_score": 0.802904473154148,
"risk_score_detail": {
"source": 0.233206,
"destination": 0.802904
},
"contributions": {
"source": [
{
"entities": [
{
"name": "Capitalist",
"is_vasp": true,
"actor_id": 53979,
"category": "Payment Services Provider",
"entity_id": "b73a9c87-...",
"category_id": "54f55bfe-...",
"is_primary_entity": true
}
],
"indirect_value": { "usd": 40194.03 },
"contribution_value": { "usd": 40194.03 },
"counterparty_value": { "usd": 0 },
"min_number_of_hops": 2,
"indirect_percentage": 31.57,
"is_screened_address": false,
"contribution_percentage": 31.57,
"counterparty_percentage": 0
},
{
"entities": [
{
"name": "KuCoin",
"is_vasp": true,
"actor_id": 11620,
"category": "Exchange",
"entity_id": "e54292da-...",
"category_id": "0a52f7a2-...",
"is_primary_entity": true
}
],
"indirect_value": { "usd": 28436.45 },
"contribution_value": { "usd": 29434.17 },
"counterparty_value": { "usd": 997.72 },
"min_number_of_hops": 1,
"indirect_percentage": 22.34,
"is_screened_address": false,
"contribution_percentage": 23.12,
"counterparty_percentage": 0.78
}
],
"destination": [
{
"entities": [
{
"name": "Bybit",
"is_vasp": true,
"actor_id": 23354,
"category": "Exchange",
"entity_id": "bddde8b7-...",
"category_id": "0a52f7a2-...",
"is_primary_entity": true
}
],
"indirect_value": { "usd": 26333.43 },
"contribution_value": { "usd": 27458.30 },
"counterparty_value": { "usd": 1124.86 },
"min_number_of_hops": 1,
"indirect_percentage": 20.69,
"is_screened_address": false,
"contribution_percentage": 21.57,
"counterparty_percentage": 0.88
}
]
},
"cluster_entities": [
{
"name": "Unknown",
"is_vasp": null,
"actor_id": -4,
"category": "Unknown",
"entity_id": "00000000-...",
"category_id": "00000000-...",
"is_primary_entity": true,
"is_after_sanction_date": false
}
],
"evaluation_detail": {
"source": [
{
"rule_id": "6c2dcb03-...",
"rule_name": "Obfuscating & Misc.",
"rule_type": "exposure",
"risk_score": 0.2332,
"matched_elements": [
{
"category": "Coin Swap Service",
"category_id": "ff85b715-...",
"contributions": [
{
"entity": "FixedFloat",
"risk_triggers": {
"category": "Coin Swap Service",
"category_id": "ff85b715-..."
},
"indirect_value": { "usd": 2891.09, "native": 0, "native_major": 0 },
"contribution_value": { "usd": 2968.66, "native": 0, "native_major": 0 },
"counterparty_value": { "usd": 77.58, "native": 0, "native_major": 0 },
"min_number_of_hops": 1,
"indirect_percentage": 2.27,
"is_screened_address": false,
"contribution_percentage": 2.33,
"counterparty_percentage": 0.06
}
],
"indirect_value": { "usd": 2891.09, "native": 0, "native_major": 0 },
"contribution_value": { "usd": 2968.66, "native": 0, "native_major": 0 },
"counterparty_value": { "usd": 0, "native": 0, "native_major": 0 },
"indirect_percentage": 100,
"contribution_percentage": 2.33,
"counterparty_percentage": 0
}
],
"matched_behaviors": []
},
{
"rule_id": "0a2b68fd-...",
"rule_name": "Illicit Activity",
"rule_type": "exposure",
"risk_score": 0.0026,
"matched_elements": [
{
"category": "Token Blacklisting",
"category_id": "94b50de8-...",
"contributions": [
{
"entity": "Tether USD",
"risk_triggers": {
"category": "Token Blacklisting",
"category_id": "94b50de8-..."
},
"contribution_value": { "usd": 1022.45, "native": 0, "native_major": 0 },
"min_number_of_hops": 3,
"contribution_percentage": 0.08
}
]
}
],
"matched_behaviors": []
},
{
"rule_id": "df59fab5-...",
"rule_name": "Sanctions",
"rule_type": "exposure",
"risk_score": 0.0024,
"matched_elements": [
{
"category": "Sanctioned Entity",
"category_id": "c1648b7a-...",
"contributions": [
{
"entity": "Garantex",
"risk_triggers": {
"category": "Sanctioned Entity",
"category_id": "c1648b7a-..."
},
"contribution_value": { "usd": 863.21, "native": 0, "native_major": 0 },
"min_number_of_hops": 3,
"contribution_percentage": 0.07
}
]
}
],
"matched_behaviors": []
}
],
"destination": []
},
"detected_behaviors": []
},
"address_users": [
{
"sources": ["api_1h_response"],
"user_id": 3162
}
]
},
"timestamp": "2026-03-10 15:56:28"
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| data.client\_order\_id | string | Unique order ID for status polling |
| data.status | string | `pending`, `processing`, `completed`, `failed`, `skipped` |
| data.risk\_score | number | null | Risk score. Elliptic: 0-10. `null` = no triggers |
| data.risk\_level | string | `low`, `medium`, or `high` |
| data.is\_sanctioned | boolean | `true` if exposure to sanctioned entities detected |
| data.result | object | Full provider response (when `response_format=full`) |
| data.address\_users | array | Known users of this address from Netts database |
### Elliptic `result` Object
| Field | Type | Description |
|-------|------|-------------|
| risk\_score | number | Precise risk score (0-10) |
| risk\_score\_detail | object | Breakdown: `source` and `destination` scores |
| contributions | object | `source` and `destination` arrays of fund flow contributors |
| contributions\[].entities | array | Known entities associated with the contribution |
| contributions\[].entities\[].name | string | Entity name (e.g. "Binance", "KuCoin") |
| contributions\[].entities\[].category | string | Entity type (e.g. "Exchange", "Payment Services Provider") |
| contributions\[].entities\[].is\_vasp | boolean | null | Whether the entity is a Virtual Asset Service Provider |
| contributions\[].contribution\_value.usd | number | Total USD volume of the contribution |
| contributions\[].contribution\_percentage | number | Percentage of total funds from this entity |
| contributions\[].indirect\_value.usd | number | USD volume received indirectly (via intermediaries) |
| contributions\[].indirect\_percentage | number | Percentage of funds received indirectly |
| contributions\[].counterparty\_value.usd | number | USD volume as direct counterparty |
| contributions\[].counterparty\_percentage | number | Percentage as direct counterparty |
| contributions\[].min\_number\_of\_hops | number | Minimum transaction hops from the entity (0 = direct) |
| contributions\[].is\_screened\_address | boolean | `true` if this is the screened address itself |
| cluster\_entities | array | Known entities directly associated with the address cluster |
| cluster\_entities\[].name | string | Entity name |
| cluster\_entities\[].category | string | Entity category |
| cluster\_entities\[].is\_vasp | boolean | null | VASP status |
| cluster\_entities\[].is\_after\_sanction\_date | boolean | `true` if activity occurred after entity was sanctioned |
| evaluation\_detail | object | `source` and `destination` arrays of triggered risk rules |
| evaluation\_detail\[].rule\_name | string | Rule name (e.g. "Sanctions", "Illicit Activity", "Obfuscating & Misc.") |
| evaluation\_detail\[].rule\_type | string | Rule type (e.g. "exposure") |
| evaluation\_detail\[].risk\_score | number | Risk score contribution from this rule |
| evaluation\_detail\[].matched\_elements | array | Categories and entities that triggered the rule |
| evaluation\_detail\[].matched\_elements\[].category | string | Risk category (e.g. "Sanctioned Entity", "Gambling", "Token Blacklisting") |
| evaluation\_detail\[].matched\_elements\[].contributions | array | Entities within the matched category |
| evaluation\_detail\[].matched\_elements\[].contributions\[].entity | string | Entity name |
| evaluation\_detail\[].matched\_elements\[].contributions\[].contribution\_percentage | number | Exposure percentage |
| evaluation\_detail\[].matched\_elements\[].contributions\[].min\_number\_of\_hops | number | Transaction hops |
| evaluation\_detail\[].matched\_behaviors | array | Detected behavioral patterns |
| detected\_behaviors | array | Global behavioral patterns detected on the address |
### Risk Levels
**Elliptic (0-10 scale):**
| Range | Level | Description |
|-------|-------|-------------|
| 0 — 3 | low | Minimal risk. No significant exposure |
| 3 — 7 | medium | Moderate risk. Some risky categories detected |
| 7 — 10 | high | High risk. Sanctioned, illicit, or high-risk entities |
| null | - | No risk triggers detected |
## Error Responses
### Authentication Error (401)
```json
{
"detail": {
"code": -1,
"msg": "API key not provided"
}
}
```
### Validation Error (400)
```json
{
"success": false,
"error": {
"code": 4001,
"msg": "Invalid or missing address"
}
}
```
```json
{
"success": false,
"error": {
"code": 4002,
"msg": "Invalid provider. Use: elliptic"
}
}
```
### Insufficient Balance (402)
```json
{
"success": false,
"error": {
"code": 4020,
"message": "Insufficient balance"
},
"timestamp": "2026-03-10 10:00:00"
}
```
### Provider Unavailable (503)
```json
{
"success": false,
"error": {
"code": 5030,
"message": "Provider elliptic not available"
},
"timestamp": "2026-03-10 10:00:00"
}
```
## Error Code Reference
| Code | Description | HTTP Status |
|------|-------------|-------------|
| `-1` | Authentication failed | 401 |
| `4001` | Invalid or missing address | 400 |
| `4002` | Invalid provider | 400 |
| `4020` | Insufficient balance | 402 |
| `5030` | Provider unavailable | 503 |
## Rate Limits
The following rate limits apply to all AML endpoints (per IP address):
| Period | Limit | Description |
|--------|-------|-------------|
| **1 second** | 2 requests | Maximum 2 requests per second |
| **1 minute** | 30 requests | Maximum 30 requests per minute |
### Rate Limit Exceeded (429)
```json
{
"message": "API rate limit exceeded"
}
```
## Result Caching
If the same address + provider combination was checked within the last **60 seconds**, the cached result is returned **at no charge**.
## Supported Networks
The `network` parameter is **required**. Use the ticker from the table below.
### Elliptic — Holistic Screening
Screening is performed for a specific address on a specific network. However, Elliptic traces all assets associated with that address — including tokens, cross-chain transfers, and interactions with known entities across other networks.
| Network | Ticker | Native Asset |
|---------|--------|-------------|
| Algorand | `algo` | ALGO |
| Aptos | `apt` | APT |
| Arbitrum | `arb` | ETH |
| Avalanche (C-Chain) | `avax` | AVAX |
| Base | `base` | ETH |
| Binance Chain | `bnb` | BNB |
| Binance Smart Chain | `bsc` | BNB |
| Bitcoin | `btc` | BTC |
| Bittensor | `tao` | TAO |
| Cardano | `ada` | ADA |
| Celo | `celo` | CELO |
| Cosmos | `atom` | ATOM |
| Crypto.com | `cro` | CRO |
| Dogecoin | `doge` | DOGE |
| dYdX | `dydx` | DYDX |
| Ethereum | `eth` | ETH |
| Ethereum Classic | `etc` | ETC |
| Fantom | `ftm` | FTM |
| Filecoin | `fil` | FIL |
| Flare | `flr` | FLR |
| Gnosis | `gnosis` | xDai |
| Hedera | `hbar` | HBAR |
| HyperEVM | `hype` | HYPE |
| Injective | `inj` | INJ |
| Internet Computer | `icp` | ICP |
| Linea | `linea` | LINEA |
| Litecoin | `ltc` | LTC |
| MobileCoin | `mob` | MOB |
| Near | `near` | NEAR |
| Optimism | `op` | ETH |
| Polkadot | `dot` | DOT |
| Polygon | `matic` | MATIC |
| Ripple | `xrp` | XRP |
| Sei | `sei` | SEI |
| Solana | `sol` | SOL |
| Starknet | `strk` | STRK |
| Stellar | `xlm` | XLM |
| Sui | `sui` | SUI |
| Tezos | `xtz` | XTZ |
| TON | `ton` | TON |
| Tron | `trx` | TRX |
| XDC | `xdc` | XDC |
| XLayer | `okb` | OKB |
| Zilliqa | `zil` | ZIL |
| zkSync | `zksync` | ETH |
### Single Asset Screening
These networks support individual address/transaction screening:
| Network | Ticker | Native Asset |
|---------|--------|-------------|
| Bitcoin Cash | `bch` | BCH |
| Horizen | `zen` | ZEN |
| ZCash | `zec` | ZEC |
::: tip Provider & Network Compatibility
When using `provider: "elliptic"` — all networks from Holistic and Single Asset tables are available (47 networks).
If an unsupported network is passed, the API returns error code `4001`.
:::
## Notes
* **Pricing**: Elliptic — $0.98 per check. Prices shown in TRX at current rate
* **Sync timeout**: `wait: true` waits up to 15 seconds. If check takes longer, returns `pending` status
* **Processing time**: Most checks complete within a few seconds. However, some requests (especially for addresses with complex transaction history) may take up to **3 minutes** to process. Use asynchronous mode (omit `wait` or set `wait: false`) and poll via [GET /apiv2/aml/{order\_id}](/api/v2/endpoints/aml-status) for such cases
* **Inactive addresses**: Addresses with no blockchain activity return `skipped` status at no charge
---
---
url: https://doc.netts.io/api/v2/endpoints/aml-history.md
---
# GET /apiv2/aml/history
Get AML check history for a specific address. Only returns checks belonging to the authenticated user. Paginated: 100 items per page, newest first.
## Endpoint URL
```
GET https://netts.io/apiv2/aml/history?address=&network=&page=1
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| X-API-KEY | Yes | Your API key from Netts dashboard |
## Query Parameters
| Parameter | Type | Required | Default | Description |
|-----------|------|----------|---------|-------------|
| address | string | Yes | — | Blockchain address (10-100 characters) |
| network | string | Yes | — | Blockchain network ticker (see [Supported Networks](/api/v2/endpoints/aml-check#supported-networks)) |
| page | integer | No | `1` | Page number (1-based, 100 items per page) |
## Example Requests
### cURL
```bash
curl -X GET "https://netts.io/apiv2/aml/history?address=TPCHni9H51NEr8iT6fNJgkdMUBPbF79HBV&network=trx&page=1" \
-H "X-API-KEY: your_api_key"
```
### Python
```python
import requests
headers = {
"X-API-KEY": "your_api_key",
}
response = requests.get(
"https://netts.io/apiv2/aml/history",
headers=headers,
params={
"address": "TPCHni9H51NEr8iT6fNJgkdMUBPbF79HBV",
"network": "trx",
"page": 1
}
)
data = response.json()
if data["success"]:
print(f"Total checks: {data['data']['total']}")
print(f"Page {data['data']['page']} of {data['data']['pages']}")
for check in data["data"]["checks"]:
print(f" {check['created_at']} | {check['client_order_id']} | "
f"{check['provider']} | risk={check['risk_score']} ({check['risk_level']})")
```
## Response
### Success (200 OK)
```json
{
"success": true,
"data": {
"address": "TPCHni9H51NEr8iT6fNJgkdMUBPbF79HBV",
"total": 250,
"page": 1,
"pages": 3,
"checks": [
{
"client_order_id": "A4C666ABE24BD4A",
"provider": "elliptic",
"status": "completed",
"created_at": "2026-03-10 15:00:00",
"completed_at": "2026-03-10 15:00:05",
"risk_score": 10.0,
"risk_level": "high",
"is_sanctioned": false
},
{
"client_order_id": "A7F3B2E1D9C04A6",
"provider": "elliptic",
"status": "completed",
"created_at": "2026-03-09 12:30:00",
"completed_at": "2026-03-09 12:30:08",
"risk_score": 0.85,
"risk_level": "high",
"is_sanctioned": false
}
]
},
"timestamp": "2026-03-10 15:05:00"
}
```
### No Results (200 OK)
```json
{
"success": true,
"data": {
"address": "TXtARC75jmh7sDDfHFunLbpA44T7JhJ53u",
"total": 0,
"page": 1,
"pages": 0,
"checks": []
},
"timestamp": "2026-03-10 15:05:00"
}
```
## Response Fields
| Field | Type | Description |
|-------|------|-------------|
| data.address | string | Queried address |
| data.total | integer | Total number of checks for this address |
| data.page | integer | Current page number |
| data.pages | integer | Total number of pages |
| data.checks | array | Array of check records (up to 100 per page) |
### Check Record Fields
| Field | Type | Description |
|-------|------|-------------|
| client\_order\_id | string | Order ID — use with [GET /apiv2/aml/{order\_id}](/api/v2/endpoints/aml-status) for full result |
| provider | string | AML provider: `elliptic` |
| status | string | `completed`, `pending`, `processing`, `failed` |
| created\_at | string | Check submission date/time |
| completed\_at | string | null | Check completion date/time |
| risk\_score | number | null | Risk score (Elliptic: 0-10). `null` if not completed |
| risk\_level | string | null | `low`, `medium`, or `high` |
| is\_sanctioned | boolean | null | `true` if sanctions exposure detected |
## Pagination
* Each page returns up to **100** records, sorted by date (newest first)
* Use `total` to know how many checks exist for this address
* Use `pages` to know the last available page number
* `page=1` returns the most recent 100 checks, `page=2` the next 100, etc.
## Error Responses
### Authentication Error (401)
```json
{
"detail": {
"code": -1,
"msg": "API key not provided"
}
}
```
### Invalid Network (400)
```json
{
"success": false,
"error": {
"code": 4002,
"message": "Unsupported network: xyz. See supported networks list."
}
}
```
## Notes
* Only your own checks are returned — you cannot see checks made by other users for the same address
* `skipped` status checks (inactive addresses) are excluded from history
* To get the full result for any check, use [GET /apiv2/aml/{order\_id}](/api/v2/endpoints/aml-status) with the `client_order_id`
---
---
url: https://doc.netts.io/api/v2/endpoints/aml-price.md
---
# GET /apiv2/aml/price
Get AML check price for a specific provider, including your balance and affordability.
## Endpoint URL
```
GET https://netts.io/apiv2/aml/price
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| X-API-KEY | Yes | Your API key from Netts dashboard |
## Query Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| provider | string | No | AML provider: `elliptic` (default) |
## Example Requests
### cURL
```bash
curl -X GET "https://netts.io/apiv2/aml/price?provider=elliptic" \
-H "X-API-KEY: your_api_key" \
```
### Python
```python
import requests
headers = {
"X-API-KEY": "your_api_key",
}
response = requests.get("https://netts.io/apiv2/aml/price?provider=elliptic", headers=headers)
data = response.json()
result = data["data"]
print(f"Price: ${result['price_usdt']} ({result['price_trx']} TRX)")
print(f"Balance: {result['user_balance_trx']} TRX")
print(f"Can afford: {result['can_afford']}")
```
## Response
### Success (200 OK)
```json
{
"success": true,
"data": {
"provider": "elliptic",
"price_usdt": 0.98,
"price_trx": 3.43,
"trx_rate_usd": 0.285756,
"available": true,
"user_balance_trx": 314.75,
"can_afford": true
},
"timestamp": "2026-03-10 09:52:05"
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| provider | string | Selected provider |
| price\_usdt | number | Price per check in USDT |
| price\_trx | number | Price per check in TRX |
| trx\_rate\_usd | number | Current TRX/USD rate |
| available | boolean | Provider availability |
| user\_balance\_trx | number | Your current TRX balance |
| can\_afford | boolean | Whether your balance covers the check price |
## Error Responses
### Invalid Provider (400)
```json
{
"success": false,
"error": {
"code": 4002,
"message": "Invalid provider. Use: elliptic"
},
"timestamp": "2026-03-10 10:00:00"
}
```
---
---
url: https://doc.netts.io/api/v2/endpoints/aml-providers.md
---
# GET /apiv2/aml/providers
List available AML providers with current prices.
## Endpoint URL
```
GET https://netts.io/apiv2/aml/providers
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| X-API-KEY | Yes | Your API key from Netts dashboard |
## Example Requests
### cURL
```bash
curl -X GET https://netts.io/apiv2/aml/providers \
-H "X-API-KEY: your_api_key" \
```
### Python
```python
import requests
headers = {
"X-API-KEY": "your_api_key",
}
response = requests.get("https://netts.io/apiv2/aml/providers", headers=headers)
data = response.json()
for provider in data["data"]["providers"]:
print(f"{provider['provider']}: ${provider['price_usdt']} ({provider['price_trx']} TRX)")
```
## Response
### Success (200 OK)
```json
{
"success": true,
"data": {
"providers": [
{
"provider": "elliptic",
"price_usdt": 0.98,
"price_trx": 3.43,
"available": true
}
],
"trx_rate_usd": 0.285756,
"supported_formats": ["rate", "full", "md", "pdf"],
"supported_languages": ["en"]
},
"timestamp": "2026-03-10 09:52:03"
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| providers\[].provider | string | Provider name: `elliptic` |
| providers\[].price\_usdt | number | Price per check in USDT |
| providers\[].price\_trx | number | Price per check in TRX (at current rate) |
| providers\[].available | boolean | Whether provider is currently available |
| providers\[].reason | string | Present when `available: false`, e.g. `quota_exhausted` |
| trx\_rate\_usd | number | Current TRX/USD exchange rate |
## Notes
* Prices include reseller discounts if applicable
* TRX prices recalculated based on live exchange rate
---
---
url: https://doc.netts.io/api/v2/endpoints/aml-status.md
---
# GET /apiv2/aml/{order\_id}
Get the status and result of a previously submitted AML check.
## Endpoint URL
```
GET https://netts.io/apiv2/aml/{order_id}
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| X-API-KEY | Yes | Your API key from Netts dashboard |
## Path Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| order\_id | string | Yes | Order ID returned from POST /apiv2/aml |
## Example Requests
### cURL
```bash
curl -X GET https://netts.io/apiv2/aml/A4C666ABE24BD4A \
-H "X-API-KEY: your_api_key" \
```
### Python
```python
import requests
order_id = "A4C666ABE24BD4A"
headers = {
"X-API-KEY": "your_api_key",
}
response = requests.get(f"https://netts.io/apiv2/aml/{order_id}", headers=headers)
data = response.json()
result = data.get("data", {})
print(f"Status: {result.get('status')}")
print(f"Risk Score: {result.get('risk_score')}")
print(f"Risk Level: {result.get('risk_level')}")
```
## Response
### Completed Check (200 OK)
```json
{
"success": true,
"data": {
"client_order_id": "A4C666ABE24BD4A",
"status": "completed",
"address": "TXtARC75jmh7sDDfHFunLbpA44T7JhJ53u",
"provider": "elliptic",
"report_language": "en",
"risk_score": 10.0,
"risk_level": "high",
"is_sanctioned": false,
"created_at": "2026-03-10 09:56:31",
"completed_at": "2026-03-10 09:56:32",
"result": {
"risk_score": 10,
"cluster_entities": [
{
"name": "ChangeHero",
"category": "Coin Swap Service"
}
]
}
},
"timestamp": "2026-03-10 10:00:00"
}
```
### Pending Check (200 OK)
```json
{
"success": true,
"data": {
"client_order_id": "A4C666ABE24BD4A",
"status": "pending",
"address": "TPCHni9H51NEr8iT6fNJgkdMUBPbF79HBV",
"provider": "elliptic",
"report_language": "en",
"message": "AML check is being processed",
"estimated_time_seconds": 5,
"created_at": "2026-03-10 09:56:31"
},
"timestamp": "2026-03-10 09:56:35"
}
```
### Order Not Found (404)
```json
{
"success": false,
"error": {
"code": 4040,
"message": "Order not found"
},
"timestamp": "2026-03-10 10:00:00"
}
```
## Notes
* Poll this endpoint to get results for asynchronous checks (submitted without `wait: true`)
* Typical check completion time: 2-10 seconds
* Polling does not incur additional charges
---
---
url: https://doc.netts.io/api/v2/endpoints/subuserdel.md
---
# DELETE /apiv2/subuserdel/{user\_id}
Delete a SUB-user and all related records. History records (orders, delegations) are reassigned to the parent user. Only the parent account or an administrator can delete a SUB-user.
## Endpoint URL
```
DELETE https://netts.io/apiv2/subuserdel/{user_id}
```
### Path Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| user\_id | integer | Yes | ID of the SUB-user to delete |
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| X-API-KEY | Yes | Your API key (must be the parent user's key) |
| X-Real-IP | Yes | IP address from your whitelist |
## Authentication & Authorization
This endpoint requires both **authentication** and **authorization**:
1. **Authentication**: Valid API key + IP from whitelist (same as other endpoints)
2. **Authorization**: Only the **parent user** (who created the SUB-user) can delete their SUB-users
If a user attempts to delete a SUB-user that doesn't belong to them, the request is rejected with `403 Forbidden`.
## Example Requests
### cURL
```bash
curl -X DELETE https://netts.io/apiv2/subuserdel/1234 \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip"
```
### Python
```python
import requests
user_id = 1234
url = f"https://netts.io/apiv2/subuserdel/{user_id}"
headers = {
"X-API-KEY": "your_api_key",
"X-Real-IP": "your_whitelisted_ip"
}
response = requests.delete(url, headers=headers)
data = response.json()
if response.status_code == 200:
print(f"Deleted user: {data['user_id']} ({data['google_id']})")
print(f"Parent user: {data['parent_user_id']}")
print(f"Records reassigned: {data['total_reassigned']}")
print(f"Records deleted: {data['total_deleted']}")
print(f"Message: {data['message']}")
else:
print(f"Error ({response.status_code}): {data.get('detail', 'Unknown error')}")
```
### Node.js
```javascript
const axios = require('axios');
async function deleteSubUser(userId, apiKey, whitelistedIp) {
const url = `https://netts.io/apiv2/subuserdel/${userId}`;
const response = await axios.delete(url, {
headers: {
'X-API-KEY': apiKey,
'X-Real-IP': whitelistedIp
},
timeout: 30000
});
const data = response.data;
console.log(`Deleted: ${data.user_id} (${data.google_id})`);
console.log(`Reassigned: ${data.total_reassigned} rows`);
console.log(`Deleted: ${data.total_deleted} records`);
return data;
}
// Usage
deleteSubUser(1234, 'your_api_key', 'your_whitelisted_ip')
.then(result => console.log('Done:', result.message))
.catch(err => console.error('Error:', err.response?.data || err.message));
```
### PHP
```php
[
'header' => implode("\r\n", [
"X-API-KEY: your_api_key",
"X-Real-IP: your_whitelisted_ip"
]),
'method' => 'DELETE',
'timeout' => 30
]
];
$context = stream_context_create($options);
$response = file_get_contents($url, false, $context);
$data = json_decode($response, true);
echo "Deleted user: {$data['user_id']} ({$data['google_id']})\n";
echo "Reassigned: {$data['total_reassigned']} rows\n";
echo "Deleted: {$data['total_deleted']} records\n";
echo "Message: {$data['message']}\n";
?>
```
## Response
### Success Response (200 OK)
```json
{
"user_id": 1234,
"google_id": "SUB123456789012345678",
"parent_user_id": 42,
"total_reassigned": 787,
"total_deleted": 8,
"message": "Mock user 1234 (SUB123456789012345678) deleted. History (787 rows) reassigned to parent 42."
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| user\_id | integer | Deleted SUB-user ID |
| google\_id | string | Deleted SUB-user's Google ID |
| parent\_user\_id | integer | Parent user ID (history reassigned to this user) |
| total\_reassigned | integer | Total number of reassigned history records |
| total\_deleted | integer | Total number of deleted records |
| message | string | Summary message |
## How Deletion Works
The deletion is performed atomically in a single transaction:
1. **History reassignment** — all order and delegation history of the SUB-user is reassigned to the parent user. No transaction data is lost.
2. **Record cleanup** — SUB-user-specific records (API key, settings, referral data, deposit address) are removed.
3. **Audit trail** — a deletion record is saved for tracking purposes.
## Safety Protections
* **Only SUB-users can be deleted** — real user accounts are protected and cannot be deleted via this endpoint
* **Authorization required** — only the parent user can delete their own SUB-users
* **Transaction safety** — all operations run in a single database transaction (all-or-nothing)
* **History preserved** — order and delegation history is reassigned to the parent, not lost
## Error Responses
### Bad Request (400)
```json
{
"detail": "User with id=9999 not found"
}
```
```json
{
"detail": "User 42 is NOT a mock user (google_id=1234567890). Only users with google_id starting with 'SUB' can be deleted."
}
```
### Forbidden (403)
```json
{
"detail": "Not authorized: you can only delete your own SUB-users."
}
```
### Authentication Error (401)
```json
{
"detail": "X-API-KEY header required"
}
```
### Internal Server Error (500)
```json
{
"detail": "Failed to delete mock user: ..."
}
```
## Error Code Reference
| HTTP Status | Description |
|-------------|-------------|
| `200` | SUB-user deleted successfully |
| `400` | User not found or not a SUB-user |
| `401` | Missing API key header |
| `403` | Not authorized (not parent user) / Invalid API key or IP |
| `500` | Internal server error |
## Notes
* Deletion is **irreversible** — ensure you want to remove the SUB-user before calling this endpoint
* All SUB-user history (orders, delegations) is **reassigned to the parent** — no data is lost
* The deletion record is **permanently stored** in the database audit table
* Referral earnings records are **not affected** by deletion
* If the SUB-user has a non-zero balance, it is **not automatically transferred** — withdraw before deleting
* SUB-users can be created again via [POST /apiv2/subusergen](/api/v2/endpoints/subusergen) endpoint
## Related Endpoints
* [POST /apiv2/subusergen](/api/v2/endpoints/subusergen) — Create a new SUB-user
* [POST /apiv2/address/rotate](/api/v2/endpoints/address-rotate) — Rotate deposit address
* [GET /apiv2/userinfo](/api/v2/endpoints/userinfo) — Get user/SUB-user information
---
---
url: https://doc.netts.io/api/v2/endpoints/subusergen.md
---
# POST /apiv2/subusergen
Create a new SUB-user (sub-account) linked to your main account. SUB-users have their own API key, deposit address, and separate balance for independent energy operations.
## Endpoint URL
```
POST https://netts.io/apiv2/subusergen
```
## Request Headers
| Header | Required | Description |
|--------|----------|-------------|
| Content-Type | Yes | application/json |
| X-API-KEY | Yes | Your API key from Netts dashboard |
| X-Real-IP | Yes | IP address from your whitelist |
## Request Body
```json
{}
```
No parameters required. The SUB-user is automatically linked to the account identified by the API key.
## Example Requests
### cURL
```bash
curl -X POST https://netts.io/apiv2/subusergen \
-H "Content-Type: application/json" \
-H "X-API-KEY: your_api_key" \
-H "X-Real-IP: your_whitelisted_ip" \
-d '{}'
```
### Python
```python
import requests
url = "https://netts.io/apiv2/subusergen"
headers = {
"Content-Type": "application/json",
"X-API-KEY": "your_api_key",
"X-Real-IP": "your_whitelisted_ip"
}
response = requests.post(url, headers=headers, json={})
data = response.json()
if response.status_code == 200:
print(f"SUB User ID: {data['user_id']}")
print(f"Google ID: {data['google_id']}")
print(f"Email: {data['email']}")
print(f"Deposit Address: {data['deposit_address']}")
print(f"API Key: {data['api_key']}")
print(f"Referral Code: {data['referral_code']}")
print(f"Parent User ID: {data['referrer_user_id']}")
else:
print(f"Error: {data.get('detail', 'Unknown error')}")
```
### Node.js
```javascript
const axios = require('axios');
async function createSubUser(apiKey, whitelistedIp) {
const url = 'https://netts.io/apiv2/subusergen';
const response = await axios.post(url, {}, {
headers: {
'Content-Type': 'application/json',
'X-API-KEY': apiKey,
'X-Real-IP': whitelistedIp
},
timeout: 30000
});
const data = response.data;
console.log(`SUB User ID: ${data.user_id}`);
console.log(`API Key: ${data.api_key}`);
console.log(`Deposit Address: ${data.deposit_address}`);
return data;
}
// Usage
createSubUser('your_api_key', 'your_whitelisted_ip')
.then(result => console.log('Created:', result))
.catch(err => console.error('Error:', err.response?.data || err.message));
```
### PHP
```php
[
'header' => implode("\r\n", [
"Content-Type: application/json",
"X-API-KEY: your_api_key",
"X-Real-IP: your_whitelisted_ip"
]),
'method' => 'POST',
'content' => '{}',
'timeout' => 30
]
];
$context = stream_context_create($options);
$response = file_get_contents($url, false, $context);
$data = json_decode($response, true);
echo "SUB User ID: {$data['user_id']}\n";
echo "API Key: {$data['api_key']}\n";
echo "Deposit Address: {$data['deposit_address']}\n";
?>
```
## Response
### Success Response (200 OK)
```json
{
"user_id": 1379,
"google_id": "SUB123456789012345678",
"email": "SUB123456789012345678@gmail.com",
"name": "SUB123456789012345678",
"deposit_address": "TExampleAddress1234567890123456789",
"api_key": "mock1234567890abcdef1234567890ab",
"referral_code": "A2B4K9",
"created_at": "2026-03-14T12:00:00",
"referrer_user_id": 42,
"comment": "SUB user linked to main user (referrer_user_id). Google ID, Email and Name are mock data (not real) that can be updated via separate endpoint. For API services usage, requests must include this SUB user's API key and IP from main user's whitelist. Calculations use SUB user's balance. Generated deposit address is not active."
}
```
### Response Fields
| Field | Type | Description |
|-------|------|-------------|
| user\_id | integer | Unique ID of the created SUB-user |
| google\_id | string | **Fake identifier** (format: `SUB` + 18 digits). Not a real Google account — used only for internal identification of the SUB-user |
| email | string | **Fake email** (google\_id + @gmail.com). Not a real email address — used only for internal identification |
| name | string | Display name (defaults to google\_id). Can be changed in the dashboard |
| deposit\_address | string | Generated TRON deposit address (not active by default) |
| api\_key | string | API key for the SUB-user (prefix: `mock`) |
| referral\_code | string | Generated referral code (6 characters) |
| created\_at | string | Creation timestamp in ISO 8601 format |
| referrer\_user\_id | integer | Parent user ID (the account that created this SUB-user) |
| comment | string | Usage instructions and notes |
::: warning Fake Google Data
The `google_id`, `email`, and `name` fields are **fake data** — they are not real Google accounts or email addresses. These fields exist solely for internal identification of the SUB-user within the system. The **name** and **tag** of a SUB-user can be changed in the [dashboard](https://netts.io).
:::
## How SUB-Users Work
### Key Concepts
* **Separate balance**: Each SUB-user has its own TRX balance independent from the parent
* **Shared IP whitelist**: SUB-user API requests are validated against the parent's IP whitelist
* **Own API key**: Each SUB-user gets a unique API key for authentication
* **Parent linkage**: The SUB-user is permanently linked to the creating account via referral system
* **All API endpoints**: SUB-users can use all API endpoints (order1h, time/order, etc.) with their own API key and balance
### Usage Flow
1. **Create SUB-user** via this endpoint
2. **Fund the SUB-user** by depositing TRX to its deposit address or transferring balance
3. **Use SUB-user's API key** in subsequent API requests (order1h, time/order, etc.)
4. **Monitor** via userinfo endpoint using the SUB-user's API key
## Error Responses
### Authentication Error (401)
```json
{
"detail": "X-API-KEY header required"
}
```
### Forbidden (403)
```json
{
"detail": "Invalid API key or IP not whitelisted"
}
```
### Validation Error (422)
```json
{
"detail": [...],
"body": {...}
}
```
### Internal Server Error (500)
```json
{
"detail": "Failed to create mock user: ..."
}
```
## Error Code Reference
| HTTP Status | Description |
|-------------|-------------|
| `200` | SUB-user created successfully |
| `401` | Missing API key header |
| `403` | Invalid API key or IP not in whitelist |
| `422` | Request validation error |
| `500` | Internal server error |
## Notes
* Empty request body `{}` is required (Content-Type must be application/json)
* The generated deposit address is **not active** by default
* SUB-user's `google_id` and `email` are **fake data** (not real Google accounts), used for internal identification only
* The SUB-user's **name and tag** can be changed in the [dashboard](https://netts.io)
* The SUB-user's API key starts with `mock` prefix
* IP whitelist validation uses the **parent user's** whitelist
* Each SUB-user has its own balance, separate from the parent
* SUB-users can be deleted via [DELETE /apiv2/subuserdel](/api/v2/endpoints/subuserdel) endpoint
* Deposit address can be rotated via [POST /apiv2/address/rotate](/api/v2/endpoints/address-rotate) endpoint
---
---
url: https://doc.netts.io/api/v2/endpoints/usdt-private.md
---
# POST /apiv2/usdt/analyze
Calculate TRON USDT transfer cost (**private** endpoint — authenticated).
Returns the exact same [`TransferAnalysis`](./usdt-public.md#data-transferanalysis)
payload as the public `GET` variant, but with a **much higher rate limit**
(50 req/sec per Kong node instead of 1/sec) and with request data passed in
a JSON body instead of the URL. **Use this endpoint for any production
integration.**
## Endpoint URL
```
POST https://netts.io/apiv2/usdt/analyze
```
## Authentication
Either of the following two headers is accepted (both supported
simultaneously; `X-API-KEY` is preferred because it matches the rest of
the Netts `/apiv2/*` API surface):
| Header | Required | Description |
|-----------------|---------------------------|-------------------------------------------------------------------------------|
| `Content-Type` | Yes | Must be `application/json`. |
| `X-API-KEY` | **Preferred** | Your Netts API key — exactly the same format used for `/apiv2/order1h` and other authenticated Netts endpoints. |
| `Authorization` | Accepted as an alternative| `Bearer {key}` or just `{key}` (no prefix). Use this if your HTTP client has a built-in bearer/auth flow. |
If both headers are sent, `X-API-KEY` wins.
**IP whitelist:** the IP from which the request reaches our edge must be in
the whitelist configured for your API key (same mechanism as the other
`/apiv2/*` endpoints). Requests from a non-whitelisted IP return
`401 Unauthorized` with `"Invalid API key or IP not in whitelist"`.
::: tip Reusing your order1h headers
If you already call `/apiv2/order1h` with `X-API-KEY: {key}`, you can send
the exact same `X-API-KEY` header to `/apiv2/usdt/analyze` — the calculator
now recognises it as the primary authentication header.
:::
## Request body
```json
{
"sender_address": "TFLit1TFohBtT2f8UVCLFVPmZxawxqByYe",
"receiver_address": "TTKR9aQdJWTgXLK9cmzaDitT5VXE497thL"
}
```
### Fields
| Field | Type | Required | Constraints |
|--------------------|--------|----------|---------------------------------------------------------------------------------|
| `sender_address` | string | Yes | Valid TRON address — 34 chars, starts with `T`, valid base58 checksum. |
| `receiver_address` | string | Yes | Valid TRON address; **must differ** from `sender_address`. |
::: tip
There is no `amount` field. The calculator returns the cost and resource
requirements for a single USDT transfer between the two addresses; if you
need the breakdown for a specific USDT amount, multiply the recommended
energy by the transfer count on your side — a single TRC-20 USDT transfer
consumes the same ~130 k energy regardless of amount.
:::
## Request examples
### cURL (preferred — `X-API-KEY`)
```bash
curl -X POST "https://netts.io/apiv2/usdt/analyze" \
-H "Content-Type: application/json" \
-H "X-API-KEY: YOUR_API_KEY" \
-d '{
"sender_address": "TFLit1TFohBtT2f8UVCLFVPmZxawxqByYe",
"receiver_address": "TTKR9aQdJWTgXLK9cmzaDitT5VXE497thL"
}'
```
### cURL (alternative — `Authorization`)
```bash
curl -X POST "https://netts.io/apiv2/usdt/analyze" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{
"sender_address": "TFLit1TFohBtT2f8UVCLFVPmZxawxqByYe",
"receiver_address": "TTKR9aQdJWTgXLK9cmzaDitT5VXE497thL"
}'
```
### Python
```python
import requests
API_KEY = "YOUR_API_KEY"
payload = {
"sender_address": "TFLit1TFohBtT2f8UVCLFVPmZxawxqByYe",
"receiver_address": "TTKR9aQdJWTgXLK9cmzaDitT5VXE497thL",
}
r = requests.post(
"https://netts.io/apiv2/usdt/analyze",
headers={
"Content-Type": "application/json",
"X-API-KEY": API_KEY, # preferred; same header as /apiv2/order1h
# or, equivalently:
# "Authorization": f"Bearer {API_KEY}",
},
json=payload,
timeout=15,
)
if r.status_code == 200:
data = r.json()["data"]
print("Energy needed:", data["requirements"]["energy_with_buffer"])
print("Total cost: ", data["costs"]["total_cost_trx"], "TRX")
print("Method: ", data["costs"]["recommended_method"])
elif r.status_code == 401:
print("Auth failed:", r.json())
elif r.status_code == 429:
print("Rate-limited — Retry-After:", r.headers.get("Retry-After"))
else:
print("Error:", r.status_code, r.json())
```
## Response
### Success (200 OK)
Identical envelope to the public endpoint:
```json
{
"status": "success",
"data": { /* TransferAnalysis — see the public-endpoint page */ },
"current_utc_time": "2026-04-23 11:54:13",
"processing_time_ms": 20.14
}
```
The full field-by-field description of `data` is on the public-endpoint
page — see
[`TransferAnalysis`](./usdt-public.md#data-transferanalysis),
[`AddressInfo`](./usdt-public.md#addressinfo),
[`Requirements`](./usdt-public.md#requirements) and
[`Costs`](./usdt-public.md#costs).
## Errors
::: warning Order of checks
Authentication is validated **before** body validation. If the `Authorization`
header is missing/invalid or your IP is not whitelisted, you will **always**
see `401` — even if the JSON body is also malformed. Fix auth first, then
re-test with a valid key; only then will Pydantic body-validation errors
(`422`) surface.
:::
| HTTP | Body | When |
|------|--------------------------------------------------------------------------------------|----------------------------------------------------------|
| 401 | `{"code": -1, "msg": "API key not provided (expected X-API-KEY or Authorization header)"}` | Neither `X-API-KEY` nor `Authorization` header present. |
| 401 | `{"code": -1, "msg": "Invalid API key or IP not in whitelist"}` | Unknown key, or request IP not in your whitelist. |
| 404 | `{"code": -1, "msg": "User not found"}` | Key valid but user record was not found (rare). |
| 422 | `{"detail": [{"loc": ["body","sender_address"], "msg": "Invalid TRON address length", "type": "value_error"}]}` | FastAPI/Pydantic body validation failed. Status is `422 Unprocessable Entity`, not `400`. |
| 422 | `{"detail": [{..., "msg": "Sender and receiver cannot be the same address", "type": "value_error"}]}` | `sender_address == receiver_address`. |
| 429 | `{"message": "API rate limit exceeded"}` | Sustained traffic beyond `50 req/sec` on a Kong node. |
| 500 | `{"code": -1, "msg": "Internal server error"}` | Unexpected server-side failure. |
## Rate limit
* **50 requests / second** per Kong node (`limit_by = ip`, policy `local`).
* `minute` / `hour` limits are not set — only the per-second limit applies.
* Every response carries the standard Kong headers:
`RateLimit-Limit`, `RateLimit-Remaining`, `RateLimit-Reset`,
`X-RateLimit-Limit-Second`, `X-RateLimit-Remaining-Second`,
and `Retry-After` on a `429`.
### Example 429 response
```http
HTTP/1.1 429 Too Many Requests
Content-Type: application/json; charset=utf-8
RateLimit-Limit: 50
RateLimit-Remaining: 0
RateLimit-Reset: 1
Retry-After: 1
X-RateLimit-Limit-Second: 50
X-RateLimit-Remaining-Second: 0
{"message":"API rate limit exceeded"}
```
::: tip
If you are reaching 50 req/sec with a single API key and need more, contact
support — the limit can be raised per key, or a dedicated rate-limit plugin
can be attached to your consumer.
:::
### Debug headers
Every response also carries identifiers useful when opening a support
ticket — please include them verbatim so we can find the request in our
logs within seconds:
| Header | Meaning |
|--------------------|-----------------------------------------------------------------------|
| `X-Request-ID` | Application-side request ID (generated by the calculator). |
| `X-Process-Time` | Application processing time in milliseconds (upstream, excluding Kong). |
| `X-Kong-Request-Id`| Kong-side request ID (present in Kong access logs). |
## Client-side timeout and retry
The calculator performs live on-chain queries to TRON nodes for each
request, so under load or slow upstream nodes a single call can take
**several seconds**. Short client timeouts will fail even on healthy
responses — this is the root cause of most `cURL error 28 (Connection
timed out)` reports from integrators.
Recommended settings:
* **Timeout ≥ 15 seconds** (30 s is safer). The default 10 s used by
many HTTP clients is too short.
* On **HTTP 429**, honour the `Retry-After` header (seconds). Add
small jitter (e.g. 0–200 ms) before retrying, then use exponential
backoff if you still hit the 50 req/sec limit.
* On **HTTP 5xx** or network errors, retry at most 2–3 times with
exponential backoff; do not hammer the endpoint.
* Cache the result client-side for **30–60 seconds** per
`(sender_address, receiver_address)` pair — the underlying resource
prices and on-chain state rarely change fast enough to warrant more
frequent recalculation.
## Browser / CORS support
**This endpoint is designed for server-to-server integrations** and
currently does not support direct calls from a browser: the upstream
FastAPI app advertises `Access-Control-Allow-Methods: GET` only, so the
preflight `OPTIONS` for a cross-origin `POST` will fail in browsers.
If you need to call the calculator from a browser front-end, proxy the
request through your own back-end (which holds the API key) instead of
exposing the key to the client anyway.
::: tip
If your use case legitimately requires browser-side POST with an API key
(e.g. a trusted internal dashboard on a known origin), contact support —
a CORS plugin can be attached at the Kong level for your route.
:::
## Notes
* Response format is intentionally identical to the public endpoint, so the
client code that parses the public response continues to work after you
migrate to the authenticated variant — only the call itself changes.
* Both `X-API-KEY: {key}` (preferred, consistent with `/apiv2/order1h`)
and `Authorization: Bearer {key}` / `Authorization: {key}` are accepted;
if both are sent, `X-API-KEY` wins.
* Cloudflare / reverse-proxy interposition does not affect this endpoint
the same way it affects the public one, because authenticated traffic is
rate-limited per-Kong-node and per-consumer semantics can be enabled on
request.
---
---
url: https://doc.netts.io/api/v2/endpoints/usdt-public.md
---
# GET /apiv2/usdt/{sender}&{receiver}
Calculate TRON USDT transfer cost (**public** endpoint, no API key required).
Returns a detailed analysis of the sender and receiver accounts, resource
requirements (energy/bandwidth) and recommended cost path.
::: warning Low rate limit — intended for occasional / testing use
This endpoint is shared globally and rate-limited at **1 req/sec** and
**60 req/min**. When your application is behind Cloudflare or another
reverse proxy, the limit may effectively be shared between all clients
reaching Netts through the same edge, so you may see `429 Too Many Requests`
sooner than 60 requests/minute from a single user.
**For anything beyond sporadic calls, use the authenticated
[`POST /apiv2/usdt/analyze`](./usdt-private.md) endpoint — it has a much
higher per-key limit (50 req/sec).**
:::
## Endpoint URL
```
GET https://netts.io/apiv2/usdt/{sender}&{receiver}
```
### URL parameters
| Parameter | Type | Required | Description |
|-----------|--------|----------|----------------------------------|
| sender | string | Yes | TRON address of the sender |
| receiver | string | Yes | TRON address of the receiver |
Addresses are passed in the path, separated by an **ampersand (`&`)**.
Both must be valid base58 TRON addresses (34 characters, start with `T`,
valid checksum).
## Request examples
### cURL
```bash
curl "https://netts.io/apiv2/usdt/TFLit1TFohBtT2f8UVCLFVPmZxawxqByYe&TTKR9aQdJWTgXLK9cmzaDitT5VXE497thL"
```
### Python
```python
import requests
sender = "TFLit1TFohBtT2f8UVCLFVPmZxawxqByYe"
receiver = "TTKR9aQdJWTgXLK9cmzaDitT5VXE497thL"
url = f"https://netts.io/apiv2/usdt/{sender}&{receiver}"
response = requests.get(url, timeout=15)
if response.status_code == 200:
payload = response.json()
data = payload["data"]
print(f"Can transfer: {data['can_transfer']}")
print(f"Energy needed: {data['requirements']['energy_needed']}")
print(f"Bandwidth needed: {data['requirements']['bandwidth_needed']}")
print(f"Total cost (TRX): {data['costs']['total_cost_trx']}")
print(f"Recommended method: {data['costs']['recommended_method']}")
elif response.status_code == 429:
print("Rate-limited — retry after:", response.headers.get("Retry-After"), "s")
else:
print("Error:", response.json())
```
## Response
### Success (200 OK)
Top-level envelope:
```json
{
"status": "success",
"data": { /* TransferAnalysis — see below */ },
"current_utc_time": "2026-04-23 11:54:13",
"processing_time_ms": 19.27
}
```
#### `data` (TransferAnalysis)
| Field | Type | Description |
|------------------|------------------|--------------------------------------------------------------------------------|
| `sender` | `AddressInfo` | Full account info for the sender (balance, staking, delegation, activation). |
| `receiver` | `AddressInfo` | Full account info for the receiver. |
| `requirements` | `Requirements` | Energy / bandwidth the transfer will need (raw + with safety buffer). |
| `costs` | `Costs` | Burn vs. rent cost breakdown and the recommended method. |
| `can_transfer` | `boolean` | `true` if the transfer can be executed with current resources/prices. |
| `issues` | `string[]` | Concerns detected during analysis (e.g. insufficient bandwidth). |
| `recommendations`| `string[]` | Human-readable suggestions for the client. |
| `variation_id` | `string \| null` | Matched scenario ID (e.g. `"CUSTOM"`) from the internal variations catalogue. |
##### `AddressInfo`
Typical fields you will use in integrations: `address`, `is_activated`,
`trx_balance`, `usdt_balance`, `has_usdt`, `energy_balance`,
`bandwidth_balance`. Additional low-level fields for advanced use:
`trx_balance_sun`, `energy_total`, `bandwidth_total`, `bandwidth_free`,
`bandwidth_staked`, `energy_used`, `bandwidth_used`, `create_time`,
`latest_operation_time`, `staked_for_energy`, `staked_for_bandwidth`,
`delegated_for_energy`, `delegated_for_bandwidth`, `delegated_out_energy`,
`delegated_out_bandwidth`, `votes`.
##### `Requirements`
| Field | Type | Description |
|-------------------------|---------|------------------------------------------------------------|
| `energy_needed` | int | Raw energy units required for the transfer. |
| `bandwidth_needed` | int | Raw bandwidth units required. |
| `energy_with_buffer` | int | Energy rounded up to a safe rental tier (e.g. 131 000). |
| `bandwidth_with_buffer` | int | Bandwidth with a small safety buffer. |
| `receiver_has_usdt` | boolean | Whether the receiver already holds USDT (affects energy). |
##### `Costs`
| Field | Type | Description |
|---------------------------|-------------------|--------------------------------------------------------------------------|
| `energy_burn_trx` | decimal | TRX burned if energy is paid via direct burn. |
| `bandwidth_burn_trx` | decimal | TRX burned to cover bandwidth if it is not available for free. |
| `total_burn_trx` | decimal | `energy_burn_trx + bandwidth_burn_trx`. |
| `total_burn_sun` | int | `total_burn_trx` expressed in SUN (10⁻⁶ TRX). |
| `energy_rental_trx` | decimal | Cost to **rent** the required energy from Netts for the period below. |
| `energy_rental_sun` | int | Same as above but in SUN. |
| `rental_time_period` | string | e.g. `"1h"`, `"5m"`, or `"not_needed"` when rental is not the best path. |
| `rental_price_per_unit` | int | Rental price per energy unit in SUN for the chosen period. |
| `savings_trx` | decimal | How much cheaper `rent` is vs. `burn` (can be negative if burn is best). |
| `savings_percentage` | float | Same as a percentage. |
| `recommended_method` | string | `"burn"` or `"rent"` — the cheaper option for the current request. |
| `total_cost_trx` | decimal | null | Actual cost if you follow `recommended_method`. |
| `sender_activation_cost` | decimal | null | Extra cost if the sender account needs activation, else `null`. |
### Example real response (abbreviated)
```json
{
"status": "success",
"data": {
"sender": { "address": "TFLit1...", "is_activated": true, "trx_balance": 191.943, "usdt_balance": 24410.499, "energy_balance": 195297, "bandwidth_balance": 148, "has_usdt": true, "...": "..." },
"receiver": { "address": "TTKR9a...", "is_activated": true, "trx_balance": 18.656, "usdt_balance": 0.0, "energy_balance": 0, "bandwidth_balance": 263, "has_usdt": false, "...": "..." },
"requirements": {
"energy_needed": 130285,
"bandwidth_needed": 345,
"energy_with_buffer": 131000,
"bandwidth_with_buffer": 360,
"receiver_has_usdt": false
},
"costs": {
"energy_burn_trx": 0.0,
"bandwidth_burn_trx": 0.345,
"total_burn_trx": 0.345,
"total_burn_sun": 345000,
"energy_rental_trx": 0.0,
"energy_rental_sun": 0,
"rental_time_period": "not_needed",
"rental_price_per_unit": 0,
"savings_trx": 0.0,
"savings_percentage": 0.0,
"recommended_method": "burn",
"total_cost_trx": 0.345,
"sender_activation_cost": null
},
"can_transfer": true,
"issues": [
"Insufficient bandwidth: have 148, need 345. Network will burn 0.345 TRX for full amount"
],
"recommendations": [
"Insufficient bandwidth: have 148, need 345. Full amount of 0.345 TRX will be burned",
"💰 Total cost: 0.345 TRX (burn for all resources)"
],
"variation_id": "CUSTOM"
},
"current_utc_time": "2026-04-23 11:54:13",
"processing_time_ms": 19.27
}
```
## Errors
| HTTP | Body (example) | When |
|------|----------------------------------------------------------------------|---------------------------------------------------------------------|
| 400 | `{"code": -1, "msg": "Invalid sender address format: Txyz..."}` | Address fails TRON base58 / length / checksum validation. |
| 400 | `{"code": -1, "msg": "Expected at least 2 parameters: sender&receiver"}` | URL does not contain two addresses separated by `&`. |
| 400 | `{"code": -1, "msg": "Sender and receiver cannot be the same address"}` | Sender and receiver addresses are identical. |
| 429 | `{"message": "API rate limit exceeded"}` | Rate limit exceeded (see the warning at the top of this page). |
| 500 | `{"code": -1, "msg": "Internal server error"}` | Unexpected server-side failure. |
### Rate-limit headers
On every response (including 429) the following headers are returned:
| Header | Meaning |
|-------------------------------|--------------------------------------------------------------|
| `X-RateLimit-Limit-Second` | Maximum requests allowed per second (currently `1`). |
| `X-RateLimit-Remaining-Second`| How many you may still send this second. |
| `X-RateLimit-Limit-Minute` | Maximum requests allowed per minute (currently `60`). |
| `X-RateLimit-Remaining-Minute`| How many you may still send this minute. |
| `Retry-After` | On a 429 — seconds to wait before retrying. |
### Debug headers
Every response also carries identifiers useful when opening a support
ticket — please include them verbatim so we can find the request in our
logs within seconds:
| Header | Meaning |
|--------------------|-----------------------------------------------------------------------|
| `X-Request-ID` | Application-side request ID (generated by the calculator). |
| `X-Process-Time` | Application processing time in milliseconds (upstream, excluding Kong). |
| `X-Kong-Request-Id`| Kong-side request ID (present in Kong access logs). |
## Client-side timeout and retry
The calculator performs live on-chain queries to TRON nodes for each
request, so under load or slow upstream nodes a single call can take
**several seconds**. Short client timeouts will fail even on healthy
responses.
Recommended settings:
* **Timeout ≥ 15 seconds** (30 s is safer). The default 10 s used by
many HTTP clients is too short.
* On **HTTP 429**, honour the `Retry-After` header (seconds). Add
small jitter (e.g. 0–200 ms) before retrying, then use exponential
backoff if you still hit the limit.
* On **HTTP 5xx** or network errors, retry at most 2–3 times with
exponential backoff; do not hammer the endpoint.
* Cache the result client-side for **30–60 seconds** per
`(sender, receiver)` pair — the underlying resource prices and
on-chain state rarely change fast enough to warrant more frequent
recalculation.
### Example 429 response
```http
HTTP/1.1 429 Too Many Requests
Content-Type: application/json; charset=utf-8
RateLimit-Limit: 1
RateLimit-Remaining: 0
RateLimit-Reset: 1
Retry-After: 1
X-RateLimit-Limit-Second: 1
X-RateLimit-Remaining-Second: 0
X-RateLimit-Limit-Minute: 60
X-RateLimit-Remaining-Minute: 0
{"message":"API rate limit exceeded"}
```
## Notes
* Anonymous access: no `X-API-KEY`, no `Authorization` header, no IP whitelist.
* The response is always wrapped in `{status, data, current_utc_time, processing_time_ms}` —
integrations should read pricing from `data.costs` and requirements from `data.requirements`.
* The response is computed in real time — it reflects the current TRON
resource prices from Netts and the current on-chain state of both
addresses, so expect small variations between consecutive calls.
* If your application needs to call the calculator more than a few times
per minute (per-IP / per-CF-edge), **switch to
[`POST /apiv2/usdt/analyze`](./usdt-private.md)** with your API key.
---
---
url: https://doc.netts.io/api/v2/endpoints/balances.md
---
# GET /apiv2/balances/{address}
Read the balances of any TRON address: right now, at a past moment, over time, or summed up for a period. Six endpoints, all synchronous — the answer comes in the reply, there is no queue and nothing to poll.
## Endpoint base URL
```
https://netts.io/apiv2/balances/{address}
```
`{address}` is a TRON address in base58, exactly 34 characters.
## Request headers
| Header | Required | Description |
|--------|----------|-------------|
| `X-API-KEY` | yes | API key from the dashboard |
| `X-Real-IP` | yes | An address from the key whitelist |
Your account balance must be at least **4 TRX**. A depleted account is answered with `402` before the request reaches the data.
## The six endpoints
| Endpoint | Answers |
|----------|---------|
| `GET /apiv2/balances/{address}` | every token held right now |
| `GET /apiv2/balances/{address}/at?on=YYYY-MM-DD` | balances at the **end** of that date, UTC |
| `GET /apiv2/balances/{address}/at-block?block=N` | balances at an exact block, or at `ts=YYYY-MM-DD HH:MM:SS` |
| `GET /apiv2/balances/{address}/history?token_id=TRX&days=90` | how one token moved, day by day |
| `GET /apiv2/balances/{address}/summary?date_from=&date_to=` | opening, inflow, outflow, fees and closing per token |
| `GET /apiv2/balances/{address}/statement?date_from=&date_to=` | statement preview with individual operations |
## Example
```bash
curl -s 'https://netts.io/apiv2/balances/TXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' \
-H 'X-API-KEY: your-api-key' \
-H 'X-Real-IP: 203.0.113.10'
```
```json
{
"status": "success",
"code": 0,
"msg": "",
"data": {
"address": "TXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"as_of_block": 86012345,
"live": false,
"hide_spam": false,
"total_value_usd": "385.25",
"balances": [
{
"token_id": "TRX",
"symbol": "TRON",
"token_type": "TRX",
"decimals": 6,
"balance": "1141.899000",
"price_usd": "0.334968",
"value_usd": "382.50",
"is_verified": true,
"is_spam": false,
"balance_source": "events",
"node_balance": "1141.899000"
}
]
}
}
```
## Things worth knowing before you integrate
**Amounts are strings, not numbers.** `"1141.899000"` is a decimal serialised as text so that no precision is lost to a floating-point round trip. Parse it with a decimal type, not a float.
**In a reply about the past, `balance` is the answer and `node_balance` is not.** `balance` is the amount at the point you asked about. `node_balance` is what the chain holds *right now*, in every reply — so in an answer about last month it still shows today's number. Never display it as the historical amount. For a question about *now* the roles swap; that is the next section.
**A date means the end of that day.** `?on=2026-09-01` answers for `2026-09-01 23:59:59Z`. If you need the start of a day, ask for the end of the previous one, or use `/at-block` with an explicit `ts`.
### Two balances, and why "now" is the tricky one
A reply carries two different numbers, and on an active address they do not agree:
| Field | What it is | When it is exact |
|---|---|---|
| `balance` | The **ledger** value, rebuilt from indexed chain events up to the block reported in `as_of_block` | Exact for that block — which is not the newest block |
| `node_balance` | What a TRON node holds **right now** | Always current, never historical |
**`balance` is not "the balance on the chain right now".** It is the balance as of `as_of_block`. When you need the chain's present number, read `node_balance` — it is taken from a TRON node at request time and, for TRX, by the full formula: liquid balance plus staked `frozenV2` plus what is delegated out. On an address holding 41.7 million staked TRX it answered `42035672.226020`, which is exactly `237799.226020 + 41760434 + 36816 + 623`. Reading only the node's plain `balance` field would have shown 237 thousand and been wrong by two orders of magnitude.
**But `node_balance` is not filled in for every row.** TRX and every TRC10 come back in one `getaccount` call, so they always carry it. TRC20 cannot: a node has no way to list the TRC20 tokens an address holds, so `balanceOf` is only asked for the major ones. Measured on a wallet with 504 TRC20 rows, 494 of them came back `null`. That `null` is policy rather than a failure, and the same `null` appears if the node is briefly unreachable. So for TRX and TRC10 the chain's present value is always available to you; for a long-tail TRC20 all you have is `balance` and the block it stands on.
The ledger advances to a block only once every indexing writer has confirmed that block, and its watermark is the minimum across all of them. The slowest writers publish their marks in batches, so the gap widens steadily and then snaps back — a sawtooth, not a constant.
Sampled over a 20-minute window on 6 September 2026:
| | Blocks behind the head | Time behind |
|---|---|---|
| Best | 22 | ~1 min |
| Median | 44 | ~2 min |
| 90th percentile | 86 | ~4 min |
| Worst observed | 121 | ~6 min |
**Plan for the ledger being a few minutes behind the chain, not a few seconds.**
What follows from that:
* **A quiet address is exact even for "now".** Once nothing has moved for longer than the current lag, the ledger has caught up and `balance` equals `node_balance`.
* **On an address that just transacted, `balance` can be wrong in either direction** — too low while an incoming transfer is still unindexed, too high while an outgoing one is.
* **`live=true` narrows the gap without closing it.** It applies the tail of transfer events between `as_of_block` and the chain head on the fly, for 30–80 ms. It does not move `as_of_block`, it does not account for fees, and it deliberately skips TRC10 tokens, which are tracked by a separate index. A measured example: an address whose ledger reported `157.317444` TRX answered `766.194807` with `live=true`, while the node held `1698.995472`. Helpful, but `node_balance` stays the only field that is the chain's current value.
* **Historical answers are exact, full stop.** `/at`, `/at-block`, `/history`, `/summary` and `/statement` describe points the ledger passed long ago. There is no lag to account for.
For accounting, reconciliation and statements, use the historical endpoints and trust them. For a live wallet screen, show `node_balance` where it is present — which covers TRX and every TRC10 — and fall back to `balance` with `as_of_block` beside it where it is `null`, so the reader knows which block the number stands on.
**`/history` returns only the days that had activity.** Asking for `days=7` on an address that moved on three of them returns three points, not seven. Each point carries that day's closing `balance` and the `delta` against the previous point.
**`/summary` reconciles itself.** For every token `opening_balance + period_in − period_out − period_fees = closing_balance`, and the engine returns that arithmetic already written out in `control_formula`, for example `76493.940406 + 141490.950160 - 216763.731366 - 79.260200 = 1141.899000`. Fees are broken out into `period_fees_energy` and `period_fees_bandwidth`. Note that `/summary` may report a small negative balance for a token that the current-balance endpoint leaves out entirely.
**`/statement` is capped by `ops_limit`.** It accepts 10 to 5000 operations; anything outside that range is a `422`. `operations_total` is the real count for the period and `operations_truncated` says whether the list was cut short. `token_id` defaults to `TRX` when omitted. For a complete statement beyond 5000 operations, order a file instead — see [Statement files](./reports-statement.md).
**Token order is deliberate.** TRX and the major stablecoins come first, then verified tokens that have a price, then everything else. Do not re-sort by amount: airdropped spam often carries enormous nominal balances and would float to the top.
**Spam is marked, not removed.** `is_spam` flags tokens classified as deceptive. Pass `hide_spam=true` to drop them from the reply; TRX and USDT are never hidden.
## Rate limits
Each endpoint accepts **10 requests per second**, shared across all clients of that endpoint. The limit is per endpoint, so `/history` and `/summary` do not compete with each other.
Exceeding it gives `429` with `Retry-After: 1`, alongside `RateLimit-Limit`, `RateLimit-Remaining` and `RateLimit-Reset`. Retry after the stated delay.
A second, much wider limit of 100 requests per second per source IP applies across the whole API. The two are told apart by the message: the endpoint limit says `Endpoint rate limit exceeded (10 req/s shared)`, the account-wide one says `API rate limit exceeded`.
## Errors
| HTTP | Meaning |
|------|---------|
| `400` | the address is 34 characters but fails its base58 checksum |
| `401` | key missing or invalid, or the source IP is not whitelisted |
| `402` | account balance below the 4 TRX minimum |
| `403` | the API key is blocked; contact support |
| `422` | a parameter is missing or out of range — a wrong address length, or an `ops_limit` outside 10–5000 |
| `429` | rate limit exceeded |
| `503` | the balance engine did not answer; the request was not counted, retry |
Error bodies come in three shapes, depending on which layer rejected the request. Match on the HTTP status, not on the body.
```json
// 401, 402, 403 — the gateway, before the request reaches the service
{"detail": {"code": 1004, "msg": "Insufficient funds. Minimum balance is 4 TRX. Please top up your account."}}
// 400, 422 — the service, after parameters are parsed
{"status": "error", "code": -4, "msg": "address must be base58 (T...)", "data": {"code": -4, "msg": "address must be base58 (T...)"}}
// 429 — the rate limiter
{"message": "Endpoint rate limit exceeded (10 req/s shared), retry shortly", "request_id": "e5dbf25437d2eb215c764617d50b8d3b"}
```
## Related
* [Statement files](./reports-statement.md) — the full statement as a CSV or PDF file
* [Report webhooks](./reports-webhooks.md) — being told when a file is ready
---
---
url: https://doc.netts.io/api/v2/endpoints/reports-statement.md
---
# POST /apiv2/reports/statement
Order a statement file — every operation of one token over a period, as CSV or PDF. The file is built in the background: the request returns an order number straight away, and the file is fetched once it is ready.
For a quick look at the same data without waiting, use the [statement preview](./balances.md) instead — it answers immediately but caps the number of operations it returns.
## Endpoint base URL
```
https://netts.io/apiv2/reports
```
## Request headers
| Header | Required | Description |
|--------|----------|-------------|
| `X-API-KEY` | yes | API key from the dashboard |
| `X-Real-IP` | yes | An address from the key whitelist |
| `X-Idempotency-Key` | no | Your own key, 12–128 chars of `A-Z a-z 0-9 . _ : -` |
## Order a file
```bash
curl -s -X POST 'https://netts.io/apiv2/reports/statement' \
-H 'X-API-KEY: your-api-key' \
-H 'X-Real-IP: 203.0.113.10' \
-H 'Content-Type: application/json' \
-d '{
"client_request_id": "stmt-2026-09-usdt",
"address": "TXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"token_id": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
"date_from": "2026-09-01",
"date_to": "2026-09-30",
"format": "csv"
}'
```
```json
{
"status": "success",
"code": 0,
"msg": "created",
"data": {
"order_no": "REPxxxxxxxxxxxx",
"client_request_id": "stmt-2026-09-usdt",
"type": "statement",
"status": "queued",
"quota_bucket": "free",
"progress_pct": 0,
"address": "TXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"token_id": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
"date_from": "2026-09-01",
"date_to": "2026-09-30",
"format": "csv",
"created_at": "2026-09-06 17:01:51.868542+00:00",
"finished_at": null,
"expires_at": null,
"artifact_sha256": null,
"artifact_size": null,
"download_url": null
}
}
```
| Field | Required | Notes |
|-------|----------|-------|
| `client_request_id` | yes | Your identifier. Unique per account |
| `address` | yes | TRON base58, 34 characters |
| `token_id` | no | `TRX` by default; a TRC20 contract or a TRC10 id |
| `date_from`, `date_to` | yes | UTC, inclusive. At most 366 days |
| `format` | no | `csv` by default. PDF is limited to 5000 operations |
## Then wait for it
```bash
curl -s 'https://netts.io/apiv2/reports/REPxxxxxxxxxxxx' \
-H 'X-API-KEY: your-api-key' -H 'X-Real-IP: 203.0.113.10'
```
The `status` field walks through `queued` → `running` → `waiting_cypherarc` → `done`. Two more are terminal: `error`, with the reason in `error_code` and `error_message`, and `expired` once the file has aged out. A short statement is usually ready in well under a minute; treat any status other than `done` as "keep waiting".
Once it is `done`, `download_url` is filled in — as a path, not a full URL — and the file can be fetched:
```bash
curl -s -OJ 'https://netts.io/apiv2/reports/REPxxxxxxxxxxxx/download' \
-H 'X-API-KEY: your-api-key' -H 'X-Real-IP: 203.0.113.10'
```
**The file arrives gzipped.** A CSV order downloads as `application/gzip` with a `.csv.gz` filename in `Content-Disposition`; decompress it before parsing. The status reply carries `artifact_sha256` and `artifact_size` for the compressed file exactly as delivered, so you can verify the download without a second request.
Rather than polling, [register a webhook](./reports-webhooks.md) and be told when the file is ready.
## Repeating a request is safe
Send the same `client_request_id`, or the same `X-Idempotency-Key`, and you get the existing order back instead of a second one being built. The reply carries `"msg": "existing"` so you can tell the two apart.
Reusing an identifier with a **different** body is an error, not a new order: that gives `409`. Identifiers are unique within your account only — another account's identifiers never collide with yours.
## Files live for 30 days
After that the order becomes `expired` and downloading gives `410`. Order it again if you need it later.
## Rate limits
**10 requests per second** per endpoint, shared across all clients. Exceeding it gives `429` with `Retry-After: 1` and the message `Endpoint rate limit exceeded (10 req/s shared)`.
That is the only limit. There is no monthly quota, no cap on how many files you may order, and no limit on how many build at once — an account with a positive balance may order as much as the rate limit allows. Orders beyond what the build queue can take are held and retried automatically rather than refused, so a burst costs you latency, not failures.
## Errors
| HTTP | Meaning |
|------|---------|
| `400` | the address is 34 characters but fails its base58 checksum |
| `401` | key missing or invalid, or the source IP is not whitelisted |
| `402` | account balance below the 4 TRX minimum |
| `403` | the API key is blocked; contact support |
| `409` | the same identifier was used with a different body — the body is `IDEMPOTENCY_CONFLICT` |
| `410` | the file has expired |
| `422` | a field is missing or malformed, or the period exceeds 366 days |
| `429` | rate limit exceeded — retry after `Retry-After` |
## Related
* [Balances](./balances.md) — reading balances and the instant statement preview
* [Report webhooks](./reports-webhooks.md) — notification when a file is ready
---
---
url: https://doc.netts.io/api/v2/endpoints/reports-webhooks.md
---
# POST /apiv2/reports/webhooks
Register a URL and NETTS will call it when a report is ready, instead of you polling for the status.
These endpoints are **separate** from the [order webhooks](./webhooks.md). Registering there does not subscribe you to report notifications, and the other way round. The wire format — signature, headers, retry behaviour — is identical, so a handler written for one works for the other.
## Endpoint base URL
```
https://netts.io/apiv2/reports/webhooks
```
## Request headers
| Header | Required | Description |
|--------|----------|-------------|
| `X-API-KEY` | yes | API key from the dashboard |
| `X-Real-IP` | yes | An address from the key whitelist |
## Primary and backup
Up to two endpoints per account. `primary` receives everything. `backup` is used only after delivery to the primary has run out of attempts — and it is signed with **its own** secret, not the primary's.
## Register
```bash
curl -s -X POST 'https://netts.io/apiv2/reports/webhooks' \
-H 'X-API-KEY: your-api-key' \
-H 'X-Real-IP: 203.0.113.10' \
-H 'Content-Type: application/json' \
-d '{"url": "https://example.com/netts/reports", "role": "primary"}'
```
```json
{
"status": "success",
"code": 10000,
"data": {
"id": 1,
"url": "https://example.com/netts/reports",
"role": "primary",
"is_active": true,
"created_at": "2026-09-06 17:05:12+00:00",
"updated_at": "2026-09-06 17:05:12+00:00",
"secret": "whsec_<64 hex characters>"
}
}
```
**The secret is shown once, here.** It is never returned again — not by the list, not by the read endpoint. Store it when you receive it. If it is lost, issue a new one:
```bash
curl -s -X POST 'https://netts.io/apiv2/reports/webhooks/1/rotate-secret' \
-H 'X-API-KEY: your-api-key' -H 'X-Real-IP: 203.0.113.10'
```
Rotation takes effect immediately and the old secret stops verifying, so deploy the new value first if you cannot tolerate a gap.
## Manage
| Method | Path | Action |
|--------|------|--------|
| `GET` | `/apiv2/reports/webhooks` | list yours, without secrets |
| `GET` | `/apiv2/reports/webhooks/{id}` | read one |
| `PATCH` | `/apiv2/reports/webhooks/{id}` | change `url`, or pause with `is_active: false` |
| `DELETE` | `/apiv2/reports/webhooks/{id}` | remove it |
The URL must be public HTTPS. Loopback, private and link-local addresses are rejected, as are credentials inside the URL. Anything rejected comes back as `422` with the reason. The check runs again immediately before every delivery, so an endpoint that later resolves to a private address stops receiving.
## What we send
```json
{
"event": "report.ready",
"delivery_id": 4,
"order_id": "REPxxxxxxxxxxxx",
"order_type": "statement",
"client_request_id": "stmt-2026-09-usdt",
"status": "done",
"format": "csv",
"download_url": "/apiv2/reports/REPxxxxxxxxxxxx/download",
"expires_at": "2026-10-06 15:48:04+00:00",
"artifact": { "sha256": "…", "size_bytes": 696 },
"confirmed_at": "2026-09-06T15:48:04Z"
}
```
| Field | Description |
|-------|-------------|
| `event` | `report.ready` — routing key for your handler |
| `delivery_id` | **Dedup key.** Also sent as the `X-Netts-Delivery` header |
| `order_id` | The order number you were given when you queued the report |
| `order_type` | `statement` or `balance_at_date` |
| `download_url` | Path to fetch the file, relative to `https://netts.io` |
| `artifact.sha256` | Checksum, so you can verify what you downloaded |
| `confirmed_at` | UTC |
All timestamps are UTC.
## Verifying the signature
```
X-Netts-Signature: sha256=
X-Netts-Timestamp:
X-Netts-Delivery:
```
The signature is HMAC-SHA256 over `"." + raw body`, computed with the secret of the endpoint that **received** the request. Compare in constant time and reject anything whose timestamp falls outside a ±5 minute window.
```python
import hmac, hashlib, time
def verify(raw_body: bytes, sig_header: str, ts_header: str, secret: str) -> bool:
if abs(time.time() - int(ts_header)) > 300: # anti-replay
return False
signed = f"{ts_header}.".encode() + raw_body
expected = "sha256=" + hmac.new(secret.encode(), signed, hashlib.sha256).hexdigest()
return hmac.compare_digest(expected, sig_header)
```
Sign with the secret of the URL the request arrived at: primary and backup have different secrets.
## Delivery is at-least-once
A dropped response causes a retry, so the same event can arrive twice.
1. **Deduplicate by `delivery_id`.** A repeat must be a no-op on your side.
2. **Verify the signature before acting**, not after.
3. **Answer `2xx` only once you have stored the event.** Anything else, or a timeout, is treated as a failure and retried.
Retries to one endpoint go at 1 minute, 5 minutes, 15 minutes, 1 hour, 6 hours and 24 hours — six attempts in all, spanning a little over 31 hours. When they are exhausted and you registered a `backup`, the delivery moves there and the schedule starts over with the backup's own secret. The `delivery_id` stays the same throughout, so an event that failed on the primary and succeeded on the backup is still **one** event.
Redirects are not followed.
## Rate limits
**10 requests per second** per endpoint, shared across all clients.
## Errors
Registering answers `201`, deleting answers `204` with no body, everything else `200`.
| HTTP | Meaning |
|------|---------|
| `401` | key missing or invalid, or the source IP is not whitelisted |
| `404` | no such endpoint on your account |
| `409` | the requested role is already taken — `role primary is already taken` |
| `422` | the URL was rejected, or a `PATCH` body carried nothing to change |
| `429` | rate limit exceeded |
A rejected URL comes back as `422` with the reason spelled out, so you can show it to whoever typed it:
```json
{"status": "error", "code": -4, "msg": "url: Value error, invalid webhook_url: resolved address 127.0.0.1 is not public"}
```
The wordings are `only https:// URLs are allowed`, `credentials in URL are not allowed`, and `resolved address is not public`. The last one is resolved at registration time and again immediately before every delivery, so a hostname that later points at a private address stops receiving.
## Related
* [Statement files](./reports-statement.md) — ordering the report that triggers this notification
* [Order webhooks](./webhooks.md) — the separate registry for energy, bandwidth and activation events
---
---
url: >-
https://doc.netts.io/blog/articles/choosing-a-service-for-renting-energy-in-the-tron-network.md
description: >-
The Tron blockchain is one of the most flexible cryptocurrency ecosystems,
providing the highest transaction speed – up to 2000 per second. At the same
time, the gas fee is one of the lowest, if users...
---
# Choosing a Service for Renting Energy in the Tron Network
The Tron blockchain is one of the most flexible cryptocurrency ecosystems, providing the highest transaction speed – up to 2000 per second. At the same time, the gas fee is one of the lowest, if users are well aware of which means are best to use for paying commissions.
Yes, Tron is practically the only blockchain that provides users with a wide choice of means for paying gas fees. Unlike other cryptocurrency networks that require commission payments exclusively in their native crypto. Tron users can use:
* Tron's native crypto – TRX;
* Special resources Energy and Bandwidth;
* USDT TRC-20 stablecoins for their transfer.
The last option is suitable for those who rarely transfer large volumes of USDT TRC-20, do not have TRX on their balance, and do not want to deal with using resources. Beginners in the Tron ecosystem can also use this method of payment for transferring stablecoins initially.
To pay for a USDT TRC-20 transfer transaction in the same currency, you should use the recently launched GasFree function and activate your wallet. This is significantly more expensive than paying for a similar operation with native crypto and even more so – with special Tron resources.
## What is the Energy Resource in the Tron Network
To ensure high transaction speeds, the blockchain draws on additional capacities – computational and energetic. It is fair that every user conducting a transaction should compensate the blockchain for these costs.
So that users do not burn the limited volume of TRX in the Tron system in transactions, special resources were developed with which network participants can pay commissions. These are the already mentioned Energy and Bandwidth. The names of the resources make it clear for compensating which costs each of them is intended.
Validators determine the volume of Bandwidth that is credited daily for free to each user's balance. Currently, this is 600 units, which is enough for two transactions with TRC-10 standard tokens. But this resource is also required for interacting with smart contracts (TRC-20 standard tokens). For example, transferring USDT TRC-20 (which is a smart contract) requires 345 units of Bandwidth. Some users forget about this, but the system remembers, and then begins to take TRX from the user's balance to cover the missing Bandwidth units. Of course, these are small amounts, but if we are talking about an exchange that makes dozens of transfers per day to different wallets, it can add up to a decent sum in native crypto.
And if the user's account has insufficient Energy resource, the TRX consumption will be simply enormous. Is it possible to avoid such inefficient spending of Tron's native crypto?
Of course, and there are two ways to do this. The first is staking: that is, you temporarily give the blockchain the right to dispose of a certain volume of TRX. For which Tron rewards you with resources. If you have the opportunity to withdraw such a large volume of TRX from circulation to receive the required amount of Energy – congratulations: you will have practically zero gas fees.
But to get enough Energy, for example, to transfer USDT TRC-20 to just two addresses per day, you must freeze ~24,000 TRX (~6000 USD) for half a month. Again, congratulations if this does not present any difficulties for you. And again, let us remind you that some exchanges conduct dozens of Tron stablecoin transfers per day.
Why are we talking about USDT TRC-20 transfers – that is, about the stablecoin of the Tron network specifically? Because today it is the most demanded cryptocurrency pegged to the US dollar exchange rate. The transfer operation is a call to a smart contract, the fuel for which in the Tron network is the Energy resource.
This means that any exchange or other decentralized platform that deals with cryptocurrencies requires significant amounts of Energy to interact with USDT TRC-20 on the Tron network.
Naturally, it is extremely unprofitable for these business platforms to spend TRX on commissions or withdraw large volumes of Tron's native crypto from circulation. Therefore, the most successful and effective decentralized exchanges choose to rent Energy through special services built on the Tron blockchain to replenish their Energy balance.
We explain what criteria cryptocurrency business platforms, as well as individual users, should be guided by when choosing an Energy rental service.
## Criterion 1. Rental Cost
This is one of the main factors in searching for and choosing an Energy rental service. You should proceed from how much you will save when using the service's services compared to if you paid for transactions in TRX.
It is clear that we are not considering staking for frequent interactions with smart contracts, since this method requires large investments, withdrawing crypto from circulation for 2 weeks, and does not guarantee the necessary volume of Energy during network overload. In addition, it is necessary to constantly keep records and monitor reserves, which, of course, does not exclude errors.
We recommend not trusting the unsubstantiated claims of services to verify the real cost of rented Energy. It is enough to conduct a "control purchase" to understand the real situation.
But at the first stage, you can filter out services with more expensive services, even based on their price lists. Let's take for comparison the already known TRON POOL ENERGY service and the recently launched NETTS Energy rental service on the Tron network.
Above is a screenshot from the TRON POOL ENERGY Telegram bot, which promises up to 65% savings on commissions.
And below are screenshots already from invoices for rented Energy, which the NETTS Energy rental service provided to its clients for 1 hour. Please note that in both cases the client rented 131K units of Energy.
That is, this is already a working moment, and you can see for yourself that at different times of the day, savings on transactions using NETTS services can be from 79 to almost 82%.
Why such a difference? The second invoice was issued for charging the wallet with Energy during a period of minimal network load. The NETTS Energy rental service, whenever possible, uses Tron's dynamic energy supply model in favor of the client.
As already noted, many well-known platforms have now also begun to provide Energy rental services. For example, the Energy rental offers of the Feee.io platform, which was initially built for resource exchange trading, are more designed for large Tron traders who are provided with additional discounts.
But a screenshot of the results of renting only 32K units of Energy indicates that for "retail" renters, the savings on commissions are somewhat different from those stated.
## Criterion 2. Interface Convenience
Here, of course, services that are initially designed for Energy rental services "win". For most large platforms, this service is no longer the main one, so the interface remains the one that was developed for trading cryptocurrency assets, exchanging, etc. At best, such a cryptocurrency platform will offer a Telegram bot.
We recommend giving preference to services that are built on the Tron network specifically for Energy rental. As a rule, such services have both a web interface and a Telegram bot.
This is convenient for serving users with different Energy volume requirements. A Telegram bot is a simpler principle of process automation, while a web interface allows connecting the client's wallet via API. And this expands the possibilities for the client up to ordering Energy wallet charging on a schedule or in accordance with an established trigger.
Below is a screenshot from the personal account of a NETTS Energy rental service client who has set a certain level of this resource on the balance. As soon as the Energy reserves reach this trigger, recharging is performed.
As can be seen even from this screenshot, the interface is maximally simple and convenient. And the main page immediately offers to fill out a form, also very simple and concise.
The NETTS Workspace page is also very simple and convenient to manage – all API capabilities, Smart and Host modes, and other tools are available and easy to find.
And compare with the interface of the Feee.io platform, where you will get to the rental section through the main page, and only then you can create an account.
## Criterion 3. Speed of Operation
Imagine a situation: you are sure that the agreed volume of Energy has arrived in your wallet and you start a transaction. And suddenly you notice that the network has burned your TRX. This is in the best case, in the worst – the transaction freezes. This means that the rented Energy arrived on the balance with a delay, albeit a small one, but for the Tron network this is enough.
That is, the speed of rented Energy delivery from the service is of great importance. Therefore, it is necessary to inquire about how long after payment the rented Energy will be credited to the balance.
The NETTS Energy rental service provides clients with the opportunity to choose a payment method – a deposit (15 TRX on the Telegram bot and 1 TRX in the personal account of the Workspace web interface with API connection) or prepayment when entering through the web interface by filling out a form.
Making a deposit implies:
* in Host mode – cyclical delivery of rented Energy according to your schedule or constant balance replenishment (eternal Energy);
* in Smart mode - delivery according to trigger readings.
That is, there simply cannot be any time delay.
When entering through the interface by filling out a form and prepaying, the time for replenishing the NETTS service client's balance is a couple of seconds after payment.
## Criterion 4. Additional Functions and Integrations
Additional functions expand the possibilities of using the Energy rental service, and integration with other platforms facilitates the workflow.
Therefore, when choosing an Energy rental service, pay attention to:
* availability of API for process automation;
* possibility of automatic Energy replenishment when its level on the balance decreases;
* integration with popular wallets and exchanges.
Again, let's compare several services that provide Energy rental services on the Tron network – as an example of studying one of the selection categories.
| Service | API | Auto-Replenishment | Integration with Wallets |
| :--------------- | :-------------- | :------------- | :---------------------------- |
| FeeSaver | No | Yes | TronLink |
| Tron Pool Energy | Limited | No | TronLink, Trust Wallet |
| NETTS | Full API | Yes | TronLink, Trust Wallet, Binance Wallet |
## Criterion 5. Customer Support and Reputation
This is the last category in our list in order, but far from the last in importance, since quality customer support helps to quickly solve their problems. And the reputation of the service is formed precisely on the basis of reviews and user experience.
Therefore, when choosing an Energy rental service, find out the potential lessor's compliance with this criterion, paying attention to the following points:
* availability of support service (24/7, e-mail, Telegram, chat);
* speed of response to user requests;
* reviews on forums and comments from the crypto community.
## Conclusion
1. Choosing a service for renting Energy in the Tron network is an important step to reduce transaction fees when interacting with smart contracts, in particular – when transferring USDT TRC-20.
2. Key criteria: rental cost, interface convenience, speed of operation, API support, and quality of service.
3. The NETTS Energy rental service offers the best conditions according to all the above criteria: cost and quality of services, client comfort, absence of hidden fees, reliability.
Rent Energy through the NETTS service – and save up to 80% on transactions right now. NETTS is with you – against inefficient TRX burning:
---
---
url: >-
https://doc.netts.io/blog/articles/energy-rental-services-on-the-tron-network-save-up-to-80-on-transaction-fees.md
description: >-
The Tron (TRX) ecosystem is one of the popular blockchain platforms known for
low transaction fees, high throughput, and reliability. Instead of charging
gas fees (transaction fees) in the native TRX ...
---
# Energy Rental Service on the Tron Network. Save up to 80% on Transaction Fees
The Tron (TRX) ecosystem is one of the popular blockchain platforms known for low transaction fees, high throughput, and reliability. Instead of charging gas fees (transaction fees) in the native TRX crypto, like other cryptocurrency blockchains, the Tron network uses specialized resources: Bandwidth and Energy.
The Bandwidth resource ensures ordinary transactions with TRX and TRC-10 format tokens, but smart contracts and TRC-20 tokens (e.g., USDT TRC-20) require Energy on the balance in addition to Bandwidth.
If the user interacting with a smart contract does not have enough Energy or Bandwidth in their wallet, the network starts burning TRX to pay for gas. And if there is not enough TRX on the user's balance either, it is impossible to successfully complete the transaction, just like any other operation with smart contracts on the Tron blockchain.
## How Resources Are Obtained on the Tron Network
The peculiarity of these specialized Tron resources is that they allow reducing gas fees to zero or significantly minimizing them. Since, by using Bandwidth and Energy, you can avoid using TRX to pay transaction fees. But where can you get these Tron resources?
You will find 600 units of Bandwidth on your balance every day – this is the amount currently voted for by the blockchain community representatives. This amount is enough for several simple transactions or one smart contract transaction.
The Energy resource can be obtained on the balance in two ways: staking and renting through special services operating on the Tron blockchain.
### Staking (Freezing) TRX
When you send a certain amount of TRX to staking (freeze it), you receive resources depending on the volume. The user chooses which resource to receive in exchange for the frozen TRX.\
The advantage of this method is the possibility of obtaining Tron Power (TP), which allows voting for Super Representatives and receiving additional rewards. The reward is approximately 4.5% per annum in TRX tokens.\
TRX sent to staking can be unfrozen, but not instantly: the unfreezing period is 14 days (according to current network conditions). And this is already one of the disadvantages of the method.
Moreover, the amount of Energy received daily for staking changes dynamically for the same amount of your TRX. The more users freeze TRX to obtain Energy, the less Energy each participant receives. That is, you cannot be sure that the Energy received for staking will be enough for your daily transactions, and it is impossible to top up the frozen amount.
### Renting Energy
If you need to quickly perform transactions with tokens (e.g., USDT) or interact with smart contracts, but you do not want to freeze a large amount of TRX for a long period, you can rent Energy from specialized services.\
Renting is significantly cheaper than burning TRX for each transaction (savings of up to 80% and more with the NETTS service), and does not require large initial investments.
## Why Renting is More Profitable Than Burning TRX
If there is no Energy in your wallet, the network "converts" the necessary amount of smart contract computing power into TRX and burns it. With intensive use of TRC-20 tokens (e.g., USDT), the fee can reach tens of TRX per transaction. For example, to obtain 64,285 units of Energy and transfer USDT to an address that already contains USDT, 13.8 TRX is required, and to obtain 130,285 units of Energy when transferring to an address where there is no USDT, 27.35 TRX is needed.\
In contrast, when you have Energy (either your own or rented), you do not pay TRX for calling a smart contract: the fee becomes zero or minimal. Thus, even if renting Energy involves a fee in TRX, it is almost always much cheaper than burning TRX tokens for each transaction. Savings can reach 80% or more, as, for example, with the NETTS Energy rental service.
### Why Renting Can Be More Profitable Than Staking Yourself
* **No need to freeze large amounts.** To obtain 131,000 units of Energy (enough for one USDT transaction to a "clean" address without USDT), current network indicators require freezing about 11,684 TRX, which at a price of $0.242 (approximate cost at the time of writing) is about $2,827.52. Moreover, this value changes dynamically: tomorrow you may need even more TRX.
* **Flexibility in use.** When renting, you pay a small fixed amount of TRX and receive the necessary amount of Energy for a specific period (day, week, month, etc.). You do not have to buy TRX every time or keep them frozen if they are needed for other purposes.
* **Full Energy recovery in 24 hours when renting for a long period.** Spent Energy is restored to your account within a day. This means that if you rent, for example, 131,000 Energy for 30 days, you can perform one USDT transaction per day to a new address (which previously did not contain USDT) or two transactions per day to an address where USDT already exists (requires less Energy). The resource replenishes every 24 hours.
Thus, renting Energy is a convenient tool for those who do not want to invest in large-scale staking but regularly perform operations with smart contracts on the Tron network.
## Overview of Energy Rental Services in the Tron Ecosystem
Below is a list of some of the most well-known platforms and services providing Energy rental. They allow users to avoid burning TRX with each transaction without freezing large volumes of TRX. Please note that rental conditions may change, so it is recommended to monitor current offers.
### 1. Feee.io
Website: [https://feee.io](https://feee.io/?ic=A72A)\
A service specifically created for renting and trading Tron resources (Energy and Bandwidth). Main features:
1. **Exchange trading.** Allows creating orders to buy or sell resources with the necessary parameters.
2. **Fast transactions.** The service automatically matches a suitable offer, and the required amount of Energy is credited to the user's wallet within minutes.
3. **Earning opportunities.** Users with large TRX reserves can rent out their resources to other participants.
Feee.io is especially convenient for those who frequently make transactions and want to save money by avoiding the systematic burning of TRX.
### 2. Netts.io
Website: [https://netts.io](https://netts.io/)\
Bot:
A relatively recently created but rapidly developing service, initially designed for convenient USDT transfers and Energy rental. We emphasize this because for platforms that simply added the Energy rental function alongside other services, it often did not become a priority.
The NETTS rental service started with a simple web interface with login via a website form, then a Telegram bot was added, and now clients have access to a unique Workspace with the possibility of connecting via API and two modes: Smart and Host.
The NETTS team are enthusiasts of the Tron network, they know all the user problems from the inside, as they are users themselves. Therefore, all improvements introduced on the service expand the comfort of network participants and significantly reduce their spending on transactions with TRC-20 format tokens, particularly with USDT TRC-20, in other words – with smart contracts.
As a result, NETTS clients have a number of significant advantages compared to other Tron users interacting with smart contracts, including large platforms engaged in daily USDT TRC-20 transfers to dozens of addresses.
1. **Minimal service fees for rented Energy.**\
For example, a USDT transfer transaction costs clients 3–6 TRX depending on the recipient's wallet status. The same operation without rented Energy costs 14–27 TRX. 80% savings – the only offer on the market from NETTS. The screenshot on the right shows the bill for the same amount of rented Energy during the night with minimal network load.
2. **Choice of automation level.**\
NETTS clients, depending on the volumes and type of tasks performed, can log in via the website form with prepayment, via the Telegram bot with a 15 TRX deposit, or via the Workspace cabinet with API connection with a 1 TRX deposit. The level of automation is inversely proportional to the deposit size.
3. **Ability to regulate the Energy supply mode as needed.**\
This function is provided by the unique Smart and Host modes. The first allows the client to set a trigger, the Energy balance will not drop below this level, because upon reaching this indicator, NETTS will immediately recharge the wallet to the initial level.
Host is a mode of constant Energy replenishment (perpetual Energy in the wallet!) or according to a schedule developed by the client. Both varieties can be paused if needed by the client.
The NETTS Energy rental service has already gained recognition in the Tron community, offering flexible rental options, fee optimization, and incredible savings. Bonus from the service: during periods of minimal network load, the client's deposit is charged only for the Energy actually used by them.
Test the capabilities of the NETTS service right now – simply make a deposit on Workspace (from just 1 TRX). By the way, it can be withdrawn back at any time.
### 3. TronSave
Website: \
Wallet:
TronSave — a platform built on the TRON Stake 2.0 mechanism, aimed at reducing transaction costs in the Tron ecosystem, as well as providing secure and reliable tools for working with Energy. The project has established itself through active participation in the Tron Hackathon: it ranked in the top three in Season 4 and won 1st place in the Builder category in Season 5, confirming the high quality and reliability of its solutions.
Main advantages for users:
* savings on transaction fees in the Tron network thanks to advantageous Energy rental;
* simplicity and convenience: Energy rental is available for both individuals and projects, with an intuitive interface;
* earn income on unused Energy: users who freeze TRX can receive additional income by renting out unused Energy;
Main advantages for Energy providers:
* up to 25% APY on frozen TRX through providing Energy rental via TronSave;
* stable passive income: you continue to receive staking rewards while renting out Energy to optimize profits;
* flexibility and reliability: you retain full control over frozen TRX, using their Energy to generate additional income.
Additional tools:
* Bulk sender (SaveSender): a service for mass distribution of tokens among a large number of users — fast, convenient, and with optimized fees;
* Swap: an integrated exchange tool with SunSwap, allowing the exchange of various crypto assets in a few clicks;
* SaveWallet ([savewallet.io](https://savewallet.io/)): a crypto wallet developed for the Tron ecosystem that reduces network fees and supports DApps. The project also offers a convenient built-in exchange for quick token conversion.
Thus, TronSave not only significantly reduces transaction costs but also allows earning additional income on frozen TRX. Users receive a high level of security and convenience, and the built-in tools (bulk sender, swap, SaveWallet) make interaction with the Tron ecosystem even simpler and more economical.
### 4. JustLend DAO
Website: \
One of the first DeFi platforms in the Tron ecosystem where you can supply and borrow assets, including crypto resources.
Automated lending platform: orders are matched automatically, without manual negotiation of rates.
Energy rental is one of the "side" functions, where prices depend on market conditions, and you can specify the desired rental period.
TRX is used as collateral, which is returned upon return of the rented Energy.\
Although JustLend DAO is primarily focused on lending digital assets, it can also be used for renting Energy, although its interface may seem less convenient compared to specialized services.
### 5. Tron Energy Market (TEM)
Website: \
The goal of TEM is to simplify the automatic purchase, sale, and rental of Energy. Main features:
* Pool system: orders to buy or sell Energy are processed instantly, without long waiting times;
* Direct rewards in TRX for sellers: payments are made directly in TRX, without the use of secondary tokens or delays in payouts;
* Buyers are guaranteed that prices will not dynamically increase depending on the volume.
### 6. Tron Pulse
Website: \
A P2P platform where users can directly buy and sell Energy.
* **Peer-to-Peer model:** users place their own orders, and the platform connects buyers and sellers.
* **User-friendly interface:** dashboard with analytics and detailed transaction information.
* **Integration with TronLink:** absence of custodial risks — you manage your resources directly from your wallet.
Tron Pulse is aimed at users who prefer direct trading of resources with other participants.
### 7. Tron Energize
Website: \
A project focused on innovation in Energy rental:
* **P2P platform** for direct access to and exchange of Energy resources;
* **Automation** — distribution of Energy through smart contracts and decentralized infrastructure;
* **Transparency** — all actions are recorded on the blockchain.
Initially created to simplify and reduce the cost of renting Energy for active users in the Tron ecosystem.
### 8. Tron Energy
Website: \
A service allowing users to choose a convenient format for renting Energy.
* **Flexible minimum rental**, starting from 32,000 units of Energy.
* **Hourly or daily rental** — advantageous if you need Energy for a short period.
* **Various ordering methods:** manual, bulk, via API, or smart managed order (based on transaction history).
* **Low entry threshold and no fees for each small contract.**
### 9. Tron Fee Energy Rental
Website: \
TRON Energy rental service with the following features:
* **Save up to 60% on rental fees;**
* **High transfer speed** — transactions are processed in seconds;
* **Potential for additional earnings:** users can rent out their Energy and receive commissions;
* **Supports payments in TRX or USDT**, as well as manual and automated (via API) modes.
### 10. Mefree.net
Website: \
Developers position this platform as the "leading provider" of Tron Energy.
* **Oriented towards individual users, DApp developers, and businesses.**
* **API integration** for automatic Energy rental in applications.
* **Secure transactions**, ensured by encryption.
Mefree.net aims to make its services accessible and effective for various categories of clients.
### 11. Tron Lending
Website: \
A self-service platform for Energy lending and resource trading that:
* reduces the cost of Energy consumption;
* actively supports DApp projects lacking Energy;
* provides a comprehensive set of tools for managing Energy loans, collateral, returns, etc.
**Additional Solutions**
1. **DApp Egon.** Simplifies access to Tron Stake 2.0, including Energy rental and saving on transaction fees.
2. **Brutus Energy Bot.** A Telegram bot that automates the rental and transfer of Tron resources.
3. **com (API).** A specialized "Tron Energy market" where no user interface is required.
## Conclusion
Renting Tron Energy is a convenient way to reduce fees when transferring USDT and using smart contracts on the Tron network without burning your own TRX or freezing large amounts. Thanks to numerous services, users can choose the option that best suits their needs based on cost, rental period, interface, and additional features:
* save up to 80% by eliminating TRX fees for each operation;
* avoid freezing large amounts, which allows maintaining liquidity;
* rent Energy for a period from one hour to one month and perform the required number of transactions without fees in TRX;
* ability to set your own mode for replenishing the Energy balance.
Choose the service that best meets your requirements (level of automation, rental period, payment mechanism) and enjoy using the Tron network with minimal costs. We hope this review helps you make the right choice and significantly save on transaction fees.
---
---
url: >-
https://doc.netts.io/blog/articles/how-are-new-technologies-gasfree-layer-2-changing-fees-in-blockchains.md
description: >-
The main problem with blockchain (including cryptocurrency blockchain) is
choosing two qualities out of three possible: performance (i.e., transaction
speed), security, and decentralization....
---
# How Are New Technologies (GasFree, Layer 2) Changing Fees in Blockchains?
The main problem with blockchain (including cryptocurrency blockchain) is choosing two qualities out of three possible: performance (i.e., transaction speed), security, and decentralization.
Each successful crypto blockchain chooses its niche. For example, the Tron ecosystem offers the fastest transactions (up to 2000 per second), while Ethereum offers maximum decentralization, etc.
However, for almost all blockchain networks, besides striving for the maximum trinity (performance + security + decentralization), high transaction fees remain a problem. Therefore, it is not surprising that cryptocurrency blockchain system teams are constantly searching for, developing, and implementing new technologies that reduce user costs.
This is especially true for interactions with smart contracts, which are the basis for stablecoins (tokens pegged to the rate of fiat currencies), as well as decentralized applications (DApps), including DeFi (finance), gaming, governance, social networks, etc.
DApp developers, entrepreneurs, and individuals who regularly transfer stablecoins—in short, everyone who interacts with smart contracts on a cryptocurrency blockchain in any capacity—wants to eliminate native crypto from gas payments or at least reduce these expenses.
Let's consider how modern technologies, such as GasFree and Layer 2 solutions, affect the reduction of fees in blockchain networks, and why renting Energy remains the most advantageous solution for paying gas fees in the Tron ecosystem. After all, this solution allows for savings of 40-80% on transactions compared to paying with TRX (Tron's native crypto).
First, let's look at the impact of GasFree and Layer 2 solutions on commission sizes, and then compare their effectiveness with the efficiency of renting Energy. Which technology or function really saves your money?
## GasFree Technology
When Justin Sun announced that Tron was eliminating mandatory gas fees, he wasn't mystifying. Users who were ready for this, and even cryptocurrency experts (some, admittedly, with a degree of skepticism), welcomed this information as a hope for the complete abolition of transaction fees.
Everyone eagerly awaited the launch of the GasFree function. As it turned out, it meant a refusal to pay gas fees in the form acceptable in the Tron system. That is – with native TRX crypto and/or special Energy and Bandwidth resources. Instead, users of the GasFree function, which can only be used for USDT TRC-20 transfers, pay commissions in USDT. Moreover, this payment for transferring USDT to one address is currently higher than when recalculated into resources, and even more so – into TRX, since 600 Bandwidth is provided free of charge on the Tron network, and Energy can be staked. But if a large volume is needed, it is, of course, better to rent.
Those who know how the Tron blockchain works are not surprised by this turn of events. Launching any smart contract on the Tron blockchain (and USDT is a smart contract) requires network resources Energy and Bandwidth. To transfer any amount of USDT TRC-20 to an empty wallet (without these stablecoins), 131K units of Energy and 345 units of Bandwidth will be required. If the recipient's address already has USDT, half as much Energy will be needed.
Let's compare how many resources will be required for such a transfer using the GasFree function:
* for a transfer to an empty wallet – ~155,000 Energy;
* for a transfer to a wallet with USDT – ~221,000 Energy;
* for each transfer, regardless of the wallet's state – 699 Bandwidth.
And then these network costs for supporting your transaction via the GasFree function are recalculated into USDT.
### Conclusion
1. Using GasFree allows users to make transactions without directly paying gas fees in Tron network resources and TRX.
2. The transaction fee can be paid by a third party, for example, a service or a decentralized application (dApp). But in this case, additional commissions from this third party are not excluded.
3. This improves the user experience by eliminating the need to own native tokens to pay for gas. Moreover, it is most suitable for those who regularly, but infrequently, transfer large volumes of USDT and do not want to bother with resources and TRX, or for beginners who have not yet understood the capabilities of the Tron blockchain. But for active users who transfer constantly and frequently, this is very ruinous.
4. The implementation of GasFree requires additional resources from services, which limits its application, for example, for paying for transactions with DApps.
## Layer 2 Solutions
Most blockchain systems have a multi-level architecture. But to expand functionality, performance, scalability, and reduce transaction fees, Layer 2 technologies can be implemented. An example of such a technology that works on top of the Tron ecosystem (Layer 1) is the BitTorrent Chain (BTTC), whose goal is to scale the blockchain.
There are also such technologies for reducing commissions, some of which are also partially solved by improving scalability. The principle of such technologies is processing transactions off the main blockchain. After processing, transactions are combined into blocks and recorded in the blockchain archive.
This principle reduces the load on the system, and consequently, reduces the costs of computing and energy capacities for transaction processing, which, in turn, leads to a reduction in gas fees.
### Examples of Layer 2 Solutions
1. Lightning Network for Bitcoin, allowing for fast and cheap transactions between participants without recording each transaction on the main blockchain.
2. Optimistic Rollups and ZK-Rollups for Ethereum, which combine many transactions and record them as one on the main blockchain, reducing fees and increasing transaction speed.
### Conclusion
Although Layer 2 technologies can help reduce transaction fees, they require additional setup and can be complex for ordinary users.
And in practice, we see that transactions, particularly on the Ethereum network when interacting with smart contracts, are still significantly more expensive than on the Tron network, if one knows the specifics of the Tron blockchain platform and the possibilities offered by renting the Energy network resource.
## Renting Energy on the Tron Network
The Tron ecosystem is constantly expanding the options for users to independently choose how to pay for gas. We have already mentioned the recently implemented GasFree function, which, despite switching to USDT for transfer payments, is actually based on the same system of calculation in Tron network resources – Energy and Bandwidth.
This once again confirms the flexibility of this blockchain, which strives to take into account the interests of users with different goals, means, and experience.
Active users who frequently and regularly interact with smart contracts have long known and used all the possibilities that Tron provides for replenishing Energy reserves, a resource often called fuel for smart contracts.
Of course, the most numerous transactions are those with the USDT TRC-20 stablecoin, for one transfer of which you need to have ~65K or ~131K units of Energy on your balance, depending on the recipient's balance status. Business platforms can make dozens of transfers to different addresses. Of course, they require not just a significant reserve of Energy, but also constant replenishment.
The options provided by the Tron network for replenishing Energy reserves are designed for different users.
1. Users can stake (freeze) their TRX to receive Energy used to pay transaction fees. But this requires withdrawing funds from circulation for 2 weeks. Moreover, to get Energy for a couple of transfers, you need to freeze ~24,000 TRX. That is, this method is suitable for those who rarely and irregularly interact with smart contracts. It is not suitable for developers and business platforms. In addition, it is difficult to calculate the exact need for Energy, as well as the amount you will receive from staking. The first depends on the network load during the transaction, and the second depends on the total volume of TRX currently staked by all Tron users.
2. Paying for transactions in TRX, buying or exchanging for Tron network resources are only suitable for a one-time operation; constantly using such methods is extremely wasteful. Although the burning of Energy in huge quantities in transactions, especially those related to USDT transfers, can still be observed daily. This suggests that Tron users know little or nothing about the most profitable way to get Energy cheaply and in the required volumes almost around the clock.
3. The Tron ecosystem supports Energy rental services operating on the blockchain. This is the easiest and most accessible way for everyone to significantly reduce commissions, especially for users who frequently make transactions.
NETTS Energy rental service not only promises but demonstrates every day how you can save about 80% on transactions.
The NETTS Workspace system is an opportunity to connect via API and charge your balance with Energy according to a schedule convenient for you. You set a threshold for the Energy volume in your wallet, and when the resource volume drops to the specified level, the balance is automatically replenished – this is how the Smart mode works by trigger.
For active users, Host mode options are also suitable – constant replenishment of the Energy balance and a cyclical principle of charging the wallet with the resource.
If you do not need such volumes of Energy, you can still use NETTS services – even for a one-time replenishment of your wallet, you will still save up to 80% on transactions. And sometimes – even more.
As mentioned above, Tron has a dynamic energy supply model. The screenshots above clearly demonstrate this. The first is an invoice for a daytime charge of 131K units of Energy, the second – for a nighttime charge.
The deposit is 15 TRX when entering via Netts Energy Charge Bot and only 1 TRX – for Workspace. API connection is possible only when entering through the web interface.
Another important advantage of NETTS Workspace with API connection: during periods of low Tron network load (50% of charges), only the cost of the Energy you actually consumed will be debited from your deposit – the debit for unused Energy will be returned.
## Comparison of Methods for Reducing Commissions
Let's summarize all of the above: what are the pros and cons of each approach to influencing commissions, what they lead to, and what benefits users receive.
### GasFree
Pros: Improves user experience by eliminating the need for the user to pay for gas in native crypto and Tron network resources.
Cons: Requires additional resources from services, limiting scalability, and increases the cost of transactions in USDT.
### Layer 2
Pros: Reduces fees and increases transaction speed.
Cons: Complexity of setup and use for ordinary users; commissions ultimately still lose out when compared to commissions on the Tron network.
### Renting Energy in Tron
Pros: Ease of use, significant reduction in commissions – 30-80% depending on the choice of Energy rental service, does not require large investments unlike staking – usually a deposit, which is more convenient than prepayment.
You don't even need to understand the mechanism of renting Energy, available only on the Tron network, or make tedious calculations – NETTS will do everything for you. You won't have to worry if there will be enough Energy for the transaction this time. With NETTS, you'll have as much as you need.
Conclusion
Although GasFree and Layer 2 technologies offer effective ways to reduce commissions, renting Energy on the Tron network remains the most profitable and accessible solution for users, especially with frequent transactions.
NETTS Energy rental service saves your TRX and saves you about 80% of your transaction costs. It's simple – deposit 1 TRX, log in, and use it right now - https://netts.io
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-avoid-fake-services-and-scammers-on-the-tron-network.md
description: >-
The demand for any product in any field, including the cryptocurrency
business, attracts the attention of scammers. The rapidly growing Tron
cryptocurrency blockchain, which has made its USDT TRC-20 s...
---
# How to Avoid Fake Services and Scammers on the Tron Network
The demand for any product in any field, including the cryptocurrency business, attracts the attention of scammers. The rapidly growing Tron cryptocurrency blockchain, which has made its USDT TRC-20 stablecoin a leader, is no exception. This token, pegged to the US dollar exchange rate (1:1), is most actively used by the cryptocurrency community for transfers. The reason is Tron's high throughput (up to 2000 transactions per second), low commissions, and flexible gas fee system.
Naturally, as the popularity of the Tron network grew, so did the number of fake services and scammers targeting users. The eco-platform's efforts to combat fraudulent platforms have not yet led to their final expulsion from the blockchain.
Therefore, it is important for users to be able to distinguish reliable platforms from fake ones to protect their funds.
We provide recommendations for recognizing fraudulent services in the Tron ecosystem and explain how to distinguish them from reliable platforms.
Let's consider the main signs of fraudulent services and give recommendations for choosing reliable platforms.
## Common Scam Schemes on the Tron Network
Let's consider the main signs of fraudulent services from the point of view of the user deception mechanism used.
Among the most popular scam schemes on the Tron network are those related to the blockchain's native crypto TRX and the stablecoin created by Tether Limited specifically for the Tron system.
### Multisignature Scams
One of the most common schemes, which is constantly being modified to catch new users. This scam method is based on the multisignature function, which was developed and implemented on the Tron network precisely to prevent theft. The function is that not one user, but several, can use a wallet. In this case, a transaction occurs with several signatures. Compare this to the method of storing keys to one safe by several bank employees.
Excellent idea, but attackers found a loophole here too. They convince victims to send supposedly missing TRX tokens to pay the commission for withdrawing USDT, promising a percentage of the transfer amount, for example, or even the amount on the balance. "I have 500 USDT, but no TRX to pay for their withdrawal. Could you help me, here is my seed phrase." And the victim indeed gains access to the wallet with the promised balance. But the victim does not pay attention to the fact that they do not control the wallet itself. The listed commissions go to the scammer.
If a user is not in the habit of checking their account permissions or has not transferred assets for a long time, they usually will not notice the changes made by the scammer. Who can take advantage of this when a significant amount of assets accumulates on such a user's balance, and transfer them to their own wallet.
The second option is to fraudulently obtain access to private keys or seed phrases. And here, success depends on the scammer's charm and knowledge of psychology.
### Fake Wallets and Applications
Fake applications and fake wallets steal both user data and their funds.
The events of 2022 are widely known – a scam using the Trust wallet (Trust Wallet) cost web-3 users 4 million dollars.
And of course, scammers were particularly pleased in May 2023 to learn that Trust Wallet now supports the Tron network, meaning it allows interaction with native TRX crypto, USDT, and USDC stablecoins.
The scammer's goal is to convince the user to sign a transaction, which facilitates access to the victim's funds. The "profitable" offer can be anything – from fake, quickly recoupable investments in DeFi, a new (equally fake) token – any pretext that requires a signature. This will facilitate the redirection of funds to the attacker's account.
### Phishing Sites
Sites are created that mimic official Tron services, through which user data is stolen. These schemes are also based on the user losing control over their accounts.
An example is fake sites with an airdrop marketing strategy, where an unsolicited distribution of a token or native crypto coin is allegedly made for free to a large number of addresses on the network. By reacting to such an offer, users open access for scammers to their assets.
### Zero Transfer Phishing
This type of scam was discovered on the Tron network in 2023, when it became known that as a result of such transfers, users lost more than 451 million USDT (TRC-20).
In this case, attackers do not even need to know the user's key – they send zero-value transactions simply so that their addresses appear in the victim's transaction history.
Often in such fraudulent schemes, addresses are used that at first glance look similar to those where the victim sends assets. Attackers may leave the same set of characters at the beginning and end of the address line.
If the user is not in the habit of carefully checking the recipient's address, they simply compare the initial and final characters of the address line, copy it, and send their tokens or other assets directly to the scammer's address themselves.
## Signs of Reliable Services in the Tron Ecosystem
How to determine if a service is safe? First of all, a Tron user (and not necessarily with a significant balance in their wallet) should always remember that scammers will definitely take advantage of a loss of vigilance. Therefore, before contacting any service built on the Tron platform, pay attention to the main parameters that can identify an attacker even at the approach.
1. Regulation and Licenses. Reliable platforms are regulated by financial (fiscal) authorities and have licenses.
2. Team Transparency. Open information about developers and the company.
3. Positive Reviews. Recommendations from users on independent sites and forums.
4. Security. Two-factor authentication, data encryption, protection against hacking.
## How to Check the Reliability of a Service Before Using
To verify the reliability of any service offering its services on the Tron network, a statement on the main page of this service that it fully complies with legal requirements is not enough.
Simple steps to check the reliability of a service on the Tron network:
* Check the domain and security certificate (SSL) – be guided by the fact that official sites use HTTPS;
* Study the documentation – be guided by the fact that reliable projects have a White Paper, API documentation;
* User reviews – be guided by the ratio of positive and negative assessments given in comments on forums and social networks;
* Test transactions – an effective verification method that helps to ensure the service's functionality by transferring small amounts;
* Use TronScan – the official Tron blockchain explorer to check suspicious addresses, and better yet – all unknown and even supposedly known ones.
## NETTS Energy Rental Service. Principles of Operation and Security Guarantees
The recently launched NETTS Energy rental service raises no doubts among Tron users, as it meets all the criteria of a legal platform on this blockchain. The service's goal is to provide users with the necessary volume of the special Energy resource, which is used on the Tron network to pay transaction fees. As a result, the gas fee is reduced by 5 times compared to burning TRX and more than 3 times compared to investing in staking.
### Why Users Trust NETTS
1. Regulation. The NETTS Energy rental service operates legally and complies with financial requirements in full accordance with the legislation in this area.
2. Transparency. All information about the company is publicly available with the appropriate required confirmations.
3. Security. The service uses encryption, account protection, and transaction monitoring.
4. 24/7 Support. Ready to help at any time of the day or week.
Tron system users can use either the Netts Energy Charge Bot (deposit 15 TRX) or the web interface (deposit 1 TRX when creating an account in Workspace) to replenish their Energy resource balance, or fill out an application form for a one-time delivery with prepayment (the amount depends on the volume of rented Energy).
The peculiarity of the web interface is that those who need constant (round-the-clock) Energy balance replenishment can connect via API. You set a minimum below which the Energy level in your wallet should not fall – this is a trigger delivery in Smart mode. For more frequent transfers, NETTS clients also choose Host mode – continuous Energy delivery or cyclical – according to your schedule.
From this moment on, you no longer need to worry about the availability of this resource in your wallet – you simply make transactions without being distracted by balance control. The need for preliminary accurate calculation also disappears – you simply take as much Energy as is required for each transaction. At the same time, you are not dependent on TRX volatility, as in staking, nor on the state of the network.
By the way, if the network conditions allow, then with low system load, the NETTS Energy rental service mechanism will deduct from your deposit only the amount for the Energy actually used. From the screenshots below, you can see that the TRX deduction from the deposit differs during the day and at night, even without peak overloads, but simply in the normal operation mode of the blockchain.
And assess your savings on transactions when using rented Energy – about 80%!!! There are no such offers on the market yet – proven in practice. The service team constantly conducts marketing research, knowing the Energy rental market perfectly. Therefore, it always has a sufficient volume of this resource to meet any needs for it.
## Conclusion
Be careful when choosing services on the Tron network. Scammers create fake platforms to conduct phishing attacks on users' wallets. In doing so, they even create analogs of existing sites and services with minor additions to the official names. A user, thinking that this is an extension, for example, of the TronScan explorer (yes, there is such a case in the history of fraud on the Tron network) trusts it with their data, which is then used to steal funds from the victim's wallet.
Therefore, be sure to check platforms before entrusting them with your funds. These are quite simple and accessible steps, neglecting which can cost significant asset losses.
NETTS service offers safe Energy rental at any time of any day and a convenient API. All information about the service is publicly available. Try it right now by depositing just 1 TRX into Workspace! And from that moment on, 80% of your TRX will not burn in the fire of transactions. Find a better use for them!
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-avoid-overspending-energy-tips-for-active-users.md
description: >-
The flexibility and adaptability of the Tron blockchain, additional security
layers, and its initial focus on easy integration with many complex
programming languages have made it a leader in cryptocu...
---
# How to Avoid Overspending Energy: Tips for Active Users
The flexibility and adaptability of the Tron blockchain, additional security layers, and its initial focus on easy integration with many complex programming languages have made it a leader in cryptocurrency systems that actively use smart contracts. In particular, DeFi and DApp products, as well as other TRC-20 standard tokens, such as USDT TRC-20 – the most popular cryptocurrency stablecoin.
Tron's efficient virtual machine is compatible with Ethereum's virtual machine: developers can easily transfer their DApps from Ethereum to Tron. Of course, the fact that Tron is the fastest blockchain also plays a significant role in the selection criteria for users interacting with smart contracts.
But active users who frequently interact with smart contracts know another advantage of this ecosystem.
This is the only cryptocurrency blockchain where transaction fees can be paid not only in the native TRX crypto. This is the case on all other mainly mining-based cryptocurrency platforms. There, the so-called gas fee is only possible in the system's native crypto.
Tron provides its users with several options for paying gas fees:
* Native TRX crypto;
* Special resources Energy and Bandwidth;
* USDT when transferring these stablecoins using the GasFree function.
Native crypto can be used much more profitably – send it for staking to receive Energy and Bandwidth resources, passive income, the ability to participate in blockchain governance, pay for Tron content, exchange for other assets, etc.
For active users who interact with TRC-20 standard tokens (smart contracts), it is very unprofitable to use TRX to pay transaction fees – the consumption is too high and extremely inefficient.
The same applies to using the GasFree function if the user constantly transfers USDT. For each transfer, instead of paying gas fees in Energy and Bandwidth, they will pay 10 USDT. This function is good for rare transfers made by holders of large assets who are too lazy or don't have time to understand Tron's resources.
But if a Tron user constantly interacts with smart contracts, for example, develops or interacts with DApps (DeFi applications, Play-to-Earn or Move-To-Earn games, metaverses, etc.), regularly and frequently transfers USDT TRC-20, etc., they will, of course, prefer to use Energy and Bandwidth to pay gas fees.
Because, firstly, Bandwidth is replenished on their balance by the blockchain itself daily and for free, and secondly, Tron allows not only staking TRX to receive free Energy. Energy rental services are currently being built and actively developing on the blockchain, the advantages of which are described below.
The special resource Energy, which Tron blockchain users can use to pay gas fees, allows for significant fee reductions compared to other means and methods of payment. But if Energy is used inefficiently, it is consumed faster. Note that the screenshot below separately shows graphs of Energy resource consumption in the Tron network obtained as a result of staking TRX and purchasing for TRX.
It is clear that rented Energy is not reflected here as a separate graph. And yet, renting is the most effective way to replenish the Energy balance, but more on that later.
Some users encounter a situation where Energy runs out earlier than planned. In such cases, the blockchain simply starts taking TRX without asking or warning, to cover the Energy spent on the transaction. In the worst case (if there is no TRX reserve), the transaction hangs, usually irretrievably, if the user has no way to instantly replenish the Energy balance. Is such replenishment even possible? Just keep reading – and you'll find out.
We explain how to effectively use Energy in the Tron ecosystem to avoid wasting it and overpaying for fees. We break down the main reasons for overspending and ways to optimize.
## Why Is Energy Consumed Faster Than Expected?
There are several points that every user should pay attention to when dealing with smart contracts. These programs (transaction protocols) are sensitive to the dynamic energy consumption model currently implemented in the Tron blockchain. Therefore, any change in the network status will also lead to a change in transaction fees in real time.
Energy will be consumed faster if the user does not foresee all the features of the smart contract itself, as well as the process of interacting with it.
You will encounter Energy overspending in the following cases.
1. Transactions are conducted during high network load, when the network's need for additional capacity increases. In this case, more Energy will be required for each transaction to pass successfully, which will be debited from the user's balance.
2. Too many small transfers are sent, which leads to greater resource consumption.
3. A smart contract is a transaction protocol. If unoptimized smart contracts are used, they will require more Energy and Bandwidth to pay for gas.
4. Part of the Energy is spent on test transfers. If the user has not taken this into account, Energy overspending is possible.
#### Conclusion
To avoid overspending Energy, you should control when and how transactions are sent.
## Tips for Reducing Energy Consumption
If you know the reasons for excessive Energy consumption, which are outlined above, it is easy to avoid situations that lead to TRX burning and can cause transactions to freeze.
### 1. Send Transfers During Periods of Low Network Load
During peak hours (usually in the evening UTC), Energy consumption increases.
Before sending, check the network status on TronScan. If you regularly interact with smart contracts on the Tron network, we recommend registering with this explorer to always be aware of all the details of the network status.
#### Conclusion
If the TronScan explorer shows that the network is overloaded, it is better to wait until the load normalizes to reduce Energy consumption.
### 2. Group Transactions Instead of Sending Many Small Payments
Each transaction requires a minimum of 40,000 Energy. And if we are talking about transferring USDT TRC-20, then a transaction may require over 130K units of Energy if the recipient's balance does not have USDT.
Therefore, do not break down shipments to one address. Sending multiple amounts at once saves Energy.
#### Conclusion
A batch USDT transaction, i.e., grouping several stablecoin transfers into one operation, saves resources compared to frequent transfers of smaller amounts.
### 3. Check if TRX Is Being Debited Instead of Energy
You already know: if there is not enough Energy on the balance of the user conducting the transaction, the Tron system automatically burns TRX.
To prevent such inefficient crypto spending, check the "Energy Consumption" section in TronScan to ensure that Energy is being consumed correctly.
#### Conclusion
Controlling Energy consumption during a transaction helps to avoid hidden fees.
### 4. Rent Energy with a Reserve if You Have Frequent Transactions
Regardless of the reasons for Energy consumption before the end of the transaction, the system starts "selling" you the missing resource for your TRX at a very high price.
Therefore, you should anticipate this possibility and charge your wallet with a reserve. You can do this through staking, if your TRX volume and time allow.
It is better to rent more than to spend TRX on fees.
To rent Energy, there is no need to "lose" a significant amount of TRX for a long time, as with staking. Temporarily withdrawing funds from circulation can lead to significant inconveniences. Yes, you get Energy for free and immediately, but you lose access to the frozen funds for 14 days.
It is much more convenient to spend a few TRX on a commission for an Energy rental service – and not limit yourself in any way.
Your possibilities expand if you deal with the automated Energy rental service NETTS. You can not only order wallet charging with Energy for a specific time and the period you need with the volume you need.
The NETTS Energy rental service, thanks to the implementation of API on the web interface, can supply you with Energy according to a schedule you set or replenish it to the initial volume when the resource drops to a trigger you define.
You can test these Smart and Host modes right now – deposit a minimum of 1 TRX into Workspace and familiarize yourself with all the possibilities of your personal account. Be warned: all Workspace testers have already become our clients – people get used to good things quickly.
By the way, if you do not use the Energy received on your balance, your deposit will not decrease – NETTS does not charge a commission for unused Energy, as happens on non-automated services with prepayment. Of course, this refers to the process under normal Tron network load conditions. During periods of ecosystem overload, NETTS does not provide such guarantees.
By the way, you can choose the Energy supply time and save money due to the fact that the network experiences minimal load at night.
For comparison, here are two screenshots taken from the web interface during the day and at night. The savings are good in the first case too – you won't find such a result (more than 79%) on the market. But the second savings figure – almost 82% – is a particular point of pride for NETTS.
#### Conclusion
An Energy reserve or the ability to quickly replenish it (trigger mode or "eternal" Energy from NETTS) saves you from unexpected TRX overspending.
## How to Control Energy Consumption?
If you receive Energy in any way other than renting through an automated service, you will need to perform a series of actions before the transaction.
1. Use the TronScan blockchain explorer or TronLink – Tron wallet, to track the remaining resources.
2. Check the average Energy consumption per transaction and plan costs for interacting with TRC-20 tokens.
3. Set up notifications for low Energy balance in your wallet.
And none of the above if your wallet is charged with Energy by the NETTS rental service. The automation mechanism will calculate everything itself. When you press the "Charge" button, the Telegram bot or web interface API checks the Energy balance in your wallet and tops it up to 131,000 units, which is enough for one transfer to any address. After the transfer is made, the unused Energy is returned and the amount spent is calculated.
## Conclusion
The main reasons for Energy overspending when interacting with smart contracts are network load, frequent transfers, and a lack of rented Energy on the balance.
To save resources and prevent TRX burning when transferring stablecoins, it is better to send USDT during periods of low load and group payments.
The best option is to rent Energy with a reserve to avoid TRX overspending. And the very best choice is an automated Energy rental service that will take care of all calculations, execute the charging schedule, and save you about 80% on transactions!
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-find-out-if-the-tron-network-is-overloaded-before-sending-a-transfer.md
description: >-
A few years ago, the Tron cryptocurrency blockchain switched to a dynamic
energy consumption model. Since then, the transaction fee on the network can
change several times a day. This can particularly...
---
# How to Find Out if the TRON Network is Overloaded Before Sending a Transfer
A few years ago, the Tron cryptocurrency blockchain switched to a dynamic energy consumption model. Since then, the transaction fee on the network can change several times a day. This can particularly negatively affect those who interact with smart contracts and use the eco-platform's special resources – Energy and Bandwidth – to pay for gas.
For example, a user transferring USDT TRC-20 thinks that one transaction (regardless of the amount sent) will cost them the same amount of energy units as yesterday, plus 345 Bandwidth units. The blockchain replenished their Bandwidth for free, as it does for every participant. Our user checked their balance, made sure they had all the necessary funds, and sent the transfer with a clear conscience. And the blockchain informs them: Failed out of Energy. A balance check showed that all funds were withdrawn from the wallet, including a small amount of TRX.
After such an experience, the user might start suspecting the blockchain of fraud – and they would be wrong. This is the user's own mistake. They did not consider the peculiarities of the network's dynamic energy consumption model. And they did not check the system's status before the transaction.
Tron is indeed the fastest cryptocurrency blockchain today. Transaction times are measured in seconds. But this is precisely what attracts a large number of smart contract developers and everyone who interacts with TRC-20 standard tokens, for example – transferring USDT stablecoins.
From time to time, user activity increases to such an extent that the system needs to draw on additional capacities – computational and energetic. It is quite understandable that the blockchain recovers these costs from users. After all, it is they who need improved network throughput and transaction speed.
Therefore, during periods of network overheating, the gas fee increases, which is what happened to our user. The system took all the special resources, and when they were not enough to pay the increased commission – it started burning TRX. The user intended to pay only with resources and did not bother to have a reserve of TRX. When there was not enough native currency either, the system interrupted the transaction.
If the user has the ability to quickly contact an Energy rental service – the transaction can be saved. It is better, of course, in this case, to arrange for automatic replenishment of the Energy reserve when the volume of this resource drops to a certain level – for example, through Netts Workspace. If the user had auto-replenishment configured, they would not have suffered from network overheating.
That is, you should know that fees on the Tron network are not fixed – they depend on the blockchain's load.
We explain how to check the TRON network load before sending USDT TRC-20 to avoid delays and inflated fees.
## Where to Check the TRON Network Status?
If the network is overloaded, transactions may get stuck or require more Energy. And if there is not enough Energy to cover the increased commission – the system will start burning TRX, if they are on the balance.
Therefore, before any transaction, you should first check the Tron network status. The most convenient option is to use the official TronScan blockchain explorer.
For active network users who frequently perform various transactions (this applies to TRC-10 standard tokens as well, not just smart contracts), this blockchain explorer can become an indispensable assistant. Therefore, we recommend registering there, although you can log in and check the network status or your transaction without registration.
To make sure the network is not overheated and the fees will be standard, you need to perform just a few simple actions:
* Go to TronScan;
* Go to the Data → Network section;
* Assess the network status using the graphs.
The more Energy is used, the more expensive the commission – this is a feature of the dynamic energy consumption model.
#### Conclusion
If the network load is above 80%, transactions may take longer to process. In this case, the transaction will be pending for longer than usual. In addition, during network overload, validators may consider a specific transaction less of a priority, and then the processing time will increase even more.
## What Indicators Show Network Congestion?
The Network section in the TronScan explorer is where you can monitor the overall state of the TRON network using data graphs. Some indicators that can be tracked in this section include: block size, number of transactions, Energy usage. TronScan also often provides more detailed data visualization so that users can understand trends and patterns in the Tron network.
What information in the Data → Network section should be obtained to assess the network status:
1. Block fullness → If each block is above average, fees increase.
2. Average energy consumption → If it is above normal, transaction costs increase.
3. Number of unconfirmed transactions → If there are many, delays are possible.
#### Conclusion
Before sending, it is worth checking all three parameters of the Tron network status to avoid unnecessary expenditure of assets and resources, and possibly – transaction freezing.
## How to Choose the Best Time for a Transfer?
If you find out through TronScan that the network is overloaded – it is better to wait for the transaction fees to standardize. Choose the most favorable time to work on the network. You should know that:
* The lowest network load is in the morning and late at night UTC.
* Peak loads occur during major events and listings on exchanges.
#### Conclusion
If there is no particular urgency, it is worth postponing the transfer to avoid overpayments.
## What to Do if the Network is Overloaded?
There are situations when it is impossible to postpone a USDT transfer or other interaction with a smart contract for a long time, despite the Tron network overheating. In this case, it is worth:
* Trying to increase the amount of Energy so that the transaction goes through;
* Replenishing the TRX balance so that if Energy is insufficient, you can pay for the transaction with them;
* Waiting for the load to drop so that the commission decreases;
* Being prepared for increased costs if the transfer is urgent.
## Conclusion
User activity on the Tron network can significantly increase, leading to the blockchain drawing on additional energy and computational power. The eco-platform covers these additional costs by increasing transaction fees.
To avoid troubles with unnecessary resource or TRX expenses, you should remember that Tron has switched to a dynamic energy consumption model.
Before sending USDT TRC-20, or any interaction with smart contracts, be sure to check the network status on TronScan.
If blocks are 100% full, the fee may be higher than usual.
The best way to save money is to send transfers during periods of low load. This also applies to any interactions with smart contracts.
This is an example of the benefit you can get with the Netts service if you rent Energy during the least active time at night. Savings of over 80% – that's what you get for being extra aware.
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-minimize-fees-when-transferring-usdt.md
description: >-
USDT TRC-20 is the most popular stablecoin on the Tron blockchain, attracting
users with its low fees and high transaction speeds. However, not everyone
knows how to further save on transfers....
---
# How to Maximize Fee Reductions for USDT Transfers
USDT TRC-20 is the most popular stablecoin on the Tron blockchain, attracting users with its low fees and high transaction speeds. However, not everyone knows how to further save on transfers.
This article will detail how to maximize fee reductions when transferring USDT TRC-20 using various methods and strategies.
## What is USDT TRC-20 and Why is it Important?
USDT TRC-20 is a TRC-20 standard token issued on the Tron blockchain and pegged to the US dollar (1 USDT = 1 USD). It allows users to make fast and cheap transactions worldwide.
### Energy and Bandwidth Points
Two main resources are used to perform transactions on the Tron network:
1. **Energy:** Required for executing smart contracts, including USDT TRC-20 transfers. If a user has insufficient Energy, TRX will be burned to pay the fee.
2. **Bandwidth Points:** Used for all types of transactions, including TRX and TRC-10 token transfers. Each account receives 600 free Bandwidth units daily. A USDT transfer typically requires about 345 Bandwidth units.
A shortage of these resources leads to the system automatically deducting TRX from your balance to cover expenses, which can be significantly more expensive.
## Key Strategies for Reducing Fees
Several effective methods exist to minimize commission costs when working with USDT TRC-20.
### 1. Using Energy Instead of Burning TRX
This is the primary way to save. Instead of letting the system burn your TRX, you can "freeze" (stake) TRX to obtain Energy.
* **How it works:** By freezing TRX, you receive Energy that can be used to pay for transactions. After unfreezing, the TRX is returned to your balance.
* **Advantages:** Significant fee reduction, as using Energy is cheaper than burning TRX.
* **Disadvantages:** TRX will be frozen and unavailable for other operations during the staking period (minimum 14 days after the last staking or vote acquisition). The amount of Energy received depends on the total amount of TRX frozen in the network.
**Example:**
One USDT TRC-20 transfer to an address that already holds USDT requires approximately 32,000 - 65,000 Energy. If the recipient's address does not have USDT, it will require about 65,000 - 131,000 Energy.
If you have no Energy, burning TRX will cost approximately 13.86 TRX (for an address without USDT) or 6.93 TRX (for an address with USDT) at current prices (subject to change).
### 2. Renting Energy
If you don't have enough TRX to freeze or don't want to lock up your funds, you can rent Energy from other users or through specialized services.
* **How it works:** Services like Netts allow you to rent the required amount of Energy for a specific period (e.g., 1 hour or 1 day). You pay a small fee to the service, which is significantly cheaper than directly burning TRX.
* **Advantages:**
* **Savings up to 70-80%:** Renting Energy through Netts can reduce your commission costs several times over.
* **Flexibility:** You can rent exactly as much Energy as you need, for the period that suits you.
* **No TRX freezing:** Your TRX remains liquid.
* **Example from Netts:**
Renting 131,000 Energy for 1 hour for one USDT TRC-20 transfer to an "empty" wallet via the Netts service can cost around 3-5 TRX, while direct TRX burning would cost almost 14 TRX. The savings are clear.
The Netts service offers a convenient interface via its website and Telegram bot, allowing for quick and easy Energy rental. Netts also provides automated solutions for businesses via API, enabling automatic Energy rental when a certain balance threshold is reached (Smart mode) or continuous replenishment (Host mode).
### 3. Choosing Transaction Times
The Tron network, like any other, experiences periods of high and low congestion.
* **How it works:** During periods of low activity (e.g., nighttime or weekends UTC), fees may be lower due to less demand for network resources.
* **Advantages:** Additional small savings.
* **Disadvantages:** It's not always convenient to adjust to low congestion times. The effect may not be as significant as renting Energy.
* **How to check congestion:** Use the TronScan block explorer (Data -> Network section) to track current network congestion and Energy consumption.
## Additional Savings Tips
* **Check the recipient's balance:** If the recipient's wallet already contains USDT, the transaction will require less Energy (about half). If possible, clarify this before sending.
* **Group transactions:** If you need to send USDT to multiple recipients, try to do so within one session when you have already rented Energy or are sure of its availability. However, each individual transaction will still consume Energy.
* **Use wallets with resource management support:** Some wallets, like TronLink, allow you to easily track and manage your Energy and Bandwidth.
* **Beware of free Energy offers:** These can often be fraudulent schemes. Use only trusted rental services.
* **Automation for business:** If you represent a business and make many transactions, consider integrating with Energy rental services via API, such as Netts. This will automate the process and significantly reduce operational costs.
## Conclusion
Reducing fees for USDT TRC-20 transfers is quite achievable with a smart approach. Using Energy (your own or rented) instead of directly burning TRX is the key factor for savings. Energy rental services like Netts provide convenient and cost-effective solutions for both private users and businesses, allowing savings of up to 80% on commissions. Choose optimal transaction times and monitor your resource balance to make your USDT TRC-20 transfers as efficient and economical as possible.
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-send-trc-20-tokens-with-minimal-fees.md
description: >-
The **Tron** blockchain offers a unique transaction fee structure when
interacting with **TRC-20 tokens**. While with **Bitcoin** or **Ethereum**
transaction fees are paid in native crypto tokens of t...
---
# How to Send TRC-20 Tokens with Minimal Fees?
The **Tron** blockchain offers a unique transaction fee structure when interacting with **TRC-20 tokens**. While with **Bitcoin** or **Ethereum** transaction fees are paid in native crypto tokens of these networks, the **Tron** eco-platform provides users with a more flexible fee structure.
Teams of developers and smart contract callers can choose the asset they will give for transactions. This can be either the native cryptocurrency **TRX** or special resources **Energy** and **Bandwidth**.
## How Are Transactions Paid for in the Tron Network?
**TRX crypto** can be used to pay for any transactions – both with **TRC-10** and **TRC-20 tokens**. But burning **TRX** in a transaction furnace is a completely inefficient way. You can choose to pay for transactions using the constantly replenished **Bandwidth** resource for free or the **Energy** resource for more complex transactions. Proper use of these resources will minimize or even eliminate the commission even for complex transactions, for example, when transferring **USDT TRC-20** or interacting with smart contract packages when developing decentralized applications.
**Bandwidth resource** is primarily used when dealing with **TRC-10 tokens**, such as **TRX** and some other simple transactions, but **USDT TRC-20 tokens** also require **345 Bandwidth** (around **0.345 TRX**) to offset the blockchain's cost of maintaining network capacity. This is more than half of the amount that each **Tron** user receives daily (currently **600 units**).
That is, if you limit yourself to this “gift” from the blockchain, the network will start charging **TRX** for the second and subsequent transactions without even warning you about it – **0.001 TRX** per 1 unit of **Bandwidth**. Do not neglect this trifle – with frequent transfers of **USDT TRC-20**, the development of **DApps** can run up a significant amount, especially if we are talking about a package of smart contracts.
**Energy resource.** Calling a smart contract and especially deploying it requires significantly more energy and computing power from the blockchain. Therefore, a transaction for transferring **USDT TRC-20**, which is a smart contract, can be charged both in **TRX** and in **Energy**. This resource can be obtained in several ways in the **Tron** system – the user should know all these options in order to make the right choice to minimize their costs, in particular – for transactions when transferring stablecoins in **TRC-20 tokens**.
## Ways to Get Energy in the Tron Network
The blockchain does not provide users with any amount of the **Energy** resource for free. You will have to get it yourself. If you combine all methods of obtaining it, and exclude the purchase of this resource for **TRX**, which we strive to save as much as possible, then in practice you can choose only from two methods of obtaining **Energy**: **staking** and **rent**.
## Pros and Cons of Staking
If you are one of the holders of a significant volume of native crypto, then there are some advantages in this method for you. Simply send a certain amount of **TRX** for **staking**, order the receipt of **Energy** as a reward, wait until the freezing period ends, and the desired resource is credited to your account. If savings allow, this process can be ongoing, and at the end of the year you will also receive your commission.
**Cons:**
* effective only if there is a significant volume of **TRX**; with small volumes of frozen **TRX**, the **Energy** output will be insufficient for regular interaction with even the simplest smart contracts, not to mention smart contract packages;
* it is not always possible to withdraw the required volume of **TRX** from circulation for staking;
* there is no option to use the staking method if **Energy** is needed for an urgent transfer of **TRC-20 tokens** or deployment of a smart contract.
Not everyone can use **staking** to replenish their wallet with the amount of **Energy** needed to develop smart contracts or transfer **USDT TRC-20**. For the latter operation, for example, you need to have **65,000** or even **131,000 Energy units** in your wallet for the commission for one transaction. To get **Energy** for a couple of such transactions, you need to freeze about **23,000 TRX**. For a fairly long period, this amount of native crypto will be unavailable to you. Currently, this minimal period is **14 days**.
## Urgent, Cheap and Abundant Energy Will Be Provided Only by Rent
**Tron** blockchain welcomes services that help improve user efficiency. The **NETTS** service, created for this blockchain, rents out the amount of **Energy** the user needs for a certain period. At the same time, you can have **3-6 TRX** on your account if you access the service through the website form, or you can deposit **15 TRX** into the **Telegram-bot** deposit to get more features.
What are the features and differences in the conditions for renting **Energy** through the website form and through **Telegram-bot**? The user is able to choose an option with the parameters that suit them.
1. **Via the website form** – advance payment for the ordered volume of **Energy**, but without refund for the unused volume.
2. **Via Telegram-bot** – minimal deposit of **15 TRX**.
This way, **NETTS** allows you to test the service by submitting an application through the website form. This does not oblige you to create an account, register or otherwise bind to the service.
A simple calculation will show how much your transaction costs will decrease when interacting with **TRC-20 tokens**. Let's take the **USDT TRC-20** stablecoin transfer as an example. The payment amounts for this process in **Energy** were given above: **65,000** or **131,000 units** depending on the recipient's wallet status, which is **13.4 TRX** or **27 TRX**, respectively. Renting this volume for an hour on the **NETTS** service will cost you **3-6 TRX**. I think you can easily calculate the percentage of savings yourself.
Our **Workspace API** toolbox allows for **FULL control** over automation of renting **Energy** – you can specify the cycles, trigger amount, schedule and all of that with a minimum deposit of only **1 TRX**! There will be a little extra cost for using the **API** though.
Note that if you have calculated your **Energy** needs correctly, you only pay for the rented **Energy**. The transaction itself will be free – you will only spend rented **Energy** on commission.
Stop burning **TRX** for **Tron** transactions – there is an opportunity to reduce the native crypto fees to zero. Rent **Energy** through the **NETTS** service – and get as much **Energy** as you need for the period you set.
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-set-up-automatic-energy-renting-to-always-have-enough-for-transactions.md
description: >-
Hopefully, you already know that for interacting with smart contracts on the
Tron network, i.e., any TRC-20 standard tokens, it is not necessary to pay
with the network's native currency – TRX. Althou...
---
# How to Set Up Automatic Energy Renting to Always Have Enough for Transfers
Hopefully, you already know that for interacting with smart contracts on the Tron network, i.e., any TRC-20 standard tokens, it is not necessary to pay with the network's native currency – TRX. Although for other cryptocurrency blockchains, this is a mandatory requirement.
Tron, however, provides its users with a fairly wide choice of means for paying gas fees: TRX, special resources Energy and Bandwidth, or a combination of native crypto and special resources.
However, USDT TRC-20 transfers are exempt from gas fees if you use the GasFree function. In this case, commissions are paid in stablecoins. This might be convenient, but it is very wasteful: any transfer will cost you 10 USDT.
This is even more expensive than commissions in TRX without using this new function. Depending on the recipient's wallet status (whether the balance contains USDT or not), commissions without GasFree will cost ~14 TRX or ~28 TRX, respectively.
Therefore, for individual users, and especially for business platforms that frequently send USDT TRC-20 to different addresses, the choice is obvious. If it is in their interest to save their assets, then special Tron resources will be chosen to pay for gas.
But even here, users have a choice. The required amount of Energy can be obtained by staking a certain amount of TRX. It is clear that frequent transactions require large reserves of Energy. These are difficult to provide by staking. For example, transferring USDT TRC-20 tokens may require about 64K or 131K units of Energy (depending on the recipient's wallet status).
To get enough Energy for at least two transactions per day, you need to freeze almost 23,000 TRX (depending on the exchange rate at the time of freezing). At the same time, there is a risk of not receiving the required amount of Energy, since the reward for staking depends on the total amount of TRX frozen in the network. That is, in addition to withdrawing a fairly large amount of native crypto from circulation, there are also staking risks.
If you do not have enough resources to pay for gas, the system will start "selling" you the missing Energy without any signal or warning, taking your TRX. If, of course, these tokens are on the balance. If not, the transaction will freeze, and the funds will be irretrievably lost: this is how blockchain technology works.
Let's also not forget that Tron is a dynamic energy-consuming model. If the network is overloaded, users will pay for the fact that the system has attracted additional capacity so that the overload does not affect transaction speed. This means that the gas fee will increase, and there is a risk of a shortage of resources and/or TRX on the user's balance.
Business conditions do not always allow waiting out this period of network overload – you have to lose funds so as not to lose your reputation.
To avoid all the listed disadvantages, active users who deal with frequent transfers of Tron stablecoins choose the most effective, inexpensive, and reliable way to charge their Energy balance. These are the services of Energy rental services, the development of which is welcomed on the blockchain.
Let's break down how auto-renting works, what ways there are to set it up, and when it is beneficial.
We explain how to automate Energy rental in TRON to avoid resource shortages during regular transactions.
## How Does Automatic Energy Rental Work?
Here, users also have a choice – manual or automatic Energy rental. The first option of services is provided by platforms where API mechanisms are not implemented. The client fills out a form each time to ensure a one-time Energy balance charge. The service is provided on a prepaid basis, and the cost of unused Energy is not refunded.
If you frequently send USDT TRC-20, manually renting Energy can take a lot of time and will require extra expenses.
Automatic Energy rental allows you to avoid delays and unexpected commissions in TRX, and also provides the client of such a service with additional advantages.
Auto-rental of Energy can be provided by a service equipped with a Telegram bot. Even more possibilities are offered to the user by more complex automation through a web interface.
We will consider the principles of automatic Energy rental using the example of the NETTS service organization, which provides its clients with the opportunity to use both a Telegram bot and a web interface, where the first version of Netts Workspace with Smart and Host modes has been implemented.
What are the features of Smart? It comes to the rescue if it is required that the client's service balance has a constant volume of Energy. The system automatically rents Energy if its balance drops below a predetermined level. The trigger is set by the client.
As soon as the Energy level decreases, the trigger activates and allocates the specified amount of Energy for a certain period.
You can set the operating mode according to your time zone, as well as the break time.
The mode works simply: launch it and forget about it. If there are no funds on the deposit, the resource is not supplied; once the deposit is replenished, everything works automatically again without any manual intervention, if the previous schedule suits you.
This option is ideal for users who regularly send USDT. This mode allows you to avoid burning TRX when Energy runs out.
And if your business requires constant USDT sending, choose Host and "eternal" Energy. Each replenishment will cost a little more – 6.5 TRX, but you will have no problems at all with calculations and the availability of Energy on your balance.
This mode also allows you to rent Energy according to a specific schedule – cyclical delivery.
#### Conclusion
Automating the Energy rental service makes transfers stable and cheap.
These screenshots were taken during the day and night replenishment of a NETTS service client's wallet. Yes, your eyes are not deceiving you. This means stable and guaranteed savings on transactions of about 80% (from 79+% to almost 82%). We have not seen similar offers on the market.
## Ways to Set Up Auto-Rental
The methods for setting up automatic Energy rental also depend on the choice of the infrastructure platform type.
### 1. Auto-Rental via Telegram Bot (if the service supports it)
Telegram bots are not supported by all Energy rental services. Usually, upon entry, it is reported what this bot can do.
#### How to Set Up
One of the first messages in Netts Energy Charge Bot is a detailed instruction on setting up Energy charging.
A Telegram bot is a way to quickly and cheaply rent the maximum amount of Energy, which is enough for a USDT transfer – 131,000 units.
It allows debiting the client's deposit only for the Energy actually used, and returning the unused part of the resource to the service.
This is a fairly simple mechanism that will satisfy the needs of a Tron user who makes several USDT transfers per day.
#### Conclusion
A Telegram bot will maximally charge the balance with the Energy needed for a USDT transfer, but will automatically debit the client's deposit only for the Energy actually used.
### 2. Renting via API for Business
If you have a cryptocurrency exchange or P2P platform, you can set up auto-rental via API. This is a reliable option if you have to conduct many transactions with USDT.
API allows you to automatically order Energy when its level drops to a certain point (trigger). In this case, you will not have to make calculations and worry that the resource may not be enough.
#### How to Connect
Contact the rental service support or register independently, as the NETTS service web interface allows.
Set up auto-rental via API, with support (for different API mechanisms):
* webhooks;
* automatic requests;
* flash wallet charging, when you need to instantly replenish spent Energy;
* manual Energy ordering;
* referral system;
* the ability to connect your pool for selling Energy and earning, etc.
To start using Netts Workspace, simply follow the link https://www.netts.io/workspace and create your personal account.
#### Conclusion
API is suitable for large cryptocurrency business platforms with a high volume of transfers.
### 3. Manual Auto-Rental through Planning
This method allows you to set reminders and rent Energy in the required volume in advance.
Useful for users who send transfers on a schedule.
#### How to Set Up
This will require accurate calculations of resource needs.
Determine the average Energy consumption.
Once a week (or according to another schedule), rent the required volume.
#### Conclusion
Suitable for users with a fixed number of transactions.
## When Should You Use Auto-Rental?
Auto-rental of Energy relieves the Tron user of practically all problems related to resources for gas fees. This universal, effective, and reliable method is suitable in all cases related to USDT TRC-20 transfers.
1. If you have frequent transfers and you don't want to monitor Energy manually.
2. If you manage a cryptocurrency exchange, P2P platform, or payment platform.
3. If you don't want to check your balance and manually rent Energy for each transaction or stock up on it, for example, for a week.
## Conclusion
Auto-renting Energy through a specialized service allows you to avoid Energy shortages and unexpected commissions in TRX.
The most convenient way for those who make several transfers a day is to set up auto-rental via a Telegram bot.
For large cryptocurrency businesses, the best option is to integrate auto-rental via API.
Users with fixed transfers (by quantity, time, and addresses) can plan Energy rental in advance.
---
---
url: >-
https://doc.netts.io/blog/articles/how-did-tron-become-one-of-the-most-popular-blockchain-networks.md
description: >-
Since the launch of the Tron ecosystem, we have observed both ups and downs.
Just a year ago, TRX was trading at $0.129, and today this figure is $0.237,
following a high of $0.44 last December. Never...
---
# How Tron Became One of the Most Popular Blockchain Networks
Since the launch of the Tron ecosystem, we have observed both ups and downs. Just a year ago, TRX was trading at $0.129, and today this figure is $0.237, following a high of $0.44 last December. Nevertheless, TRX remains in the top 10 on CoinMarketCap with a market capitalization of over $22 billion.
Cryptocurrency market analysts predict further strengthening of Tron's native crypto in 2025.
Tron has also firmly established itself in the top five of the TVL (total value locked) rankings. This indicator is crucial for assessing the investment attractiveness of blockchain projects.
Tron successfully chose one of the important niches in cryptocurrency blockchains – the use of TRC-20 tokens to create its own stablecoin based on Tether – USDT TRC-20. The network's dollar-pegged stablecoin is in huge demand. The Tron ecosystem provides almost instantaneous transactions and offers the ability to efficiently use special resources for gas fees, which significantly reduces transaction costs. Therefore, the volume of USDT TRC-20 operations here is high and steadily growing.
It's no coincidence that Tether Limited issued an additional 1 billion USDT specifically for use on the Tron blockchain. Apparently, the company was attracted by the fact that at the end of last year, USDT TRC-20 became the winner in the nomination for transactions made with stablecoins by real people, not bots. The share of such transactions exceeded 68%.
Thus, the growth of the Tron ecosystem is driven by a combination of technological innovations and strategic initiatives. Let's take a closer look at the key aspects that have contributed to Tron's success.
We explain the factors contributing to the growing popularity of the Tron network, including its technical features, strategic decisions, and low fees.
## Technical Features of Tron
To get an idea of the Tron blockchain's performance, it's enough to compare its "speed" with its closest competitor, which was previously a partner:
* Tron – 2000 TPS (transactions per second);
* Ethereum – 15-30 TPS.
How is the Tron ecosystem capable of achieving such staggering results? Primarily – due to an updated blockchain architecture.
### Multi-level Architecture of Tron
Tron is a public blockchain designed for developers, offering a basic infrastructure for creating smart contracts and decentralized applications, as well as free publication, ownership, and data storage. Unlike public blockchains (such as Bitcoin) that use a Proof-of-Work (PoW) consensus mechanism, TRON uses a Delegated Proof-of-Stake (DPoS) consensus mechanism.
The three-tiered blockchain structure largely provides its user-attractive characteristics and advantages.
1. The storage layer manages blockchain data and transactions, ensuring secure and efficient data processing.
2. The Core Layer processes smart contracts and consensus mechanisms, ensuring the seamless execution of decentralized applications (dApps).
3. The application layer facilitates the development of decentralized applications and their integration into real-world use cases, stimulating ecosystem expansion. Examples include the constant introduction of new features, such as GasFree, as well as the construction of new services on the blockchain that make it easier for users to interact with smart contracts – Energy rental services, etc.
### Advantages of the Tron Network Provided by its Architecture
* Flexibility and scalability – for example, the integration of Tron and BitTorrent allowed the Tron ecosystem to become one of the largest decentralized systems in the world;
* Increased performance up to 2000 transactions per second with minimal delays – unprecedented among cryptocurrency blockchains;
* Maximum possible decentralization allows for interaction with smart contracts;
* Developers can create decentralized applications (dApps) based on Tron.
## Low Fees and Their Impact on Popularity
An analysis of the fee policy in the Tron network allows us to conclude that the blockchain team strives to provide participants with a choice of means for paying for transactions. Moreover, users of the ecosystem can pursue different goals and achieve them. Most aim to reduce transaction costs, but some prefer the convenience of paying without much effort.
For the former, Tron offers special resources, Energy and Bandwidth, which can be used to pay for gas instead of the native TRX crypto.
And here the team did not stop at the fact that these resources can be obtained by staking. They met users halfway who cannot or do not want to withdraw large volumes of TRX from circulation to stake Energy (600 Bandwidth units are given free to all users every day). The Tron blockchain supports the construction of services that rent out Energy.
Here is a prime example of how quickly such services are developing, using the latest API technologies. The NETTS Energy rental service was specially designed to find this resource on the market so that Tron users do not experience problems with their balance and do not spend native crypto on transactions.
Initially, only a web interface was offered, then a Telegram bot appeared, and now it is possible to connect active users who frequently interact with smart contracts via API. This is very convenient and profitable, for example, for cryptocurrency platforms that make dozens of USDT TRC-20 transfers per day.
The wallet of such a platform is connected via API, an Energy charging schedule is created – and that's it. The user just needs to decide on a trigger – the Energy level in the wallet. As soon as the level drops – NETTS recharges your wallet.
The Host mode also provides for the possibility of a constant presence of a certain amount of Energy on the client's balance or the supply of this resource in cycles.
That is, you do not need to calculate the required amount of Energy, nor check the availability of the resource before each transaction, nor worry that Energy may not be enough due to increased network congestion. And most importantly – you will not have to withdraw a large volume of native crypto for staking to get Energy. It is enough to deposit 20 TRX to connect via API.
You can also use a Telegram bot if you don't have many transfers per day. This will cost 15 TRX for a deposit.
But only payment for actually used Energy will be debited from the deposit (except for periods of Tron network overload).
Registration via the website form provides for prepayment and is designed for those who rarely transfer USDT TRC-20.
And here are screenshots that demonstrate how low the prices are at NETTS:
Why such different amounts? It's simple. A few years ago, the Tron blockchain implemented a dynamic energy consumption model. That is, network load in real time affects the gas fee. The second screenshot is an invoice for a client's wallet being charged overnight.
The savings during the day are good and have no analogues on the market – 79+%, and during periods of minimal system load – it's simply unprecedented: almost 82%!
For holders of large USDT TRC-20 assets who do not have TRX, Energy, and Bandwidth on their balance and want to transfer stablecoins without extra hassle, the GasFree function was introduced. This, of course, is more about comfort than about reducing transaction costs, since calculations here are made in stablecoins – 10 USDT per transaction for any amount and to any address. But the comfort is like transferring fiat currencies via online banking.
### Conclusion
The abolition of gas fees, despite some increase in the cost of transactions for USDT transfers using the GasFree function, attracted new users. They appreciated the convenience of paying in USDT without the need to accumulate TRX and/or special resources.
The team supports Energy rental services on the Tron network, which minimize transaction fees when interacting with smart contracts.
## Strategic Initiatives and Partnerships
Above, we have already mentioned some important steps Tron has taken on its path to success. Despite similarities with EOS and Ethereum, Tron distinguished itself by being adopted by major projects.
1. Tether (USDT) has become one of the largest stablecoin networks, benefiting from Tron's efficient and cost-effective infrastructure.
2. BitTorrent (BTT) uses the Tron blockchain to improve peer-to-peer file sharing, enhancing decentralized content distribution.
3. APENFT serves as Tron's specialized NFT marketplace, facilitating the trading of digital assets and art-dedicated tokens.
4. Investments in projects. In December 2024, Tron founder Justin Sun invested $30 million in World Liberty Financial, strengthening the network's position in the market.
5. Expansion of functionality. The ability to waive gas fees for stablecoin transfers has made Tron more attractive for mass adoption. This capability is provided by the recently launched GasFree function.
6. The blockchain's functionality is also expanding due to the team's support for various services, particularly Energy rental, which attract additional users by allowing them to reduce transaction costs, freeing them from the need to withdraw assets in the form of native crypto.
### Conclusion
It is no accident that the Tron eco-platform is consistently among the leaders of cryptocurrency platforms. This was achieved through persistent work on implementing technical innovations.
Low fees and the highest transaction speed due to correct strategic decisions have allowed the Tron system to take a leading position in the world of blockchain technologies.
Its success serves as an example of how a combination of technology and business strategies can lead to mass adoption.
Join the Tron ecosystem and take advantage of its benefits today!
If you are already an active user of this blockchain but still complain about high gas fees, pay attention to how they are formed. After all, Tron provides its users with all the opportunities to reduce their transaction fees to a minimum – 3-5 times compared to paying in TRX.
To do this, you don't even need to withdraw huge amounts of native crypto from circulation to freeze them. It is much more profitable to turn to an Energy rental service built on the Tron blockchain.
Test the capabilities of the NETTS Energy rental service API. You will forever be free from problems with this resource, and 80% of the saved funds will remain with you from this moment on. Just deposit 1 TRX into your Workspace – and explore the possibilities of your personal account. We are sure we will meet again: all testers are now NETTS clients. People get used to good and profitable things instantly.
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-check-if-you-have-enough-energy-for-multiple-transfers.md
description: >-
As you know, users do not need to have the special resource Energy on their
balance for TRX transfers. These resources – Energy and Bandwidth – are used
on the Tron network to pay for gas when transfe...
---
## How to Check if You Have Enough Energy for Multiple Transfers
As you know, users do not need to have the special resource Energy on their balance for TRX transfers. These resources – Energy and Bandwidth – are used on the Tron network to pay for gas when transferring stablecoins – USDT TRC-20 tokens pegged to the US dollar exchange rate.
These resources are used in Tron blockchain transactions when interacting with smart contracts, including TRC-20 standard tokens. But we specifically highlight transactions with USDT TRC-20 because the Tron eco-platform is currently leading compared to stablecoins on other cryptocurrency blockchains.
The blockchain's leading position is not only due to the high speed of transaction processing. The ability to significantly reduce commissions also plays a role, if you choose the right way to get Energy on your balance. For each transaction when transferring USDT TRC-20, the gas fee is a maximum of 65K or 131K units of Energy (depending on the recipient's balance status) and 345 units of Bandwidth.
Using these resources is much more profitable than burning TRX. The native TRX currency can be used more effectively – sell it, exchange it, use it as payment for renting Energy or as a means of payment for content in the Tron ecosystem, send it for staking, etc.
Now, with the advent of the GasFree function, you can also pay for transactions in USDT, but this is extremely unprofitable: any transfer will cost you 10 USDT, or ≈43 TRX.
Whereas, even with inefficient TRX burning, you would need 13.5 TRX or 27 TRX per transfer – depending on whether the recipient has USDT on their balance or not.
So: burning TRX is expensive, and GasFree is even more expensive. All that remains is good old Energy!
But what awaits the user if they run out of Energy during a transaction? In the best-case scenario, the system will start burning native crypto (TRX). In the worst case, if there isn't enough TRX either, the transaction will freeze. If the balance is not quickly replenished, the funds will be irretrievably lost, as actions on the blockchain are irreversible.
Is it possible to calculate before sending USDT TRC-20 whether there will be enough Energy for several transactions to avoid constant checks and unexpected expenses?
We break down how to calculate in advance how much Energy will be needed for several transfers and how to account for all cases where commissions may increase. And also – how to completely automate the Energy replenishment process to forget about such problems once and for all.
## How to Calculate Energy Consumption?
It would seem, what problems could there be with calculating the required amount of Energy if we know that a regular USDT transfer requires a maximum of 65,000 or 131,000 units of Energy.
### Calculation Formula
Total Energy = (Average Energy Consumption per 1 Transfer) × (Number of Transfers)
### Calculation Example
If you need to send 5 USDT TRC-20 transfers to 5 different addresses where this stablecoin is on the balance, substitute the numbers into the formula to get the result:
65,000 × 5 = 325,000 Energy.
Let's say you need to send another transfer to an address without USDT. 325,000 + 131,000 = 456,000 units of Energy. It is always better to calculate for the maximum to ensure there is enough for all transfers.
If it is unknown whether USDT is present in the recipient's wallet, always count 131k for this transfer - do not rely on luck, otherwise the transaction may freeze.
### Conclusion
Nothing complicated – just basic math. Just don't forget to consider the possible absence of USDT at the recipient's address.
## Where to Check Energy Balance?
But before you proceed with the transfer, you should check your balance. It is possible that the Energy obtained from staking or renting has not yet arrived, and you start the transaction. This can lead to TRX burning until the Energy arrives.
An indispensable assistant that will give you comprehensive information about the Tron blockchain is the unique TronScan explorer. We recommend registering there to be able to study it well and in detail. But you can use the blockchain without registration:
Enter TronScan → Enter wallet address → "Resources" section
You can also get information through the TronLink wallet, if you have it activated, by following these steps:
TronLink → "Energy" section.
Any similar wallet also shows the amount of Energy at the address.
### Conclusion
Before sending USDT TRC-20, make sure you have enough Energy for all transfers.
## How to Avoid Energy Shortage?
To avoid an Energy shortage during a transaction, a series of simple actions are required that will save you from difficult consequences.
And the very first thing that active users who regularly transfer USDT TRC-20, develop DApps, and interact with other types of smart contracts should do is choose an automated Energy rental service. Why? It's simple – special resources are always cheaper, and process automation will save you time.
In general, Tron users have several options to get Energy. Let's compare them before moving on:
1. Staking. For a couple of USDT TRC-20 transfers per day, you need to freeze almost 24,000 TRX, taking them out of circulation for at least 14 days.
Pros: Daily receipt of Energy during the freezing period.
Cons: Withdrawal of a significant amount of TRX from circulation, the risk of receiving a smaller amount of the resource due to a large amount of TRX in the general network staking, the impossibility of quickly replenishing the Energy balance if a transaction freezes.
2. Renting Energy through special services built on the Tron blockchain. There are practically no downsides.
Pros of renting Energy through a special service:
* Transaction cost is 3-5 times lower compared to standard fees or investments in staking;
* The required amount of Energy is provided for a specific period (usually from an hour) at a precisely agreed time;
* Flexible system, settings are provided by the service client;
* Possibility to set up cyclical Energy charging for your wallets;
* Payment only for actually used Energy;
* Possibility of resource delivery at any time of the day;
* Possibility to choose the most favorable time for receiving and using Energy.
Only a service that has implemented competent automation, like NETTS – a rapidly growing Energy rental service that has already taken a leading position in this market – can provide the last four positions.
Testing the service clearly showed that rental time matters. Compare two screenshots taken after charging a client's wallet during the day and at night. In the first case, the savings are almost 80%, in the second – almost 82%! As they say, shop around, find it cheaper (which is unlikely).
Of course, this does not mean that a NETTS client has to place an order in the middle of the night. This can be done in advance by setting up cyclical balance replenishment at certain hours every day. There is one limitation: a minimum of 3 cycles per day.
By opening a deposit on the NETTS rental service in your Workspace personal account (minimum – only 1 TRX), you won't even have to resort to calculations. You can simply order a stable Energy recovery mode – after all, the deposit will be debited not for the rented volume, but for what was actually spent on transactions, in particular – on USDT TRC-20 transfers.
NETTS service provides a choice of Energy delivery mode: by trigger (Smart), according to a schedule you set (cyclical), or constant replenishment ("eternal" Energy) – Host.
And if you decide to do without NETTS, you will be forced to follow a whole series of recommendations so as not to spend TRX on commissions and not risk transaction freezing.
1. Rent Energy with a reserve if frequent transfers are planned.
2. Check if the network load has increased (so as not to spend more than necessary).
3. Do not make a test transfer before a series of shipments – it also consumes Energy, and if you have staked or rented just enough, there may not be enough for the transfer.
## How to Automate Energy Control?
A service with auto-rented Energy gives its clients the following opportunities and advantages:
* No need to calculate the required amount of Energy based on transactions;
* Instant Energy balance charging without manual intervention;
* Maximum flexibility – rent in the required volume and for a specific period;
* Possibility to set up cyclical resource balance replenishment;
* Possibility to choose the most favorable time for Energy balance replenishment (minimum network load);
* Maximum possible savings on transactions – about 80% on the NETTS Energy rental service;
Those who do not cooperate with NETTS will have to constantly check the notification settings in their wallet if Energy is low.
You can quickly charge your wallet with Energy right now either through the service's website or through a Telegram bot (minimum deposit – 15 TRX). And registration through the website form involves prepayment and a one-time delivery, which is beneficial for Tron users who do not regularly transfer USDT-TRC-20.
NETTS will not deduct anything from your deposit in the Telegram bot if the Energy pumped into your wallet is not used within the agreed rental time. Except for cases of Tron network overload, but here the service has no control.
This same opportunity is now available to NETTS renters when accessing through the website, in addition to many other new and useful functions. Thanks to the development and connection of Workspace, an automatic wallet charging mechanism on the Tron network, you can order cyclical replenishment of your balance according to a schedule convenient for you.
Simply create your personal account, top up your deposit (minimum just 1 TRX!) and start testing. Choose the mode you need, set the hours, replenishment amount, and also the minimum threshold for recharging. If in doubt, start with a small amount on deposit.
NETTS service charges a minimal commission but provides you with unlimited comfort in obtaining Energy and the possibility of practically free transactions.
## Conclusion
Tron network users who constantly need Energy to transfer USDT TRC-20 are usually divided into those who stake and those who rent this resource.
They must:
* Calculate the required amount of Energy in advance so as not to check the balance before each transaction;
* Before a series of transfers, compare the Energy balance with their calculations;
* Check the network status so as not to risk transaction freezing during system overload;
* If Energy is not enough, renting is your best option.
Test the NETTS Energy service right now – and you will understand that you have gotten rid of all the problems and hassles with obtaining Energy. You will no longer look for other sources of Energy, as you will immediately appreciate the speed and benefits. Charge with NETTS – keep your 80%!
---
---
url: >-
https://doc.netts.io/blog/articles/what-are-the-hidden-fees-in-crypto-networks-and-how-to-minimize-them.md
description: >-
Just like in traditional finance, cryptocurrency networks, platforms,
exchanges, and other decentralized services also have various types of
commission fees. Most of these networks and services claim ...
---
# What Hidden Fees Exist in Crypto Networks and How to Minimize Them
Just like in traditional finance, cryptocurrency networks, platforms, exchanges, and other decentralized services also have various types of commission fees. Most of these networks and services claim that their fees are not only lower than those in similar centralized organizations but also completely transparent. While one can agree that fees in cryptocurrency operations are lower than in fiat finance, are some of them truly transparent?
Experience shows that users can encounter unexpected expenses. However, this is not always due to malicious actions by the cryptocurrency platform. Often, users themselves do not carefully study the policies of a cryptocurrency exchange, P2P platform, or ecosystem.
Studying and understanding hidden fees helps users effectively manage their funds.
We will examine various types of hidden fees in cryptocurrency networks and suggest effective methods for minimizing them.
## Main Types of Hidden Fees in Crypto Networks
If you understand that services, exchanges, and platforms are created to make money, then the very concept of a hidden fee disappears for you. Potential expenses will only be a surprise during a transaction for an unprepared user.
Let's list the most common fees for the services of cryptocurrency decentralized platforms and services that can be a surprise if the user has not studied the platform's policy carefully enough. So, hidden expenses can be both types of commissions that the user did not expect and their size.
### Service Fees
For most cryptocurrency operations on leading exchanges, only network fees apply. However, some wallets and exchanges charge additional fees for using their services, in addition to standard network fees. For example, the ZenGo wallet is known for its convenience but charges additional fees for its services.
### High Transaction Fees
Quite often, users of even such an inexpensive network as Tron are perplexed that they do not have enough funds to pay for gas, although yesterday the same transaction cost much less. This is because the user conducted transactions under different network conditions.
During periods of high network load, fees can increase significantly. In the Tron ecosystem, this can lead to excessive burning of expensive native TRX crypto instead of Energy resource obtained through staking or renting.
For example, on the Ethereum blockchain, fees can range from a few dollars to hundreds of dollars per transaction depending on network congestion.
You should also be aware of the conditions for some operations. For example, if you transfer USDT on the Tron network to a wallet that does not have these stablecoins, the transaction will cost you twice as much as a transfer to a wallet where USDT is present.
The size of the commission is directly proportional to the complexity of the transaction. For example, a simple TRX transfer on the Tron network is ~$0.25, while a TRC-20 standard token transfer is ~$3.09.
### Conversion Fees
Exchanging one cryptocurrency for another may be accompanied by hidden fees, especially on platforms with non-transparent pricing policies.
Additional fees are quite common when depositing or withdrawing funds if the account is replenished in one currency and trading is done in another. Under these conditions, the exchange may apply an additional fee, which is often not disclosed to traders.
### Withdrawal Fees
This is a fee for withdrawing funds from an exchange to an external personal wallet or bank account. When withdrawing cryptocurrency, the fee is usually fixed, while when withdrawing fiat funds, it depends on the payment method (e.g., up to 5% for a bank transfer or PayPal).
Some platforms charge significant fees for withdrawing cryptocurrency to external wallets. So, before making a transaction, clarify the withdrawal fee from your crypto wallet with the exchange's support service.
## Factors Affecting Fee Size
Several factors mentioned above determine the size of commissions for transactions on the Tron and Ethereum networks. However, most factors affect the fee size on most cryptocurrency blockchains, and consequently, on related decentralized services and platforms.
### What Determines the Size of Commissions
1. Network Congestion. On most cryptocurrency blockchains, during periods of high user activity, transaction fees can increase significantly. This is especially true for mining blockchains, as it is in the miners' interest to choose the most profitable transactions for them. For example, on the Ethereum network, during moments of increased user activity, the cost of operations can rise to enormous values.
2. Transaction Size. Larger or more complex transactions may require a larger commission for their processing. Above, we compared the commissions for a simple transfer of native crypto and a transfer of stablecoins, i.e., an operation involving a smart contract call. And if a user interacts with a package of smart contracts, the commissions will be higher due to the increased transaction size.
3. Type of Platform Used. Different exchanges and wallets have their own fee structures, which can vary significantly. For example, fees on different exchanges can range from 0.5% to 4.5% of the transaction amount. It also matters whether the exchange uses methods to reduce transaction costs depending on the features of the cryptocurrency blockchain. For example, the Tron ecosystem allows paying for gas not only in native TRX crypto but also using special resources for this purpose, one of which, Energy, can be rented on special services.
The NETTS Energy rental service is built on the Tron blockchain and provides users, including exchanges, exchangers, P2P platforms, and other decentralized platforms, with the opportunity to significantly reduce transaction costs, for example, when transferring USDT TRC-20. As you know, today this is one of the most demanded stablecoins pegged to the US dollar exchange rate.
Minimizing commissions is achieved by excluding TRX from gas payments. Instead, NETTS provides the special Energy resource for rent, which is used to pay commissions for USDT TRC-20 transfers.
At the same time, NETTS, by connecting the exchange to the API, provides any necessary amount of Energy for transfers. Energy can be supplied according to a schedule provided by the client of the Energy rental service (exchange, etc.), or based on a trigger. The client specifies the Energy level on the balance, upon reaching which the wallet is replenished with the resource. And in Host mode, a variant of constant Energy replenishment is possible – "eternal" Energy.
The NETTS Energy rental service provides savings on transactions of up to 80%, and during periods of minimal Tron network load – almost 82%, as shown in the screenshots below.
At the same time, the NETTS service does not charge any hidden fees – you deposit 15 or 1 TRX, depending on the choice of automation type. The first option is entry through a Telegram bot. The second is through the Workspace web interface with the possibility of connecting via API.
The option of applying for Energy rental through the website form involves prepayment. It is more suitable for individual users who make 1-2 transfers per day.
The Telegram bot and Workspace are preferred by large cryptocurrency business platforms that transfer USDT TRC-20 to dozens of addresses daily.
Clients of the NETTS Energy rental service connected via API, during periods of minimal Tron network load, will only have payment deducted from their deposit for the Energy actually used out of the entire rented volume. As you can see – everything is truly transparent.
With NETTS, you are not afraid of any hidden exchange fees, as well as an increase in gas fees during periods of high Tron load.
Right now, go to the NETTS Energy rental service, deposit 1 TRX into Workspace, and test the API capabilities. From this moment on, pay for transactions in Tron with rented Energy and keep 80% of your TRX.
## Ways to Minimize Hidden Fees
Now you know what surprises and under what circumstances you may encounter when interacting with cryptocurrency platforms. We hope that after reading this information, the number of hidden fees for you will decrease. The main thing is to carefully study all network and exchange fees before interacting with cryptocurrency platforms and systems.
And if you follow these recommendations, you will be able to reduce transaction costs. To achieve this, it is enough to perform a few simple actions.
1. Make transfers during periods of low network congestion to reduce fees. Choosing the optimal time for transactions can significantly reduce network fees.
2. Choose a blockchain that offers lower fees for the operation you are interested in. Compare: the average transaction fee on the Tron network is less than $0.01, while on the Ethereum network, fees can range from a few dollars to hundreds per transaction.
3. Before making a transaction, study the exchange fees of various platforms, as well as wallets, which will help you choose the most favorable conditions. Transaction fees on various exchanges can range from 0.5% to 4.5%.
4. Use payment gateways (bridges) with minimal fees and the ability to work with a large number of digital currencies and other assets. Payment gateways usually offer much lower fees for processing crypto payments than exchanges and provide the ability to customize interfaces via API.
## Conclusion
Fees that the user is unaware of can significantly affect the efficiency of using cryptocurrencies.
Many call such fees hidden, but in reality, awareness and a proactive approach will help minimize transaction costs when working with decentralized networks, exchanges, and services.
You should analyze the policy of a decentralized platform, carefully choose platforms and tools for working with cryptocurrencies. Then all fees and charges will be transparent for you, and transactions will be as economical as possible.
---
---
url: >-
https://doc.netts.io/blog/articles/why-some-usdt-transfers-on-the-tron-network-are-not-going-through.md
description: >-
The popularity of Tron network's Tether-based stablecoin continues to break
all records for crypto coin popularity. USDT TRC-20 is pegged to the dollar at
a 1:1 ratio and combines the best characteris...
---
# Why Some USDT Transfers on the Tron Network Fail
The popularity of Tron network's Tether-based stablecoin continues to break all records for crypto coin popularity. USDT TRC-20 is pegged to the dollar at a 1:1 ratio and combines the best characteristics of cryptocurrency and fiat money.
Users are attracted by high transaction speeds, reaching 2000 TPS (transactions per second), and a flexible gas fee system using specially designed resources. Users are not required to pay for USDT TRC-20 transfers in native TRX crypto. It is much more profitable to use special resources Energy and Bandwidth.
For this reason, the USDT TRC-20 stablecoin holds the lead in transactions made with stablecoins by real people, not bots. All these efforts to support the stablecoin have been appreciated by Tether, the company that issues it. Just as this article was being written, it became known that Tether Treasury had completed the minting of 1 billion USDT on the Tron network.
In total, since the beginning of this year, Tether has issued a total of $8 billion USDT on this blockchain.
The TronScan blockchain explorer reports that over the past 30 days, 1.04 million accounts were transferred daily on the Tron network, which is 3.9% more than a month earlier. And the number of USDT TRC-20 holders has begun to count the 65th million.
Such popularity of a cryptocurrency coin pegged to the dollar exchange rate, of course, attracts various kinds of attackers. But this article is not about victims of fraudsters. Often, network users encounter failed transfers due to their own fault. Some of them simply do not know about all the capabilities of the Tron blockchain and the features of this flexible system based on the principle of dynamic energy supply.
In this article, we examine the main reasons for failed USDT transfers on the Tron network and offer solutions, including the use of Energy rental to prevent such problems.
## Main Reasons for Failed USDT Transfers on the Tron Network
Possible reasons for failures during USDT TRC-20 transfers can be related to both a lack of funds on the user's balance (native crypto, special resources) to pay for gas, and sender errors. Let's consider the most common reasons for such failures.
### Insufficient Special Energy Resource (Energy)
On the Tron network, you can use not only native crypto for transactions, as on other cryptocurrency blockchains, but also special resources – Energy and Bandwidth. If you do not have enough Energy on your balance, the transaction may not go through, especially if you also lack TRX (Tron's native crypto).
The special Energy resource can be used to pay for any transaction related to interaction with TRC-20 standard tokens, i.e., smart contracts, which the USDT TRC-20 stablecoin is.
Currently, to transfer USDT on the Tron network, you need to have ~65K or ~131K units of Energy on your balance. The first amount is for transferring to a wallet that already has this stablecoin, the second, as they say, is for an empty wallet, i.e., if the recipient's balance does not have USDT TRC-20.
By the way, do not forget that for transferring USDT on the Tron network to each address, you will also have to pay 345 units of Bandwidth.
If there are not enough of these special resources on the balance, Tron will "sell" them to you without interrupting the transaction and without warning, taking your TRX.
### Insufficient TRX Balance to Pay the Fee
Even if you have Energy, if your account does not have enough TRX to pay the commission, the transaction may be rejected. This situation can arise if you have stocked up on Energy "just enough," not taking into account that Tron implemented a dynamic energy supply model several years ago. That is, all interdependent parameters change in real time. For example, the gas fee is directly proportional to the network load level. If such moments are not taken into account, then with a forced overuse of the Energy reserve and a lack of TRX, the user will receive the message "Failed — Out of Energy".
### Incorrect Network Selection During Transfer
Tether is the world's first stablecoin pegged to the US dollar (1:1). Several cryptocurrency blockchains issue stablecoins based on it. In particular, for the Tron and Ethereum crypto platforms, Tether Limited created stablecoins based on the standards of these blockchains – TRC-20 and ERC-20, respectively.
But this does not mean that you can use the networks of these blockchains to transfer both types of Tether-based stablecoins.
Sending USDT through the wrong network (e.g., TRC-20 instead of ERC-20 or vice versa) can lead to loss of funds.
It should be remembered that irreversibility is a key characteristic of cryptocurrency blockchains as well. That is, USDT TRC-20 sent to an ERC-20 address is practically impossible to recover.
### Incorrect Recipient Address
The reason for transferring USDT to the wrong address can be both a user error and the actions of fraudsters. In any case, an error in the recipient's address can lead to transaction failure and/or loss of funds.
If these are fraudulent actions, there is no possibility of recovering the funds.
In the case of a sender's typo in the address, two scenarios are possible: the transaction freezes or is confirmed. If the transaction is confirmed, you can contact the wallet holder and try to negotiate a refund. However, a positive outcome is unlikely, as fraudsters use a similar method on cryptocurrency blockchains.
### Network Congestion
High activity on the Tron network can cause delays or failures in transaction processing. Therefore, the system draws on additional computing and energy capacities to maintain high network throughput.
Additional capacities are paid for by each user who performs transactions with smart contracts during this period, including USDT TRC-20 transfers.
What can happen: the user accurately calculated the need for special resources, but due to the additional load on the network, additional units of Energy and Bandwidth were taken from their balance. When the reserve of resources on the balance ran out, the system began to burn TRX.
In the best case, the reserve of native crypto was enough for the transaction, but part of the native crypto was unintentionally spent from the account.
If there is no TRX on the balance or it is insufficient, the transaction freezes.
## Recommendations for Preventing Problems with USDT Transfers on the Tron Network
If the user knows the principles of the Tron ecosystem, including the features of gas fees, they will use special resources, avoiding TRX burning.
After all, to avoid failures during USDT transfers on the Tron network, just follow a few rules:
* Ensure a sufficient balance of TRX, Energy, and Bandwidth; before transferring, make sure you have enough funds on your account to pay commissions and provide Energy;
* Check the correctness of the recipient's address; carefully enter the recipient's address and make sure it is correct before sending;
* Choose the correct network for the transfer; before sending, check that you have selected the correct network (e.g., TRC-20 for Tron) when sending USDT;
* Monitor the network status; with increased system load, it is advisable to postpone the transfer or, if this is not possible, be prepared for possible delays and higher transaction fees.
But, of course, the most economical and safe method of paying for gas is to use special Tron resources. But many users have a question: where to get Energy in sufficient volume for successful transactions on the Tron network?
## Energy Rental as a Way to Avoid Problems with Transfers
To pay for gas on the Tron network, you can use only special resources, without involving the native crypto of the TRX blockchain and other types of assets. But if the Bandwidth resource for a couple of simple transactions comes free to every wallet of ecosystem users, then Energy can be obtained in several ways: staking and renting.
In the staking process, you will, of course, receive the Energy due to you as a reward for free, which is very profitable. But for a couple of transfers a day, you need to freeze almost 24,000 TRX. Few users are able to withdraw such a volume of assets from circulation for half a month.
Moreover, it is not a fact that you will receive the volume of Energy you were counting on. Remember – the dynamic model? The share of the reward for staking (and this is a certain volume of Energy) is distributed among all network users who have sent their TRX to freeze.
## How Energy Rental Helps in Successful Transactions
Renting Energy through special services built on the Tron blockchain is currently an ideal solution for those who regularly transfer USDT TRC-20 to a significant number of addresses.
Yes, this is not a free service, but your costs for renting Energy are significantly more favorable compared to burning TRX to pay for gas. To buy the necessary amount of Energy for one USDT TRC-20 transfer, you will need ~14 or ~28 TRX – depending on the state of the recipient's wallet (with or without USDT on the balance).
Compare these expenses with how much the NETTS Energy rental service deducted from its client's deposit for the maximum volume (131K units).
Why are the amounts small, but still different? We remember: the dynamic model. The second screenshot was taken during a period of minimal load on the Tron network – at night. Under these conditions, NETTS deducts from your deposit payment only for the Energy you actually used.
The deposit amount depends on which type of automation you choose. The service has left an option for those who make transfers irregularly and are ready to recharge their balance each time. To do this, you can simply fill out an application form on the website without using a deposit, but by prepayment.
The Telegram bot (deposit 15 TRX) and Workspace (minimum deposit 1 TRX) are designed for large business platforms that perform dozens of USDT TRC-20 transfers daily.
Connecting the NETTS service client's wallet via API allows you to choose the Energy "delivery" mode to your balance:
* by trigger – Smart mode;
* cyclically, according to a schedule – Host mode;
* continuously - Host mode.
Connecting to the NETTS Energy rental service via API is a solution to all problems related to gas fees on the Tron network.
If your Bandwidth reserves suddenly run out, 1 TRX will be sent from your deposit to your wallet, and the transaction will be successful.
Of course, not all Energy rental services provide API connection, and no one will give you savings on transactions of about 80%, like NETTS, but they all provide:
* significant reduction in transaction fees for USDT transfers on the Tron network;
* increase the probability of a successful transaction, because with a sufficient supply of Energy, you reduce the risk of transaction failure due to lack of resources;
* availability of Energy rental services that allow you to rent this resource for short periods to conduct transactions.
## Conclusion
Failed transactions when transferring USDT on the Tron network can be caused by various reasons, including a lack of Energy and TRX on the sender's balance.
Renting Energy through special services is an effective way to reduce commissions and guarantee successful transactions.
We recommend using proven services for renting Energy and carefully checking transaction details before sending.
Clients of the NETTS Energy rental service do not worry about transactions going through. They are confident that there will always be enough Energy on the balance. Join now - - and keep 80% of your saved TRX.
---
---
url: >-
https://doc.netts.io/blog/articles/why-usdt-trc-20-has-become-more-popular-than-usdt-erc-20.md
description: >-
Tether – a product of the company of the same name, Tether Limited – is the
world's first stablecoin pegged to the US dollar (1:1). Several cryptocurrency
blockchains issue stablecoins based on it....
---
# Why USDT TRC-20 Has Become More Popular Than USDT ERC-20
Tether – a product of the company of the same name, Tether Limited – is the world's first stablecoin pegged to the US dollar (1:1). Several cryptocurrency blockchains issue stablecoins based on it.
The popularity and demand for this cryptocurrency are evidenced by the fact that Tether Limited recently issued an additional 1 billion USDT on the Tron network. This means that since the beginning of 2025, a total of 8 billion USDT has been issued. As a result, the capitalization of the largest stablecoin has exceeded $96 billion.
This article will discuss the stablecoins of the Tron and Ethereum cryptocurrency networks, created by Tether Limited based on the standards of these crypto platforms: TRC-20 and ERC-20, respectively.
So why was 1 billion USDT issued specifically for the Tron network, i.e., based on the TRC-20 standard tokens of this eco-platform?
Well, for starters, for over three years (or 40 consecutive months), the Tron-based version of USDT has outperformed the Ethereum-based version of the stablecoin. And by the end of 2024, USDT became the leader in so-called "organic" transactions – transfers made by real people, not bots.
In the first weeks of this year, USDT TRC-20 reached a huge milestone – it became 900% more popular than its counterpart, USDT ERC-20.
We examine the reasons for the increased popularity of USDT TRC-20 compared to USDT ERC-20, driven by various factors, ranging from low fees on the Tron network to the advantages of the system's technological capabilities.
We will also consider ways for additional savings on commissions, which are available to all users of the Tron eco-platform.
## Comparison of USDT TRC-20 and USDT ERC-20
USDT TRC-20 and USDT ERC-20 tokens ensure compatibility with protocols based on the Tron and Ethereum blockchains, respectively, and with decentralized applications (DApps). This allows users to make transactions and exchange fiat currencies within these cryptocurrency systems.
### Main Differences Between the Two Standards
1. Gas fees or transaction commissions:
USDT ERC-20. Fees on the Ethereum network are charged only in native crypto, and when converted to fiat currency, can reach several dollars, especially during high network load.
USDT TRC-20. The Tron network uses special resources for gas fees, which can be obtained by staking or renting. In the latter case, native crypto may not need to be withdrawn from circulation at all. As a result, commissions are significantly lower than on the Ethereum network, making Tron attractive to users, including cryptocurrency business platforms.
2. Transaction speed:
USDT ERC-20. The speed of stablecoin transfers on the Ethereum network is about 15 TPS (transactions per second).
USDT TRC-20. The Tron network provides the highest transaction processing speed among all blockchains using Tether-based stablecoins – up to 2000 TPS.
3. Compatibility and ecosystem:
USDT ERC-20. Wide support in decentralized applications (dApps) and DeFi platforms.
USDT TRC-20. Has limitations in some systems, for example, in Ethereum itself.
| **Network** | **Advantages** | **Disadvantages** |
| :---------- | :--------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------- |
| TRC-20 | Low fees and the possibility of using additional ways to save on commissionsHigh transaction speedSupport for many DAppsAdditional comfort due to the GasFree function for those who do not hold TRX and Tron resourcesGrowing ecosystem | Less decentralizationLimited support on some platforms |
| ERC-20 | Wide support in decentralized applications (dApps) and DeFi platformsHigh level of decentralizationSecurity and reliability | High feesLow transaction speedLack of a built-in mechanism for transaction status notifications |
## Advantages of Using USDT TRC-20
Above, we listed the differences between Tether stablecoins developed for the Tron and Ethereum cryptocurrency blockchains. Now let's conclude – why users choose USDT TRC-20.
1. Low fees make the Tron network's stablecoin ideal for micropayments and frequent transfers. This is beneficial both for individual users who regularly, but not often, transfer USDT to several addresses or even to one address, and for business platforms that make dozens of transfers to various addresses.
2. The Tron ecosystem supports various services operating on the network that help users reduce transaction costs (Energy rental services) or provide necessary comfort during transfers (GasFree).
3. High transaction speed ensures quick confirmation of operations, which saves users time and costs. In addition, transaction speed affects network load, and consequently, gas fees. That is, using USDT TRC-20, unlike USDT ERC-20, saves not only your time but also your money.
4. Growing support from various exchanges and wallets simplifies the use of USDT TRC-20 – at the moment, it is difficult to even name the number of wallets that support the Tron stablecoin, so high is its popularity and demand.
## How to Reduce Fees When Using USDT TRC-20
To transfer USDT TRC-20, you can, of course, use native crypto as a gas fee, as is done on most cryptocurrency blockchains. But the Tron team has developed special resources for users that can be used to pay commissions. The Bandwidth resource is credited to each user's balance daily for free. These 600 units are enough for one USDT transfer – it requires 345.
The Energy resource can be obtained in several ways (it is not distributed for free).
### Ways for Additional Savings
1. Staking TRX. For a couple of transfers a day, you will have to withdraw almost 24,000 TRX from circulation and freeze them, which does not guarantee the receipt of the required amount of Energy, nor that the resource will be enough for the planned transactions. Surprises can come from Tron's dynamic energy supply model.
2. Renting Energy on the Tron network through platforms that, among other cryptocurrency operations, can charge your wallet with the resource. This allows you to reduce transaction fees by 30-70%. But the user will have to manually submit an application each time, and beforehand – accurately calculate the required amount of Energy.
3. Using specialized Energy rental services that can connect clients via API.
The NETTS Energy rental service provides its clients with the opportunity to connect via API to automate processes and optimize commission costs.
Your task is to decide on the mode, choosing between Smart and Host.
To work in Smart mode, you need to determine a trigger, that is, such a level of Energy on the balance, a decrease to which during USDT TRC-20 transfers requires another replenishment.
This means that you will not have to scrupulously calculate the required amount of Energy for a working day with an accuracy of ten. The NETTS Energy rental service will replenish your wallet itself as soon as the resource level drops to the minimum you specified.
What is another advantage of connecting via API – only the cost of the Energy actually used will be debited from your deposit (except for periods of Tron network overload). If you rent on a prepaid basis, as is customary on other platforms, you will not be refunded the difference in TRX, and the unused Energy will not remain in your wallet.
Although NETTS has left the option of renting on a prepaid basis – this rental mode is in demand by those who rarely and irregularly transfer stablecoins.
Large businesses are attracted by the Host mode – a constantly replenished balance ("eternal" Energy) or replenishment of the wallet/wallets in cycles.
And most importantly – the answer to the question, how much can I save by renting Energy from NETTS? Here are screenshots of real invoices for actually rented Energy in the amount of 131K units for one hour.
You, of course, noticed the difference in the amount? This reflects the peculiarity of the Tron blockchain's dynamic energy supply model. And proof that the invoices are issued in real time during the rental process: the first – during the day, the second – at night, when the network load is minimal.
Well, you certainly couldn't have missed the economic effect: even during the day – almost 80%! So far, only the NETTS Energy rental service can provide such discounts on transaction fees on the market!
## Conclusions
If your choice is speed and cheap transactions when transferring tokens pegged to fiat currency rates, we recommend USDT based on the TRC-20 standard. This stablecoin is not accidentally breaking records in popularity and demand, as the Tron blockchain provides speeds of up to 2,000 transactions per second.
The features of the Tron ecosystem not only ensure the highest transaction speed among all cryptocurrency blockchains but also significantly reduce commission costs. You do not have to spend native crypto on commissions – there are special resources for this, which you will not find on any other cryptocurrency blockchain.
For additional savings, use the NETTS service for renting Energy on the Tron network.
Start saving 80% on transactions today by connecting via API. And keep your TRX, don't burn them in the fire of transactions!
---
---
url: >-
https://doc.netts.io/blog/articles/best-telegram-bots-for-working-with-trx-and-trc-20.md
description: >-
Users of the Tron eco-platform who interact with smart contracts (including
USDT TRC-20) are always interested in reducing transaction costs....
---
# Best Telegram Bots for Working with TRX and TRC-20 (Energy Rental, Transfers, DeFi)
Users of the Tron eco-platform who interact with smart contracts (including USDT TRC-20) are always interested in reducing transaction costs.
For TRC-20 transactions, the blockchain charges gas fees, which can consist of the native crypto TRX, specially created resources – Energy and Bandwidth, or include all types of these assets simultaneously.
For the commission of simple transactions with TRC-10 tokens (e.g., transferring TRX), the Bandwidth resource is sufficient, the limit of which is constantly replenished. The ecosystem does this for free for each participant – the daily replenishment of this resource is 600 units.
When interacting with smart contracts, it is necessary to cover the network's expenses for attracting additional capacities for the successful completion of the transaction. Both TRX and the special resource Energy can be spent on this.
The advantage of using Energy is that it can be obtained practically for free by using staking. However, to conduct one transaction, say, transferring any amount of USDT, requires 65K or 131K Energy, depending on the presence of USDT in the target wallet. To obtain such an amount of resource, a substantial volume of native crypto should be sent to staking – ~12000 TRX for one free transfer per day.
But even if such an amount of TRX is available on the balance, not every user is ready to withdraw them from circulation for two weeks. Besides, it's not guaranteed that you will receive the necessary amount of Energy, as the volume of TRX directed to freezing by all blockchain participants is constantly growing, while the total volume of proportionally distributed resources is not.
And why the extra headache, when there is an opportunity to:
* receive Energy without the risks of staking;
* not withdraw large volumes of TRX from circulation;
* fill the wallet with Energy in the required amount;
* receive the resource practically at any time;
* save about 80% on each transaction – this is the only offer on this market from NETTS, others are significantly lower.
We are talking about Energy rental services built on the Tron blockchain. And in this publication, we will turn to those services that allow users of the eco-platform to automatically replenish their Energy balance through Telegram bots.
Such services provide their users with a choice. You decide which method suits you better: renting through a form on the website or through a Telegram bot. There is a difference, and in some aspects significant, especially concerning ease of use, savings and security.
Of course, both options ultimately provide you with much more advantageous Energy acquisition than staking. But there is also a difference.
1. Renting through the website form allows you to receive Energy without any obligations, whereas using a bot provides a much more automated and reliable solution for everyday transactions. You can order an algorithm to "charge" your Energy balance depending on your schedule of interaction with TRC-20 standard tokens.
2. Renting through the website form involves prepayment for each request. In the Telegram bot, payment for services is made through a deposit. What's the difference? If you haven't used the entire rented volume, the difference from the prepayment for the webform will not be returned to you. However, from the deposit, the service usually deducts payment only for the actually consumed Energy. Unless, of course, the demand for the resource exceeds market capacity, but this is specified separately. That is, renting through a Telegram bot can be more advantageous with adequate demand for Energy, which is most often observed on the Tron network.
3. Tron network users should be aware that there are also phishing sites and services in the Energy rental sphere that offer low prices, but during the operation, they deduct USDT instead of TRX from you, if the sale is done through a website, for example. Always carefully check what you are signing when connecting via web3. It is better to use Telegram bots for renting. And do not connect through a browser with your main wallet – choose those services whose Telegram bot provides the ability to use a non-custodial wallet linked to it.
## 1. Feee.io
The Feee.io platform has a Telegram bot — `@feee_io_bot`
It allows, in particular, to rent energy, exchange TRX for USDT, request the exchange rate, and monitor transactions.
This service was initially created for trading Tron resources, so the main functions were exchange trading, and later, functions for renting blockchain resources were added with the following advantages:
* the ability to create buy or sell orders for resources in the required volumes;
* automatic matching of offers and demand;
* prompt transactions – the required volume of resources (Energy and Bandwidth) is credited to the user's wallet within minutes;
* providing users the opportunity to rent out TRX and Tron resources to other blockchain participants.
Feee.io is capable of renting out large volumes of resources and funds, which is suitable for active blockchain users who wish to save on transactions by avoiding the systematic spending of native crypto.
## 2. Netts.io
An actively developing service initially designed for renting Energy to ensure savings on USDT transfers —
Bot address:
The NETTS Energy rental service offers exceptional advantages.
1. **Opportunity to reduce transaction costs by up to 80%, and sometimes even more:**\
For renting 131K Energy for an hour, you will pay only 6 TRX. For comparison: the approximate cost of such an amount of Energy for 1–2 USDT transfers, depending on the recipient's balance, is 27 TRX.\
At the time of writing this review, this is the lowest price on the Energy rental market, as shown by monitoring the most popular services.
2. **Very user-friendly interface:**\
You can charge your wallet with rented Energy even without having native TRX crypto tokens on your balance. Simply connect to the Telegram bot, enter your address, and make a USDT transfer through any of your Tron-compatible wallets, paying the service fee with the same stablecoins you are transferring.
3. **Flexible Energy rental conditions:**\
You can rent the required volume of resource for a period determined by you, at a time determined by you.
4. **There is an option to order automatic Energy replenishment when its balance drops to a certain level.**
Through **Netts Energy Charge Bot**, it is advantageous to rent Energy because, with minimal Tron network load, the service deducts only for the actually consumed Energy volume from your deposit. Whereas prepayment through the website form, for understandable reasons, does not provide for refunds — in this case, it is impossible for the service to control the actual consumption of rented Energy.
Even more possibilities are offered to NETTS clients through the **Workspace** — via the personal account, you can keep your finger on the pulse of the entire Energy rental process and conducted transactions, including recipients. A high level of automation is provided by connecting via API.
Two unique modes allow you to choose the method of charging your wallet/wallets with Energy:
* **Smart Mode** — this is the possibility of using a trigger: when the Energy level drops to a certain indicator, NETTS automatically replenishes the balance to the initial level determined by you.
* **Host Mode** — charging your wallet with Energy according to your schedule or in *non-stop* mode.
**Test the capabilities of Workspace right now: the minimum deposit is only 1 TRX, which you can withdraw after completing the exploration.**
## 3. TronSave
TronSave has a Telegram bot that allows performing individual orders for purchasing Energy: `@tronsaveofficial`
The platform aims to reduce transaction costs in the Tron ecosystem, offering secure tools for working with Energy.
The service provides an opportunity not only to save on transactions but also to receive additional income from using frozen TRX.
It offers users a range of built-in tools that ensure simple and profitable interaction with the Tron eco-platform.
In addition to those listed, the TronSave platform provides both network users and Energy providers the following advantages:
* savings on transaction fees in the Tron network;
* Energy rental is available not only to individual users but also to projects;
* the possibility to earn income on unused Energy by renting it out;
* up to 25% APY on TRX sent to staking (through rented Energy via TronSave);
* stable passive income while simultaneously receiving staking rewards, renting out Energy, and optimizing profit.
Full user control over staked TRX and income from renting out Energy, which you receive as a reward for frozen assets, is maintained.
## 4. Mefree.net
**Mefree.net** — a constantly growing decentralized ecosystem where users can buy and exchange Energy.\
Bot address: `@SuperXCoinBot`
The **Smart hosting** and **Subscribe Energy** functions are also available, allowing process automation.
The interface is not as user-friendly as specialized services focused on Energy rental, but the bot works around the clock.
The amount of Energy in the pool is about 1.2 billion and constantly growing.\
There is an option to buy a large amount of Energy at once for several wallets or many orders for one address.\
The service promises Energy delivery to the wallet within a minute.
## 5. Tronify
Address: `@tronify_energy_bot`
This bot provides Energy and virtual currency rental services.
By renting Energy in advance, you can avoid burning TRX to obtain this resource, which will save you a significant amount of TRX for your transfers.
* Renting 64,000 Energy on this platform will cost you **7.04 TRX** at the time of writing this review.
* Renting 130,000 Energy will cost **14.3 TRX**.
This Energy leasing platform offers rewards for replenishment:
* 500 ≤ top-up amount < 1000 — **5% discount**;
* 1000 ≤ top-up amount < 10000 — **8% discount**;
* 10000 ≤ top-up amount < 500000 — **13% discount**.
> Please note that this review focuses not on the most popular Energy rental services, but on platforms that have not only implemented but also successfully use a Telegram bot for Tron platform users engaged in USDT TRC-20 transfers and interacting with other smart contracts.
These 5 services provide the most advanced ways to reduce transaction costs associated with USDT TRC-20 transfers and development of all types of DApps — DeFi, DEX, Decentraland, The Sandbox, etc.
---
---
url: https://doc.netts.io/blog/articles/fees-in-the-tron-network-how-they-work.md
description: >-
Tron is one of the most promising and rapidly growing blockchains. Unlike
Bitcoin or Ethereum, where fees are charged directly in the network's token
(BTC, ETH), Tron uses a different model with Bandw...
---
# Fees in the Tron Network: How They Work and How to Minimize Them
Tron is one of the most promising and rapidly growing blockchains. Unlike Bitcoin or Ethereum, where fees are charged directly in the network's token (BTC, ETH), Tron uses a different model with Bandwidth and Energy resources. Because of this, understanding Tron fees is not straightforward at first glance. Let's figure out what constitutes fees in the Tron network and how they can be practically reduced to zero or significantly minimized.
## Activating a New Account (One-Time Fee)
Firstly, the Tron network has a one-time fee for account activation. When you create a Tron address for the first time, you need to activate it by sending some amount of TRX to it. Currently, activation costs 1 TRX. After this, the account becomes a full participant in the network, and further transfers are possible from it.
Note: Many wallets (including services like NETTS) can perform activation automatically, so you might not even notice it.
## Bandwidth – Fee for Simple Transactions
For ordinary transactions in Tron (e.g., transferring TRX or other TRC-10 standard tokens), the Bandwidth resource is used. Each transaction consumes a certain amount of Bandwidth, proportional to the transaction size in bytes.
Good news: Every Tron account receives a small amount of free Bandwidth daily. This means that several small transactions per day can be performed without using TRX for fees.
### Daily Bandwidth Limit
Currently, the network allocates about 600 Bandwidth points per address per day. This is enough for 1–2 transactions (depending on their size). The limit may change depending on decisions made by the Tron community, but the essence is that you can perform a certain number of operations with TRC-10 tokens for free every day.
A simple TRX transfer usually consumes about 250–300 Bandwidth, depending on the amount of data in the transaction (sender address, recipient address, etc.). If you stay within the free limit, TRX will not be deducted from your balance at all.
### Paying for Bandwidth Beyond the Limit
If the free Bandwidth units are exhausted, the network will take an equivalent amount in TRX from your balance for each additional unit of the resource. The current rate is 0.001 TRX per 1 Bandwidth. That is, 100 additional units of the resource will cost 0.1 TRX.
#### Example (TRX Transfer)
Suppose you have already exhausted your daily Bandwidth limit, and the next transaction requires 300 units of this resource. In this case, the fee will be 300 × 0.001 = 0.3 TRX. If you convert this fee into dollars (at a TRX rate of approximately $0.24), it comes out to about $0.072 — not much at all. And if the Bandwidth limit has not yet been exhausted, this transaction will cost you 0 TRX in fees.
## Energy – Fee for Smart Contract Operations
For more complex operations in Tron, such as sending TRC-20 tokens (e.g., USDT TRC-20) or calling a smart contract of a decentralized application, Bandwidth alone is not enough. Here, the second special Tron resource comes into play – Energy.
### Features of Energy in Tron
There is no daily limit. Unlike Bandwidth, the network does not distribute Energy for free. Each user must take care of Energy themselves if they plan to interact with smart contracts.
### What Energy is Spent On
When calling a smart contract (and transferring a TRC-20 token is also a contract call), a certain amount of energy is consumed. The more complex and "heavy" the operation execution, the more energy capacity the transaction requires. These network costs are covered by users using the special Energy resource.
For example, transferring a USDT (TRC-20) token might require about 64,000 – 131,000 units of Energy. The exact figures depend on whether new addresses are involved, how complex the contract logic is, etc.
### Paying for Energy
If the user does not have the Energy resource on their balance, or it is insufficient to pay for the transaction, the missing part is covered by burning TRX. In other words, the network "sells" you the missing Energy for TRX at the moment of the transaction. Currently, the price of Energy is about 0.00021 TRX per unit of Energy (this value can be updated by network parameters).
#### Example (USDT TRC-20 Transfer)
You want to send 100 USDT on the Tron network, and you have no TRX staked and, consequently, no Energy. Suppose the USDT smart contract required 64,000 Energy to perform the transfer. The network will deduct a fee from your TRX balance equivalent to this volume of resource:
64,000 × 0.00021 = 13.44 TRX
If TRX is trading at ~$0.24, then this is about $3.22. Such a fee is roughly equal to the fee for transferring USDT on Ethereum, but it can be minimized by 80% or even reduced to zero if prepared correctly.
## How to Reduce Tron Fees: Staking TRX and Renting Resources
The Tron fee system is designed so that you can prepare (accumulate) resources in advance to avoid paying for them with each transaction. There are two main ways to reduce or even avoid network fees: staking (freezing) and renting Energy and Bandwidth.
### Freezing (Staking) TRX
Staking involves withdrawing a certain volume of TRX from circulation. The user essentially rents them out to the ecosystem for a certain time, for which they receive a reward.
1. By freezing TRX to receive Bandwidth as a reward, you will increase your daily limit of free Bandwidth, allowing you to send TRX more often without commission.
2. By freezing TRX to receive Energy, you will receive a certain amount of Energy daily. These free amounts of Energy will be used instead of burning TRX when interacting with TRC-20 tokens.
The amount of resources received is proportional to the amount and duration of the freeze.
#### Example
To have enough Energy for 2 USDT TRC-20 transfers per day, it is currently necessary to freeze about 23,000 TRX (this amount is approximate and depends on the total volume of TRX staked in the Tron network).
This method does not require spending TRX on fees, but the frozen coins remain unavailable for trading and must be unfrozen before they can be used again. As a result, a fairly substantial sum has to be withdrawn from circulation for half a month.
### Renting Resources (Energy) from Other Participants
To obtain Energy, it is not necessary to own a large amount of TRX. There are resource rental markets in the Tron ecosystem. That is, other network users with large stakes are willing to rent out their surplus Energy for a small fee. You pay a certain amount of TRX and in return receive Energy to your address for a specific period. This is significantly cheaper than burning TRX with each transaction.
#### Example
Renting 1,000,000 units of Energy for 3 days will cost approximately 270 TRX and allow for about 10-15 transactions of TRC-20 format tokens (depending on their "weight" and consumed Energy).
For comparison: if you do not rent, but pay for these transactions by burning TRX, a total of about 630 TRX will be spent on fees. The savings are obvious – about 60% of the funds remain with you.
Of course, independently finding and renting Energy requires additional steps and understanding of the Tron resource market. For the average user, this is difficult. Fortunately, services are emerging that simplify working with Tron resources, allowing transfers with minimal fees and in a convenient format.
## NETTS – Tron Transactions Without Worrying About Fees
The NETTS Energy rental service was created specifically to relieve users of the complexities associated with bandwidth and energy consumption. NETTS is an infrastructure platform that optimizes payments on the Tron network.
### Advantages of Using NETTS
The main advantage of this relatively recently created but rapidly developing service is that it was initially designed for convenient USDT transfers and Energy rental. For many older platforms that simply added the Energy rental function alongside other services, it often never became a priority.
NETTS started with a simple web interface and login via a website form. This function remains and is ideal for those who do not regularly engage in USDT transfers.
Parallel to the web interface, a Telegram bot was developed and launched.
But the team – enthusiasts and users of the Tron network – does not stand still: now clients have access to a unique Workspace with API connection and two modes, Smart and Host.
The NETTS Energy rental service maximizes the comfort of network users and significantly, up to 80%, reduces their spending on transactions with TRC-20 format tokens, particularly with USDT TRC-20, in other words – with smart contracts.
As a result, NETTS clients have a number of significant advantages compared to other Tron users, including large platforms that transfer USDT TRC-20 to dozens of addresses daily.
1. A USDT transfer transaction costs clients 3-6 TRX depending on the recipient's wallet status, as seen in the screenshot above. The same operation without rented Energy costs 14-27 TRX. 80% savings – the only offer on the market, and it comes only from NETTS.
2. When using the Telegram bot in conditions of minimal network load, you will only pay for the Energy actually used.
3. You can choose the type and level of automation for the Energy rental process according to your tasks. For example, log in via the website form with prepayment, via the Telegram bot with a minimum deposit of 15 TRX, or via the Workspace cabinet with API connection with a minimum deposit of only 1 TRX.
4. You independently regulate the mode of charging your wallet with Energy thanks to the unique Smart and Host modes.
5. Smart allows the client to set a trigger, upon reaching which NETTS immediately recharges the balance to the initial level.
6. Host is a mode of perpetual Energy or cyclical resource supply according to your schedule. There is an option to pause at any moment.
7. NETTS allows you to make USDT (and other TRC-20 tokens) transfers even if you don't have TRX for the fee. The service charges a symbolic fee in the same USDT. Essentially, you pay the fee with the token you are transferring, instead of holding separate TRX for this purpose.
8. You don't need to withdraw thousands of TRX from circulation or understand Tron's mechanisms. NETTS takes care of these tasks. You freely use your funds while the service provides resources in the background.
## Conclusion
The Tron network initially offers very low fees by utilizing an innovative resource system. Once you understand the purpose of Bandwidth and Energy, you can save significantly and even conduct transactions for free.
And services like NETTS make this process even simpler: you get the benefits of Tron (fast and inexpensive transfers) without worrying about technical details or managing network resources. You simply send your TRX or USDT — and NETTS will take care of minimizing the fee!
Test the capabilities of the NETTS service right now – simply add some TRX to the Workspace's deposit and explore the possibilities of your personal account. This is your control center, allowing you to strictly control the Energy rental process, choosing the tools suitable for you to get the maximum discount – up to 80%!!! – when conducting transactions with TRC-20 tokens.
---
---
url: >-
https://doc.netts.io/blog/articles/how-do-exchangers-and-p2p-platforms-save-on-tron-fees.md
description: >-
A decentralized or centralized cryptocurrency P2P platform allows users to
sell, buy, or exchange cryptocurrency directly through a transaction with
another user. Such a peer-to-peer platform can be p...
---
# How Do Exchangers and P2P Platforms Save on Tron Fees?
A decentralized or centralized cryptocurrency P2P platform allows users to sell, buy, or exchange cryptocurrency directly through a transaction with another user. Such a peer-to-peer platform can be part of a larger platform where, in addition to exchange operations, spot trading, futures, crypto lending, etc., are presented.
Currently, the cryptocurrency market features:
* crypto exchanges with a wide range of functions and optimized platforms for working with digital assets; here, the platform organizes the transaction on behalf of the client, and the market determines the asset price;
* separate P2P services for exchanging cryptocurrency directly between users without third-party intervention;
* crypto asset exchangers with automatic exchange without the ability to choose the seller and buyer.
Cryptocurrency exchangers and P2P platforms are attractive due to anonymity, low or zero fees, and the absence of intermediaries between the transaction parties.
Since the native currency of the Tron ecosystem – TRX – has grown in value over the past year, outpacing many other well-known cryptocurrencies, the most famous exchanges readily work with the blockchain through their peer-to-peer platforms.
It has also become important that Tron has almost definitively established itself as a center of high stablecoin activity. Therefore, among the exchanges working in this blockchain – Binance, Bybit, OKX, Bynex, Huobi, MEXC, EXMO, Bitfinex, Gate.io, Kraken, KuCoin – many have a P2P platform.
To conduct transactions in the Tron ecosystem, all exchangers and P2P platforms need special resources to pay commissions only on this blockchain. For these cryptocurrency platforms, fees on the Tron network can constitute a significant part of expenses due to the large volume of transactions. Therefore, finding an effective way to reduce costs is very relevant for them.
We consider which methods large services use to minimize commissions, and also find out how API helps in automating processes.
## Main Costs for Exchangers on the Tron Network
Decentralized exchanges and P2P services operate on the blockchain principle and are based on smart contracts. The fuel for smart contracts in most cryptocurrency blockchains is their native currencies. The Tron eco-platform is an exception. Gas fees for interacting with smart contracts in this system are paid, among other things, using specially developed resources – Energy and Bandwidth.
Everyone working on the Tron blockchain strives to exclude the native crypto TRX from transaction payments. Exchanges are even more interested in this, as they can use TRX in more profitable operations – selling, exchanging, etc.
Interaction with smart contracts on the Tron network, i.e., with TRC-20 standard tokens, requires exchanges to maintain a significant reserve of Energy. Despite Tron implementing the GasFree function for transferring USDT TRC-20 (a stablecoin pegged to the USD rate), exchangers and P2P platforms, like other Tron users, are in no hurry to switch to paying for transactions with stablecoins instead of Energy and Bandwidth.
But all Tron participants dealing with smart contracts face the task of having sufficient resource reserves. Because otherwise, the missing volume of Energy and Bandwidth will have to be paid for with native TRX crypto. Moreover, the blockchain switches to burning the native currency from the sender's balance without even warning them. If TRX is also insufficient – the transaction hangs, and only a prompt replenishment of the balance with Energy can save it.
Furthermore, Tron switched to a dynamic energy supply model several years ago. This helps attract additional energy and computing power during periods of high user activity. But under high load on the Tron network, the gas fee can also increase in real time. The screenshot below clearly shows the trend of annual increase in Energy consumption:
That is, to prevent transaction freezes during Tron network overheating, P2P platforms and exchanges working with it must provide for:
* an additional reserve of Energy;
* the ability to quickly replenish the balance when the network status changes, even at night;
* ensure replenishment of the Energy balance according to a specific schedule, or better yet – depending on the reserve dropping to a certain level.
Let's figure out if such previously unbelievable possibilities exist within the Tron blockchain or beyond it.
## Methods for Optimizing Fees
Let's start this unique review with strategies familiar to most, used by exchangers and P2P exchanges, and then move on to more modern and advanced methods.
### 1. Staking TRX
For exchanges holding large volumes of TRX, this was, until recently, a proven method not only for obtaining free Energy but also an opportunity to participate in the governance of the Tron blockchain as part of its validators. But this is acceptable for holders of large TRX volumes who can painlessly withdraw them from circulation for two weeks. Large cryptocurrency exchanges with their associated P2P platforms can afford this.
A simple example: for the daily replenishment of the Energy reserve for one USDT transfer transaction, 12,000 TRX must be sent to staking – if the recipient's balance does not have these tokens, and half as much – if it does.
Now imagine the volume of transactions on an autonomous P2P platform, and you will understand that for exchangers and independent P2P platforms, staking is not the best option.
### 2. Using GasFree
Tron has indeed launched the long-awaited GasFree function. And it really relieves the USDT sender from paying gas fees. But not from paying the transaction commission!
Yes, you can use this function to transfer USDT without having TRX, Energy, and Bandwidth on your balance. Instead, you will pay in the same stablecoins, and one transfer will cost much more than the gas fee.
Above is a screenshot from testing the function: for transferring USDT using the GasFree function, the blockchain takes 10 USDT – that's almost 43 TRX. That is, two to three times more than the gas fee for the same transaction, considering the recipient's wallet status.
So, for mass transactions, this method of optimizing fees is practically unavailable. It is more suitable for individual lazy users who rarely transfer stablecoins but have a significant volume of USDT and do not want to spend time on staking.
This function is also suitable for Tron newcomers who have not yet understood the specifics of gas fees on this blockchain.
### 3. Renting Energy
This method of optimizing fees on the Tron network is maximally acceptable for cryptocurrency decentralized exchangers and P2P platforms because it:
* allows reducing commission costs by at least 2–3 times compared to staking;
* does not require freezing TRX, making this method optimally flexible;
* advanced Energy rental services provide the possibility of full process automation through a web interface or Telegram bot;
* gives the exchange the opportunity to order the "delivery" of the required volume of Energy from the rental service for a specific period at a specific time;
* the presence of optimal automation tools at the rental service allows the user to pay only for the actually used volume of Energy.
When collaborating with a service that provides all these services, P2P platforms, like regular users, will not experience any problems with transactions at all.
The recently emerged and rapidly growing NETTS Energy rental service has already taken leading positions in this market. This is largely due to the implementation of automation and the team's excellent market knowledge.
Already now, NETTS provides a discount on Tron network transactions of about 80%, and during hours of minimal network load, this figure is even higher:
This is how you can save on transactions if you know the right spots and the right time. Yes, the best choice is a 24/7 automated Energy rental service. The screenshot on the right, shown above, was taken during a night session of Energy rental from the NETTS service. As you can see, renting 131,000 units cost the user less than 5 TRX.
Let's take a closer look at how the API of an Energy rental service helps exchangers and P2P platforms working on Tron save on fees.
## API for Automating Energy Rental
Let's start by saying that rental services without competent automation cannot provide the client with a refund for unused but prepaid Energy.
But the NETTS service will not deduct anything from your deposit in the Telegram bot if the Energy pumped into your wallet is not used within the agreed rental time (exception – Tron network overload).
This possibility is now available to NETTS renters even when accessing through the website – along with other new features. The team has developed and connected Workspace — a mechanism for automatically charging a wallet on the Tron network.
What does this offer besides the possibility of not paying for unused resources? You can order a charging cycle – this is especially beneficial for exchanges that make a large number of USDT transfers per day.
15 seconds after a transfer secured by Energy rented from NETTS, 131K units of the resource are poured back into the balance. So you will never worry about the problem of a possible Energy shortage. If desired, you can configure any schedule for replenishing the Energy balance provided for rent by the NETTS service. The minimum cycle is three charges per day.
These are the capabilities of the Host mode, which can provide practically "perpetual" Energy. And the Smart mode is the replenishment of your balance when the Energy level drops to a set trigger.
That is, the user of an Energy rental service with an API gets the following advantages:
* no need to calculate the required volume of Energy based on transactions;
* instant charging of the balance with Energy without manual intervention;
* maximum flexibility – rent in the required volume and for a specific period;
* possibility to set the resource replenishment cycle;
* maximum possible savings on transactions – about 80% on the NETTS Energy rental service;
* simple integration with decentralized P2P platforms and exchangers;
## Conclusion
The key tools for reducing fees in Tron are renting Energy and automating this process via API.
The most effective and profitable Energy rental service is one that allows saving as much money as possible per transaction and allows full automation of the recharging process without extra hassle.
Decentralized P2P platforms and exchangers using these technologies save significant amounts.
Try the NETTS service API for automatic Energy rental and reduce commission costs by 80% starting right now — \
Workspace deposit — only 1 TRX, which you can withdraw after exploring the possibilities of your personal account.\
**We warn about possible addiction: all explorers have already become NETTS clients.**
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-reduce-usdt-transfer-costs-for-business.md
description: >-
Just a day before writing this article, news arrived that Tether Limited
issued an additional 1 billion USDT on the Tron network. That means a total of
8 billion USDT has been issued since the beginni...
---
# How to Reduce USDT Transfer Costs for Business?
Just a day before writing this article, news arrived that Tether Limited issued an additional 1 billion USDT on the Tron network. That means a total of 8 billion USDT has been issued since the beginning of 2025.
Tether is a product of the company of the same name. It is the world's first stablecoin pegged to the USD rate (1:1). Stablecoins for cryptocurrency blockchains are issued based on it. USDT TRC-20 is the stablecoin of the Tron eco-platform. By the end of 2024, USDT dominated the "organic" transaction segment (i.e., made by real people, not bots) with a share of over 68%.
USDT TRC-20 tokens ensure compatibility with TRON blockchain-based protocols and decentralized applications (DApps), allowing users of the ecosystem to conduct transactions and exchange fiat currencies within this system.
What else makes these tokens so attractive for business is the speed of confirmation and low fees.
However, objections can be heard regarding the latter statement. Allegedly, the cost of transactions with USDT TRC-20 (and other smart contracts) in the Tron system is constantly growing. We hope these objections are not too widespread. Because the truth is that companies facing high fees for USDT transfers on the Tron network simply aren't familiar with the mechanisms and features of this ecosystem.
Therefore, for businesses conducting numerous transactions with Tron stablecoins daily, these costs can be significant. But only if the native crypto – TRX – is burned each time for a USDT TRC-20 transfer.
Is there another way? Experienced and active users know that transaction costs on the network can be minimized. You just need to use all the possibilities provided by this very flexible and user-friendly blockchain.
Let's consider how renting Energy can become an effective solution for significantly reducing commission expenses related to smart contracts. We explain how renting Energy on the Tron network can help online stores, P2P exchangers, and payment services reduce fees for USDT TRC-20 transfers.
## Why Are Fees for USDT Transfers on the Tron Network High?
First, let's understand the factors influencing the size of the fees.
And the very first one is the choice of means and method of payment for the transaction. Unlike most cryptocurrency blockchains where gas fees are charged in the native crypto of the blockchain itself, Tron offers a very flexible and diverse payment scheme for USDT TRC-20 transfer transactions.
The most inefficient choice of payment method is Tron's native crypto – TRX. Analysis via the TronScan explorer shows that colossal volumes of TRX are burned for transactions on the Tron network.
Yet Tron provides its users with a unique opportunity – to reduce commission payments significantly. You just need to understand the blockchain's resource system, which can be used to pay for gas.
There are only two types of such resources, and one is replenished on the balance of every network user daily and for free.
### Bandwidth
This is the resource that the blockchain replenishes for you for free. The replenishment volume depends on the validators' decision. Today it is 600 units. This amount of Bandwidth is enough for a couple of simple transfers of TRC-10 standard tokens, the native crypto, for which it was initially launched. One transaction with TRC-20 tokens requires 345 Bandwidth units, so the daily free limit will not satisfy active users.
### Energy
This is the main resource needed in more significant volumes than Bandwidth for executing transactions with TRC-20 tokens, including USDT. If the balance lacks Energy, the system automatically starts burning TRX, which increases the transaction cost. After all, you can obtain Energy through staking, simply by freezing a certain amount of TRX, or rent this resource on special services. This expense is also incomparably less than paying commissions with native crypto.
Another example of irrational spending and significant transaction cost increase when transferring USDT TRC-20 is using the GasFree function. It seems great – the gas fee is indeed canceled. But not the transaction commission. With this function, they are charged in USDT, and this is even more expensive than paying in TRX.
While you would burn ~14 TRX or ~28 TRX when transferring USDT TRC-20, depending on the recipient's balance status, using the GasFree function, you will pay 10 USDT for transferring any volume of stablecoins.
By the way, here is another point to consider when transferring USDT – the state of the recipient's balance, if you pay for gas in TRX or with Bandwidth and Energy resources. For transferring to a wallet with a zero USDT balance, Tron will take ~14 TRX from you, and when transferring to a balance where these tokens already exist – ~27 TRX. Or the equivalent if you pay with resources.
## How Does Renting Energy Help Reduce Fees?
The mechanism for renting Energy on a special service is very simple, especially if the service is automated.
When switching to renting Energy to replenish the balance, the user gains several significant advantages.
1. Renting allows obtaining the necessary volume of Energy without needing to stake a large amount of TRX. For business platforms with a large number of transactions, this is particularly advantageous: funds are not withdrawn from circulation, and they won't have to be burned to obtain Energy during a transaction if resources are insufficient.
2. Savings on commissions. Renting Energy can reduce commission costs by up to 75% and even more, as confirmed by practical examples.
Let's look at specialized automated Energy rental services to see that implementing a Telegram bot and API allows not only quickly charging the user's wallet but also ensures a significant reduction in transaction costs. After all, the user only needs to pay a small commission to the service.
Moreover, it provides the opportunity to choose the most suitable resource delivery mode.
### TRON POOL BOT
For example, the TRON POOL BOT service operates via a Telegram bot. Below is a screenshot comparing how much cheaper USDT transfers become with rented Energy.
### NETTS
And here is an example of how, in a short period, the young NETTS service, which allows using both a Telegram bot and the API web interface automation mechanism, has achieved even more significant results.
Below are screenshots of calculations for Energy rental via the NETTS service. Almost 80% and almost 82%! But why such a difference, when the volume of "shipped" Energy is the same – 131K units?
Simply, the second screenshot is the result of charging the client's wallet at night when the blockchain network is less congested. Not every service can set up cyclic Energy charging for you based on network load.
By the way, 131K units of Energy are charged to prevent surprises during the transaction – this volume is enough for any contingencies. But the client will not pay for unused Energy – it will return to the service. And only the payment for the actually used resource volume will be deducted from the deposit (15 TRX – for services via Telegram bot and only 1 TRX for Workspace).
Very beneficial for business platforms that conduct multiple transactions – you can choose the most advantageous time for charging with Energy, as well as a suitable Energy pumping mode:
* **Smart** – replenishment of Energy in the wallet immediately after its volume drops to a set level – the trigger;
* **Host** – choice between two options: cyclic replenishment according to your defined schedule or constant replenishment after each use ("perpetual" Energy).
### FeeSaver
Many services have referral programs that offer earnings for inviting new clients, like FeeSaver, for example. With promised savings on transactions of 60%, FeeSaver offers both auto and manual Energy rental. Connection via API is provided for exchanges, exchangers, processing services, and other cryptocurrency services.
## Practical Steps for Businesses to Rent Energy
To get the maximum possible effect from the rental service, here is a guide on renting Energy to reduce fees.
1. **Service Selection.** Above, we provided examples of several services offering different Energy rental conditions. Choose the platform that best meets your business needs.
2. **Rental Process.** This may include registration and opening a personal account. When paying without registration, an application form is filled out, which includes selecting the required Energy volume, rental time and duration, as well as prepayment for the service in TRX. Renting through a personal account or bot is often preferable to prepayment, as payment is only deducted for the actually used volume.
NETTS clients have access to all 3 options.
3. **Integration with Business Processes.** Businesses can use the rented Energy, received on their balance, for USDT TRC-20 transactions with minimal or zero fees, which is especially relevant for online stores and payment services.
## Conclusion
The ability to use Energy rental is further proof of the Tron network's flexibility. The blockchain allows and even welcomes the "construction" of Energy rental services on its platform. Rented Energy provides businesses with an effective way to reduce commission costs for USDT TRC-20 transfers.
By utilizing the opportunity provided by the blockchain and rental services, business platforms can not only optimize expenses but also increase competitiveness.
Want to save on transactions right now? The NETTS rental service offers a testing opportunity. Just 1 TRX deposit to Workspace – check, be convinced, and from this moment on, keep your 80% TRX!
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-rent-tron-energy-and-make-money-doing-it.md
description: >-
Tron is currently practically the only cryptocurrency blockchain that allows
users to choose a convenient means for paying for transactions. Even for
paying for simple transfers with TRC-10 tokens, a ...
---
# How to Rent Tron Energy and Make Money Doing It?
Tron is currently practically the only cryptocurrency blockchain that allows users to choose a convenient means for paying for transactions. Even for paying for simple transfers with TRC-10 tokens, a special Bandwidth resource has been created, which is updated daily.
Tron credits each user with 600 units of it for free. If a user runs out of this resource, they can pay with TRX – the native crypto of this blockchain. If this happens during a transaction, the system itself will take TRX as payment for the missing resource.
And for those who interact with smart contracts (TRC-20 standard tokens), the choice of means for paying commissions is even wider. By the way, on other cryptocurrency platforms, the gas fee (short name for commissions for transactions with smart contracts) is charged only in the native crypto.
For gas fees in the Tron blockchain, besides Bandwidth, the Energy resource is also used. These resources compensate for the system's costs of attracting additional capacities (energy, computing) to ensure the necessary network throughput for a specific transaction.
The speed of transactions with smart contracts is one of the highest specifically on Tron. Tron users regularly involved in USDT TRC-20 transfers (a stablecoin pegged to the US dollar rate) have secured the platform's lion's share of popularity:
It is precisely for these transactions and due to the increased demand for the service that the blockchain implemented the GasFree function. With it, users indeed do not pay for gas with Tron's special resources – commissions when activating this function are charged in USDT. This costs the user much more than using resources as a payment method. But for lazy users or overly busy holders of large assets who do not want to delve into the intricacies of gas fees, this may be acceptable. As well as for beginners who have not yet grasped the possibilities of Tron resources. This was for reference; we will not discuss this function further here.
Those wishing to save on Tron transactions are still recommended to continue reading. We explain how to use Energy rental on the Tron network to reduce commissions and as a way to generate additional income.
**What is Energy on the Tron Network?**
Let's return to the main fuel for smart contracts in the Tron system – the Energy resource. All TRC-20 standard tokens are smart contracts, including, by the way, the Tron blockchain's stablecoin – USDT. Developers of decentralized applications and those interacting with them also need a sufficient amount of Energy on their balance, since DApps are also smart contracts, and the most complex ones are packages of smart contracts.
A lack of Energy on the balance leads to increased user expenses for transactions because, as with Bandwidth, the system compensates for the missing volume of Energy by taking TRX from the account. Tron simply sells you the missing Energy at the expense of your native crypto.
Of course, a user can fully pay for a transaction involving smart contracts with native crypto, but this is extremely wasteful. After all, TRX can be sent to staking to receive passive income and resources, participate in blockchain governance, pay for necessary content, exchange, sell, etc. In short, it's better to leave crypto tokens for other purposes that are more beneficial for you.
Especially since you can replenish your balance with the Energy resource in such a way that the transaction will cost the user almost nothing. And if they apply some effort and enterprise, they can also earn money. The path to this goal is not difficult – the correct choice of an automated Energy rental service.
## How to Rent Energy on the Tron Network?
Discussing the possibilities of reducing transaction costs when interacting with smart contracts, we rejected GasFree as a narrowly focused function unsuitable for mass use.
Staking requires significant investments that cannot be returned to circulation during the freezing period.
But what if you need it quickly and in large quantities, and at the right time, and when the network is not loaded, and without meticulous calculations, errors in which could lead to burning TRX or transaction freezing, and all this – cheap. Is it really possible? Now – yes.
**Ways to Rent Energy**
You can easily bring all these wishes to life if you choose the right Energy rental service. There are now enough of them built on the Tron blockchain, and some specialized services, such as FeeSaver and TRON POOL BOT, even have a Telegram bot.
But we recommend choosing the most advantageous and fully automated Energy rental service. Many platforms that now rent out Energy simply added this service to those they consider primary – crypto exchange and sale, futures, exchange operations, etc. Of course, they do not study the Energy market as thoroughly, nor are they overly eager to automate the process. Far from all have their own Telegram bot, let alone an API. Therefore, their commissions are higher than, for example, at NETTS – a modern Energy rental service that has already taken leading positions in this market.
As seen below, charging the wallets of NETTS renters is in full swing. Just look at these volumes. And then – at these prices. Just imagine how much you can save on transactions when you become a client of NETTS – an automated Energy rental service.
Moreover, you can rent Energy through the web interface with a personal account in Workspace or through the Telegram bot – you are guaranteed all the advantages of full process automation.
Finally, Tron users are not afraid that their TRX will burn due to lack of Energy! Finally, they have the opportunity to pay only for the actually used Energy. Well, how to pay... It can hardly even be called payment for Energy. With these meager commissions, you pay for your comfort and freedom.
Just order the schedule for charging your balance with Energy and get busy with smart contracts – NETTS will do the rest. But there are other modes: trigger-based charging or constant replenishment of the balance with Energy immediately after each transaction (Smart and Host modes).
Did you notice that with NETTS, transactions are free? What leaves your deposit is payment for comfort, and it's not that high. Ah, you still want to compare? Below are two screenshots demonstrating savings of almost 80% and over 80%. The second was taken during a night transaction when the network was minimally loaded.
Not ready for large volumes yet? Put just 1 TRX on the Workspace deposit (this is the minimum allowed) – and test it. Choose the mode you need, set the rental period for Energy, the time, the amount of replenishment, as well as the minimum threshold for recharging. NETTS – a fully automated Energy rental service – will do the rest for you.
For one-time transactions, you can simply log in via the website form and make a prepayment, after which NETTS will replenish your balance with Energy.
### Rental Process
Usually, automated rental services offer to set up a deposit. If the service is not automated, it may work on a prepayment basis. In this case, funds for rented but unused Energy are not returned, but the unused volume of the resource, of course, does not remain on the balance, meaning you lose funds. A service with an API excludes this.
Your actions may differ slightly depending on the type of service. To place an order, you should:
* access the service via the web interface or Telegram bot;
* fill out an application (form) for the volume of Energy;
* specify the rental period;
* on a service with an API, set the schedule (cycle) for resource replenishment or another supply mode;
* transfer TRX to the deposit or make a prepayment in TRX;
* receive the specified volume of Energy in your wallet (or receive the resource according to the schedule automatically, without any additional actions);
* conduct the transaction (or transactions).
### Advantages of Renting
Regardless of the choice of rental service, you will still benefit, receiving a reduction in commissions by 60–70% when cooperating with ordinary services and by 80–82% – when cooperating with NETTS. Rental services allow the renter greater freedom of choice.
If you deal with NETTS, the following advantages are added:
* instant charging of the balance with Energy without manual intervention;
* maximum flexibility – rent in the required volume and for a specific period;
* possibility to set the resource replenishment cycle;
* possibility to choose the most advantageous time for replenishing the balance with Energy (minimum network load).
## How to Earn Money by Renting Energy?
Of course, by using rented Energy, you can now more effectively manage the Energy you receive through staking. Here are just a few options for how you can profitably use the saved Energy.
### Ways to Generate Income from Renting Energy
1. **Renting out Energy to other users.** Owners of large amounts of TRX can stake them to obtain Energy and rent it out through specialized services and platforms, receiving their share of income from renters.
2. **Creating your own Energy rental service.** With technical capabilities, one can create a platform for renting Energy, earning commissions for providing services.
3. **Partnering with existing services.** Integrating with Energy rental services to receive a share of the profits or commissions.
## Conclusion
Renting Energy on the Tron blockchain allows not only significant savings on transaction fees with TRC-20 tokens but also generating additional income.
For renting Energy, use proven automated services that provide an expanded range of services.
When saving staked Energy, consider the possibilities of earning income by renting it out.
Try the fully automated NETTS service for renting Energy and start saving and earning today.
---
---
url: >-
https://doc.netts.io/blog/articles/gasfree-vs-energy-rental-what-to-choose-in-2025.md
description: >-
The Tron blockchain is a very flexible cryptocurrency eco-platform that
provides users with choices in transaction payment methods. Even when
interacting with simple transfers in TRC-10 tokens, you ca...
---
## GasFree vs Energy Rental: What to Choose in 2025?
The Tron blockchain is a very flexible cryptocurrency eco-platform that provides users with choices in transaction payment methods.\
Even when interacting with simple transfers in TRC-10 tokens, you can choose: use TRX or Bandwidth for fee payment.
But Tron offers even more choice to users who interact with smart contracts.\
For example, to pay fees for transferring USDT TRC-20, you can now choose the following options:
* only native TRX crypto;
* special resources Energy and Bandwidth + TRX (burned if resources are insufficient);
* only Energy and Bandwidth, if sufficient;
* completely gas-free transaction via the **GasFree** function — payment in USDT stablecoins.
Much has already been written about ways to minimize expenses by using special resources instead of native crypto,\
and active users know that using **Energy** to pay for transactions is much more advantageous than burning TRX.\
This is because Energy can be obtained as a reward for staking a substantial volume of TRX\
or, much more conveniently and almost as profitably — renting Energy on special services.
In the latter case, savings in paying for USDT TRC-20 transfers can reach **80%** on a service like **NETTS**.
Recently, another innovation from Tron caused a stir: using the **GasFree** function, a user can forgo using gas (Energy, Bandwidth, and TRX) to pay commissions for USDT TRC-20 transfers.
That is, in 2025, users of the eco-platform involved in USDT stablecoin transfers can choose between **GasFree** and **Energy rental** to pay for these transfer transactions.
Which option is better? Let's delve into the details.
## How Does GasFree Work?
**GasFree** is a mechanism that allows users to send transactions without burning TRX, Energy, and Bandwidth.\
The actual commission costs are passed on to the smart contract sponsor (service provider).\
Essentially, these are meta-transactions in the Tron ecosystem.
1. The user sends a transfer request (in USDT or another TRC-20 token) through a GasFree smart contract.
2. The smart contract (sponsor) pays the system costs (TRX, Energy, Bandwidth).
3. The user compensates the sponsor for the costs — pays the commission in another token (usually USDT).
This approach simplifies work for users who do not want to complicate their wallet balance with different assets and special resources.\
GasFree allows sending USDT TRC-20 **without TRX on the balance**.
However, the price of such "compensation" can differ significantly from Tron network fees in native crypto and resources.\
Because GasFree does not allow transactions with zero commission, but only **shifts the commission from TRX to another token**.
### Advantages of GasFree
Complete absence of the need for TRX, as well as other gas components — special Tron resources Energy and Bandwidth.
Ease of use — sending transactions without complex settings.
### Disadvantages of GasFree
1. GasFree is only available in supported wallets and services.
2. The service provider can disable GasFree support at any moment.
3. Hidden fees or transaction limits may be imposed. By the way, the accompanying documentation includes a disclaimer that the transaction fee may be significantly higher than if the user paid the gas themselves, especially during high network congestion on Tron.
When using GasFree, the commission can be noticeably higher than when using "gas": current tests show amounts of **10–20 USDT per operation**.\
This is without even considering the payment for activating the **GasFree Wallet** (another 10 USDT).
## How Does Energy Rental Work?
**Energy renting** — provision by a special service for a specific period (hour or more) of computing resources to reduce the commission for TRC-20 transactions.
Such rental allows the user to completely exclude TRX from transaction fees when interacting with smart contracts,\
including when transferring USDT TRC-20.
Rented Energy allows for more transactions with minimal costs.
### Advantages of Energy Rental
* Commission reduction by **2–3 times** compared to regular transfers.
* Availability for **any wallets and services**.
* Flexibility — you can rent the required amount of energy for different durations.
* Full automation — when using Telegram bots or web interfaces, such as **NETTS's Workspace**.
### Disadvantages of Energy Renting
The disadvantages of this method could possibly include the need to calculate the required Energy volume in advance and keep some TRX on the balance for rental.
And in the case of automating recharge, initial setup is required.
Some users stock up on "extra" TRX also to prevent transaction freezes in case of network overload.
Although this factor can also be eliminated simply by renting a larger volume of Energy or activating auto-recharge of the wallet, if interaction with smart contracts occurs under system overload conditions.
For example, the NETTS Energy rental service allows its clients, who send USDT TRC-20 to dozens of addresses daily, to choose a suitable mode for charging the balance:
* **Host** – this is "perpetual" Energy or the second option – resource supply according to a schedule approved by the client;
* **Smart** – trigger-based Energy supply: as soon as the resource reserves reach the specified level, the balance is replenished to the initial level.
## GasFree vs. Energy Rental: Which is More Profitable?
Let's compare both methods based on key parameters.
| **Parameter** | **GasFree** | **Energy Rental** |
|--------------|-------------|---------------------|
| Is TRX needed? | No | Yes |
| Fixed commission? | No (may depend on the provider) | Yes |
| Works with any TRC-20 tokens? | No (limited support) | Yes |
| Support in all wallets? | No | Yes |
| Suitable for mass transactions? | No | Yes |
| Transaction cost for transferring USDT TRC-20 to one address | from 10 USDT | ~3-6 TRX (depending on recipient's balance) |
Conclusion:
1. The GasFree function is useful for large players who do not want to hold TRX and special resources to service a large number of addresses. But they must be prepared to pay an increased commission in USDT for convenience.
2. GasFree is not the best choice for the mass audience of Tron users, but for special cases (corporate wallets, exchanges, B2B services) it can be a convenient option.
3. GasFree is also convenient for beginners who find obtaining special resources complicated. But the high transaction fees prevent those who regularly interact with TRC-20 from using this method.
4. Energy rental is suitable for everyone, including holders of significant USDT volumes and those who regularly transfer stablecoins, interact with smart contracts, and avoid inefficient expenses that can be easily eliminated by renting Energy.
From all the above, it follows that in 2025, Energy rental remains the main method for minimizing commissions in Tron. It is more advantageous than staking and much cheaper than GasFree.
The main thing is to carefully choose an Energy rental service. **NETTS** offers ease of use even for Tron beginners. No registration or account creation needed. Just log in via the website form or Telegram bot. Choose the payment method – preliminary one-time payment at a rate of 3–6 TRX per transaction or a deposit of 15 TRX, enough for 2–5 transactions. You can also use the new feature – auto-recharge via the **Workspace** web interface.
Just try how it works and get real **80% savings from the NETTS Energy rental service** – \
**Workspace deposit – only 1 TRX.**
---
---
url: >-
https://doc.netts.io/blog/articles/which-services-save-money-on-transactions-in-tron-top-solutions.md
description: >-
The question posed in the title is often asked by newcomers to the Tron
blockchain. In principle, the term 'money' can refer to all assets and
resources related to this ecosystem. All of them can be c...
---
## Which Services Save Money on Transactions in Tron? Top Solutions
The question posed in the title is often asked by newcomers to the Tron blockchain. In principle, the term "money" can refer to all assets and resources related to this ecosystem. All of them can be converted to the rate of any fiat currency. But let's focus on the main assets that are most often associated with paying for gas during transactions – the native currency of the eco-platform TRX and the stablecoin USDT.
USDT TRС-20 is a version of the Tether (USDT) stablecoin issued specifically for Tron. It is transfers of this token, pegged to the US dollar rate, that account for the lion's share of transactions on the Tron ecosystem network.
So, the question in the title can be refined. We explain how special services can help you save your TRX and USDT and avoid burning them on transaction fees. Specific knowledge about Tron technologies will help here.
## What Can You Pay for Gas with in Tron
During transactions on the blockchain, a different set of assets and resources can be used to pay for gas:
* native TRX crypto tokens;
* special resources Energy and Bandwidth;
* recently – USDT stablecoins.
Active users who frequently transfer Tron stablecoins, developers of smart contracts (various decentralized applications, for example), in short, everyone who interacts with TRC-20 standard tokens, of course, prefer to use the special resources Energy and Bandwidth to pay commissions.
Otherwise, they would have to spend significant amounts in TRX, as is customary on most other cryptocurrency blockchains, where transactions are paid only in the native crypto or their own version of stablecoins.
However, for many blockchain newcomers, it becomes a revelation that it is not necessary to spend hard-earned TRX or USDT on transactions in Tron. Furthermore, many find obtaining the most important resource – Energy – complicated.
Why does Energy specifically cause difficulties? Because every user sees the daily replenishment of Bandwidth in their wallet – Tron distributes 600 units of this resource to everyone, which the participant then uses to pay for the network's expenses on improving throughput specifically for their transaction.
Those interacting with smart contracts should know that each transaction will take a certain amount of Bandwidth from your wallet. For example, one USDT TRC-20 transfer (which is also a smart contract, like all TRC-20 tokens) will require 345 units of Bandwidth. That is, the daily free limit is not enough even for a couple of transfers per day. What happens when the Bandwidth reserve runs out during a transaction? The transaction does not stop if there is TRX in the account – the system will start burning your native crypto tokens without any warning.
The same happens if you don't have enough Energy. Only in this case, the loss of TRX will become more critical and noticeable. It is then that inexperienced users wonder: why did both resources and TRX disappear after the transaction? Simply, the user did not account for the upcoming Energy consumption, or the state of the overheated network, or the conditions of the exchange to which USDT was transferred.
Rest assured, this is not the worst scenario. It is much worse when a transaction hangs due to insufficient funds for the gas fee. Actions in the decentralized blockchain model are irreversible. Once a transaction is added to a block, it can neither be deleted nor changed. That is, the user loses their funds irrevocably.
To prevent this from happening – diligently study the possibilities provided by Tron if you plan to quickly transition from a beginner to an active user and developer of smart contracts.
## Ways to Obtain Energy: Staking or Renting?
This is one of the most important resources on the Tron network for paying gas fees during transactions related to TRC-20 standard tokens. For example, for one USDT TRC-20 transfer, you will need 65,000 or 131,000 units of Energy (corresponding to 13.5 and 27 TRX) to pay the commission.
By the way, you should always check the recipient's balance. If they already have these stablecoins, you will pay the first amount for gas; if not – the second. This is a requirement of Tether (USDT), not the Tron blockchain.
To get enough Energy for even a couple of transfers, you need to stake almost 24,000 TRX. Any online calculator will convert the value of this asset into USD – and you will be surprised by the result.
Yes, you must withdraw these funds from circulation to get Energy for just a couple of USDT TRC-20 transfers. Firstly, you will have to wait half a month for this amount to return to circulation; secondly, not everyone has that much TRX on their balance.
Here, alas, more pain can be added: it's not guaranteed that you will receive the expected volume of Energy. After all, the size of the reward for frozen assets depends on the total volume of TRX being staked across the entire network at that moment. That is, the following scenario is possible: you start staking, having accurately calculated the volume of TRX, yes, you immediately receive Energy, BUT in a smaller volume than you expected. What to do? Add another portion of TRX to staking or simply allow the system to burn them during the transaction after the received Energy is gone from the account?
What remains for those who constantly need Energy for transferring Tron stablecoins or developing decentralized applications, indeed, for any interaction with smart contracts? After all, they are the majority in the Tron system.
Until recently, they had to resort to inconvenient staking, accumulating the necessary volumes of TRX or burning native crypto in transactions. Before the advent of Energy rental services, there were no other options.
## 1. Energy Renting Services
Now it is not necessary to own a large volume of native crypto to obtain practically any required volume of Energy. Here too, several paths can be taken. You can independently search for and rent resources from other users with large staking positions who are willing to provide you with staked Energy for a small fee for a certain period.
But for most users, this is a very difficult path, and practically impossible for beginners, as it requires knowledge of the market for special resources of the Tron ecosystem.
### How Not to Make a Mistake When Choosing an Energy Rental Service
It is much simpler and faster to act through Energy rental services, which have begun to be actively built and developed based on the blockchain. By renting Energy, you can forget about the lack of resources during transactions.
Let's consider important factors when choosing such a service.
**Maximum possible savings on transactions.** Be sure to conduct a test – rent a small amount of Energy first to find out if the service's advertising promises match reality. Quality services usually welcome this approach and offer a "trial" themselves. You should be able to check the real percentage of savings per transaction. It often happens that, while claiming large savings on transaction costs, the service omits some additional commissions or provides a smaller volume of Energy than stated.
**Presence of a Telegram bot or other automation.** Services without proper automation cannot provide the user with a refund for unused but prepaid Energy. The same applies to situations where the transaction was not carried out within a certain period. Of course, the resource will not disappear in this case either, but the fact remains: the presence of a Telegram bot or automation via a web interface with the possibility of opening a deposit provides the user with more opportunities, including in managing Tron resources.
**Flexible structure and user-friendly interface.** If the process of interacting with a service that offers Tron resources for rent is not intuitively clear and simple, it means the service was initially tailored for other tasks. As a rule, Energy rental is of secondary importance for such a platform. This affects the search for pools and the most advantageous resource providers, orientation in the conditions of this particular market. This means the service offers less favorable rental conditions.
We recommend several Energy rental services that offer users the most advantageous conditions.
### Netts.io
Website address: \
Telegram bot address:
This Energy rental service has not only a form on the site through which you can place an order for Energy rental by prepayment. The Telegram bot allows you to open a deposit for 15 TRX. The automation web interface with a minimum deposit of only 1 TRX and a personal client cabinet, Workspace, provides different levels of automation adapted to your regime:
* using a trigger;
* applying a specific balance charging schedule;
* with instant balance replenishment after using the previous volume of Energy, etc.
Testing showed that the cost of obtaining 131K Energy for an hour to transfer USDT TRC-20 to an "empty" wallet costs about 5.7 TRX and even around 5 TRX at night. So the stablecoin transfer transaction itself is free: you pay the gas fee with Energy rented from NETTS. And the service will take the above-mentioned fee from the deposit only for its services and your comfort.
You can see the percentage of savings from the calculation display on the screenshot. Remember that 131K Energy is equivalent to 27 TRX and calculate the savings. About 80%! This is a record in the Energy rental market.
But if during the transaction it turns out that the recipient's wallet has USDT on balance, only half of the TRX indicated in the calculation will be deducted from your deposit. And if for some reason you refuse the transfer within the agreed time (1 hour in our case), nothing will be charged for the volume of Energy you ordered, and the service will simply return the resource from your wallet.
The NETTS service continues to develop, and currently, you can order a service such as automatic balance replenishment when it drops to a certain volume.
For those who regularly and frequently interact with any types of smart contracts, this is a very valuable function that eliminates transaction freezes and irreversible loss of funds.
At the same time, you can also rent Energy through the site, but with prepayment and the impossibility of returning the unused volume.
Very easy to master – the interface is simple, user actions are constantly accompanied by hints.
## Feee.io
The Feee.io platform has its own Telegram bot - @feee\_io\_bot
However, the platform is not fully focused on Energy rental, as it was initially built for exchange trading of resources. Therefore, there is also an exchanger providing the exchange rate upon request, as well as the ability to monitor transactions.
Energy rental offers are calculated more for large Tron traders, who are provided with an additional reduction in service fees.
But the screenshot of renting only 32,000 units of Energy indicates that for "retail" renters, the savings on commissions differ somewhat from those stated.
## Tronify.io
Tronify is a convenient platform for buying, selling, and renting energy, also providing staking services. It has its own API for automation.
Not all Energy rental services have convenient and advantageous automation, thanks to which rental services can be obtained without much hassle and interface разбирательств. The Telegram bot (@tronify\_energy\_bot) of this service provides Energy and virtual currency rental services.
However, there are discrepancies in the stated savings when transacting with Energy rented here. Here is what we see in the screenshot:
And we are slightly perplexed when we recall where the figures of 27 TRX for 64K Energy came from, given the usual commission of 13.65 TRX? And what about the 54 TRX for 131K, from which the alleged 73% savings are calculated? Of course, this will all be cheaper than staking in the end, but be careful with such claims about savings – not all services are equally advantageous.
### Other Energy Rental Services
Of course, the list of platforms based on Tron can be continued – the most advantageous and popular ones were given above as examples.
Among other reliable platforms that also provide Energy rental services:
* TronSave;
* JustLend DAO;
* Tron Energy Market (TEM);
* Tron Pulse;
* Tron Energize.
It is best to check for yourself which service suits you best – visit each site, make test cheap orders, check the functionality of the Telegram bot, automation web interface, etc. Look for the best prices without unnecessary problems and failures: round-the-clock availability of the service is also an important factor.
## 2. Staking Services
Of course, staking is still a better option than burning TRX. And it is not surprising that platforms have appeared that offer TRX holders this function on more favorable terms, according to the services themselves, among which the most famous are:
**TronWallet**. A mobile wallet for the Tron network, with a user-friendly interface that offers various staking options, including voting for super representatives, participating in staking pools through its super representatives, as well as direct staking – for holders of large volumes of TRX (who most often are part of the super representatives).
**Sesameseed**. A decentralized community operating on the same principle but using SEED tokens as rewards. Higher payouts and bonuses are provided for experienced players (read – holders of the largest assets).
**TronTrade**. The principle of distributing rewards for staking on this decentralized exchange is the same. Only users receive rewards in TRXD tokens. There is a minimum limit: the minimum stake amount today is 100 TRX.
**Cryptomus**. This payment platform operates without charging commissions for its staking services, has a conveniently organized interface for tracking rewards, and provides users the ability to manage multiple wallets.
In short, all these services are an additional option for those Tron participants, as well as "external" TRX holders, who are set on receiving passive income without additional costs. But, as can be seen even from the brief descriptions, they are still designed for holders of large volumes of TRX and, moreover, compared to energy rental, the benefit is very small.
## 3. GasFree. Without Gas Fees – Even More Expensive
Since March 2025, another function has been added to the Tron blockchain. GasFree allows excluding both TRX and Tron resources from gas payments. The function is aimed at transferring USDT TRC-20. It is assumed that this will simplify the introduction of beginners to transactions in the Tron system, and relieve other users from staking and other methods of obtaining special Tron resources.
Of course, we are not talking about free transactions, as was enthusiastically perceived initially by everyone involved in USDT TRC-20 transfers. Simply, transactions using this function are also paid in Tron stablecoins. Moreover, initial tests show that this is much more expensive than using resources or TRX.
Here is a rather eloquent screenshot from testing the transfer of 8 USDT TRC-20 via GasFree with payment in the same tokens.
Let's not take into account the payment for activating the GasFree wallet (this is a mandatory condition for using the function), but the size of the transaction fee is also not pleasing.
Even if you pay with native crypto from your balance or with Energy obtained from sending TRX to staking, it will already be much more advantageous. Now compare this with the commission charged by any Energy rental service for a transaction – the difference is huge.
The conclusions from all the above are simple.
1. The most necessary service for those who regularly and frequently interact with TRC-20 standard tokens is an Energy rental service.
2. Energy rental services provide practically free transactions, charging a negligible commission for services.
3. To ensure free transactions for yourself, choose a service through trial testing.
4. The most effective and advantageous Energy rental service is one that allows saving as much money as possible per transaction and allows full automation of the wallet recharging process without extra hassle.
5. GasFree is currently limited only to transferring Tron stablecoins and is designed either for blockchain beginners or holders of large assets who do not want to deal with paying gas fees in Tron resources. This method is not suitable for those who wish to save on transactions.
And one more thing - do not confuse the service's Telegram channel with the presence of a Telegram bot at the service (above). Having an informational channel on Telegram does not provide the user with any preferences regarding Energy rental.
That's all. We hope this information helps you save as much TRX as possible in the future.
---
---
url: >-
https://doc.netts.io/blog/articles/what-to-do-if-you-sent-usdt-to-the-wrong-address.md
description: >-
It's not just Tron blockchain newcomers who make mistakes related to entering
the wrong address when transferring USDT TRC-20. Even experienced and active
users make errors. The result of such mistake...
---
# What to Do If You Sent USDT to the Wrong Address
It's not just Tron blockchain newcomers who make mistakes related to entering the wrong address when transferring USDT TRC-20. Even experienced and active users make errors. The result of such mistakes can be the irreversible loss of funds.
There's no ill will involved – this is how the decentralized blockchain model works. Due to its irreversibility, a successful transaction cannot be canceled or reversed. Sending funds to an incorrectly specified address is not recognized by the system as an erroneous transaction.
Therefore, if the funds have been sent, recovering them is difficult, and sometimes impossible. Let's analyze if there's a chance to recover the funds and provide recommendations on how to prevent such an error.
## Is It Possible to Recover USDT If Sent to the Wrong Address?
The possibility of recovering USDT sent to the wrong address depends on the type of error.
1. If the address exists (e.g., a real person's wallet whose details you entered by mistake) – USDT can only be recovered with the owner's consent.
2. If you made a mistake while manually entering this long string of numbers and letters, and such an address does not exist – the transaction simply won't go through, and the funds will remain with the sender.
3. If, when transferring to an exchange, you entered the address without a MEMO or Tag (identifier for a specific wallet) – the funds will get stuck, but there's a chance to recover them through the exchange's technical support. In this case, the sender will not receive a quick response to the transaction – and this is a reason to start checking.
**Conclusion.** In most cases, when transferring USDT to an incorrectly specified or incomplete address, recovering the funds is very difficult.
## What to Do If You Sent USDT to Someone Else's Wallet?
First of all, register on TronScan if you haven't already. This unique blockchain explorer will be useful to you more than once, and registration will help you better understand the service's features. This is not a mandatory requirement; you can use the service without registration, as all blockchain data is publicly available. It's just more convenient to learn the ecosystem itself through TronScan, as well as quickly find necessary information.
This explorer is intended not only for tracking transactions and checking smart contracts but also for analyzing the operation of the entire eco-platform.
To find out the status of a sent but unanswered transaction, you should check the recipient. To do this:
* go to TronScan;
* find the TxID (transaction identifier) – this is a unique transaction hash generated using a cryptographic algorithm based on the information contained in the transaction;
* enter the transaction hash into the search bar, press Enter;
* after the page with detailed information opens (transfer amount, its status, sender, and recipient), see who owns this address;
* if the address owner is associated with an exchange, contact technical support;
* if it's someone's personal wallet, try contacting the owner, but this rarely helps.
Many unscrupulous blockchain participants take advantage of other users' carelessness by creating exact copies of phishing services. A difference of just one character is enough – for example, instead of `netts.io`, you might accidentally go to, say, `metts.io` (a fake URL) and see a familiar design, form, personal account, etc. The redirection might happen due to a simple typo or through a malicious website. Any transfer made on such a service will be carried out without the knowledge of the original, copied site. Scammers might use fake "verified" accounts on social media to lure you to such a site. Of course, after such a transfer, no one will return your crypto, so be careful.
**Conclusion.** If the recipient of USDT sent to the wrong address is a private individual, the chances of recovering the funds are practically zero.
## What to Do If You Sent USDT to an Exchange Without a MEMO?
Some exchanges require specifying a TAG or MEMO (identifier) for USDT deposits. Cryptocurrency exchanges and other blockchains may use shared addresses for transfers. Special identifiers (Destination Tag or MEMO) in the form of a series of numbers and letters are entered into a separate field to distinguish the addresses of specific users who might "share" one common wallet.
If the USDT sender did not specify a MEMO, the funds will arrive at the exchange's general wallet but will not be credited to the account of the intended recipient.
### How to Recover USDT If You Didn't Specify a MEMO
The starting point is the same as in all cases of specifying the wrong transaction address:
* go to TronScan;
* find the TxID;
* contact the exchange's support and explain the situation.
The exchange may require confirmation of the sender's identity and return the funds. Be prepared that you might have to pay a commission to the exchange for the search and reverse transfer.
**Conclusion.** If the sender of stablecoins to an exchange forgot to specify the Tag or MEMO, there is a chance the exchange will return the USDT, but the process may take time and require additional costs in the form of an exchange commission.
## How to Avoid Such Mistakes?
Even if you are transferring USDT to addresses you frequently send to, and you usually don't make mistakes entering the address line, don't rush the transaction until you have checked all the details.
The following actions, which we recommend performing without fail, will help prevent the irreversible loss of funds:
* triple-check the address before sending if it's entered manually;
* if preparing a transfer to an exchange – carefully review the exchange's policy if you are doing this for the first time;
* ensure the MEMO is specified if required;
* use the saved addresses feature in your wallet to avoid manual entry, where errors are most easily made;
* but regardless of the address entry method, don't limit your check to only the first and last 3-4 characters – scammers are always active;
* check the recipient's network: TRC-20 ≠ ERC-20 ≠ BEP-20; an erroneous transfer between different networks can lead to loss of funds;
* thoroughly check the URLs of the services used and their account names on social media.
So, let's draw conclusions from everything said above:
1. If USDT went to the wrong address – it's almost impossible to get them back.
2. If funds were sent to an exchange without specifying a MEMO – there's a chance to recover them through customer support.
3. The best way not to lose funds – meticulously double-check all addresses and accounts multiple times before sending.
As you can see, the techniques that help prevent losses are not complicated at all. They are based on attentiveness, patience, thoroughness, and control. All these qualities are also required when dealing with fiat currencies, and even more so with cryptocurrency tokens, due to the irreversibility of transfers on the blockchain.
---
---
url: >-
https://doc.netts.io/blog/articles/why-is-energy-rental-a-profitable-solution-for-crypto-wallet-owners.md
description: >-
There are over 63 million holders of the Tron eco-platform's stablecoin – USDT
TRC-20. If interested, the distribution of this token in the cryptocurrency
world can be viewed on the chart in TronScan,...
---
# Why Is Energy Rental a Profitable Solution for Crypto Wallet Owners?
There are over 63 million holders of the Tron eco-platform's stablecoin – USDT TRC-20. If interested, the distribution of this token in the cryptocurrency world can be viewed on the chart in TronScan, but we will limit ourselves to demonstrating how the number of USDT TRC-20 holders in the Tron blockchain is steadily growing.
Stablecoins are popular among those involved in cryptocurrency because they are pegged to the rate of fiat currencies and have less volatility than native crypto.
As for the USDT stablecoin of the TRC-20 standard, it was issued by Tether Limited specifically for use on the Tron blockchain. Recently, by the way, Tether issued an additional 1 billion USDT on the Tron network. And according to the results of the past year, USDT TRC-20 led in the category of transactions made by real people, not bots, with a share above 68%.
Therefore, it is not surprising that daily owners of this stablecoin, whose rate is pegged to the US dollar, perform tens of billions of transactions on the Tron blockchain.
And what attracts the issuing company and users to the Tron ecosystem are almost instantaneous transactions and minimal gas fees.
Why then do many crypto wallet owners face high fees with frequent cryptocurrency transfers, especially USDT on the Tron network? With active use of USDT TRC-20 in business, these fees can significantly increase costs.
**Bad news**: if you are still paying high fees for USDT transfers on the Tron network, it means you don't know that the blockchain actually provides you with the opportunity to minimize gas fees as much as possible.
**Good news**: now we will explain how renting Energy on the Tron network helps users who frequently send cryptocurrency to significantly reduce fees and optimize expenses.
## What is Energy on the Tron Network?
If you complain about high commissions on the Tron network, it means you are paying for gas in the native currency – TRX. Or you are using the GasFree function – meaning you pay 10 USDT for any transaction with this stablecoin.
This means you are not familiar with the concept of special resources on the Tron network, which are designed to significantly reduce commissions when interacting with smart contracts. One of the main resources – Energy – is even called fuel for smart contracts. USDT used on the Tron network is a smart contract based on the TRC-20 standard token.
### Explanation of the Energy Concept in the Tron Blockchain
Energy is a specially created resource in the Tron ecosystem, necessary for executing smart contracts and transactions with TRC-20 tokens, including USDT. By giving this resource as a commission, you compensate the blockchain for the costs of additional energy and computing power attracted specifically for this particular transaction.
This is why the gas fee increases during high network congestion.
If there is insufficient Energy in the user's wallet, the system automatically charges the commission in the native crypto – TRX, without warning, which increases the transaction cost. After all, Energy can be obtained on the balance as a reward for staking TRX or even rented from a special Energy rental service.
In the first case – staking – the received Energy will cost you nothing. But to get resources for a couple of daily transfers, you need to freeze about 24,000 TRX. But it might also happen that the received Energy may not be enough for the planned transactions because you are forced for some reason to transfer USDT during a period of high network congestion.
## How Does Renting Energy Reduce Fees?
All the problems outlined above are completely eliminated if you use rented Energy. It is very important to choose a service that offers the most automated rental process mechanism. A service with a Telegram bot is preferable to a regular platform, and a web interface with API mechanisms is even better for cryptocurrency business platforms.
### Energy Rental Mechanism and its Advantages
1. **Without withdrawing assets from circulation.** Renting Energy allows users to obtain the necessary volume of Energy without needing to freeze a large amount of TRX.
2. **Savings on commissions.** Renting Energy can reduce commission costs by 65% or more, as confirmed by practical examples.
In the screenshot below, you see the bill from the NETTS Energy rental service for 131K units of Energy rented for 1 hour. The first was taken during the day, and the second – at night, during the period of minimal Tron network load. On average – 80%! This is the only such offer on the Energy rental market.
Those who actively transfer USDT should not forget that Tron implemented a dynamic energy supply model long ago.
But for those who rent Energy and send stablecoins to a dozen different addresses at any time – this is not a problem. Especially if you cooperate with a service that actively implements and develops API technologies.
A service like NETTS can provide you with balance charging as soon as the Energy reserve drops to a level you set – this is the trigger-based Smart mode. And if you choose the Host mode in the Workspace personal account, you can select one of the options: constant Energy replenishment as soon as the previous "portion" is spent on a transaction, or balance charging according to your required schedule – cyclical Energy supply.
## Practical Steps for Renting Energy
To ensure the balance always has a sufficient supply of Energy, you won't have to perform any complex actions: staking, buying, exchanging, etc. Of course, this is true if you make the right choice.
Renting Energy is the ideal choice both for those who do not interact with smart contracts often, and for active users, especially for various cryptocurrency business platforms operating on the Tron network daily and sending USDT to dozens of addresses.
### Instructions for Renting Energy to Reduce Fees
1. **Service Selection.** There are various platforms offering Energy rental, such as the already mentioned NETTS with a web interface with API and Netts Energy Charge Bot, TRON POOL BOT – a Telegram bot, FeeSaver with auto and manual Energy rental settings, Tronify, etc.
Carefully study not only the promised percentage of savings but also the capabilities of the technologies used by the services. Not all services can ensure Energy delivery according to a schedule.
With the NETTS service, it's very simple – just set the trigger, as shown in the screenshot below, and when the Energy volume decreases, your balance will be replenished.
2. **Rental Process.** If the user has an insignificant number of transfers, the process usually involves launching the bot in Telegram, setting up wallets for Energy replenishment, and paying for the service in TRX.
For active users and business platforms, a service that allows logging in via a web interface and setting a schedule for Energy delivery to the wallet is preferable.
3. **Use as Intended.** After receiving Energy on the balance, the rental service client can conduct transactions with minimal fees.
### Conclusion
Renting Energy in the Tron ecosystem is an effective way for users to reduce commission costs with frequent cryptocurrency transfers, particularly USDT TRC-20 stablecoins.
It is an opportunity to stop the wasteful burning of TRX by paying for transactions with cheap rented Energy instead of native crypto.
Besides optimizing expenses, renting Energy also ensures transaction efficiency – the risk of freezing due to insufficient resources on the balance is eliminated.
You can have all this right now. Test the NETTS Energy rental service by depositing just 1 TRX into Workspace. From this moment, your 80% for any transaction with TRC-20 will always remain with you!
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-find-out-how-much-energy-is-needed-for-a-transaction.md
description: >-
Each **smart contract** command consumes system resources when interacting
with **TRC-20** tokens in the **Tron** network. This feature of the
eco-platform allows saving the system's native crypto in ...
---
# How to Find Out How Much Energy Is Needed for a Transaction
Each **smart contract** command consumes system resources when interacting with **TRC-20** tokens in the **Tron** network. This feature of the eco-platform allows saving the system's native crypto in **TRX** tokens. Other cryptocurrency blockchains, as a rule, do not provide users with such opportunities, setting a fixed commission in native crypto or other tokens.
**Tron** users who plan to work with **TRC-20** tokens (developing **DApps**, **USDT TRC-20** transfers, etc.) should study the capabilities of the blockchain in order to avoid using **TRX**. Instead of using native crypto to compensate the network for the necessary energy and computing resources, use **Energy** to pay transaction fees.
It is no secret for experienced smart contract developers that if there is not enough **Energy** in the wallet during the transaction, the system will “switch” to burning your **TRX** to pay for the transaction.
Therefore, it is very important to know how much **Energy** is required for planned transactions in order to top up your balance in advance and avoid extra **TRX** expenses.
Here are some examples of calculating the amount of **Energy** needed to transfer **USDT TRC-20** stablecoin, which will help you avoid wasting **TRX**.
## How Is Energy Consumption Calculated?
To transfer **USDT TRC-20**, you interact with the **Tether** smart contract. The cost of executing each smart contract on the **Tron** network is expressed in both **TRX** and **Energy**.
For example:
* To transfer any amount of **USDT TRC-20**, the transaction fee will be **13.4 TRX** or **65,000 Energy** units.
* **However**, if the stablecoins are transferred to a wallet where these tokens are not present, the gas consumption doubles:
* **27 TRX** or **131,000 Energy** units.
**Conclusion**: Using the **Energy** resource, you can pay commissions for operations within the **Tron** blockchain, including the transfer of **USDT TRC-20**.
## Energy Calculation Formula
Active users of the **Tron** blockchain who frequently transfer **USDT TRC-20** know that there are a few more conditions that need to be met to prevent the network from burning **TRX** during the transaction.
Your precisely calculated **Energy** reserve may not be enough if the system is **overloaded**. During high loads, the deployment of a smart contract will require additional computing and energy capacity to avoid failures in transaction processing. It is these network costs that you offset with your transaction using the **Energy** resource.
If it is not possible to postpone the transfer, then the following formula can be used to calculate **Energy**:
*Energy per transaction = Base consumption + Additional network load*
The **additional network load** depends on the number of transactions in a block. This is how the dynamic energy model of the **Tron** blockchain works.
**How to take this additional load into account when calculating the required Energy?**
Each contract has an energy factor field, which indicates the factor by which the smart contract transaction energy consumption is increased relative to the base energy consumption. The initial value is 0. If the smart contract energy factor is greater than 0, which means that the contract is already popular and additional energy will be consumed when it is called.
Therefore, the formula for calculating Energy per transaction will look like this:
*Base consumption + (base consumption x energy factor)*
Experience shows that the more loaded the network is, the higher the Energy consumption for calling and deploying a smart contract.
TRC-20 tokens transferred does not affect the Energy consumption for the transaction fee, but network congestion may increase it.
## How to Check How Much Energy Is Needed
Balance control is an effective method for correctly calculating the required Energy. There are a number of tools available for Tron users that allow this to be done quickly and accurately.
**TronScan** blockchain explorer, you can log into your wallets, check your updated balance, view your energy consumption history, and decide whether to top up your Energy.
The decentralized non-custodial **TronLink** wallet will not only provide quick access to the Tron blockchain and DApps, but will also show you the expected fees.
If for some reason these methods do not suit you, you can make a test transfer of a small amount to get data on the actual costs of the transaction.
## How to Prepare in Advance and not Overpay
TRX on transaction fees in advance before interacting with the smart contract. To do this, you just need to perform a number of simple steps.
1. Check the current Energy balance on the wallet that will be used.
2. Check for Bandwidth resource availability – 345 units of this resource (about 0.345 TRX) are required to transfer USDT TRC-20 tokens in the Tron network.
3. Rent Energy in advance if you don't have enough in your wallet.
4. Send transfers during periods of low network load.
Conclusion: Energy is the main resource that will help you save your TRX when transferring USDT TRC-20. The consumption of this resource per transaction will be 65,000 or 131,000 Energy units, depending on the state of the recipient's wallet.
The best way to avoid burning TRX is to rent the required amount of Energy through a special service **NETTS** before transferring USDT TRC-20. You can even automate the entire process by using **Workspace**. For example, **Host Mode** for just a little extra allows you to completely forget about Energy for 24 hours – no matter how much transactions you want to make in one day!
Don't burn your TRX in the transaction fire! Simply rent as much Energy as you need from **NETTS**, getting a final transaction cost of only 3-6 TRX, and even less when using the Telegram bot, taking into account frequent TRX refunds for unused energy.
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-quickly-check-how-much-energy-you-need-for-transactions.md
description: >-
Transactions when interacting with **TRC-20 tokens** in the **Tron** network
can be fully paid for with the network's native cryptocurrency – **TRX**. But
this is a very inefficient use of such a valu...
---
# How to Quickly Check How Much Energy You Need for Transactions?
Transactions when interacting with **TRC-20 tokens** in the **Tron** network can be fully paid for with the network's native cryptocurrency – **TRX**. But this is a very inefficient use of such a valuable asset. Blockchain offers other options for paying transaction fees – special resources. We talk about how to get them and how to quickly check whether you have enough resources for a smart contract, for example, to transfer **USDT TRC-20**, and for other operations with tokens of this standard.
## What Resources Are Used to Pay Fees in the Tron Network
The **Bandwidth** resource allows the user to compensate for the network's costs to ensure operational network throughput during a transaction, while the **Energy** resource compensates for the platform's costs for using additional computing and energy capacities so that failures do not occur during the transaction process due to additional load.
**With the Bandwidth resource, everything is simple**: the blockchain throws **600 units** into each user's wallet daily. This is enough for two simple transactions of **TRC-10 tokens**. But **DApps** developers or those who regularly and frequently transfer stablecoins should know that in addition to the **Energy** resource for each transaction related to smart contracts (and all **TRC-20 tokens** are smart contracts), you also need to have **345 Bandwidth units** (analogous to **0.345 TRX**).
**It's more complicated with the Energy resource** – it can be obtained in sufficient quantity only by sending a sufficiently large volume of **TRX** for staking or by renting the required volume of resources on a special service.
## Renting or Staking?
The former option is much more profitable for those users who need to get **Energy** quickly, but have neither time for staking, nor the required amount of **TRX** to get enough **Energy** for freezing. For example, the **NETTS** platform with a non-custodial wallet and **Telegram-bot** can rent as much **Energy** as you need at a specified time for a certain period.
The point of renting: the transaction is free, and the service fees are simply minimal. If, for example, we are talking about transferring **USDT TRC-20** – the most frequent transaction in the **Tron** network – then the fee for renting **Energy** using **NETTS** from the website will cost **3-6 TRX**.
Now let's calculate how much you would have to spend on this operation if you were mining **Energy** yourself. Depending on whether the wallet you plan to send to already has **USDT**, you will spend **27 or 13.4 TRX** on the transaction, which corresponds to approximately **131,000 or 65,000 units of Energy**.
The difference (quite sensitive) is easy to calculate. The **NETTS** service did it for you. The result is in the screenshot above: **NETTS saved almost 80% of your TRX!**
To get this amount of resource using the **staking** method, you need to freeze almost **12,000 TRX**, which is equivalent to almost **$3,000**, or half that amount if you transfer stablecoins to a wallet that already has **USDT TRC-20**. But this is also not a small amount, especially considering that you will not be able to release these **TRX** from freezing for a certain period of time – now it is **two weeks**. Keep in mind that all data related to staking is constantly changing, since the dynamic system of the **Tron** blockchain reacts to the replenishment of the total volume of frozen crypto. The dependence of the received **Energy** on the increase in this volume is inversely proportional. So, you may not receive the desired amount of **Energy** and burn **TRX** during the transaction.
And if there is a shortage of **Energy** in the wallet, the system does not interrupt the transaction, but starts to deduct its equivalent in **TRX**.
## How to Quickly Calculate the Required Volume of Energy
To quickly check how much **Energy** is needed for a planned transaction, you don't have to waste a lot of time on calculations if you:
* are familiar with **TronScan**, the official blockchain network explorer in the Tron system;
* use **TronLink** – a decentralized non-custodial wallet with fast access to the Tron blockchain and DApps;
* use **NETTS Wallet** – a decentralized non-custodial crypto wallet in the form of a **Telegram mini-application**.
Before interacting with a smart contract (**USDT** transfer **TRC-20** is a smart contract call) be sure to check the balance of assets on your wallet that will be involved in the transaction. This will help you quickly calculate the missing amount of assets and, if necessary, replenish the balance. You can use our **Workspace API** to automate the entire process and completely forget that **Energy** even exists. For example, with **Host Mode** you pay **6.5 TRX** for each refill without needing to worry about the number of transactions.
**TronScan** browser will tell you about the network load, show transactions carried out by users in real time, through it you can access your wallet and even the wallet where you are going to transfer **USDT**, the level of staking load, etc.
From here you can go to the **TronLink** wallet, if you are registered there, and send the required amount of **TRX** for staking. After selecting the desired resource, the system will calculate and show how many transactions the received amount of **Energy** will be enough for.
But when using the **NETTS** rental service, you don’t even have to worry about the amount of **Energy** in your wallet. If you log in through the website form, you simply fill it out and pay the rental fee – **3-6 TRX**, and if there is no native crypto on the account, you can pay in **USDT**. The transaction itself will cost you… nothing.
It's even easier when you log in via **Telegram bot**: you deposit **15 TRX**, and the service uses it to make payments for the specific **Energy** used. And imagine: it returns the difference in payment to your deposit! For example, you declared **131,000 Energy units**, but used **65,000** for the transaction – the recipient's wallet contained stablecoins. The service will only charge you the cost of the resource actually used, and the difference will remain in your deposit. And if the rented **Energy** was not spent at all during the period you specified, **0 TRX** will be debited from you.
Why should you count **TRX** for staking if to rent **Energy** on the **NETTS** service you only need to have less than **10 TRX** in your account (when renting through website), and transactions will cost you absolutely nothing. Just use the ordered **Energy**, loaded into your wallet at a convenient time and for the period you need.
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-rent-tron-energy-and-reduce-fee-costs.md
description: >-
It is hard to believe that someone still continues to burn **TRX**, paying for
transactions with them, if there is such a convenient service as **Energy
rental**. A special resource **Energy** in the ...
---
# How to Rent Tron Energy and Reduce Fee Costs? Step-by-Step Guide
It is hard to believe that someone still continues to burn **TRX**, paying for transactions with them, if there is such a convenient service as **Energy rental**. A special resource **Energy** in the **Tron** network can be used to pay for transactions using **TRC-20 standard tokens**. As you know, these include all types of smart contracts, including **DApps** and **USDT stablecoins**.
You also know that there is no such thing as too much **TRX** – why throw them into the fire of transactions if you can use your native crypto much more effectively. The **Energy** resource is great at paying the commission for transferring **USDT** or interacting with **DApps**. At the same time, you keep your precious crypto intact, and transactions are practically free. However, for this you need to have a fairly decent supply of this resource. After all, if during the transaction it turns out that there is not enough **Energy**, the system will still start burning **TRX** without warning or stopping. What are the options for getting cheap **Energy**?
## Staking? Renting!
The problem is which method to choose to obtain a sufficient amount of **Energy**. We immediately reject buying it forever, since this requires a significant expenditure of **TRX**. The **staking** path is not suitable for those who do not have time to wait until frozen funds become available for use again. In addition, most users do not have enough **TRX** for staking to satisfy the need for **Energy**. Only for one **TRC-20 USDT** transfer you need **65k or 131k units** of this resource (depending on the state of the recipient's wallet) – this is the equivalent of **13.4 TRX** or **27 TRX**, respectively.
The good news is that you don't even need to resort to **staking** to get the required amount of **Energy**, and all you need is a very small amount of **TRX** on your account, much less than what is required to transfer **USDT**. We'll tell you how to reduce transaction fees to zero in the **Tron** blockchain. The most effective alternative to accumulation and **staking TRX** is **renting Energy** through special services. Let's consider the process using the **NETTS** service as an example. **Energy rental** in **NETTS** is much more profitable than **staking** – you get **three times more transactions** for the same investment.
## Step-By-Step Guide to Renting Energy on NETTS
To see the benefits you get in **NETTS**, you can simply rent the required amount of **Energy** for **1 hour**.
1. When renting **Energy** through the website form, simply fill in all the fields – users of the service claim that the interface is intuitive. You need your **Tron** wallet address, as well as specify the amount of desired **Energy** and the rental period.
2. After clicking the button, you will need to confirm sending **TRX** – payment for the rented **Energy** – after which your wallet will be charged within seconds. It's that simple!
3. If you prefer renting through **NETTS Energy Bot**, then the first thing you need to do is follow the link in **Telegram**, add your wallets to the bot’s interface and make a small deposit of **15 TRX**.
4. Then just go to the **Resource Rental** section and charge any of the wallets with **131k Energy** with one button! The advantage of the bot is that you can attach up to **6 wallets at once**.
## Benefits for NETTS Service Users
As we mentioned, for the same investment in **staking** you get **three times more** with **NETTS**. This is the main advantage: you stopped burning your **TRX** for transactions, giving away rented **Energy** instead. As a result, the transaction itself is absolutely free for you.
### Example
To transfer **USDT TRC-20**, you need to have **13.4 TRX** or **27 TRX** depending on the balance of these stablecoins in the recipient's wallet. Instead of burning these **TRX**, the **NETTS** service pumps your wallet with **Energy**, renting you **65k** or **131k units** of this resource for the period you need. This way, transferring **USDT** will cost you **3 or 6 TRX**, as the payment for the service for rent. That's all the expenses. Now calculate the percentage savings – more than **77%**!
### A Number of Other Important Advantages From NETTS
* If using the **Telegram bot**, you pay only for the **Energy** actually used. The final payment is made only **AFTER** the **Energy** was used in your wallet. This is what makes **NETTS** fundamentally different from services where you have to pre-pay for the **Energy** rental in full.
* The bot will check the presence/absence of **Energy** in your wallet immediately after the "Charge" command and will add the resource volume to **131,000 units**. After you transfer **USDT**, unused **Energy** is returned to the service and payment is made for the resource used.
* In case of lack of such resource as **Bandwidth**, the bot will top up your account by **1 TRX**.
* The prices for renting **Energy** using the **NETTS** service are significantly more favorable compared to competition.
* You can fully automate the entire process through **Workspace** – robust **API toolbox** with anything you need to get all the **Energy** on the fly with minimum deposit of only **1 TRX**.
If the amount of **TRX** you staked was not enough to get the required amount of **Energy**, the bot will compensate for the missing amount at the time of transfer. Moreover, it will calculate the right amount itself as accurately as possible. Just click the magic button **“Charge”**.
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-save-on-tron-fees-2-proven-methods.md
description: >-
An analysis of exchange wallets and exchangers shows that users burn millions
of **TRX** on transactions absolutely pointlessly on a daily basis. This also
applies to users of the **Tron** network, de...
---
# How to Save on Tron Fees? 2 Proven Methods
An analysis of exchange wallets and exchangers shows that users burn millions of **TRX** on transactions absolutely pointlessly on a daily basis. This also applies to users of the **Tron** network, despite the fact that this blockchain provides participants with the opportunity to do without **TRX** when paying transaction fees.
While cryptocurrency blockchains **Bitcoin** and **Ethereum** charge fees directly in the native crypto of their network (**BTC**, **ETH** tokens), the **Tron** eco-platform makes it possible to use special resources instead of its native crypto in **TRX** tokens: **Bandwidth** and **Energy**.
The names of the resources make their purpose clear: the first one compensates the blockchain costs of ensuring network throughput during the transaction, the second one compensates the platform's computational and energy costs when the participant interacts with smart contracts: **USDT** and **USDC** tokens, **DApps** and other **TRC-20 standard tokens**.
It is important to know that **Bandwidth** is used not only when interacting with **TRC-10 tokens** (for example, when transferring **TRX** and other simple transactions). When interacting with **TRC-20 tokens**, it is also necessary to compensate the network for its efforts to ensure high throughput when conducting transactions.
So, **Tron** blockchain users may not spend **TRX** on transactions at all, but only use these resources. The main thing is to ensure that there is a sufficient amount of them in your wallet. If there is not enough resource reserve when conducting a transaction, the system will not even stop the transaction process, but will take **TRX** from your account without warning.
**Conclusion:** To save on fees in the **Tron** network, you should replace the means of payment for transactions – use **Bandwidth** and **Energy** resources instead of **TRX**.
Now we’ll tell you about the most effective ways to significantly reduce transaction costs, their features and advantages.
## Method 1. Renting Energy
The platform provides such a resource as **Bandwidth** for free to each participant – now it is **600 units per day**, which is enough for a couple of simple transactions. Therefore, the main concern of users and developers who interact with **TRC-20 standard tokens** remains a sufficient amount of **Energy**. Remember: if there is not enough **Energy**, the system will start burning **TRX**.
For active users who often transfer **USDT stablecoins** or regularly develop **DApps**, interact with smart contracts in any field, the capabilities of the **Tron** blockchain for obtaining free **Energy** may not be enough. You can get this resource in the **Tron** system for free only through **staking**, which we will discuss below.
An outlet for active users appeared with the emergence of **resource rental markets** in the system. **Energy rental** services are well aware of the blockchain features and the capabilities of its users. It is difficult for an ordinary participant to find users with high rates who can use excess **Energy** for a small fee. And rental services such as **NETTS** are engaged in the search for such opportunities.
For example, **NETTS service**’s team has deep knowledge of the **Tron** resource market, it is an infrastructure platform with its own bot and non-custodial cryptocurrency wallet, fully compatible with the **Tron** network. Includes robust **API** with different modes for user’s specific needs.
**Renting Energy** allows users to use it to reduce fees without having to freeze their own **TRX**. This is important if there are no available funds in the account to freeze, or the time limit does not allow obtaining **Energy** by **staking**.
### Benefits of Using Energy Rental Service
**Energy rental** services allow you to transfer **USDT** and other **TRC-20 tokens** even if you don’t have **TRX** to pay for the transaction. But you probably have **3-6 TRX** to rent **Energy** – it will be much cheaper than the transaction fee. Let’s consider this possibility using the **NETTS** service as an example.
To transfer **USDT** to a wallet that already has such stablecoins, you need to have **65,000 Energy units** or **13.4 TRX**. If the recipient's wallet does not have **USDT**, the transaction fee will require **131,000 Energy units** or **27 TRX**.
Renting **Energy** through **NETTS** will cost you **3-6 TRX** (respectively) instead, and the transaction itself for transferring **USDT** in the **Tron** system is free! That is, you give only **20%** of the amount that you would have to pay for a transaction in **TRX** the usual way.
So, let's highlight the most important advantages of a **Tron** network user when renting **Energy**:
* the ability to completely exclude **TRX** from transaction fees at the expense of rented **Energy**;
* significantly reduce overall costs (up to **80%**) for interaction with **TRC-20 tokens** by paying only a small rental fee in **TRX**;
* flexibility in choosing the volume and term of **Energy** rental – the user himself determines for what period and how much **Energy** they need;
* there is no need to send large amounts of **TRX** for **staking**.
Among the disadvantages, it is possible to note the difficulty for the average user to find a reliable service for renting **Energy**. Well, and in any case, you will have to pay a commission to the service.
## Method 2. TRX Staking
In the **Tron** network, you can use **staking** to reduce fees by using resources instead of the native currency: you essentially rent out your **TRX**, and **Tron** replenishes your wallet with the resource you designate – **Bandwidth** or **Energy** – in exchange for the opportunity to use them for a certain period of time.
This method of replenishing your wallet with the necessary resources has both undeniable advantages and annoying disadvantages.
### Benefits of Staking to Earn Energy
The number of resources received in **staking** depends on the amount and duration of **TRX** freezing. When a sufficient amount of **TRX** is frozen, the user can:
* get **Bandwidth** and **Energy** at no extra cost;
* use **Energy** earned from **staking** to pay fees instead of **TRX**, which significantly reduces the cost of transactions or makes them free;
* participate in the governance of the **Tron** network and receive rewards in the form of **TRX**, **Bandwidth**, and **Energy** for frozen **TRX** delegated to super representatives.
### Disadvantages of Staking to Earn Energy
To understand that the **staking** method will not provide its undeniable advantages to everyone, one fact is enough. In order to have enough **Energy** for two **USDT** transfers per day, you need to stake more than **20,000 TRX**. Keep in mind that this value fluctuates, and most often – upwards. This is explained by many factors, including the total volume of native crypto in **Tron staking**.
It is clear that not every user can afford to keep such a volume of **TRX** frozen permanently. After all, **staking** does not allow you to withdraw even part of the **TRX** before the end of the freezing period.
So, both the advantages and disadvantages of **staking** to obtain **Energy** are obvious, including:
* the need to freeze significant amounts of **TRX** for active users and developers;
* risk associated with **TRX** exchange rate volatility;
* limited liquidity of frozen native crypto.
## Comparison of Both Methods
**Tron** users who interact with **TRC-20 tokens** must check the remaining amount of **Energy** before each transaction and check the balance of resources after the transaction to prevent **TRX** from being burned during the transaction.
It is also very important to choose the method of replenishing resources. If you are using simple **TRX** transfers, you only need to have a **Bandwidth** resource on your account, which the network will replenish for you for free, or which you can additionally receive for short-term **staking**.
With the **Energy** resource, everything is more complicated – the system will not replenish it for you, you have to "mine" it yourself. And here you should realistically assess your capabilities and determine the methods that are most beneficial for you. It is quite possible that you are a holder of large volumes of **TRX**, and then you can choose **staking**, which in addition to additional **Energy** will also give you annual accruals in **TRX**.
But large holders are usually not **DApps** developers, for example, although they interact with smart contracts when transferring **USDT**. Therefore, active users and smart contract developers have to constantly choose: **staking** or **renting**.
The table below will help you make the right choice.
| **Indicator** | **Energy Rental** | **TRX Staking** |
|----------------------------|-----------------------------------------------------------------------------------------------------------|--------------------------------------------------------------|
| **The need for TRX** | Minor volume – only for payments of renting services | Significant volume |
| **Transaction fee reduction** | If the required volume of rented Energy is correctly determined – up to 80%, since only the rental service commission is paid, which is 20% of the transaction cost when renting for 1 hour | Up to 80% depending on the type of transaction |
| **Flexibility** | High – the user determines the volume of rented Energy, the time of receipt of Energy to the wallet and the rental period | Low – the user cannot change the staking conditions at his own discretion |
| **Risks** | Prices depend on the service | **TRX** price volatility |
To sum it up, we can conclude that the **Tron** network has opportunities for effective savings on transaction fees. The choice of these opportunities depends on the individual needs and capabilities of the user.
The most balanced and optimal option for active users who interact with smart contracts in the form of **USDT**, **USDC**, **DApps**, and other **TRC-20 standard tokens** is **renting Energy**. To do this, you do not need to have a large amount of **TRX** on your wallet to freeze. You also fully control the rental process, since you determine all the parameters yourself – and **NETTS** is one of the most transparent rental services out there.
To check for yourself, use the **NETTS energy rental** service right now and save on fees from now on.
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-understand-why-a-transaction-does-not-go-through-analyzing-the-main-reasons.md
description: >-
Not only newcomers to the **Tron** blockchain, but also experienced users of
the network may encounter a situation where a transaction gets stuck. For
users who have been working with smart contracts ...
---
# How to Understand Why a Transaction Does Not Go Through. Analyzing the Main Reasons
Not only newcomers to the **Tron** blockchain, but also experienced users of the network may encounter a situation where a transaction gets stuck. For users who have been working with smart contracts for a long time, this is usually the result of inattention. They quickly find the cause and know what measures to take to get out of this situation with fewer losses. We warn you right away that this is not always possible.
But for newcomers to the system, the reason for the transaction hanging is a lack of knowledge of how everything works in the **Tron** blockchain. Even if you have successfully transferred cryptocurrencies on another platform, you may encounter unfamiliar principles of paying transaction fees in the **Tron** ecosystem.
One of **Tron**’s features that attracts users is the fastest transaction speed among all known similar systems. Usually, the wait for a full transaction confirmation lasts from **3 seconds to a minute**.
Why then do users sometimes wait for a long time for a response after a transaction, especially related to interaction with smart contracts? That is, tokens of the **TRC-20 standard** – **USDT stablecoin** and various types of **DApps**.
The transaction can sometimes get stuck, be rejected, or not appear in the blockchain at all: let’s figure out how to find out the status of a transaction in **TronScan**, identify errors, and how to check and fix them.
## Where Can I Check the Status of a Transaction?
If you are new to the **Tron** ecosystem and are interacting with smart contracts or making simple transactions with **TRC-10 tokens**, we recommend registering with **TronScan** right away. This will allow you to make the most of the capabilities of this unique blockchain explorer.
**TronScan** provides detailed information about individual transactions, helping users verify and understand transactions on the **Tron** network.
To find out the status of a transaction that is not going through, you need to enter the **TxID** (transaction identifier) or the sender's address in the appropriate window.
If the transaction is not found, it means it was not sent to the network.
**TronScan** is the main tool for monitoring the status of transactions in the **Tron** system.
## Main Reasons Why a Transaction Fails
Once you have found out that the transaction is not displayed in **TronScan**, proceed to find out the reasons for the "crash." There may be several: as a rule, it is a user error, network problems, or lack of resources to pay for the transaction.
### Reason 1: Not Enough Energy to Complete the Transaction
**Tron** blockchain allows users to use not only native cryptocurrency to pay fees, as is common on other cryptocurrency platforms. This ecosystem has developed special resources, which you can read about in more detail in other articles on our blog. In short, instead of burning **TRX**, network users can pay fees with two types of resources: **Energy** – to replenish the computing and energy capacity spent by the system and **Bandwidth** – compensates for the blockchain's costs of providing system bandwidth for your transaction.
**Tron** itself partially takes care of restoring the **Bandwidth** reserve on the user's wallet. Each user has this resource renewed daily. The volume depends on the decision of the blockchain super representatives, now it is **600 units**. They are enough for several regular transactions, and a transaction with **TRC-20** requires **345 Bandwidth**. That is, the daily limit is only enough for one **USDT TRC-20** transfer. This should be remembered because some, knowing that the resource is being updated, may miss the moment when it is not enough for a transaction when interacting with a smart contract.
But of course, the main problem for many newbies is the **Energy** resource. For simple transfers of **TRC-10 tokens** it is not required. But for the transfer of **USDT TRC-20**, for example, supply of **65K or 131K Energy** is required.
If there is no or insufficient **Energy** on the wallet, the system automatically starts burning **TRX** during the transaction. If there is enough native crypto, the transaction will successfully go to the network, and if there is not enough **TRX** to complete the transaction, it will hang.
#### How to Check
To find out if the state is the reason for the transaction to be stuck, go to the **TronScan** blockchain explorer and see if **Energy** or **TRX** has been written off.
#### How to Solve
Quickly replenish your **Energy** reserves. It is clear that **staking** is not the most convenient option in this case. The best way to replenish your wallet with this resource is to **rent Energy** through a special service.
**Energy rental service NETTS** is a matter of seconds, especially if you already have an open deposit. The contribution is small – only **15 TRX**. This is if you enter the service through **NETTS Energy Charge Bot**. In this case, you can even download excess **Energy** – only the amount actually used will be debited from the deposit, and the rest will simply be returned to the service if the system is not overloaded.
Of course, if you pre-pay for one session of **Energy** upload to your wallet, you will have to calculate the volume exactly before you go through the website form and fill out the application. Or just rent **65K or 131K Energy units** for an hour – it will cost you only ~**3-6 TRX**. You pay for your comfort, and the **NETTS** service pays for your transaction in full. The result is in your favor: about **80% savings**! To make sure, just convert these thousands of **Energy** units into **TRX**. In the screenshot below, we have already done this, you can check.
You can also use the **web-interface** to set up a cycle of constant **Energy autorecharge** for your wallet.
Of course, you can also simply top up your **TRX** balance to pay extra for the pending transaction. But we personally are strongly against such ineffective burning of native crypto.
### Reason 2: Not Enough TRX in the Wallet
This situation was described above: even if you have **Energy**, the system may require a small part of the commission in **TRX**. This may be caused by various reasons, for example, the decision of super representatives or "overheating" of the network with a significant influx of users.
If there are no **TRX** to fully settle, the transaction is stuck.
#### How to Check
Before sending a transaction, check your **TRX** balance. Also check the availability of resources – both **Energy** and **Bandwidth**.
#### How to Solve
Keep **10-20 TRX** in reserve for possible unforeseen expenses.
### Reason 3: TRON Network is Overloaded
If the network is heavily loaded, the **Energy** and **Bandwidth** fees increase. This is because the system must use more computing and energy power to successfully process each transaction.
If you have just enough funds to pay for gas, then you may not have enough to cover the increased commission.
Another option: low priority transactions in such a situation may simply get stuck waiting for confirmation.
#### How to Check
1. First, go to **TronScan → Network Status** and check the network load.
2. If you have already made a transaction and it is stuck, check its status in the blockchain explorer.
##### How to Solve
1. Log in to the system when it has cooled down and make a transaction.
2. If time is of the essence, increase the amount of funds on your balance to pay for gas.
3. If the transaction does not respond, check the status: if the transaction is reflected, just wait for the process to complete and the system to respond.
### Reason 4: Error in Recipient Address
If the address is entered incorrectly, the transaction will not be sent. This is unless the user mistakenly used a fraudulent address. In the latter case, the transaction is irretrievable.
Exchanges require that you monitor the **Tab** or **MEMO** (identifier) for correct crediting of transferred funds. The address of the cryptocurrency exchange is usually the general deposit address, and identifiers help to send funds to the balance of a specific recipient. Therefore, if the **Tab** or **MEMO** is not specified, the funds may be lost irretrievably.
#### How to Check
* Very carefully, check the address several times before sending.
* Eliminate the possibility of using fraudulent addresses.
#### How to Solve
* If the transfer is made to the exchange address, be sure to read its policy – in particular, check whether it is required to indicate a **MEMO** when sending the transfer.
## How to Fix a Stuck Transaction?
Let's collect in one section all user actions that can save an unresponsive frozen transaction.
1. Check the presence and status of a transaction in **TronScan**.
2. Top up your **TRX** balance or rent more **Energy**.
3. If the network is overloaded, wait for a while, check in the **TronScan** browser that the influx has subsided, and try again.
4. If the transaction has been sent to the exchange but has not been credited to the recipient's balance, contact technical support.
Let's draw conclusions from all of the above.
If the transaction fails, your first step is to first check the status in **TronScan**.
The main problems that can cause a transaction to hang are:
1. Lack of **Energy**.
2. **TRX** shortage.
3. Network congestion.
4. Error in address.
The best way to avoid problems is to rent **Energy** through the **NETTS** service before sending **USDT** to get the best conditions on the market.
---
---
url: >-
https://doc.netts.io/blog/articles/is-it-worth-staking-trx-or-is-it-more-profitable-to-rent-energy.md
description: >-
How to reduce transaction fees? As the **Tron** blockchain continues to gain
momentum, this question is becoming relevant not only for individual users,
but also for organizations. Especially if stabl...
---
# Is It Worth Staking TRX or Is It More Profitable to Rent Energy? Comparison of Two Methods: Staking vs Renting Energy
How to reduce transaction fees? As the **Tron** blockchain continues to gain momentum, this question is becoming relevant not only for individual users, but also for organizations. Especially if stablecoins that support the US dollar exchange rate, **USDT TRC-20**, are used to transfer funds – these are smart contracts, like all Tron tokens of the **TRC-20** standard.
The two main methods of securing the necessary resources to process transactions on the **TRON** network are **Energy leasing** and **staking TRX**, the native cryptocurrency of the Tron blockchain. Let's look at a set of advantages and disadvantages of each method, which will help you make a choice depending on your specific needs, capabilities, and the volume of planned transactions.
Before we dive into the comparison, it is important to understand what the **Energy** resource is in the Tron network, and why it is important to have enough of it if a blockchain user is interacting with smart contracts.
**Energy** is a resource in the Tron system used to execute smart contracts, in particular for transactions of **TRC-20 tokens**, such as **USDT TRC-20** stablecoins – one of the most popular variants of the Tether token, which is pegged to the US dollar exchange rate.
Without enough **Energy**, users must burn **TRX** to process transactions – a very inefficient way to spend native crypto. Earning **Energy** through **staking** or **renting** is an opportunity to significantly reduce these costs. Which of these methods is more profitable for you?
## What is TRX Staking?
**Staking TRX** involves locking a certain amount of the native cryptocurrency of the Tron blockchain to generate **Energy**. The amount of the resource you receive is directly proportional to the amount of **TRX** you put into “freezing.” **Energy** received as a reward for transferring **TRX** for temporary use to the Tron network can then be used as fuel for smart contracts, as this resource is often called. There is no need to burn **TRX** to pay transaction fees if there is enough **Energy** in the wallet.
### Benefits of TRX Staking
Any amount of **TRX** can be staked, and if it is large enough, the user receives the following benefits:
* passive income in the form of interest from staked **TRX** if freezing for at least 1 year;
* accrual of **Energy**, necessary for conducting transactions without commissions.
### Disadvantages of TRX Staking
But not all **Tron** users can receive the required amount of **Energy** as a result of freezing – and this is the disadvantage of this method.
1. A significant amount of **TRX** must be frozen to obtain enough **Energy** to fully pay for transactions. For example, to have enough **Energy** for a single transfer of the **USDT TRC-20** stablecoin, about **12,000 TRX** must be frozen at the time of writing.
2. Limited liquidity of funds during the staking period. You cannot interrupt the process and release your assets if you suddenly need them urgently. Although you will receive **Energy** immediately, you will not be able to release **TRX** from staking until **14 days** have passed (the term is valid at the time of writing).
The **Tron** ecosystem platform is a dynamic model and responds to changes in the network in real time. For example, the amount of **TRX** to freeze can fluctuate depending on the overall distribution of staking in the network.
If the system is overloaded, it will increase the commission fee on the fly, and the available **Energy** volume (as well as the **Bandwidth** resource, by the way) may not be enough for the transaction that has already been launched. As a result, **Tron** will either make up for the missing resource volume at the expense of **TRX**, or the transaction will hang altogether if there are no native crypto reserves in the wallet.
In this case, it is impossible to top up your wallet balance using staking. Unless, of course, you know about such an effective and profitable method as **renting Energy**.
## What is Energy Renting?
This is an alternative to staking – you can rent **Energy** from other users or **Energy** rental services in the **TRON** system.
Such method has more advantages than disadvantages.
### Benefits of Renting Energy
The most important advantage of renting **Energy** is that you do not need to have a large volume of **TRX**, and there is no need to resort to staking, making your native crypto tokens unavailable to you for half a month. In addition, renting **Energy** provides the user with:
1. **Flexibility** in choosing the volume and duration of **Energy** rental. This is especially attractive to users who deal with smart contracts with fluctuating transaction volumes. You can rent as much resource as you need without committing to long-term staking.
2. **The ability to reduce commission costs to zero**, you only pay the service for rent. This is several times less than the cost of the staked **Energy** that you typically spend per transaction.
3. **Eliminate the risk of Energy shortage** when changing the size of the commission. **Energy** rental is immediate access to the resource.
4. **No long-term commitments** between the user and the rental service.
5. **There is no asset lock-up**: your funds remain liquid and available for other investments or use.
Among the disadvantages one can name only the absence of additional rewards that are possible with staking, such as participation in blockchain management.
## Comparison of Staking and Energy Rental
For clarity, let's look at individual aspects of **Energy** staking vs renting and evaluate the leader in each of these methods.
### Financial Costs
* **Staking** – the requirement for a significant initial investment to freeze **TRX**.
* **Energy renting** – Get **three times more transactions** for the same investment.
### Flexibility
* **Staking** – restriction for a certain period of user access to **TRX** sent to staking.
* **Energy renting** – you are given maximum flexibility in managing not only resources: the user sets the rental time and term, as well as the amount of **Energy** that the service must provide.
### Efficiency
* **Staking** – it is impossible to get **Energy** instantly, for example, if there are not enough funds during the transaction and it freezes.
* **Energy renting** – instant access to the resource, charging the user’s wallet with the required amount of **Energy** within a couple of seconds.
If you use our **Workspace API** you can specify the cycles of automatic refilling, trigger amount for refills, and many other parameters to come up with perfect individual settings for any **USDT** transfers you might need. Only **1 TRX** minimum deposit!
### Profitability
* **Staking** provides passive income from network rewards.
* **Renting energy** does not generate additional income, but it does reduce commissions.
For example, the **Energy** service **NETTS** provides its clients with up to **80% cost savings** compared to staking. Here's a look at how much it would cost you to rent **131,000 Energy units** on this service. Let us remind you that this is the equivalent of **27 TRX** – this is how much you would have to spend when transferring **USDT TRC-20** to a wallet that does not have these tokens or for a couple of transfers of this stablecoin if the recipient already has the same on their balance.
In conclusion, we note that the choice of method for obtaining the required **Energy** depends on the financial capabilities and activity of the user when interacting with smart contracts, that is, on the frequency of transactions.
The choice is simple: if you are not ready to send large volumes of **TRX** for staking, you need a reliable and profitable rental service **Energy**.
With **Energy NETTS** rental service, you don't even need a large stock of **TRX**. Experience the benefits of **NETTS** yourself with a test rental.
---
---
url: >-
https://doc.netts.io/blog/articles/top-5-mistakes-users-make-when-sending-usdt-trc-20.md
description: >-
The popularity of stablecoins in the cryptocurrency world is due to the fact
that these tokens are tied to the exchange rate of fiat currencies. **USDT
TRC-20** is one of the variants of the **Tether*...
---
# Top 5 Mistakes Users Make When Sending USDT TRC-20
The popularity of stablecoins in the cryptocurrency world is due to the fact that these tokens are tied to the exchange rate of fiat currencies. **USDT TRC-20** is one of the variants of the **Tether** token, which is tied to the **US dollar** exchange rate. The **USDT TRC-20** stablecoin operates on top of the **TRON** blockchain and is a smart contract based on **TRC-20** standard tokens. Along with the **USDT ERC-20** stablecoins of the **Ethereum** blockchain, this is the most popular version of the Tether token in the world. The main advantage of **USDT TRC-20** over the **ERC-20** version is the highest transaction speed combined with low fees.
The terms of interaction with **USDT TRC-20** are especially attractive for those who make frequent transfers of relatively small amounts expressed in **USD**. Unfortunately, the popularity of this stablecoin is often the cause of errors when transferring **USDT TRC-20** by insufficiently prepared users of decentralized platforms. In addition, this popularity can cause network overloads, which also leads to transaction freezing if the user does not take this factor into account.
We analyze the most common user errors when transferring **USDT TRC-20**, their consequences, and recommend ways to prevent such errors. Let's consider the 5 most common errors, the prevention of which will help you save your assets and minimize fees.
## Mistake №1: Not Enough Energy for Transaction
Incorrect calculation of the required volume of assets for a transaction is one of the most common mistakes that can lead to a transaction being stuck or **TRX** not being spent efficiently.
A novice user often knows that to pay for **USDT TRC-20** transactions in the **Tron** network, in addition to the native **TRX** cryptocurrency, a special resource **Energy** can also be used. This reimburses the network for additional capacities (computing and energy) used for the transaction.
However:
* **65,000 Energy units** are required if the recipient’s wallet already holds **USDT**.
* **131,000 Energy units** are required if the recipient’s wallet does not hold **USDT**.
* **345 Bandwidth units** are also required per transaction.
If there is not enough **Energy**, **TRX** will be used to cover the deficit. If there is no **TRX**, the transaction hangs.
### How to Avoid Mistake №1
To prevent a transaction from hanging:
* Check the recipient's wallet status via **TronScan**.
* Check your **Energy**, **Bandwidth**, and **TRX** balances using **TronScan**, **TronLink**, or other methods (TronLink has a resource calculation function).
* **Rent Energy** in advance.
We recommend **NETTS Service** and its **Telegram Energy Bot**. A **15 TRX deposit** enables **3-4 USDT TRC-20** transfers with no extra costs:
* **131,000 Energy** costs **5.7 TRX** (saving around 80% compared to 27 TRX).
* Use **Host Mode** in **Workspace** for unlimited **Energy** over **24 hours** (6.5 TRX per refill).
Renting allows for instant replenishment of **Energy**, so transactions can continue without delay.
## Mistake №2: Insufficient TRX Balance on Wallet
Even with **Energy** and **Bandwidth**, **TRX** may still be charged if:
* **Energy** is insufficient.
* **Bandwidth** is insufficient.
* The **Tron** network is overloaded and requires additional resources.
If there is no **TRX** to cover these extra charges, the transaction will hang.
### How to Avoid Mistake №2
* Keep a reserve of **100 TRX** in your wallet for unexpected fee changes.
* Before calling a smart contract, confirm there is **TRX** available.
* Check the **Tron network status** via **TronScan**. If overloaded, postpone or top up **Energy/TRX**.
## Mistake №3: Sending USDT to the Wrong Address
Transactions on the **TRON** blockchain are **irreversible**. If:
* The **wrong address** is entered, **funds are permanently lost**.
* Exchanges may require a **MEMO** or **Tag** for proper fund allocation.
No support team can recover such transactions.
If you are acting through exchanges, keep in mind that some of them require you to specify a **MEMO** or **Tag** (an identification code made up of numbers and letters) to correctly credit funds to a specific wallet, which may be used by several people. If you forget to specify this identifier, the transferred funds will not be reflected in the balance.
### How to Avoid Mistake №3
In order to keep your funds and avoid contacting support services of cryptocurrency blockchains and exchanges, especially since with an incorrect address this will not give results in most cases, before calling the smart contract try to:
* Carefully check the address several times, especially if it is entered manually.
* Check the address through **TronScan** – it shows the addresses used by scammers.
* When transferring to an exchange, make sure to specify a **MEMO** or **Tag** if required.
## Mistake №4: Selecting the Wrong Network for Transaction
**Tron** users who frequently send Tether-based stablecoins may make the mistake of sending **USDT TRC-20** to **ERC-20** (Ethereum) or **BEP-20** (Binance Smart Chain) addresses. For example, sending **USDT TRC-20** to an address that only accepts **USDT ERC-20** will result in a loss of funds.
In most cases, if such an error occurs, the funds will be lost permanently or will require complex recovery.
### How to Avoid Mistake №4
* Make sure that the recipient's wallet supports **TRC-20** (the recipient's exchange or wallet will indicate not only the address, but also the supported network).
* When transferring to the exchange, select the correct network and the corresponding wallet.
* Carefully read the exchange policy if you are operating through it – additional fees may be specified there, and the transaction will hang if you do not have enough assets for the additional exchange fee.
* For correct transfers between blockchains, use **cross-chain bridges**, choosing proven services.
## Mistake №5: Sending USDT when the Network is Overloaded
It was mentioned above that the congestion of the **Tron** network can cause the transaction to hang when transferring **USDT TRC-20**. When the network is heavily loaded, the blockchain is forced to use additional capacities (energy and computing) to prevent platform failures. This leads to increased fees, requiring more **Energy** and **Bandwidth**, or their equivalent in **TRX**, for the same transaction.
**NETTS** has convenient statistics to estimate the best time for renting **Energy**:
Due to overflowing blocks, a transaction may get stuck in the **Pending** status for a long time if your wallet does not have enough resources and **TRX** to cover the additional network costs.
### How to Avoid Mistake №5
After checking the network status in **TronScan** before transferring **USDT TRC-20**, and making sure that it is overloaded, you can:
1. If time allows, reschedule the transfer to another time when the network has “cooled down”.
2. If the transfer needs to be done urgently, the most convenient solution is to rent additional **Energy** through the **NETTS** service on the most favorable terms.
***
So, what should be taken away from all of the above in order not to lose funds, spend extra resources and crypto when transferring **USDT TRC-20**?
* **Firstly**, before sending **USDT TRC-20**, check your **Energy** balance, **Bandwidth**, and **TRX** reserve.
* **Secondly**, use the correct addresses and networks, especially when transferring to exchanges.
* **Thirdly**, use reliable services for renting **Energy**.
Before sending a large amount of **USDT TRC-20**, you can conduct a **test transaction**. However, this will lead to additional costs – after all, the volume of the transfer will not affect the size of the fee. In this and other cases (for example, urgent replenishment of **Energy**), the **Energy renting service** will help you.
Renting **Energy** through the **NETTS** service not only eliminates the burning of **TRX** during the transaction but reduces the cost of transferring **USDT TRC-20** by **80%** – like no other service! And when renting through a bot, you can also return **TRX** for unused **Energy**.
The conditions for renting **Energy** allow you to conduct a **test transaction** if you have doubts about the recipient's address, exchange, etc.
If you plan to transfer a significant amount of stablecoins, then **3 TRX** for rental services on **NETTS** is a minimal expense that will allow you to avoid major losses.
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-avoid-mistakes-when-renting-energy-what-s-important-to-consider.md
description: >-
Almost all users of the **Tron** blockchain who deal with smart contracts know
that before interacting with **TRC-20 standard tokens**, you should have a
solid reserve of assets on your wallet. This c...
---
## How to Avoid Mistakes When Renting Energy. What’s Important to Consider
Almost all users of the **Tron** blockchain who deal with smart contracts know that before interacting with **TRC-20 standard tokens**, you should have a solid reserve of assets on your wallet. This can be either native crypto (**TRX**) or **USDT** stablecoins.
It’s much more optimal to pay with special resources – **Energy** and **Bandwidth**, which compensate for the network's expenses for attracting additional capacities to ensure the error-free execution of each specific transaction.
The blockchain replenishes each user's wallet with **600 Bandwidth units** daily and free of charge. Users replenish the **Energy** balance themselves, using two methods for this – **staking** and **renting** this resource using special services.
**Staking** is an investment of a significant amount of **TRX** and a half-month waiting period before these funds are released from freezing. Due to such inconveniences, users are increasingly switching to using rented **Energy**.
But since this method of replenishing a cryptowallet with resources is relatively new, many beginners make both technological and organizational mistakes.
To prevent **TRX** losses and delays in **Energy** accrual, we analyze the main mistakes when renting **Energy** and tell you how to avoid them.
## Mistake №1: Renting Too Little Energy
For various reasons, the user may rent an insufficient amount of **Energy**. Or start working with the next smart contract, forgetting that there is no longer enough resource on the balance. In this case, the lack of **Bandwidth** may also have an effect. Such an error leads to the fact that after the **Energy** and **Bandwidth** reserves are exhausted, the blockchain continues to withdraw fees in **TRX** from the balance. And that's not even the worst of it. If there are not enough **TRX** to continue the transaction, the transaction hangs.
### How to Avoid Mistake №1
Before using a rental service, you should decide on the number of possible transactions and calculate the required amount of **Energy** in advance, not approximately. For example, you should know that for one **USDT TRC-20** transfer, you will need **65K** or **131K Energy units** to pay the commission, depending on the state of the recipient's wallet. Do not forget to check the **Bandwidth** balance – for such a transaction, you must give **345 units** of this resource.
If you plan to make many transactions with the transfer of **USDT TRC-20** to different addresses, you can set up automatic wallet recharge or rent a large amount of **Energy** at once, which is necessary to pay the commission for all transactions. It is better to do this with a small reserve, because the state of the network may change during operation, and the commission for the same transaction will increase.
It is better to rent **Energy** with a reserve, and then return the surplus to the rental service or set up automatic wallet charging. Yes, not every service offers such services. But if you are dealing with the **NETTS** rental service, you can top up your wallet with **Energy** in any amount you need, and return the excess without paying. This is the case if you log in to the service via the **NETTS Energy Charge Bot** and have a deposit of **15 TRX**. **NETTS** will only charge you for the rent of the **Energy** you actually used, unless the system is overloaded.
And if you log in via the website form, you will simply make an advance payment, based on the fact that you will pay less than **3 TRX** for renting **65K Energy units**, and about **6 TRX** for renting **131K**. The transaction will be free of charge. And **NETTS** will receive a commission for the comfort it provides you, freeing you from having to stake **TRX**.
Well, if you take into account all your expenses for one transaction, for example, for transferring **USDT TRC-20** to a wallet whose balance does not contain these stablecoins, and you also need **131K Energy**, then look at the screenshot below:
Almost **80% savings** compared to paying with **Energy** earned through **staking**! You would need to stake almost **12,000 TRX** to get just one free transaction per day.
**NETTS** eliminates **staking** and saves **80%** of your funds – you won't find better **Energy** rental terms anywhere.
## Error №2: Specifying the Wrong Wallet when Renting
If, when cooperating with the **Energy rental** service, the user enters someone else's or an inactive address, or simply makes a mistake when entering the address manually, then the **Energy** does not go to their wallet, but goes to the recipient instead.
In the **Tron** blockchain, **Energy** cannot be returned by the sender's actions.
### How to Avoid Mistake №2
It is advisable to double-check your **TRON** address before renting **Energy** and interacting with the service.
We recommend using only those wallets that support the **Energy** resource (**TronLink**, **NETTS Wallet**, and recently **Trust Wallet**).
## Error №3: Not Taking into Account the Delay in Energy Accrual
Different **Energy rental** services require different amounts of time to credit the resource to the tenant's balance. Although it is measured in seconds and minutes (for **NETTS** it is several seconds), it is still not instantaneous.
Some users start a transaction immediately after paying or ordering **Energy** (depending on the terms of the service), without checking whether the resource arrives at all.
### How to Avoid Mistake №3
Do not interact with the smart contract before checking your **Energy** balance in your wallet or **TronScan** before sending **USDT**.
Until the **Energy** is credited, do not make a transaction, the system may have time to burn your **TRX** before the resource appears on the wallet.
## Error №4: Not Checking Network Load Before Renting
Users of the **Tron** ecosystem know that fees for smart contract transactions may increase when the **Tron** network is under high load. As a result, the need for **Energy** may also increase. And if you rented the usual amount, the **Energy** credited to the balance during the rent may not be enough to complete the transaction. Then **TRX** will be used, and if there is no crypto on the balance, the transaction will hang.
In turn, **Energy rental** services, of course, also react to the increase in demand for the resource, and raise prices for services. Also keep in mind that during periods of increased demand, you will not be able to return the excess rented **Energy** to the service with a refund of expenses for this volume.
### How to Avoid Mistake №4
There are several options here, depending on whether it is possible to postpone the transaction, or whether the user is obliged to make, say, a **USDT** transfer, regardless of the state of the network.
1. Before renting **Energy** each time, you should check the network status via the **TronScan** blockchain explorer.
2. If conditions allow, reschedule the transaction for another time or day.
3. If you are dealing with regular mandatory transfers, you should rent **Energy** in advance when the network is less busy.
4. Just set up automatic recharge of your wallet using **Workspace** or **Telegram Energy bot**.
## Mistake №5: Trying to Rent Energy when your TRX Balance Is Too Low
To successfully interact with the **Energy rental** service, a certain amount of **TRX** is required on the user's balance. If the native crypto is not enough, it will not be possible to rent **Energy**.
This happens for various reasons, one of which was mentioned above (**Tron** system overload). In this case, there may not be enough **TRX** in the wallet, since the user did not take into account that part of the **TRX** may go to system fees.
### How to Avoid Mistake №5
Before renting **Energy**, you should:
* carefully read the rules and policies of the **Energy rental** service;
* make sure you have enough **TRX** in your wallet;
* keep **+10-15 TRX** in reserve on your balance to avoid rental cancellation.
## Conclusion
So, before you contact the **Energy rental** service, you must perform several actions that will ensure the successful crediting of **Energy** and the safety of your funds.
1. Calculate the required resource volume to avoid wasting **TRX** on repeated operations.
2. Check your address carefully – it is impossible to return **Energy** that has already been credited by mistake.
3. Please make sure to wait for the **Energy** to actually be credited before sending **USDT**.
4. Rent **Energy** in advance to avoid price spikes when the network is congested.
5. You can simply set up full automation of **Energy** and **Bandwidth** rentals, which will allow you to forget about these resources at all and simply transfer **USDT** without hassle.
---
---
url: >-
https://doc.netts.io/blog/articles/why-does-a-tron-transaction-sometimes-hang-without-confirmation.md
description: >-
Users of the **Tron** blockchain interacting with **TRC-20** tokens may
encounter a situation where a transaction that usually takes a few seconds to
complete suddenly freezes without confirmation. Be...
---
# Why Does a TRON Transaction Sometimes Hang Without Confirmation?
Users of the **Tron** blockchain interacting with **TRC-20** tokens may encounter a situation where a transaction that usually takes a few seconds to complete suddenly freezes without confirmation. Below we analyze the main reasons and provide step-by-step instructions for unblocking frozen transactions in the **Tron** network.
In centralized online financial systems, payment for energy and computing resources is handled by the service provider (e.g., an online bank). In decentralized systems like **Tron**, these costs are paid by users. Most cryptocurrency blockchains charge **gas fees** in their native crypto. **Tron**, however, allows transactions to be paid not only with **TRX** but also with special resources.
**Bandwidth** is mainly used for **TRC-10** tokens, like **TRX** transfers. However, users interacting with **smart contracts** (TRC-20 tokens) must also maintain a reserve of **Bandwidth** (345 units per transaction). The system provides **600 Bandwidth units** daily for free, but this is only enough for one **TRC-20** transaction. Without **Bandwidth** or **TRX**, transactions can freeze.
**Energy** is the primary resource for **TRC-20** transactions. **Staking TRX** is one method to acquire Energy, but this locks funds for about 14 days. A faster alternative is **Energy rental services**, where users pay a small commission (20-25% of the fee) instead of locking up large amounts of **TRX**.
Freezing or delayed transactions typically result from user errors or third-party service issues (exchanges, wallets, etc.).
## Reason 1: Not Enough Power or TRX to Complete the Transaction
The most common reason for a transaction to hang is a lack of **Energy** (or **Bandwidth**) combined with insufficient **TRX**. When **Energy** or **Bandwidth** runs out, the network uses **TRX**. If there isn’t enough **TRX**, the transaction may not complete.
Before interacting with **TRC-20** tokens:
* Use **TronScan** to check your wallet's **Energy**, **Bandwidth**, and **TRX** balance.
* Check the transaction status:
* Open **TronScan** and enter the sender's address.
* Go to transaction history.
* Look for any transaction with the **Pending** status.
**Solution**:
1. Top up your **TRX** balance or rent additional **Energy**.
2. Try resending the transaction.
## Reason 2: High Load on the TRON Network
A sharp increase in activity on the **Tron** network can lead to higher fees. To maintain transaction speeds under heavy load, the network uses more computing and energy resources, which raises **Energy**, **Bandwidth**, and **TRX** consumption.
## How to Check:
* Go to **TronScan** browser.
* Navigate to the **Network Status** section.
* Check the **blockchain load** – if this indicator exceeds **80%**, there may be delays.
**Solution**:
1. Wait until the **network load** drops to standard levels.
2. Try sending the transaction again later.
## Reason 3: Wallet or Exchange Error
Delays in transaction confirmation may result from internal processes on the **wallet** or **exchange** side.
Increased waiting times are common on exchanges that **manually process** incoming transfers instead of automatic processing.
**How to check**:
* Go to **TronScan** browser.
* Check **transaction status**.
* Confirm whether the delay is on the **wallet** or **exchange** side.
* Contact the **technical support** of these services.
**Solution**:
1. Wait for the **transaction** to be processed.
2. If the delay persists, contact the **exchange** or **wallet support** repeatedly until the issue is resolved.
Fraudulent activities, such as **spam transactions** or sending **empty transactions**, can also disrupt the process. The goal of such actions is often to trick users into copying a scammer’s address. Always verify recipient addresses thoroughly.
## How to Unblock a Stuck Transaction
For each cause of a stuck transaction, different solutions apply:
1. **Insufficient assets**:
* Top up **TRX** and **Energy**.
* Use **Energy rental services** for quick replenishment.
2. **Speed up transaction**:
* Use your wallet's **"speed up transaction"** feature if available.
3. **Network congestion**:
* Wait until the **network load** reduces and retry the transaction.
4. **Exchange or wallet delays**:
* Contact the **technical support** of the relevant service.
Summarizing:
Transactions in the **Tron** blockchain can hang due to:
* Lack of **Energy**.
* **Network overload**.
* Issues on the **recipient wallet** or **exchange** side.
Always check transaction status through **TronScan**.
The most reliable and profitable solution:
* **Rent Energy** in advance to ensure smooth transactions without burning **TRX**.
**NETTS rental service** calculates the required **Energy** and uploads it to your wallet within seconds. By using **NETTS via Telegram bot**, you can save **up to 80%** of your **TRX**:
* A **15 TRX deposit** covers **3-5 transactions**.
* Using **Workspace** allows for full automation with only **1 TRX deposit**, which you can withdraw at any time.
Example:
* For a **USDT TRC-20** transfer requiring **65,000** or **131,000 Energy**, **NETTS** charges around **5.7 TRX**, saving nearly **80%** compared to the **13.4-27 TRX** you'd spend otherwise.
* Without **NETTS**, you'd need to stake about **23,000 TRX** for 14 days to get the same amount of **Energy**.
**No deposit?** Use **NETTS** via the **website form**:
* No registration or account creation required.
* Pre-pay for the **Energy volume** you need.
* Receive it **immediately** after payment for the chosen period.
**Energy Rentals from NETTS** guarantee hassle-free transactions without burning **TRX**.
---
---
url: >-
https://doc.netts.io/blog/articles/how-do-fees-work-on-the-tron-network-why-do-they-vary.md
description: >-
For the fast and secure processing of transactions in the Tron blockchain, the
technical team of the eco-platform must ensure good network throughput, spend
computing and energy resources. Of course, ...
---
# How Do Fees Work on the Tron Network? Why Do They Vary?
For the fast and secure processing of transactions in the Tron blockchain, the technical team of the eco-platform must ensure good network throughput, spend computing and energy resources. Of course, the user must recover these costs of the cryptocurrency blockchain by paying a commission for each transaction. To pay for transactions, you can use the native cryptocurrency TRX, as well as two types of resources - Energy and Bandwidth.
Less experienced users of the Tron blockchain are perplexed by the fact that when transferring USDT (or using TRC-20 tokens in other ways), the cost of transactions in TRX can differ significantly – literally several times.
In this article you will find out how fees are calculated in the Tron network, and how you can pay less if you are aware of all the opportunities that the blockchain and renting services provide for you.
## What Are Tron Fees Comprised Of?
It has already been mentioned above that in addition to TRX, two types of special resources are used to pay for transactions, which are renewable, but through different methods. Additional TRX can be obtained by passive or active staking, purchase or exchange. Accumulating TRX using such methods requires a significant amount of free crypto, since frozen assets do not belong to you for 2 weeks - they are managed by the blockchain. Therefore, spending TRX on 100% payment for transactions is unprofitable even for those who have large reserves of native crypto. This way, you should make the most of the capabilities of Energy and Bandwidth resources.
### Bandwidth
This resource is aimed at supporting the high throughput of the Tron network during transactions. A certain amount of Bandwidth (at the time of writing this article, it is 600 units) is received by each user on their account daily.
This resource is used mainly to pay for transactions with TRC-10 tokens, for regular transfers of native currency. But commissions when using TRC-20 tokens (USDT, USDC, smart contracts, etc.) must be also paid in TRX or the Energy resource. Please note the possibility of choice, which is discussed in more detail below.
### Energy
When working with stablecoins USDT, USDC and other Dapps using smart contracts, transaction fees are paid from the reserves in the user's wallet of the Energy resource.
But as soon as the Energy supply runs out, even in the midst of working with a smart contract, the blockchain will automatically start burning TRX from the user's account. That is why the transaction becomes more expensive, and significantly more expensive.
Conclusion: the user must have access to the required amount of Energy for the duration of transactions with TRC-20 tokens. Otherwise, he/she will have to pay with his reserves of the native currency (TRX), which means the transaction price will skyrocket.
## Why Might Fees Differ?
The amount of transaction fees may be affected by various factors.
1. **Energy reserve on the user's crypto wallet.** The larger the reserve, the more likely it is that TRX will not be withdrawn from the account during the transaction.
2. **The load of the blockchain network at the time of the transaction.** If the load is high, then the costs of computing and energy resources of the network increase, which the user must replenish from his assets.
3. **TRX transfers and other operations with TRC-10 tokens will be the cheapest** – they only require the Bandwidth resource. For transactions using TRC-20 tokens, including USDT transfers, both types of resources are charged towards the commission (or TRX if there are not enough resources).
For example, if a USDT transfer is made without Energy reserves, and **15-25 TRX** will be withdrawn from your wallet as a commission, then the same operation will cost you only **5-7 TRX** if you use Energy rental services in the event that you do not have enough reserves of this resource and do not have time for staking.
So, we came to the conclusion: low fees can be provided either by staking or by renting Energy.
## How Can You Save on Fees?
For the mass user of the eco-platform, the main methods of reducing transaction costs remain:
* **Staking** – when freezing **13 thousand TRX**, you get a sufficient reserve of Energy so as not to spend native crypto on transactions, but during the staking period you cannot use TRX, and you cannot release funds early – it always takes at least two weeks.
* **Renting Energy on special services** is a fast and profitable way that will allow you to reduce commissions by **2-5 times**. And you can automate the process through API.
**Conclusion:** Renting Energy on special services is the most profitable, convenient and efficient way to significantly reduce transaction costs if you have to send USDT frequently.
Now that you have a comprehensive understanding of how fees are formed in the Tron network and how you can pay less, it’s time to move from theory to practice.
**Don't overpay!** Rent Energy using the **NETTS** service – and reduce the commission for transferring USDT TRC-20 by up to **5 times**. Rent energy for **1 hour** using the form on the website, Workspace API or through our Telegram bot – and get your Energy in seconds.
---
---
url: >-
https://doc.netts.io/blog/articles/how-to-check-energy-and-bandwidth-balance-in-tron.md
description: >-
Unlike other cryptocurrency blockchains, where payment for transactions is
made only in tokens of these systems, the Tron eco-platform offers users to
pay transaction fees using special resources....
---
# How to Check Energy and Bandwidth Balance in TRON
Unlike other cryptocurrency blockchains, where payment for transactions is made only in tokens of these systems, the Tron eco-platform offers users to pay transaction fees using special resources.
By using **Energy** and **Bandwidth** resources to pay for transactions when interacting with TRC-20 tokens, you can significantly reduce the size of the commission and even completely avoid using **TRX** – tokens of the native Tron currency. For active users who often transfer USDT tokens, as well as for developers of DApps and other smart contracts, this is an opportunity to save significant funds:
But if during the transaction it turns out that the available amount of Energy or Bandwidth is not enough to pay the commission… No, the transaction will not be interrupted – the system will simply start taking your **TRX** as payment without any warning.
To prevent this, you should carefully check your resource balance before interacting with **TRC-20 tokens**. Incidentally, this should also be done for non-smart contract transactions when **TRC-10 tokens** are used. In this case, the blockchain will charge a transaction fee in **Bandwidth** units… or in **TRX** if the wallet does not have enough of this resource.
A Tron user who makes any type of transaction must estimate the resource consumption in advance. And for a correct estimate, it is necessary to control the balance of resources and be able to check the presence of **Bandwidth** and **Energy** among their assets.
The Tron cryptocurrency system provides a number of opportunities for this:
* **TronScan** – the official blockchain network explorer in the Tron system;
* **TronLink** – decentralized non-custodial wallet with fast access to the Tron blockchain and DApps;
* **Trust Wallet** – non-custodial cryptocurrency wallet with access to Web3 applications on multiple blockchains, including TRON.
We give step-by-step instructions on how to check available resources in **TRON** using these tools. We tell you how the **NETTS** service will pump up your wallet with Energy at any time, and you won’t have to spend your TRX on transactions.
## How to Check Resource Balance in TronScan
**TronScan** is available for free and without registration for browsing the basic information, but if you want to explore the platform's full potential, it is better to create an account. This is what we recommend if you intend to expand your experience in the **TRON** ecosystem and effectively use all the features that the blockchain offers.
The **TronScan** browser allows you to control the balance of resources on the user's wallet in a few clicks, for which it is enough to:
1. Go to **tronscan.org**.
2. Enter your **TRON** account address in the search bar.
3. Open your profile.
4. In the section **"Total Assets"** you can see the amount of **Bandwidth** and **Energy**.
**Conclusion:** TronScan allows you to quickly and freely view the availability of resources on your wallet. To do this, you do not need to register or install additional applications.
## How to Check Resource Balance in TronLink
Active users and smart contract developers benefit from using **TronLink** because it offers powerful features designed specifically for this blockchain, including simplified asset management, reduced fees due to optimized **Energy** and **Bandwidth** resources, and support for **TRX** staking with the ability to earn rewards in the form of additional resources or **TRX** (for holders of large amounts of crypto).
To check the availability and volume of resources in your wallet, you need to:
* open the **TronLink** wallet in the browser extension or mobile app;
* enter your account in the **Tron** blockchain;
* select the **Resources** section;
* examine the current **Energy** and **Bandwidth** balance.
**Conclusion:** **TronLink** allows you to quickly check the current balance of resources, for which you do not need to go to the browser.
## How to Сheck the Balance of Resources in Trust Wallet
**Trust Wallet** allows you to manage your assets on those blockchains to which it can connect – the **Tron** eco-platform is included in this list. You can also, if necessary, control the current balance of your assets, including **Energy** resources and **Bandwidth** used in the Tron system.
To check the amount of **Bandwidth** and **Energy** on your account, just a few steps are enough:
1. Open the **Trust Wallet** app.
2. Select **Tron** wallet.
3. Go to **More → Resources**.
4. View your **Bandwidth** and **Energy** balance.
**Conclusion:** **Trust Wallet** is convenient to use if you are registered on several cryptocurrency blockchains. Access to the main data is quite fast, but their updating is not always instantaneous.
## How Often Should Resource Data Be Updated?
After each transaction or **Energy** rental you conduct, the resource data must be updated. Therefore, we recommend checking the balance of assets, including resources, before each interaction with **TRC-20 tokens**, for example, before transferring **USDT**.
You should know that the size of the **USDT** transaction fee does not depend on the volume of stablecoins transferred. If the transaction is paid in native currency, then for the transfer of any volume you will pay either **13.4 TRX** or **27 TRX**, depending on whether the recipient has **USDT** in their wallet or these stablecoins are not in the recipient's wallet.
But if you use **Energy rental services**, you can completely get rid of the cost of transactions in **TRX**.
**NETTS will fill your wallet with Energy at any time** in the amount required to transfer **USDT**. You do not even need to have **TRX** on your balance for the **USDT** transfer transaction to go smoothly.
You will simply receive **131,000 Energy units** to your account if the recipient does not have **USDT** in their wallet, or **65,000** if they do. In exchange, **NETTS** wants to receive only ~**5.7 TRX** for renting **Energy** in the first case and half as much in the second. You must admit – the difference is significant. You also can automate the entire process using **Workspace** – just add a deposit (**15 TRX** minimum) and set up a trigger or constant refill to **131k**.
**Final conclusions:** If the **Energy** reserves in your wallet are running out, it is worth renting it in advance, otherwise the system will start burning your **TRX** without even stopping the transaction.
To monitor the availability of **Tron** resources (**Energy** or **Bandwidth**), it is very convenient to use **TronScan**, **TronLink**, and **Trust Wallet**.
Before sending **USDT** and interacting with other **TRC-20 tokens**, we recommend checking each time that the available resources are sufficient for the planned transactions, so as not to waste **TRX** on commission.
If you don’t have enough **Energy**, minimize your costs by renting it from specialized services such as **NETTS**.
---
---
url: >-
https://doc.netts.io/blog/articles/is-it-possible-to-send-usdt-to-tron-without-any-fees-at-all.md
description: >-
The USDT stablecoin, like other TRC-20 tokens, is a smart contract. When
transferring USDT TRC-20 (before the GasFree feature appeared on the Tron
blockchain), the transaction fee could be paid in the...
---
# Is It Possible to Send USDT to Tron Without Any Fees at All?
The USDT stablecoin, like other TRC-20 tokens, is a smart contract. When transferring USDT TRC-20 (before the GasFree feature appeared on the Tron blockchain), the transaction fee could be paid in the following ways:
* native currency TRX, as on most other cryptocurrency blockchains;
* special resources that are specifically created for Tron users – Energy and Bandwidth;
* combined approach – TRX+Energy+Bandwidth.
Depending on the recipient's balance, one transaction when transferring USDT costs the sender **13.4 or 27 TRX**.
And if the user pays for gas in full with rented Energy, then the costs for the entire process are ~**3-6 TRX**. This is the amount that will be withdrawn from the deposit when renting **65K or 131K Energy units**, respectively, through the NETTS service. Here is an example of a completed form – in this case, the tenant receives **131K Energy units for 1-hour rental**.
The appearance of GasFree technology in the Tron blockchain was preceded by a promise to completely free users from paying for gas. But is this really the best solution, or is renting Energy still a more profitable option? There is no need to write much to answer this question – just look at another screenshot and compare it with the previous one.
Even without taking into account the one-time fee for activating a special wallet, **10 USDT** for transferring any amount (here – for **8 USDT**) is not efficient at all.
First, let’s discuss GasFree technology, which allows you to send USDT without paying for gas. We explain why GasFree option is not as efficient compared to renting Energy and consider the pros and cons of both approaches to paying transaction fees on the Tron network.
## How Does GasFree Work?
The GasFree feature, which was launched by the Tron eco-platform in early March, allows you to send USDT TRC-20 without having to hold TRX or special Energy and Bandwidth resources on your balance.
When using this method, the commission for gas in TRX or Energy and Bandwidth is paid by the service provider (smart contract sponsor) instead of the user.
That is, when using the GasFree feature, a standard transaction is complicated, becoming a meta-transaction. This allows the sender of USDT to perform actions in the Tron ecosystem without directly paying a gas fee each time.
Instead, a third party pays the gas fee, in our case it could be a service provider or another smart contract sponsor. The sender signs the transaction and the provider processes it and pays for the gas.
But for the Tron network user, of course, this transaction is not free at all. Although this is how it was presented to the crypto community by the media last year. In fact, the user is obliged to pay this cost, just in stablecoins.
And compared to paying for gas in TRX, it turns out to be more expensive, and compared to paying for a transaction with rented Energy, it is significantly more expensive.
### GasFree Benefits
Of course, this approach also has its advantages, in particular:
* simplicity for users who rarely use Tron;
* the ability to send USDT even if there is 0 TRX on the balance and no resource reserve.
### Disadvantages of GasFree
The disadvantages of this method of paying commissions are hidden in its advantages:
1. GasFree is a very narrowly focused mechanism, its users are either Tron newbies who have not yet mastered the most effective mechanisms of the blockchain, or holders of large funds for whom shelling out **10-20 USDT** for the transfer of **10-100 thousand stablecoins** is an insignificant expense in exchange for the absence of hassle.
2. The service provider may include hidden fees or restrictions.
3. This function is not supported by all wallets and services.
4. When the network is heavily loaded, the provider may limit the number of meta-transactions.
To sum it up: the GasFree function is in demand by a narrow circle of users.
Those who regularly transfer USDT TRC-20 are not ready to pay **10-20 USDT** for one transaction regardless of the transfer amount.
Beginner users usually do not have enough USDT on their balance to pay fees with it.
Energy rental market is growing – after all, this is the most profitable way to pay for gas, truly excluding TRX from the commission.
## Why Might Renting Energy Be Better?
Using special resources to pay for gas is the exclusive prerogative of Tron blockchain users. Initially, this resource could only be obtained by staking. Unlike the Bandwidth resource, which appears on the balance of each blockchain participant daily and for free. Today, it is **600 units**. This resource is used to pay for gas when transferring TRC-10. But for a transaction with TRC-20 standard tokens, you also need to have **345 Bandwidth units** for one USDT transfer.
Energy staking requires a significant amount of TRX to be withdrawn from circulation for half a month. If this option is not available, the user is left without Energy and has to pay for gas with native crypto, which is very unprofitable.
The problem of a lack of TRX for staking or resources for paying for gas is successfully solved by renting Energy through special services.
The example above confirms that renting Energy is a proven way to really refuse to pay for gas. The Energy rental service will do it for you **NETTS**. You will simply pay for the service of charging your wallet with Energy in the amount necessary for the successful transfer of USDT.
**3-6 TRX** is not expensive at all for such a level of comfort. Especially compared to **10 USDT** that you will have to pay for the comfort of GasFree. And with automatic recharge via **Telegram Energy Bot** you can save some of the resources spent in case of non-use of rented Energy. You can also use the **Workspace** web interface for full automation of resource replenishment at the lowest price around the clock.
Of course, **NETTS** is currently the only service that allows you to reduce the cost of transferring TRC-20 by **80%**. But the Energy rental market is steadily growing, as it is ideal for those who regularly and frequently send USDT and other TRC-20 tokens.
### Benefits of Energy Rental
Energy leasing is the ideal option today to significantly reduce transaction costs. It provides the following benefits to a Tron user who regularly interacts with TRC-20 tokens:
* fixed low price, set by the rental service;
* predictable expenses;
* variability in the choice of payment – deposit or prepayment;
* rented Energy can be used not only for USDT transfers, but also for any TRC-20 transactions, including DApps;
* Energy rental is available for all wallets that support Tron.
Some services also offer their own wallets that are compatible with the Tron blockchain.
### Disadvantages of Energy Rental
The only disadvantage of this method is the need to carefully calculate the required amount of Energy in advance.
But the Energy rental service **NETTS** is ready to provide additional comfort here too. You can return the excess volume of unused resource without payment if you have a deposit. It can be replenished through **Netts Energy Bot**. It's only **15 TRX**, but you won't have to calculate the required volume with the fear of overpaying for the extra. **NETTS** will simply withdraw from the deposit the cost of Energy actually used for the transaction.
Some consider the need to have a small reserve of TRX on the balance for prepaid rent a disadvantage – **NETTS** provides the ability to pay for services in stablecoins.
## GasFree vs. Energy Rental: Which is More Profitable?
Let's compare both methods by key parameters:
| **Parameter** | **GasFree** | **Energy rental** |
|-------------------------------------------------|----------------------------------------------------------|------------------------------------------------------|
| Availability of native TRX crypto | No | No – you can find a service that accepts USDT for services |
| Fixed commission | Not always – depends on the provider's policy | Yes |
| Interact with any TRC-20 tokens | No | Yes |
| Support in other wallets | No | Yes |
| Suitable for bulk transactions | No | Yes |
| Transaction cost when transferring USDT TRC-20 at one address | 10 USDT | 3-6 TRX (depending on the recipient's USDT availability) |
**Conclusion:** If you need to send USDT without the ability to top up your TRX or Energy balance, **GasFree** can be useful, but the transaction will be much more expensive than using rented Energy.
If you make frequent transactions, renting Energy is pretty much the only optimal choice, as it offers stable low fees.
There is a surefire way to save your USDT and TRX – switch to rented Energy. With the **NETTS Energy rental service**, you get three times more transactions for the same investment when compared to staking!
---
---
url: https://doc.netts.io/blog/articles/what-are-energy-and-bandwidth-in-tron.md
description: >-
It is not a secret that the TRON network does not have fixed transaction fees.
Even novice users can see this for themselves after a relatively short period
of dealing with TRC-20 tokens, which includ...
---
# What are Energy and Bandwidth in TRON
It is not a secret that the TRON network does not have fixed transaction fees. Even novice users can see this for themselves after a relatively short period of dealing with TRC-20 tokens, which include the USDT and USDC stablecoins, as well as other Dapps using smart contracts.
But active users or Dapps developers know this for sure – they also know very well why commissions for similar transactions can differ so much, sometimes several times.
If you want to know about this, you should understand how commission charges are formed and what role such Tron blockchain resources as **Energy** and **Bandwidth** play in the process. These resources can be used when paying for transactions without spending any TRX.
The TRON ecosystem uses **Energy** and **Bandwidth** instead of the standard “gas” fees like Ethereum. This is why Tron users can effectively reduce transaction fees, especially when sending USDT TRC-20.
## What is Bandwidth?
It’s always easier for those who limit themselves to simple TRX transfers. For this type of transaction, **TRC-10 tokens** are used, for which network bandwidth is important. Each blockchain user receives **600 Bandwidth units** to their wallet every day for free. In order to check the availability of this resource, you must be registered via **TronScan** (an explorer for the TRON network) in the decentralized non-custodial wallet **TronLink** or another similar one linked to your Tron account.
Of course, if this volume is not enough for the day, then you will have to pay for the missing Bandwidth with the network's native cryptocurrency – TRX. Or send TRX for staking in advance, setting the required resource as payment for this.
But to transfer **TRC-20 USDT** you need not only Bandwidth, but also **Energy** – this resource compensates for the blockchain’s costs of computing power and electricity.
## What is Energy
The **Energy** resource in the Tron network can be compared to the gas fee in cryptocurrency blockchains that obtain crypto through mining.
Energy is also called the fuel for smart contracts, since neither their development nor their use can be done without this resource when paying for transactions. And since all **Dapps** are smart contracts or smart contract packages, decentralized application developers must also have significant Energy reserves. Of course, this also applies to those who are engaged in **USDT TRC-20** transfers and work with other **TRC-20 standard tokens**.
Why do those who work with TRC-20 standard tokens need a reserve of Energy? Because if your wallet lacks this resource, **TRX will be burned during the transaction**. Of course, this is much more expensive than paying for the transaction using the Energy resource.
Although this resource is not provided by the blockchain for free, like Bandwidth, you can get it in several ways:
* passive staking of TRX;
* purchase on the stock exchange;
* exchange with other users for other assets;
* renting using specialized services such as **NETTS**;
Of course, you may not feel interested in other ways to get Energy except for staking if you have a sufficient amount of TRX and you can constantly keep a certain amount of native crypto in staking, which will provide you with a constant flow of the necessary resources and almost free transactions. But very few active users of the Tron network, including developers of smart contracts and Dapps based on them can afford to keep sufficient amount of TRX in staking.
And even if you stake around **3k$ worth of TRX**, you can still get **3 times the transactions** from this amount of TRX if you would just rent Energy. Which makes renting incredibly profitable no matter how you look at it.
## Why USDT TRC-20 Transfer Fees Are Different
The answer to this question starts with the fact that you will have to pay **27.25 TRX** when sending to an empty USDT wallet and **13.4 TRX** when sending to a USDT wallet that has at least some of this asset: even **0.1 USDT TRC-20** in the recipient's wallet will already halve the cost of the transaction. Here is the first factor regarding this stablecoin pegged to the USD rate.
But since it is a TRC-20 token in the Tron blockchain system, you can use other factors to ensure a lower transaction cost when transferring through the Tron network.
1. **Availability of Energy on the wallet.** With a sufficient amount of Energy, the commission will be minimal, you will spend only resources, without using TRX.
2. **TRON network load.** Commissions may change depending on the activity level: a more loaded network requires more costs to ensure throughput, these costs will be compensated by increasing the cost of transactions.
3. **Access to operational rent of Energy.** Large volumes of this resource can be rented, which will prevent the risk of switching the network to TRX during interaction with TRC-20 tokens.
It’s much more efficient to use **Energy** to pay for the transaction. If you do not have this resource, **NETTS** will always provide – this will reduce the cost of any transaction by up to **FIVE TIMES**. By the way, we advise you not to split the USDT transfer, since the cost of the transaction does not depend on the volume of stablecoins transferred.
Using **NETTS**, you can get **65k or 131k of Energy** to your wallet within a second for an hour. This will significantly reduce the cost of the transaction – so why pay more?
## How to Use Energy and Bandwidth Correctly
Active Tron users and developers of applications and smart contracts based on TRC-20 tokens should avoid risks associated with sudden depletion of Energy reserves and Bandwidth, so that you don’t have to spend native cryptocurrency against your will.
For this purpose, the following “safety precautions” methods are quite accessible to these categories of users:
* check for availability of resources before sending USDT, remember that both types of resources are required for this operation, the same applies to all TRC-20 standard tokens;
* rent Energy beforehand to avoid "unauthorized" TRX spending;
* constant use of Energy renting services if you send USDT often.
Let's sum up everything that has been said above.
**Bandwidth** is sufficient for regular TRX transfers. However, it also forms part of the commission when working with TRC-20 tokens, including USDT transfers.
To avoid high transaction fees when transferring USDT, use another resource on the Tron network – **Energy**, which will save TRX from burning.
The best option that guarantees constant access to an unlimited amount of Energy is using an **Energy renting service**.
---
---
url: >-
https://doc.netts.io/blog/articles/why-trx-are-burned-when-transferring-usdt-with-examples.md
description: >-
Even active users of the Tron blockchain and smart contract developers, that
is, experienced network participants, are surprised when they notice that the
system wrote off **TRX** – native crypto toke...
---
# Why TRX are Burned when Transferring USDT - with Examples
Even active users of the Tron blockchain and smart contract developers, that is, experienced network participants, are surprised when they notice that the system wrote off **TRX** – native crypto tokens – for the transfer of **USDT** stablecoins. At the same time, there was a sufficient amount of **Energy** in the account before the transfer to pay for the transaction with this resource. Sometimes, even experienced users of the eco-platform make mistakes, and this happens regularly with beginners. As a result, millions of **TRX** are withdrawn from wallets, while a transaction for the transfer of **USDT** could be limited to only the **Energy** resource. And you can get this resource either for free or for a symbolic fee in the native crypto.
Find out why TRX may be used when sending USDT, even if the user had Energy in reserve before the transaction, and also how to avoid this.
***
As you know, in addition to native crypto for paying for transactions, **Tron** offers to use special resources – **Bandwidth**, which pays for the network's expenses to ensure the prompt passage of your transaction, as well as **Energy**, which replenishes the network's expenses for computing and energy capacity.
For regular transfers in **TRX**, it is enough to have **Bandwidth** on the wallet. **600 units** of this resource are enough for several transactions per day, this is the volume **Tron** replenishes users' wallets daily. The same applies to other types of interaction with other **TRC-10** standard tokens.
It's a different matter if the user is dealing with **TRC-20** standard tokens such as **USDT** or other types of smart contracts, like decentralized applications. When making a transaction, it is necessary to replenish not only the costs of bandwidth, but also energy and computing power. This can, of course, be done with **TRX**, but it is much more efficient to use the **Energy** resource for this.
Therefore, knowledgeable users try to have enough of this resource on their wallet to cover the fees for planned transactions. However, sometimes **TRX** are written off along with **Energy**.
Let's figure out why this happens.
## Reason 1: Not Enough Energy for the Transaction
An elementary error in calculating the required amount of **Energy** for **USDT** transfer transactions – this may occur because the sender did not check the presence of these same stablecoins in the recipient's wallet.
If the recipient has **USDT** in their account, the transaction fee will be **13.4 TRX**, and if not, it will be **27 TRX**. The sender had **65,000 Energy** in their wallet, which they thought was enough to cover the transaction fee for the transfer, but they failed to notice that the recipient did not have **USDT** in their wallet. So, to save **TRX**, the sender should have had **131,000 Energy** in reserve.
If the sender's wallet does not have enough **Energy**, the system automatically burns **TRX** to complete the transaction. The **TRX** consumption may vary depending on the **Energy** limit for the transaction.
**Example:**
* **Energy balance: 65,000** → the system burns **13.4 TRX** to pay the commission if the recipient's wallet does not have at least **0.01 USDT**.
* **Energy balance: 131,000** → commission in **TRX** is absent or minimal for other reasons.
**Conclusion:** Be sure to check your **Energy** balance before transferring **USDT TRC-20**.
***
## Reason 2: the Network Is Overloaded and the Base Fee Has Increased
This could be the reason for burning **TRX**, even if the user did not make a mistake in calculating the required amount of **Energy** for the planned transactions.
The **TRON** ecosystem uses a dynamic fee system. Therefore, as the network load increases, its energy and computing power requirements also increase. This increase is compensated by the users' **Energy** resource.
**Example:**
* under normal network load conditions, a transaction requires **131,000 Energy units** to transfer **USDT** to an "empty" wallet;
* under high load, the need for additional power increases transaction fees, which leads to **TRX** being burned when there is a lack of **Energy**.
**Conclusion:** Carefully check and take into account the level of network congestion, save your assets by refusing to work during busy periods or replenish the **Energy** reserves in your wallet.
## Reason 3: Recipient's Address is the Exchange
In this case, the transaction fees depend on the exchange policy, some of them require a fee for depositing **USDT**.
**Example:**
* sending **USDT** to a personal wallet → **0 TRX** (if you have **Energy**);
* sending **USDT** to the exchange → **x TRX**, where **x** is the exchange fee for depositing **USDT**.
**Conclusion:** Before transferring **USDT TRC-20** to an exchange, check the terms of the service and the established commissions for the operation you are using.
## How to Avoid Unnecessary TRX Write-Offs
So, the conclusions from all of the above are as follows:
1. Check your **Energy** balance before each **USDT TRC-20** transfer.
2. Check the recipient's balance status.
3. Rent **Energy** if you don't have enough to avoid spending **TRX**.
4. Send **USDT** during periods of low network load.
5. Before transferring to the exchange, check the conditions for individual transactions.
***
The native currency is written off from the sender's account when transferring **USDT TRC-20** when there is a shortage of **Energy**. The state of the network at the time of the transaction with **TRC-20** standard tokens, as well as the transfer of stablecoins to the exchange, can also increase transaction costs and lead to the write-off of **TRX** along with **Energy**.
The optimal way to save is to **rent Energy** before transferring **USDT** and interacting with other **TRC-20** tokens.
---
---
url: >-
https://doc.netts.io/blog/articles/why-usdt-transfer-fees-on-tron-keep-changing.md
description: >-
You have probably noticed that when transferring USDT stablecoins in the Tron
network, the transaction fee is sometimes different. Moreover, in some cases
it can differ several times. Of course, you a...
---
# Why USDT Transfer Fees on Tron Keep Changing
You have probably noticed that when transferring USDT stablecoins in the Tron network, the transaction fee is sometimes different. Moreover, in some cases it can differ several times. Of course, you are interested in how to ensure that you do not overpay for interactions with TRC-20 tokens, such as the network’s most popular stablecoin tied to the US dollar exchange rate – USDT.
Tron blockchain has provided its users with enough opportunities to manage their assets economically. The main thing is to study these opportunities well and be able to maneuver, also using friendly services that help to get resources for paying for transactions much cheaper.
We will explain what factors influence the size of fees when working with blockchain stablecoins, and how you can significantly reduce the cost of these operations, saving your TRX, including with the help of rental services.
## What Affects the Fee Size on the Tron Network?
First of all, you should know what resources of your wallet can be used to pay for transactions. Newbies mistakenly believe that payment for interaction with smart contracts and stablecoins is limited only by such a network resource as **Energy**. This is a very important resource that compensates for the blockchain's costs for computing and energy capacity.
But we must not forget about the **Bandwidth** resource, which provides network throughput and is also included in the cost of transactions not only in regular transfers of Tron's native currency in TRX tokens or when working with TRC-10 standard tokens, but also in transactions when interacting with smart contracts and transferring stablecoins.
What else should you remember besides the purpose of these two types of Tron blockchain resources?
1. **Bandwidth**\
The Tron ecosystem daily replenishes each user's wallets with this resource for free; at the time of writing, the replenishment volume is 600 units. It is mainly used for TRX transfers. It is enough for a couple of simple transfers. If you exceed the Bandwidth limit on your wallet, the network will spend your TRX on commission without warning.
2. **Energy**\
The resource is not given out for free by the blockchain, it will have to be "mined" independently, we will talk about the methods below. It is necessary for the execution of smart contracts, including USDT transfers. If during the transaction the resource supply on the user's wallet runs out, the blockchain starts burning TRX without warning and stopping the transaction, which significantly increases the commission.
Energy reserves in the wallet directly affect the size of the transaction fee when working with TRC-20 standard tokens (USDT, DApps, other types of smart contracts).
## Why Might Fees Change?
Some of the factors that directly affect the size of the transaction fees in the Tron network can already be identified from the previous information, but there are other points that you should pay attention to when interacting with TRC-20 standard tokens.
1. **Energy volume in the wallet →** It should be enough for all planned transactions. The larger the reserve, the lower the commission will be, since the system will not have time to "get" to your TRX.
2. **Tron network activity at the time of the transaction →** When the network is heavily loaded, the costs of computing and energy capacity, as well as ensuring network throughput, may increase.
3. **Transaction type →** Transactions involving interactions with TRC-20 tokens (USDT transfers, development and interaction with smart contracts, including DApps) are more expensive than transactions involving TRC-10 tokens.
4. **The state of the wallet you are transferring USDT to →** If it already has these stablecoins (any amount), the fee will cost you 13.4 TRX, and the cost of the transaction when transferring to a wallet that does not have this cryptocurrency will be twice as expensive. Moreover, the volume of USDT does not affect the size of the fee – you will be charged the same amount of TRX for 1, 0.01, or 1000 USDT.
***
Your goal is to eliminate as much native currency as possible from TRC-20 token transaction fees by replacing TRX with **Energy**. Look at how much TRX is burned every day – let’s try to avoid this:
The aforementioned transaction cost of 13.4 TRX is approximately equal to **64,000 units of Energy**. And under certain conditions, this amount can cost you significantly less. For example, for USDT transfers, which we are talking about, the commission can be reduced by up to **80%** if renting Energy.
**Conclusion:** To minimize fees for transactions with TRC-20 tokens, including USDT transfers, you should ensure that you have a **significant amount of Energy** in your wallet.
## How to Minimize Fee Costs?
The most effective ways to reduce costs involve either having a large supply of TRX or using special services.
### TRX Staking
For a certain period of time, the user provides part of their assets in TRX for use by the Tron network. In gratitude, you receive any of the ordered resources from the blockchain – **Energy** or **Bandwidth**. This is only beneficial to large TRX holders who can afford to freeze a significant portion of their assets for a long time. In addition to receiving resources, the user will also be credited with annual fees.
The disadvantage of this method is that not every user can allocate more than **20,000 TRX** for staking – that’s exactly how much is needed to consistently receive Energy for **two USDT transfers per day**.
You can also provide a portion of your TRX to manage the blockchain through community-selected representatives who generate blocks. But in this case, the result also depends on the invested funds of each – resources are distributed proportionally. And do not forget that you will not be able to release frozen TRX even in extreme cases until the established staking period ends.
But the Tron blockchain is distinguished by its great flexibility and the attraction of friendly services to meet the needs of users.
### Energy Renting
The eco-platform has launched a number of its own **Energy rental services**, but does not object to the participation of Tron enthusiasts in this process – users who are ready to provide this most accessible, economical, and efficient way to obtain the necessary volumes of Energy.
For those who constantly interact with TRC-20 tokens – for example, regularly and frequently transfer USDT – **renting Energy** is the most optimal solution for significantly reducing transaction costs. The main thing is that **you don’t need to have a significant amount of TRX in stock** to do this.
### Using NETTS Service
The **NETTS** service was created specifically to relieve Tron network users from problems due to the lack of Energy when working with TRC-20 standard tokens like **USDT**.
Here are the benefits that NETTS provides:
1. **Transfer USDT (and other TRC-20 tokens) even without TRX** on your balance – NETTS will take care of a sufficient amount of Energy for you for a symbolic fee in the same USDT.
2. **Avoid freezing your TRX** – NETTS takes care of that while you freely use your assets.
3. **Use a convenient application** that includes a mini-bot in Telegram and combines wallet and resource management.
4. **Use Workspace to set up a trigger** for a certain amount of Energy – once this trigger is reached, your balance will automatically recharge. Minimum deposit: **20 TRX**. Use Host mode for 1k+ transactions to ALWAYS have Energy available during the day - only 6.45 TRX per transfer!
**Conclusion:** For frequent USDT transfers, **renting Energy** is the optimal solution to reduce fees.
Avoid overpaying for transactions and let a renting service minimize fees by providing the required amount of Energy.
**Stop burning TRX** – NETTS will give you the Energy you need to cut up to **80%** of your TRX costs.
---
---
url: https://doc.netts.io/blog/articles/energy-rental-services-on-the-tron.md
description: >-
A comprehensive guide on renting energy on the Tron network, detailing how to
save on transaction fees and avoid burning TRX.
---
# Energy Rental Services on the Tron Network: Save Up to 80% on Transaction Fees
## Introduction to Tron and Resource Rental
Tron (TRX) is one of the popular blockchains known for its low transaction fees, high throughput, and reliability. Instead of paying fees directly in TRX, the Tron network uses specialized resources: **Bandwidth** and **Energy**. While Bandwidth is sufficient for ordinary TRX transactions and TRC-10 tokens, smart contracts and TRC-20 tokens (for example, USDT) require Energy.
If there is not enough Energy or Bandwidth available, TRX is burned to make up the shortfall. If you do not have enough TRX in your balance, nor sufficient Energy or Bandwidth, you will not be able to perform a transaction or any other operation on the Tron blockchain.
## How Resources are Acquired in Tron
### 1. Staking (Freezing) TRX
When you freeze a certain amount of TRX, you receive resources—either Bandwidth or Energy (you choose which resource you want in exchange for your frozen TRX).\
At the same time, you receive **Tron Power (TP)**, which allows you to vote for Super Representatives and earn additional rewards. The reward is approximately 4.5% per annum in TRX tokens.\
Frozen TRX can be unfrozen, but not instantly: the unfreezing period is 14 days (according to the current network conditions).\
The amount of Energy obtained for the same amount of TRX changes dynamically: the more people freeze TRX for Energy, the less Energy each participant receives.
### 2. Energy Rental
If you need to quickly execute transactions with tokens (for example, USDT) or interact with smart contracts but do not want to freeze a large sum of TRX for a long period, you can rent Energy from services specialized in this field.\
Renting is significantly cheaper than burning TRX for each transaction (up to 80% savings or more) and does not require large initial investments.
## Why Renting is More Advantageous than Burning TRX
If you do not have Energy in your wallet, the network will "convert" the required amount of smart contract computational power into TRX and burn it. With heavy use of TRC-20 tokens (for example, USDT), the fee can reach tens of TRX per transaction. For instance, 13.8 TRX is required to obtain 64,285 units of Energy and transfer USDT to an address that already holds USDT, and 27.35 TRX is needed to obtain 130,285 units of Energy for a transfer to an address that does not have USDT.\
In contrast, when you have Energy (either your own or rented), you do not pay TRX for triggering a smart contract: the fee becomes zero or minimal. Therefore, even if renting Energy involves a fee in TRX, it is almost always cheaper than burning tokens for every transaction. Savings can reach 80% or more.
## Why Renting Can Be More Advantageous Than Self-Staking
* **No need to freeze large sums.** To obtain 131,000 Energy (sufficient for one USDT transaction to a “clean” address without USDT), current network indicators require freezing about 11,684 TRX, which at a price of $0.242 (approximate cost at the time of writing) equals roughly $2,827.52. Moreover, this value changes dynamically: tomorrow, you might need even more TRX.
* **Flexibility in usage.** With rental, you pay a small fixed amount of TRX and receive the required amount of Energy for a specific period (a day, a week, a month, etc.). You won’t have to buy TRX every time or keep them frozen if they are needed for other purposes.
* **Full Energy Recovery in 24 Hours.** The spent Energy is restored to your account within a day. This means that if you rent, for example, 131,000 Energy for 30 days, you can execute one USDT transaction per day to a new address (which did not have USDT) or two transactions per day to an address that already holds USDT (requiring less Energy). Every 24 hours, the resource is replenished.
Thus, renting Energy is a convenient tool for those who do not want to invest in large-scale staking but regularly perform smart contract operations on the Tron network.
## Overview of Energy Rental Services in the Tron Ecosystem
Below is a list of some of the most well-known platforms and services that provide Energy rental. They allow users to (a) avoid burning TRX for every transaction and (b) avoid freezing large sums. Please note that rental terms may change, so it is advisable to keep track of the latest offers.
### 1. Feee.io
**Website:** [https://feee.io](https://feee.io/?ic=A72A)\
A service specifically created for renting and trading Tron resources (Energy and Bandwidth). Key features:
* **Exchange Trading:** Allows you to create buy or sell orders for resources with the necessary parameters.
* **Fast Transactions:** The service automatically selects a suitable offer, and the required amount of Energy is credited to the user’s wallet within minutes.
* **Earning Opportunities:** Users with large TRX reserves can rent out their resources to other participants.\
Feee.io is especially convenient for those who frequently perform transactions and want to save by avoiding systematic TRX burning.
### 2. Netts.io
**Website:** \
**Bot:** \
A service originally developed for convenient USDT transfers and Energy rental:
* **Wallet “Charging”:** You can obtain up to 131,000 units of Energy for two hours even with a minimal TRX balance in your wallet. Simply connect to the Telegram bot and “charge” your address before sending USDT, then complete the transfer using your wallet (TronLink, Trust Wallet, etc.).
* **Flexible Rental:** Allows you to rent the necessary amount of Energy for a specific period; auto-top-up can also be ordered when the Energy level drops.
* **Netts Wallet:** A non-custodial crypto wallet (a mini-app in Telegram) that allows you to:
* Send USDT even from an inactive (empty) wallet (no need for TRX or Energy on it).
* Pay fees in USDT if there is no TRX on the account.
* Offers some of the lowest prices on the market thanks to the aggregation of multiple Energy providers (pools and services).\
Netts.io has already gained community recognition in Tron by offering flexible rental options and fee optimization. API development is also ongoing for integrating Netts solutions into any software, including a wallet API, along with additional solutions for Energy rental, pool management, and USDT transfers.
### 3. TronSave
**Website:** [https://tronsave.io/market](https://tronsave.io/?ref=netts)\
**Wallet:** \
TronSave is a platform built on the TRON Stake 2.0 mechanism aimed at reducing transaction costs in the Tron ecosystem while offering secure and reliable tools for working with Energy. The project has established itself through active participation in Tron Hackathon: it ranked in the Top 3 in Season 4 and won 1st place in the Builder category in Season 5, confirming the high quality and reliability of its solutions.
**Key benefits for users:**
* **Up to 92% savings** on transaction fees in the Tron network thanks to advantageous Energy rental.
* **Simplicity and Convenience:** Energy rental is available both for individuals and projects, with an intuitive interface.
* **Earning on Unused Energy:** Users who stake TRX can earn additional income by renting out their unused Energy.
**Key benefits for Energy providers:**
* **Up to 25% APY** on your staked TRX through providing Energy rental via TronSave.
* **Stable Passive Income:** You continue to receive staking rewards while renting out Energy to optimize profits.
* **Flexibility and Reliability:** You retain full control over your staked TRX while using its Energy to generate additional income.
**Additional Tools:**
* **Bulk send (SaveSender):** A service for mass token distribution to a large number of users—fast, convenient, and fee-optimized.
* **Swap:** An integrated exchange tool with SunSwap that enables the exchange of various crypto assets in just a few clicks.
* **SaveWallet (savewallet.io):** A crypto wallet designed for the Tron ecosystem that reduces network fees by up to 93% and supports DApps. The project also offers a convenient built-in swap for quick token conversion.
Thus, TronSave not only significantly reduces transaction costs but also allows you to earn extra income from your staked TRX. Users enjoy a high level of security and convenience, while the built-in tools (bulk send, swap, SaveWallet) make interacting with the Tron ecosystem even simpler and more cost-effective.
### 4. JustLend DAO
**Website:** [https://app.justlend.org](https://app.justlend.org/energy?lang=en-US)\
One of the first DeFi platforms in the Tron ecosystem where you can lend and borrow assets, including crypto resources:
* **Automated Lending Platform:** Orders are matched without manual negotiations on rates.
* **Energy Rental:** One of the “byproduct” functions, where prices depend on market conditions, and you can specify the desired rental period.
* TRX is provided as collateral, which is returned upon the return of the rented Energy.\
Although JustLend DAO is primarily oriented toward lending digital assets, it can also be used for Energy rental, though its interface might seem less convenient than that of specialized services.
### 5. Tron Energy Market (TEM)
**Website:** [https://tronenergy.market](https://tronenergy.market/?ref=TBeTxs7Fa8wmYANUb38KTP6T5h9nRDGh6T)\
TEM’s goal is to simplify the automatic buying, selling, and renting of Energy:
* **Pool System:** Orders to buy or sell Energy are processed instantly, without long waits.
* **Direct TRX Rewards for Sellers:** Payments are made directly in TRX, with no secondary tokens or delayed payouts.
* Buyers are guaranteed that prices will not dynamically increase based on volume.\
Thanks to its pool system, you quickly receive the required amount of Energy, while sellers enjoy a stable income from renting out their resources.
### 6. Tron Pulse
**Website:** [https://tronpulse.io](https://tronpulse.io/r/netts)\
A P2P platform where users can directly buy and sell Energy:
* **Peer-to-Peer Model:** Users post their own orders, and the platform connects buyers and sellers.
* **User-Friendly Interface:** A dashboard with analytics and detailed information about transactions.
* **Integration with TronLink:** No custodial risks—you control your resources directly from your wallet.\
Tron Pulse is geared toward users who prefer direct resource trading with other individuals.
### 7. Tron Energize
**Website:** \
A project focused on innovation in Energy rental:
* A P2P trading platform providing direct access to and exchange of Energy resources.
* **Automation:** Energy distribution through smart contracts and a decentralized infrastructure.
* **Transparency:** All actions are recorded on the blockchain.\
Initially created to simplify and reduce the cost of renting Energy for active users in the Tron ecosystem.
### 8. Tron Energy
**Website:** [https://itrx.io](https://itrx.io/ru/buyer/?code=VAWA9Mp)\
A service that allows users to choose a convenient Energy rental format:
* **Flexible Minimum Rental:** Starting from 32,000 Energy, which is enough for transferring USDT to a wallet that already holds USDT.
* **Hourly or Daily Rentals:** Beneficial if you need Energy for a short period.
* Various ordering methods: manual, bulk, via API, or smart managed ordering (based on transaction history).\
It is characterized by a low entry threshold and the absence of contract fees for each small transaction.
### 9. Tron Fee Energy Rental
**Website:** \
A TRON Energy rental service with the following features:
* **Cost Savings on Rental Fees:** Up to 60% savings.
* **High Transfer Speed:** Transactions are processed in seconds.
* **Additional Earning Potential:** Users can rent out their Energy and earn commissions.\
Supports payments in TRX or USDT, as well as both manual and automated (via API) leasing modes.
### 10. Mefree.net
**Website:** [https://mefree.net](https://mefree.net/en.jsp)\
The developers position this platform as a "leading provider" of Tron Energy:
* Oriented toward individual users, DApp developers, and enterprises.
* API integration for automatically renting Energy within your own applications.
* Secure transactions ensured by encryption.\
Mefree.net aims to make its services accessible and efficient for different categories of clients.
### 11. Tron Lending
**Website:** [https://tronlending.xyz](https://tronlending.xyz/rent?referral=TBeTxs7Fa8wmYANUb38KTP6T5h9nRDGh6T)\
A self-service platform for Energy lending and resource trading:
* Reduces expenses on Energy consumption—its goal is a “revolution” in the Tron ecosystem.
* A community of developers actively supports DApp projects that lack sufficient Energy.
* Self-service tools: A comprehensive suite for managing Energy loans, collateral, returns, and more.
### Additional Solutions
* **DApp Egon:** Simplifies access to Tron Stake 2.0, including Energy rental and transaction fee savings.
* **Brutus Energy Bot:** A Telegram bot that automates the rental and transfer of Tron resources.
* **apitrx.com (API):** A dedicated "Tron Energy market" where no user interface is required—simply send TRX to the specified address via the bot and receive Energy within seconds.
## Conclusion
Renting Tron Energy is a convenient way to reduce fees when transferring USDT and using smart contracts on the Tron network without burning your own TRX or freezing large sums. Thanks to a multitude of services, users can choose the option that best fits their needs based on cost, rental duration, interface, and additional features:
* **Save up to 80%** by not paying TRX for every operation.
* **Avoid freezing large amounts,** thus keeping your liquidity.
* **Rent Energy for as short as an hour or as long as a month** and perform the required number of transactions without TRX fees.
* **Energy recovers in 24 hours** and is only consumed when a smart contract is executed.
Choose the service that best meets your requirements (level of automation, rental period, payment mechanism) and enjoy using the Tron network with minimal costs. We hope this overview helps you make the right choice and significantly save on transaction expenses.
---
---
url: https://doc.netts.io/wallet/create-a-wallet.md
---
# Create a Wallet
To get started on Netts Wallet, the first thing you'll need is to set up a Telegram application and connect to the bot. Telegram is available both on desktop computers and on smartphone devices.
## Steps to Create a Wallet
When you're setting up a wallet in the Telegram bot, be sure to:
* ✅ **Connect with the bot only from official sources.**
* ✅ **Follow the setup guide carefully.**
* ✅ **Safely back up your recovery phrases.**
* ❌ **NEVER share your recovery phrases with anyone, under any circumstances.**
* ❌ **NEVER input your recovery phrase to a website or app, other than your wallet app.**
Official Netts Wallet mini-app:
***
## Open the Netts Wallet Bot
Press **Wallet** or **Open Wallet**. Then press **Create a New Wallet**.
***
## Enter Password and Create Your Wallet
Enter the password for accessing the application and press **Create Password**.
***
## Save Your Seed Phrase
After creating a password, do not forget to save the seed phrase for your new wallet.
`Important: We do not save your passwords or seed phrases. If you lose them, you lose your assets.`
***
And after that, your wallet is ready for use. You can rename it or create more wallets.