Adamant Tradebot says open source and ships an UNLICENSED manifest

The manifest says UNLICENSED and the page says open source

The repository carries no licence in its own metadata, and the root manifest's licence field reads `UNLICENSED`. There is no LICENSE file among the top level entries. The page, meanwhile, describes the software as open source, inspectable and runnable by anyone, backed by what it calls a ten-year open source crypto project with public repositories and production infrastructure.

Those two statements cannot both be right, and nothing in the repository settles which one to believe. An unlicensed package marked publishable rather than private, with no licence file and no licence metadata, is the package manager's way of saying that reuse rights are not granted, and the page is the only place asserting the opposite. Which of the two a court or an auditor would honour is not something this repository answers.

This matters more here than it would for most projects. The pitch is that you should trust this with your exchange API keys and your token inventory, and the trust argument rests on being able to read the code and on knowing the terms you are reading it under. The code is public. The terms are the part that is missing.

The controls that shape what traders see are premium features

The free feature list is about placing orders. It covers initial order book filling, dynamic order book building, buy and sell limit orders, buy and sell market orders, spread maintenance, basic liquidity and depth support, price range settings, four configurable trading policies named spread, order book, optimal and depth, reference price and arbitrage logic across pairs or exchanges, an account view of fees, daily volume, balances, orders and bot statistics, command aliases, and management through the project's messenger with no public admin panel.

The premium list is about appearance and safety. It names in-spread orders, no-gap order book logic, smoother chart behaviour, safer liquidity strategies, better spread maintenance, a DEX price watcher, anti-cheat and cleaner logic, additional exchange connectors, WebUI access, setup assistance, configuration tuning and ongoing support.

Read together, the split is sharper than a feature comparison usually is. Everything in the free tier moves orders. Everything in the paid tier governs how those orders look to an exchange's surveillance systems and to the other participants in the book. A no-gap book and in-spread orders are the difference between a market that looks like a market and one that looks like a single participant moving a price, and anti-cheat logic is the layer that would recognise that pattern. None of that is in the free version.

A market maker fails through liquidation, and nothing here bounds that

The mechanism is worth stating plainly before any feature discussion, because it decides what to look for. The bot holds or spends real inventory and places real limit and real market orders on a real exchange account using your own funds. It is not a simulator and the page does not offer one.

For that reason the risk is not a failed order, it is a position. If the price leaves the band you configured, two things can happen and the page describes neither. The bot can stop quoting, and the liquidity you paid for vanishes exactly when a trader needs it, which is the failure a token issuer is trying to avoid. Or it keeps quoting into a trend it does not understand, and the inventory is sold on the way down and bought on the way up. With market orders in the feature list, that second path has no spread to protect it.

What the free feature list names as containment is a price range setting and four trading policies. What it does not name anywhere is a maximum position, a notional cap, a per-order size limit, a daily loss threshold, a stop, a dry run mode, or a documented way to halt a running process. `npm run clear` exists and it clears the database for a configuration, which is not a stop. Anyone pointing this at real inventory should assume the only available control is stopping the process, and should decide in advance what a gap looks like before one happens.

Six exchanges in the free tier, and an offer that expired a month ago

The free version names six exchange connectors: Azbit, P2PB2B, StakeCube, Coinstore, FameEX and NonKYC. Additional exchange connectors appear on the premium list, so which venues a project can use without paying depends entirely on where its token happens to be listed among those six. A token listed on a larger venue is a premium case, and the page is explicit that premium and custom exchange support is what covers other centralised exchanges.

There is also an onboarding offer, and it has a date on it. The page says a connector may be added for free or at a discount as part of an onboarding campaign, valid until September 1, 2026, with a contact instruction. The last push to the repository is dated 2026-09-28, which is nearly four weeks after that date lapsed, and the offer is still in the page. A reader arriving now is being invited to chase a deadline that has passed.

The pattern is consistent with a project whose marketing page and code move on different clocks. The release tags tell the same story from the other direction: v7.0.1 in September 2025, v8.0.0 on 2026-06-26 and v9.0.0 on 2026-07-02, with the default branch named `dev` and last pushed on 2026-09-28. The tagged line a self-hoster would pin is three months behind a development branch, and the offer that would have covered the gap has expired.

A CLI ships in the package and the page routes CLI users to a manager

The manifest exposes two binaries, `mm` and `adamant-tradebot`, both pointing at the same file, `bin/mm.js`. The container image makes it global by symlinking that file into the binary directory. So a command line interface is part of the distributed artefact in both install paths, not an optional extra.

