# ADAMANT Console: a command line client for a chat-first blockchain

> adamant-console is a Node.js command line and JSON-RPC tool for the ADAMANT blockchain that signs ADM transactions locally so passphrases never travel to a node, with an interactive prompt, one-shot commands and an RPC server for other languages. It suits developers and power users who need scriptable access to a messaging-oriented chain, and its node availability is outside the operator's control.

**Adamant-im/adamant-console** — Command-line and JSON-RPC tool for interacting with the ADAMANT blockchain

- Repository: https://github.com/Adamant-im/adamant-console
- Website: https://console.docs.adamant.im
- Stars: 517 · Forks: 10
- Language: JavaScript
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/adamant-im-adamant-console

## What the tool is, and what it deliberately keeps local

adamant-console is a command-line and JSON-RPC tool for interacting with the ADAMANT blockchain. The README describes what it does in one sentence: it signs ADM transactions locally and submits signed payloads to configured ADAMANT nodes.

That local signing is the whole point, and the README states the consequence directly. Passphrases never need to be sent to a node, and the instruction is to keep passphrases, private keys, decrypted messages and local config files out of logs and shared terminals.

The features list makes the scope concrete. There is an interactive `adm` prompt for common account, node, send, get, delegate and vote commands. There are one-shot CLI commands for scripts and operations. There is a JSON-RPC server for integration from other languages and services. And there is local ADM account generation, signing, voting, token transfers and encrypted messages. The node lists and the RPC port are configurable, and the project shares ADAMANT Node API v0.10.0 behavior through the `adamant-api` client library.

That last point is the architecture. ADAMANT Console is a command and RPC surface over `adamant-api`, not a reimplementation of the protocol. The top level of the repository shows the same shape: a `bin/` directory for the entry point, a `lib/` directory holding the API, a `prompt/` directory for the interactive prompt, a `utils/` directory, a `test/` directory, and a `docs/` directory. The `package.json` points `main` at `lib/api/index.js` and declares the binary as `adm` pointing at `./bin/adamant.js`, and the package is an ES module.

The primary language is JavaScript, the default branch is `dev`, and the homepage is console.docs.adamant.im.

## Configuration: a JSONC file that defaults to testnet

The configuration is created from a bundled default, and the command is short:

```sh
node bin/adamant.js init
```

By default the file is created as `~/.adm/config.jsonc`, and the README also allows a `config.jsonc` in the current working directory for local overrides. The format is JSONC, so comments are allowed, which is the same approach the `config.default.jsonc` file at the top of the tree takes.

The fields that matter are listed in a table. The `passphrase` is the default ADM account passphrase used for signing. The `network` is `mainnet` or `testnet`. `networks.<network>.nodes` holds the ADAMANT nodes used by `adamant-api`, and `rpc.port` is the JSON-RPC HTTP server port.

The default network is `testnet`, and the README is emphatic about the consequence: update `network` to `mainnet` only when you intend to use real ADM funds. That default is the right choice for a tool whose most likely first use is experimentation, but it means a user who assumes the tool is pointed at the real network is wrong until they change a file.

Node lists are a maintenance item as well. When updating ADM node lists, the README says to use the canonical metadata in the `adamant-wallets` repository's `info.json` file, which is where the ADAMANT project keeps its node registry.

The security notes add the operational rules: passphrases are used locally to derive keys and sign transactions, private keys, passphrases and decrypted message content must not be logged or transmitted, `config.jsonc` is user-local and must not be committed, node responses can fail or be stale so the `success` and error fields should be checked before trusting data, and POST retries and signing behaviour are owned by `adamant-api` rather than by this tool.

## The one-shot command surface

The CLI examples in the README are the fastest way to understand what the tool does, and they cover the read paths and the write paths in a single block.

The node commands are `node height`, `node version` and `node status`. The account commands are `account new` and `get address U123456789`. The get commands extend to transactions, with `get transaction 123456789` and the variant `get transaction 123456789 returnUnconfirmed=1`, to delegates, to chats with `get chats U123456789 includeDirectTransfers=1`, and to a single chat with `get chat U123456789 U987654321 returnUnconfirmed=1`.

The write commands are `send tokens U123456789 110020030` in the smallest unit, `send tokens U123456789 1.1ADM` with a decimal amount, and `send message U123456789 "hello"`. Voting is `vote for +delegatePublicKey`.

Two conventions are worth noticing. Query parameters are passed as bare key=value pairs after the positional arguments, not as flags, so `returnUnconfirmed=1` and `includeDirectTransfers=1` are appended to the command. And the token amount is accepted in both the base unit and a decimal ADM form, which saves a lookup for anyone who has to convert.

The npm package exposes the same commands as the `adm` binary, and the passphrase can be overridden for a single invocation:

```sh
adm --passphrase "your local passphrase" send tokens U123456789 1
```

The README immediately qualifies that: avoid shell history exposure when using passphrase flags in shared environments. A passphrase on a command line lands in the shell history file and in the process list, which is a real leak on a shared machine even though the passphrase never goes to a node.

