TradeOgre markets, the v1 API, and the bots that ran on it

What TradeOgre actually listed

At the point it stopped operating, TradeOgre carried roughly 109 trading pairs across about 96 assets, with daily volume in the region of US$3.5 million. Those are small numbers in absolute terms. Their significance is entirely in the composition.

The listings skewed hard toward two categories. The first was privacy coins — Monero above all, alongside Wownero, Pirate Chain and others that regulated venues had progressively delisted as travel-rule obligations tightened. The second was small proof-of-work projects: coins with active miners, real hash rate and a community, but no market capitalisation worth a major exchange's listing process.

For the second group especially, a TradeOgre pair was frequently the only meaningful market that existed. Price discovery, miner sell pressure, and any notion of what the coin was "worth" all ran through a single order book on a single unregistered platform. That concentration was invisible while it worked and total once it stopped.

Almost everything was quoted against BTC, with a small number of USDT pairs. That meant exiting an obscure asset to anything stable usually took two trades and two rounds of the 0.2% fee, and it left BTC as the platform's de facto reserve currency.

The API and how bots used it

TradeOgre published a small REST API at a versioned endpoint, documented on its own help pages. It was deliberately minimal — no WebSocket streams, no FIX gateway, no order types beyond limit buy and limit sell — and that minimalism is exactly why so much was built on it.

Public endpoints needed no authentication at all. You could pull the full market list, an order book, a ticker, recent trade history or candle data with a plain HTTP GET, which made TradeOgre one of the easiest venues in crypto to gather data from. A great deal of the price data for small proof-of-work coins that ended up in aggregators, portfolio trackers and mining calculators originated from those endpoints.

Authenticated endpoints used HTTP basic authentication with a key pair generated in account settings, passed as the username and password of the request. That is a simple scheme with a real drawback: unlike request-signing schemes, a basic-auth key pair that leaks is immediately usable by anyone who has it. Combined with no IP allowlisting and no withdrawal-scoped permissions, the practical guidance at the time was to treat any TradeOgre API key as a credential with full trading authority and to store it accordingly.

Support for the venue found its way into general-purpose trading libraries, which is why references to it still appear in code and documentation today.

What happened to running bots

When the platform went down, bots failed the way most bots fail: badly, and in silence.

A well-written client treats an HTTP error as a condition to handle. A great many small trading scripts do not — they assume a response, parse it, throw an exception, and either exit or retry in a loop for weeks. Users running market-making strategies discovered they had open orders they could not cancel and positions they could not close, with no interface to intervene through.

Three lessons carry over to any venue, and they are worth stating plainly because this failure mode recurs.

• Fail closed, not open. A bot that cannot confirm the state of the exchange should stop, not keep submitting. Retry loops against a dead endpoint have historically produced spectacular losses when the endpoint came back in an unexpected state.
• Alert on absence, not just on errors. Silence is a signal. A monitor that fires when your bot has not reported a successful cycle in an hour catches an exchange failure faster than any error handler.
• Scope and rotate keys. Use withdrawal-disabled keys for trading bots wherever the platform supports it, restrict by IP where possible, and revoke keys for any venue you have stopped using. TradeOgre offered little of this, which is itself information about the platform.

If you have old TradeOgre keys in a configuration file or environment variable, delete them. They cannot be used against the dead platform, but they are exactly the sort of thing that ends up in a public repository.

RTM, BTCP and the long-tail problem

The coins that suffered most were the ones with the least elsewhere to go.

Raptoreum is the clearest case. A CPU-mineable proof-of-work project with an active mining community, its RTM/BTC pair on TradeOgre was for long periods the primary venue where miners converted rewards and where any market price was set. When the platform stopped, that price signal stopped with it, and the miners lost their most convenient exit at the same moment.

Bitcoin Private illustrates the other end of the pattern. A 2018 Bitcoin fork that lost the confidence of most exchanges after a controversy over its coin supply, BTCP had been delisted almost everywhere. TradeOgre was among the last places it traded at all, which meant the platform functioned as a kind of terminal venue for assets that had run out of alternatives.

Neither situation was healthy, and the concentration risk was structural rather than accidental. When a single unregistered exchange is the only market for an asset, that asset's holders are exposed to that exchange's regulatory position whether they know it or not. The seizure did not just freeze balances — it removed the market itself.

Where those markets went

There is no single replacement, and the honest answer is that some of these assets no longer have a functioning market at all.

For privacy coins, the migration has largely been toward non-custodial routes: decentralised exchanges built around atomic swaps, and peer-to-peer platforms where trades settle directly between wallets. These are less convenient than an order book and require you to manage keys, but they do not have a custodian who can be raided.

For small proof-of-work coins without a decentralised market, the situation is harder. Some found listings on other small centralised venues, which reproduces the original risk with a different operator. Others are effectively illiquid, tradeable only through direct negotiation between holders.

For data, aggregators that once pulled from the TradeOgre API now show nothing for these pairs. If you maintain a tool that depended on that source, the endpoint is gone permanently and needs replacing rather than retrying.

The structural takeaway for anyone building on exchange APIs: source your data from more than one venue, and treat any strategy whose viability depends on a single unregistered platform as carrying that platform's regulatory risk in full.