The page then describes management differently. It lists the free management route as the project's messenger, described as secure command-based control with no public admin panel exposed, and then says that for additional management options, including Telegram, CLI and WebUI access, a manager has to be requested. So the same page that walks through npm scripts and a process manager invocation for launching the bot tells a reader that CLI access is something to ask for.

The most likely reading is that the messenger is the supported remote control and the CLI is the local launch path, with the sentence about additional options aimed at people who want to drive a running bot from a phone or a browser. Either way the wording does not distinguish the two, and a reader deciding whether they can script this thing locally has to guess. For a bot that acts on an exchange account, being unsure whether you are permitted to drive it from a shell is the wrong thing to be unsure about.

The container exposes a port and expects a database you supply

The image is small and reproducible in the usual way: it starts from a slim Node 22 Debian base, installs certificate authorities and nothing else, copies the manifest, the lockfile and the npm configuration before installing with development dependencies omitted, then copies the tree. It makes the entrypoint and both command line files executable, sets a production node environment, sets a flag marking that it is running in a container, exposes port 3000, and runs the entrypoint script with the application as its command.

Copying the npm configuration before the install is the detail that matters there, because that file changes how the dependency tree resolves. Omitting development dependencies in the same step means no build toolchain is present, which is consistent with a project that installs from prebuilt artifacts.

Two things are missing from the container and neither is surprising. There is no database in it, and MongoDB is a stated requirement, so a container deployment needs an external instance and a connection setting in the configuration file. And the page never says what listens on port 3000 in the free version. The manifest's file list includes a compose file under a docker directory, so a paired deployment exists, but the free tier's management story is command-based, and whether that port serves anything you should keep closed or bind elsewhere is not answered. Exposing a port from an image that holds exchange credentials is worth checking before the first run rather than after.

Configuration is two filenames and one argument

Configuration resolution is simple and worth copying into your own notes. The bot uses `config.jsonc` if that file exists and otherwise falls back to `config.default.jsonc`. A named configuration is `config.<name>.jsonc`, and the name is passed as a launch argument. Every parameter is described in comments inside the file, and the documented edit is to copy the default over the live file and open it in a text editor:

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

The bot is set up to run as a dedicated unprivileged account rather than as whoever cloned it.

The npm scripts mirror that scheme exactly: a plain start using whichever of the two files is present, a start with a config name passed through, a development start that is simply the name `dev`, and two database clear commands, one for the default configuration and one taking both a config name and a `clear_db` argument.

The process manager invocation works the same way, with the config name after a double dash so the process name and the configuration name can differ, which is how several configurations can run side by side on one machine.

That per-configuration separation is the real design point. One bot process per configuration, each with its own settings and its own database, is a clean way to run several venues or several risk profiles at once. It is also why a `clear_db` argument exists in the free version: the state each configuration accumulates can be deleted from the command line, so whatever trade history the bot keeps about itself is not something you are obliged to retain.

Requirements are narrow, and the codebase mixes JavaScript and TypeScript

The runtime requirements are stated as tested combinations: Ubuntu 20 or newer, or CentOS 8 or newer, with other distributions described as possibly working but untested. Node 22.2 or newer, npm 9 or newer, and MongoDB, linked to its own installation instructions. A Node version file at the repository root pins an engine version for the development environment, so the version you install with is recorded rather than guessed.

The codebase is mixed in a way that shows in the root listing. The application entry point is a JavaScript file, there is a Babel configuration, there are two TypeScript configurations including one scoped to a specific web interface API, and there is a Jest configuration with its own setup file. The test scripts split into a general scope and an API and web interface scope, both selected by an environment variable, with a wrapper script as the entry point. Linting runs through ESLint with a flat config, and there are separate configuration files for markdown linting and for a spell checker.

Nothing here is unusual for a project of this size and age, and the two-scope test split suggests the HTTP surface is covered separately from the trading core, which is the right place to put the boundary. What the tooling does not show is any test of order placement behaviour against an exchange, and given that the premium tier is where the anti-cheat logic lives, that is the layer a self-hoster ends up owning.

Editorial conclusion

The architecture is the right one for this problem, because the argument for self-hosting a market maker is precisely that you keep custody of the keys and the inventory. Read the free tier as what it is, though: order placement with a price band, on six named exchanges, with nothing in the documented feature list that bounds your loss or stops the bot. Before running this against real funds, settle three things. Read the manifest, because a licence field reading UNLICENSED and a page describing the software as open source cannot both be right, and there is no licence file in the repository root to arbitrate. Decide what you are accepting in the free tier, where the anti-cheat and cleaner logic that shapes what other traders and an exchange's surveillance see is a paid item. And test on a venue you can afford to be wrong on, since a market-making bot with real market orders fails through liquidation rather than through an error message.

Frequently asked questions

Official sources

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