There is also a startup health check. Interactive mode checks configured node health before the first command, so users can see node availability early, while one-shot commands skip this startup check. To disable it explicitly, set `ADM_CHECK_HEALTH_AT_STARTUP=0` in the environment before running the binary.

## The JSON-RPC server mirrors the existing Console API

For anyone integrating from another language, the RPC server is the interesting surface. It is started with:

```sh
node bin/adamant.js rpc server
```

The server listens on `config.rpc.port` and exposes methods that match the existing Console API surface. The README lists them: `clientVersion`, `accountNew`, `delegateNew`, `getAddress`, `getBlock`, `getBlocks`, `getChats`, `getChatMessages`, `getChatTransactions`, `getDelegate`, `getMessage`, `getTransaction`, `getTransactions`, `getTransactionsInBlockById`, `getTransactionsInBlockByHeight`, `getTransactionsReceivedByAddress`, `nodeHeight`, `nodeStatus`, `nodeVersion`, `sendTokens`, `sendMessage`, `sendRich`, `sendSignal` and `voteFor`.

The naming is the point. A method called `getTransactionsInBlockByHeight` and one called `getTransactionsInBlockById` are distinct operations, and the set covers the read surface a wallet or an explorer would need, plus the write surface for transfers, messages, signals and votes.

The README also documents a calling convention that will trip up a first-time implementer: array-style methods accept JSON-RPC `params` as an array, while template-style send and vote methods accept named object parameters. So the same server takes two different shapes of `params` depending on the method, which is a compatibility decision inherited from the original Console API rather than a fresh design.

For JavaScript specifically, the README steers you away from the RPC server and towards the library underneath. Console is built on `adamant-api`, and you should use that directly for programmatic JavaScript access, lower-level protocol features, typed DTOs, metadata, WebSocket subscriptions and advanced transaction handling. The Console wrappers exist to preserve compatibility, and the README says which fields they preserve: Node v0.10.0 response fields including numeric `count`, transaction `timestampMs`, and the unconfirmed transaction fields returned with `returnUnconfirmed=1`. Chat query helpers send `includeDirectTransfers`, and the deprecated `withoutDirectTransfers` input is accepted only as a compatibility alias and normalised before calling `adamant-api`.

## Development tooling and a deliberately small project

The development section is short, and the project says what it wants to be. This project intentionally stays small. Prefer focused changes over framework migrations, and keep CLI command names, JSON-RPC method names, config fields, and library exports stable unless a task explicitly approves a breaking change.

That is a stability policy rather than a technical constraint, and it is worth noting that it is a policy about API surface, which for a wallet client is the part users depend on. A rename of `sendTokens` or a change to the `rpc.port` field would break scripts that other people wrote, and the project is saying it will not do that without an explicit decision.

The development commands are:

```sh
npm ci --ignore-scripts
npm run lint
npm run format:check
npm test
```

The `--ignore-scripts` flag on the install is a detail worth pausing on, since it means the local development install does not run any package lifecycle scripts.

The script table covers the rest. `npm run lint` checks JavaScript with the ESLint flat config, `npm run lint:fix` applies safe ESLint fixes, `npm run format` formats repository files with Prettier and `npm run format:check` checks the formatting, `npm test` runs Node.js test discovery, and there are four documentation scripts: `npm run docs:api` generates the Console API reference, `npm run docs:dev` generates the API docs and runs VitePress locally, `npm run docs:build` generates the API docs and builds the docs site, and `npm run docs:preview` previews the built docs site after a build.

The tooling stack in the dev dependencies matches: ESLint 10 with the flat config and `eslint-config-prettier`, Prettier 3.9.1, and TypeDoc with a markdown plugin and a VitePress theme for the documentation site. The `typedoc.json` and `tsconfig.docs.json` files at the top level are the documentation build configuration, and there is an `AGENTS.md` in the tree for coding assistants.

## Where ADAMANT Console is the wrong choice

The first wrong-tool case is anything needing a general purpose wallet. This is a command line client for one specific chain, with the commands the ADAMANT Node API exposes. If you need a multi-chain wallet, an exchange interface, or hardware key support, this is not it, and the npm package with the `adm` binary is a tool for one network.

The second is a service with an availability requirement. The node list is configuration, and the README's own warning is that node responses can fail or be stale, so you should check the `success` and error fields before trusting data. The startup health check in interactive mode exists to surface node availability early, which is evidence that availability is not guaranteed. A production service that needs a dependable upstream has to handle node failure itself.

The third is a caller that needs typed, low-level protocol access. The README is explicit that `adamant-api` is what you want for lower-level protocol features, typed DTOs, metadata and WebSocket subscriptions, and the Console layer deliberately does not expose those. Reaching through the RPC server to get at them is possible but is the wrong shape of solution.

The fourth is a platform that cannot run modern Node. The package requires Node.js 22.13.0 or newer and npm 10 or newer, which is a high floor for a tool people might want to run on an old server or a small embedded box.

