Forem: Anton Erpulev

How MERX Aggregates All Energy Providers Into One API

Anton Erpulev — Wed, 01 Apr 2026 08:35:25 +0000

The TRON energy market in 2026 has a fragmentation problem. At least seven major providers offer energy delegation services, each with their own API, pricing model, and availability patterns. If you want the best price, you need to integrate with all of them, monitor their prices continuously, handle their individual quirks, and build failover logic for when one goes down.

Or you can make one API call to MERX.

This article explains how MERX aggregates all major energy providers into a single API - the architecture behind price monitoring, best-price routing, automatic failover, and the operational simplification that comes from replacing seven integrations with one.

The Provider Landscape

The TRON energy market includes multiple providers, each operating independently. As of early 2026, the major providers include:

TronSave - one of the earliest energy rental services
Feee - competitive pricing with API access
itrx - focus on bulk energy orders
CatFee - mid-market positioning
Netts - newer entrant with aggressive pricing
SoHu - provider with Chinese market focus
PowerSun - direct staking and delegation

Each provider has their own:

API format and authentication method
Pricing structure (some charge per energy unit, others per TRX)
Minimum and maximum order sizes
Available durations (1h, 1d, 3d, 7d, etc.)
Supported payment methods
Status pages and uptime characteristics

The Integration Tax

Integrating with a single provider is straightforward. Integrating with all of them to get best pricing is a significant engineering undertaking:

Per provider:
  - API client implementation:    2-3 days
  - Price normalization:          1 day
  - Error handling:               1 day
  - Testing:                      1-2 days
  - Ongoing maintenance:          2-4 hours/month

7 providers x 5-7 days = 35-49 days of initial integration
7 providers x 3 hours/month = 21 hours/month ongoing maintenance

This is the integration tax that MERX eliminates. Instead of maintaining seven provider integrations, you maintain one MERX integration. MERX handles the rest.

The MERX Architecture

MERX sits between your application and the provider ecosystem. The architecture has three core components:

1. Price Monitor

The price monitor is a dedicated service that continuously polls every integrated provider for current pricing. Every 30 seconds, it queries each provider's API, normalizes the response into a standard format, and publishes the result to a Redis pub/sub channel.

Every 30 seconds:
  For each provider:
    1. Query provider API for current prices
    2. Normalize to standard format (SUN per energy unit)
    3. Validate response (reject outliers, stale data)
    4. Publish to Redis: channel "prices:{provider}"
    5. Store in price history (PostgreSQL)

The 30-second interval is deliberately chosen. Faster polling would stress provider APIs and add minimal value (prices rarely change second-to-second). Slower polling would risk serving stale prices.

2. Redis Price Cache

Redis serves as the real-time price cache. Every price update from the price monitor is stored in Redis with a TTL (time-to-live) of 60 seconds - twice the polling interval. If a provider's price data is older than 60 seconds, it is automatically expired and excluded from routing decisions.

Redis key structure:
  prices:tronsave     -> { energy: 88, bandwidth: 2, updated: 1711756800 }
  prices:feee         -> { energy: 92, bandwidth: 3, updated: 1711756800 }
  prices:itrx         -> { energy: 85, bandwidth: 2, updated: 1711756800 }
  prices:catfee       -> { energy: 95, bandwidth: 3, updated: 1711756800 }
  ...

  prices:best         -> { provider: "itrx", energy: 85, updated: 1711756800 }

The prices:best key is recomputed on every price update, giving the API instant access to the current best price without scanning all providers.

3. Order Executor

When you place an order through the MERX API, the order executor receives it and determines the optimal routing:

Order received: 65,000 energy for TBuyerAddress

1. Read prices:best from Redis -> itrx at 85 SUN/unit
2. Check itrx availability for 65,000 energy -> available
3. Submit order to itrx
4. Monitor for on-chain delegation confirmation
5. Verify energy arrived at TBuyerAddress
6. Notify buyer (webhook + WebSocket)

If the cheapest provider cannot fill the order (insufficient stock, API error, timeout), the executor automatically falls through to the next cheapest provider.

Price Normalization

