Self-hosted service
Adamant-im/adamant-tradebot avatar
Adamant-im/adamant-tradebot

ADAMANT Market-Making Software: a self-hosted CEX liquidity bot reviewed

Free self-hosted liquidity bot for token issuers who want to improve CEX market quality without sending tokens, funds, or API keys to a third-party market maker.

853 stars125 forksJavaScriptLicense varies

At a glance

What is it?
Adamant-im/adamant-tradebot is a free, self-hosted Node.js bot that keeps buy and sell orders on six centralized exchanges using your own account and API keys. The design keeps custody with the issuer, but the free tier is deliberately basic and the README does not state a licence.
Who is it for?
Adopt it if you are a token issuer already listed on Azbit, P2PB2B, StakeCube, Coinstore, FameEX or NonKYC, you have a Linux host and Node.js v22.2 or newer, and you want order book activity driven from your own account rather than handed to a market maker. Do not adopt it if your listing is on a large exchange outside that list, if you need a GUI on day one, or if you cannot operate MongoDB and a process manager yourself.
Can I use it commercially?
Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
Is it still maintained?
Yes. The repository last received commits 6 days ago.
What is it written in?
Mainly JavaScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The listing problem this bot is aimed at

Getting onto a centralized exchange does not create a market. The README frames the gap directly: a thin book, a wide spread, or a price that moves on small orders reads as risk to a new trader before they read anything about the project. The situations table lists the same set of complaints from the issuer side, including retainer and token-loan costs from full-service market makers and a stated distrust of third parties who hold API keys.

The intended user is a token issuer, not a general trader. The README names two groups: small and early-stage projects that need a free basic toolkit, and mid-size or large projects that want advanced features, extra exchange connectors and paid setup help. Both groups are assumed to already have a CEX listing. There is no path here for a project that has not listed yet, and nothing about decentralized exchange liquidity except a premium DEX price watcher mentioned in passing.

The pitch is custody. The README repeats that the software runs on your server, uses your exchange account, and does not require sending tokens, funds or API keys to an outside market maker. That is the whole argument: you keep the account, so the risk of a third party misusing it or dumping a token loan does not exist by construction.

What the bot actually places on the book

The free tier is a set of order-management behaviours rather than a single strategy. The README lists buy and sell limit orders, buy and sell market orders, initial order book filling, dynamic order book building, spread maintenance, price range settings, and basic liquidity and depth support. It also names four trading activity policies: spread, order book, optimal, and depth.

How those policies differ is not explained in the material available. The README gives the names and stops there, and parameter descriptions live in comments inside config.jsonc rather than in the README. Anyone evaluating this should treat the policy semantics as something to read out of the config file after cloning, not something the documentation answers up front.

Two mechanisms are described with more shape. The first is a reference price or arbitrage logic that works across trading pairs or exchanges, which is how the bot decides where to sit relative to a market it is not itself moving. The second is the account information surface: exchange fees, daily volume, balances, orders, and bot statistics. Those are read paths, useful for confirming that the bot is doing what the config says, and they matter because there is no public admin panel by default. Control is described as command-based through ADAMANT Messenger, with command aliases, and the README notes that Telegram, CLI and WebUI access require requesting a manager.

Install path and the config keys you will actually edit

The requirements section is specific: Ubuntu 20 or newer, or CentOS 8 or newer, with the caveat that other Linux distributions may work but are not tested. Node.js v22.2 or newer, npm v9 or newer, and a MongoDB instance, with a link to MongoDB's own community installation instructions.

Setup is four commands as written in the README:

su - adamant git clone https://github.com/Adamant-im/adamant-tradebot cd adamant-tradebot npm i

The bot resolves configuration in a defined order: config.jsonc if present, otherwise config.default.jsonc. Named configs follow the pattern config.<name>.jsonc, and the name is passed as a launch argument, which means one checkout can hold several exchange or pair profiles side by side. The documented way to start editing is:

cp config.default.jsonc config.jsonc nano config.jsonc

Launch is node app.js, though the README recommends a process manager instead of a bare foreground process. The section covering the npm approach is truncated in the material available, so the exact process-manager invocation is not something I can quote.

The exchange API credentials, the pair list, the price range and the chosen activity policy all live in that config file. The README does not enumerate the keys, so plan on reading the comments in config.default.jsonc before you can predict what the bot will do on first start.

Six exchanges, and what happens outside that list