The alternative worth naming is writing directly against `adamant-api` in JavaScript, which the README itself points to for programmatic access. The difference in approach is that Console adds the command surface, the interactive prompt, the local config with a passphrase, the JSON-RPC server for other languages, and a compatibility layer that preserves the older response fields, while `adamant-api` gives you the protocol client and nothing else. If your work is a script, the library is the smaller dependency. If your work is an operator at a terminal or another language, the Console is the one that ships the prompt.

## Maintenance state, licensing and what to check

The repository is not archived, and the last push to the default branch was on 2026-10-16. The recent releases are v3.1.0 on 2026-06-29, v3.0.0 on 2024-06-19 and v2.3.0 on 2024-03-29.

So the release pattern has a gap and then a gap, with a major version in 2024 and a minor in 2026, and a branch named `dev` that has been pushed to more recently than the last tag. That is the shape of a project where the `dev` branch carries work that has not been cut as a release yet.

On the licence there is an inconsistency worth flagging, because the two sources disagree. The project listing records the licence as unknown, while the `package.json` records `GPL-3.0` and the authors as the ADAMANT community developers, the ADAMANT Foundation and ADAMANT Tech Labs. No `LICENSE` file is visible in the repository tree, so the `GPL-3.0` identifier in `package.json` is the best available signal of the published terms. This is a description of the published terms and not legal advice.

The homepage is console.docs.adamant.im, and the README says the full Console documentation is published there, with links out to the ADAMANT website, the main documentation, the ADAMANT Improvement Proposals, the ADAMANT Node implementation and the ADAMANT API schema.

For an adopter the checks are short. Confirm Node 22.13.0 or newer and npm 10, run `npm ci`, create the config with `node bin/adamant.js init`, and check the `network` field before you do anything with funds, because the default is testnet and the README is explicit that mainnet should be set only when real ADM is intended. Then confirm that the `config.jsonc` file is excluded from version control, since the security notes say it is user-local and must not be committed, and that a passphrase is not being passed on a command line in a shared environment.

## Conclusion

Adopt ADAMANT Console when you need scriptable or interactive access to the ADAMANT chain and you want transaction signing to happen on your own machine rather than on a remote node, since that is the design the whole project is built around. Do not adopt it as a general wallet, as an exchange interface, or as the basis for a service that needs guaranteed node availability, because the node list is a configuration item you maintain and the network can be unreachable. Before you start, decide on mainnet or testnet deliberately, because the default is testnet and the README says to change it only when you intend to use real ADM funds, and treat the passphrase handling rules as binding, since the config file and the credentials in it must never be committed or logged.

## FAQ

### What is ADAMANT Console and what does it do?

It is a command-line and JSON-RPC tool for interacting with the ADAMANT blockchain that signs ADM transactions locally and submits signed payloads to configured ADAMANT nodes. It offers an interactive `adm` prompt, one-shot commands for scripts, a JSON-RPC server for integration from other languages, and local account generation, signing, voting, token transfers and encrypted messages.

### How do I install and configure ADAMANT Console?

You need Node.js 22.13.0 or newer and npm 10 or newer, then run `npm ci` to install dependencies. Create the config with `node bin/adamant.js init`, which writes `~/.adm/config.jsonc` by default, and set the `passphrase`, `network`, `networks.<network>.nodes` and `rpc.port` fields. The default network is testnet, and the README says to change it to mainnet only when you intend to use real ADM funds.

### How does ADAMANT Console keep my passphrase safe?

Passphrases are used locally to derive keys and sign transactions, so they never need to be sent to a node. The security notes add that private keys, passphrases and decrypted message content must not be logged or transmitted, that `config.jsonc` is user-local and must not be committed, and that a passphrase passed as a CLI flag risks shell history exposure in shared environments.

### How do I use the ADAMANT Console JSON-RPC server?

Start it with `node bin/adamant.js rpc server`, and it listens on the port set by `config.rpc.port`. It exposes methods matching the existing Console API surface, including `clientVersion`, `accountNew`, `getAddress`, `getTransaction`, `sendTokens`, `sendMessage` and `voteFor`. Array-style methods take JSON-RPC `params` as an array while template-style send and vote methods take named object parameters.

### Should I use ADAMANT Console or adamant-api directly?

The README says to use `adamant-api` directly for programmatic JavaScript access, lower-level protocol features, typed DTOs, metadata, WebSocket subscriptions and advanced transaction handling. Console is the layer for the interactive prompt, one-shot commands and the JSON-RPC server for other languages, and its wrappers preserve the older Node response fields for compatibility.

## Sources

- [Adamant-im/adamant-console on GitHub](https://github.com/Adamant-im/adamant-console)
- [Issues](https://github.com/Adamant-im/adamant-console/issues)
- [Project website](https://console.docs.adamant.im)
- [README](https://github.com/Adamant-im/adamant-console/blob/dev/README.md)
- [Releases](https://github.com/Adamant-im/adamant-console/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/adamant-im-adamant-console