Different providers quote prices in different formats. Some quote in SUN per energy unit. Some quote total TRX for a given energy amount. Some include bandwidth in the price; others charge separately.

MERX normalizes everything to a single format:

interface NormalizedPrice {
  provider: string;
  energyPricePerUnit: number;    // SUN per energy unit
  bandwidthPricePerUnit: number; // SUN per bandwidth unit
  minOrder: number;              // Minimum energy units
  maxOrder: number;              // Maximum energy units
  availableEnergy: number;       // Currently available
  durations: string[];           // Supported durations
  lastUpdated: number;           // Unix timestamp
}

This normalization is critical. Without it, comparing prices across providers would require the consumer to understand each provider's pricing model. With it, price comparison is a simple numerical sort.

Best-Price Routing in Detail

The routing algorithm is not just "pick the cheapest." Several factors influence the routing decision:

Factor 1: Price

The primary factor. All else being equal, the cheapest provider wins.

Factor 2: Availability

A provider quoting 80 SUN but with only 10,000 energy available cannot fill a 65,000 energy order. The router must check available inventory.

Factor 3: Reliability

MERX tracks each provider's historical fill rate, response time, and failure rate. A provider with a 95% fill rate is penalized relative to one with a 99% fill rate, even if the 95% provider is slightly cheaper.

Effective price = quoted_price / fill_rate

Provider A: 85 SUN, 99% fill rate -> 85.86 effective
Provider B: 82 SUN, 94% fill rate -> 87.23 effective
Winner: Provider A despite higher quoted price

Factor 4: Duration Support

Not all providers support all durations. If you need a 1-hour delegation, providers that only offer daily minimums are excluded.

Order Splitting

For large orders that exceed any single provider's capacity, the router splits the order across multiple providers:

Order: 500,000 energy

Provider A: 200,000 available at 85 SUN -> fill 200,000
Provider B: 180,000 available at 87 SUN -> fill 180,000
Provider C: 300,000 available at 92 SUN -> fill 120,000

Total filled: 500,000 energy
Blended rate: 87.28 SUN/unit

The buyer sees a single order with a blended rate. The complexity of multi-provider execution is entirely hidden.

Automatic Failover

Failover is where aggregation truly earns its value. When you integrate directly with a provider and they go down, your application stops functioning. With MERX, provider failures are handled transparently.

Failover Chain

Primary provider fails
  |
  v
Mark provider as unhealthy (exclude from routing for 5 minutes)
  |
  v
Retry with next-cheapest provider
  |
  v
If second provider fails, try third
  |
  v
If all providers fail, return error to buyer with retry guidance

Health Tracking

The price monitor maintains a health score for each provider:

Health score components:
  - Last successful price fetch: must be within 60s
  - API response time: penalize > 2 seconds
  - Recent order fill rate: penalize < 95%
  - Recent error rate: penalize > 5%

Unhealthy providers are excluded from routing until they recover. Recovery is detected automatically when the price monitor successfully fetches prices from them again.

Zero-Downtime for Buyers

From the buyer's perspective, provider failures are invisible. Their API call succeeds as long as at least one provider is operational. In practice, having seven or more providers means that total market outage is essentially impossible - the odds of all providers being down simultaneously are negligible.

One API Replaces Many

Here is what your integration looks like with MERX versus direct provider integration:

Without MERX

// Pseudo-code: direct multi-provider integration

// Initialize 7 provider clients
const tronsave = new TronSaveClient(apiKey1);
const feee = new FeeeClient(apiKey2);
const itrx = new ItrxClient(apiKey3);
// ... 4 more

// Fetch prices from all providers
const prices = await Promise.allSettled([
  tronsave.getPrice(65000),
  feee.getPrice(65000),
  itrx.getPrice(65000),
  // ... 4 more
]);

// Normalize different response formats
const normalized = prices
  .filter(p => p.status === 'fulfilled')
  .map(p => normalizePrice(p.value)); // complex per-provider logic

// Sort by price, check availability, handle errors...
const best = normalized.sort((a, b) => a.price - b.price)[0];