The free basic version supports Azbit, P2PB2B, StakeCube, Coinstore, FameEX and NonKYC. That list is the hard boundary of the free tier. The README states plainly that premium and custom exchange support is available for other CEXs, and runs a limited onboarding offer through September 1, 2026, under which a connector for your exchange may be added for free or at a discount.

Read that offer as a signal about the architecture. Connectors are written per exchange, and adding one is a development task, not a configuration task. If your token trades somewhere that is not on the list, the free software does not help you today, and the route forward runs through a commercial conversation rather than a config edit.

The premium feature list also tells you where the free tier has been cut. In-spread orders, no-gap order book logic, smoother chart behavior, anti-cheat and cleaner logic, a DEX price watcher, WebUI access, and setup assistance are all listed as premium options. Several of those, particularly in-spread orders and no-gap logic, are exactly the behaviours a trader notices on a chart. The free version does the basic work; the polish is behind the paid tier.

Where this is the wrong tool

The first limitation is operational. This is a Node.js process talking to MongoDB, launched from the command line, on a server you administer. There is no hosted control panel in the free tier. If nobody on the team is comfortable with SSH, systemd or pm2, a bare node app.js is not a deployment strategy, and the README's own recommendation of a process manager is the minimum bar.

The second is the licence. The repository metadata supplied here does not identify one. The README calls the software free and open source and says the code can be inspected, but it does not name a licence, and the premium tier implies a commercial boundary somewhere. Until the licence file is checked, you cannot say what you are allowed to redistribute or modify, and no article can settle that for you.

The third is the gap between free and paid. A project that needs tight in-spread quoting or a book with no visible gaps is being pointed at premium features by the README itself. The free tier is positioned as a starting point, and the README says so: it is suitable for getting started with self-hosted liquidity operations on supported exchanges. Treat any expectation of full market-maker behaviour as a paid feature.

Finally, market making on your own account does not remove market risk. The bot places orders; it does not promise that those orders are profitable. The README makes no performance claim, and there is no benchmark material here to lean on.

Compared with renting a market maker

The obvious alternative is a full-service market-making firm, the model the README describes as retainers, token loans and opaque terms. The difference is not the strategy, it is who holds what. With a service, the firm holds or borrows your tokens and operates through an arrangement you monitor from outside. With this bot, the exchange account stays yours, the API keys stay on your server, and the order flow is whatever config.jsonc says it is. You trade away the firm's experience and its willingness to take on the operational burden, and you take on the server, the monitoring and the tuning yourself.

A second alternative is writing your own bot against the exchange APIs. That is the same custody model with none of the shared connectors. The value this project adds is the six exchange integrations, the reference price logic, and the config-driven policy switch, plus the Messenger control channel that avoids exposing a public admin panel. If you already maintain an internal trading stack, that value may be small.

A third option worth naming is doing nothing and letting the book stay thin. For a project with no near-term volume targets, that is a legitimate choice, and it costs nothing.

Maintenance cost and version cadence

The release history shows v7.0.1 in September 2025, then v8.0.0 in late June 2026 and v9.0.0 a week later in early July 2026. The default branch is dev and the last push recorded is September 2026. Two major versions inside a week suggests active development, and it also suggests that upgrading across a major version is a real task rather than a patch. A self-hosted operator should expect to re-read config.jsonc comments after a major bump, because the README points at the config file as the source of parameter documentation rather than maintaining a separate reference.

Ongoing costs are the ones you supply: a Linux host, a MongoDB instance, and someone who notices when the process dies. Exchange API changes are the other recurring cost, and those land on the connector, which is the part you cannot fix by editing config. If your exchange is not among the six, that cost is already being handled by someone else, on their schedule.

On licensing, the material does not state a licence identifier, so the practical step is to read the repository's licence file before you build anything around this code. That is a factual check, not legal advice, and it determines whether internal use, modification or redistribution is on the table.

Editorial conclusion

Adopt it if you are a token issuer already listed on Azbit, P2PB2B, StakeCube, Coinstore, FameEX or NonKYC, you have a Linux host and Node.js v22.2 or newer, and you want order book activity driven from your own account rather than handed to a market maker. Do not adopt it if your listing is on a large exchange outside that list, if you need a GUI on day one, or if you cannot operate MongoDB and a process manager yourself. Before committing, verify three things: the repository licence, whether the commands you need are exposed through the ADAMANT Messenger control path or only through the premium manager, and whether the free tier's order placement policy matches the depth you actually need.

Official sources

  1. Adamant-im/adamant-tradebot on GitHub
  2. Issues
  3. Project website
  4. README
  5. Releases
Community notes

Community notes