// Place order with best provider
try {
  const order = await getClient(best.provider).createOrder({
    energy: 65000,
    target: buyerAddress,
    // Provider-specific parameters...
  });
} catch (e) {
  // Failover to next provider...
  // More provider-specific error handling...
}

With MERX

import { MerxClient } from 'merx-sdk';

const client = new MerxClient({ apiKey: 'your-merx-key' });

// Get best price across all providers
const prices = await client.getPrices({ energy: 65000 });
console.log(`Best: ${prices.bestPrice.provider} at ${prices.bestPrice.perUnit} SUN`);

// Place order - automatically routed to best provider
const order = await client.createOrder({
  energy: 65000,
  targetAddress: buyerAddress,
  duration: '1h'
});

// Done. Failover, retries, verification handled automatically.

Seven integrations become one. Hundreds of lines of routing and failover code become four lines. Ongoing maintenance of provider API changes drops to zero.

Real-Time Price Feed

For applications that want to display live prices or make real-time routing decisions, MERX provides a WebSocket price feed:

const client = new MerxClient({ apiKey: 'your-key' });

client.onPriceUpdate((update) => {
  console.log(`${update.provider}: ${update.energyPrice} SUN/unit`);
  console.log(`Best price: ${update.bestPrice} SUN/unit`);
});

The WebSocket feed publishes every price update from the price monitor - roughly every 30 seconds per provider. This enables applications to show live pricing without polling.

Provider Transparency

MERX does not hide which provider filled your order. Every order response includes the provider name, the price paid, and the on-chain delegation transaction hash:

{
  "orderId": "ord_abc123",
  "status": "completed",
  "provider": "itrx",
  "energy": 65000,
  "pricePerUnit": 85,
  "totalCostSun": 5525000,
  "delegationTxHash": "abc123def456...",
  "verifiedAt": "2026-03-30T12:00:00Z"
}

You always know where your energy came from, what you paid, and can verify the delegation on-chain independently.

Getting Started

MERX aggregation is available through the REST API, the JavaScript SDK, the Python SDK, and the MCP server for AI agents:

API documentation: https://merx.exchange/docs
JavaScript SDK: https://github.com/Hovsteder/merx-sdk-js
Python SDK: https://github.com/Hovsteder/merx-sdk-python
MCP Server: https://github.com/Hovsteder/merx-mcp

Create an account at https://merx.exchange, get an API key, and start routing energy orders to the best available price with a single API call.

This article is part of the MERX technical series. MERX is the first blockchain resource exchange, aggregating all major TRON energy providers into a single API with best-price routing and automatic failover.

Introducing MERX: The First TRON Resource Exchange

Anton Erpulev — Tue, 31 Mar 2026 07:29:00 +0000

MERX.exchange is the first aggregator-exchange for TRON network resources - energy and bandwidth - built to solve the fragmented provider market that forces businesses to overpay for every USDT transfer on the TRON blockchain. By connecting multiple energy providers into a single platform with real-time price comparison and automatic best-price routing, MERX reduces USDT transfer costs by up to 94 percent compared to the default TRX burn mechanism.

The Problem MERX Solves

Every USDT transfer on TRON requires a network resource called energy. Without it, the protocol burns TRX from your wallet - roughly 27 TRX per standard transfer. An entire market of energy rental providers exists to solve this, offering delegated energy at a fraction of the burn cost.

But this market is fragmented. There are at least seven major providers, each with their own API, pricing model, authentication system, and availability patterns. Prices range from 22 SUN to 80 SUN per energy unit on any given minute - a spread of more than 3.6x between the cheapest and most expensive option.

For a developer building a payment system, exchange, or any application that sends USDT programmatically, this fragmentation creates real engineering problems:

Multiple integrations. Each provider has its own SDK, API format, and error handling. Integrating with all of them to get the best price means maintaining multiple codebases.

No price transparency. There is no central order book or price feed. To know the best price, you have to query each provider individually and compare.

No failover. If your single provider goes down or runs out of capacity, your transactions either fail or fall back to the expensive TRX burn.

Manual price monitoring. Prices change throughout the day. The cheapest provider at 9 AM might be the most expensive at 3 PM. Without continuous monitoring, you cannot guarantee you are getting the best deal.

MERX eliminates all of these problems with a single integration point.

How MERX Works

The architecture is built around three core operations that run continuously.

Price Polling

MERX connects to every major TRON energy provider and polls their current prices every 30 seconds. This creates a real-time price index across the entire market. When you check prices on MERX, you see every provider's current rate and which one is cheapest at that moment.

The polling is not a simple price check. MERX also verifies provider availability, capacity, and supported duration ranges. A provider might have a great price but no capacity to fulfill your order. MERX filters those out before presenting options.

Best-Price Routing

When you place an energy order through MERX, the platform does not simply forward it to a default provider. It evaluates all connected providers against your specific order parameters - amount, duration, target address - and routes to the cheapest provider that can fulfill the order.

If the cheapest provider fails to deliver (network issues, capacity exhausted, timeout), MERX automatically fails over to the next cheapest option. This failover is transparent. You receive your energy either way; the platform handles the routing complexity.

Order Execution

Once a provider is selected, MERX executes the energy delegation on-chain. The energy appears in your target address, ready for use. The entire process - from API call to energy delegation - typically completes within seconds.

Platform Components

MERX is not just a web interface. It is a full platform with multiple integration paths designed for different use cases.

Web Exchange

The primary interface at merx.exchange provides a real-time view of the energy market. You can see current prices across all providers, place orders manually, check your balance, and review order history. The interface is designed for professionals: dark theme, no visual clutter, data-dense layouts.

REST API

The API exposes 46 endpoints covering the complete lifecycle of energy trading:

Market data - current prices, price history, provider comparison
Orders - create, track, list energy and bandwidth orders
Standing orders - recurring energy purchases on a schedule
Account management - balances, deposits, withdrawals
Monitoring - set up resource monitors and threshold alerts
Address utilities - validate addresses, check on-chain resources

All endpoints are versioned under /api/v1/ and return standardized error responses. POST endpoints support idempotency keys to prevent duplicate orders.

Full documentation is available at merx.exchange/docs, covering 36 pages of endpoint references, authentication guides, error code tables, and integration examples.

WebSocket

For applications that need real-time price updates without polling, MERX provides a WebSocket connection. Subscribe to price channels and receive updates as they happen - every 30 seconds when prices change.

JavaScript SDK

The official JavaScript/TypeScript SDK wraps the REST API in a typed client with built-in error handling, retry logic, and convenience methods.

import { MerxClient } from 'merx-sdk';

const merx = new MerxClient({
  apiKey: process.env.MERX_API_KEY
});

// Get best current energy price
const prices = await merx.getPrices();
console.log('Best price:', prices.energy.best.price, 'SUN/unit');
console.log('Provider:', prices.energy.best.provider);

// Compare all providers
const comparison = await merx.compareProviders();
for (const provider of comparison) {
  console.log(`${provider.name}: ${provider.price} SUN`);
}

// Buy energy at the best price
const order = await merx.createOrder({
  resourceType: 'ENERGY',
  amount: 65000,
  duration: '1h',
  targetAddress: 'TRecipientAddressHere'
});

console.log('Cost:', order.totalCost, 'SUN');

Available on npm as merx-sdk. Source code on GitHub.

Python SDK

The Python SDK provides the same functionality for Python applications, with synchronous and asynchronous support.

from merx_sdk import MerxClient

client = MerxClient(api_key="YOUR_API_KEY")

# Get best current energy price
prices = client.get_prices()
print(f"Best price: {prices['energy']['best']['price']} SUN/unit")

# Calculate potential savings
savings = client.calculate_savings(
    energy_amount=65000,
    num_transfers=1000
)
print(f"Monthly savings: {savings['savings_trx']} TRX")

# Place an order
order = client.create_order(
    resource_type="ENERGY",
    amount=65000,
    duration="1h",
    target_address="TRecipientAddressHere"
)
print(f"Order {order['id']}: {order['status']}")

Available on PyPI as merx-sdk. Source code on GitHub.

MCP Server for AI Agents

MERX includes a Model Context Protocol (MCP) server that allows AI agents and LLM-based applications to interact with the TRON energy market directly. An AI agent can check prices, place orders, monitor addresses, and manage energy purchases through natural tool calls.

This is particularly relevant as AI agents increasingly manage on-chain operations. An AI agent handling a treasury, processing payments, or managing a DeFi strategy can use the MERX MCP server to optimize energy costs without custom integration code.

Available on npm as merx-mcp. Source code on GitHub.

Key Numbers

Providers connected: 7 major TRON energy providers
Price polling: every 30 seconds across all providers
Commission: 0% on energy orders
API endpoints: 46 versioned endpoints
Documentation: 36 pages including full API reference
SDKs: JavaScript (npm) and Python (PyPI)
Cost reduction: up to 94% compared to TRX burn
Mainnet verified: transactions confirmed on TRON mainnet

What Makes MERX Different from Single Providers

A single energy provider is a vendor. MERX is a marketplace. The distinction matters in several concrete ways.

Price. A single provider sets their own price. MERX shows you every provider's price and routes to the cheapest. On any given minute, the cheapest provider is different. Over a month, the savings from always hitting the best price compound significantly.

Availability. If a single provider runs out of capacity or goes offline, your energy purchase fails. MERX automatically routes to the next available provider. Your application does not need to handle failover logic.

Transparency. With a single provider, you have no visibility into whether you are getting a competitive price. MERX shows you the full market spread so you can see exactly where your order was routed and why.

Integration simplicity. Integrating with 7 providers means maintaining 7 API integrations, 7 authentication flows, and 7 sets of error handling. Integrating with MERX means one API, one SDK, one set of credentials.

Neutrality. MERX does not operate its own energy staking operation that competes with the providers on the platform. It is a pure aggregator, aligned with routing to the best price rather than favoring its own supply.

Documentation

The MERX documentation is built to the standard of enterprise API references. Thirty-six pages cover:

Getting started guides for web and API users
Authentication and API key management
Complete endpoint reference with request/response schemas
Error code tables with resolution steps
SDK installation and usage guides
WebSocket subscription documentation
Idempotency and retry best practices
Rate limiting and quota information

The documentation is available at merx.exchange/docs and is kept in sync with the API - every endpoint documented matches the live API.

Real On-Chain Results

MERX has executed energy orders on TRON mainnet with verified results. Eight transactions have been confirmed on-chain, demonstrating the full flow from API order to energy delegation to USDT transfer with zero TRX burned for energy.

In these mainnet transactions, USDT transfers that would have cost 27.30 TRX through the burn mechanism cost 1.43 TRX through MERX-routed energy rental. The delegation and transfer transactions are publicly verifiable on any TRON block explorer.

These are not testnet simulations. They are real mainnet transactions with real TRX and real USDT, demonstrating that the routing, provider integration, and on-chain execution all work in production.

Who MERX Is For

Payment processors that send USDT to merchants, freelancers, or suppliers. Each transfer's energy cost is a direct hit to margins.

Crypto exchanges that process TRC-20 withdrawals. Energy costs are either absorbed (reducing profit) or passed to users (reducing competitiveness).

Trading bots that execute frequent on-chain transfers as part of arbitrage or market-making strategies. Every fraction of TRX saved per transfer scales with volume.

DeFi protocols that interact with TRON smart contracts. Energy costs affect the economics of every on-chain operation.

Treasury management teams that need to optimize operational costs for on-chain movements of USDT and other TRC-20 tokens.

AI agents that manage on-chain operations autonomously and need a programmatic way to acquire energy at the best price.

Getting Started

Visit merx.exchange to create an account and see the live energy market. The platform is operational and processing orders on TRON mainnet.

For API integration, start with the documentation. Install the SDK for your language:

# JavaScript / TypeScript
npm install merx-sdk

# Python
pip install merx-sdk

For AI agent integration:

npm install merx-mcp

The first step is always the same: check current prices. See what the market looks like. Compare what you are currently paying for energy to what the aggregated market offers. The numbers speak for themselves.

Tags: merx exchange, tron energy exchange, tron resource marketplace, tron energy aggregator, usdt transfer optimization