A signing key in a dotenv file, and no dry run

A signing key in a dotenv file

The example configuration contains the most important paragraph in the repository, and it is a warning rather than a description.

A private key variable is required for swap and order commands. The comment above it is marked as a security warning and makes four points: the key signs requests to the vendor's API, it is not a blockchain wallet key, if it is compromised an attacker can forge authenticated API calls on your behalf, and it must never be committed. It also tells you to restrict the file's permissions.

chmod 600 ~/.config/gmgn/.env

The value is the full contents of a PEM block, and the file offers two formats: a single line with escaped newlines, or a multiline value wrapped in double quotes. The second example is written with every line commented out, so copied literally it produces nothing.

The author is right about the risk. What is missing is any statement of where the key is generated, whether it can be rotated, or whether the vendor can revoke it.

There is no dry run in any of the documentation

The order documentation is entirely about execution, and it is specific about speed.

The README claims the same request routing as the vendor's own web trading interface, multi-region deployment, and order submission under three tenths of a second end to end. It lists market orders, limit orders, and take-profit and stop-loss orders as strategy orders attached to a swap, plus trailing variants that track a price peak and fire after a drawdown, plus multi-wallet batch trading where several wallets each carry their own four order types.

What is absent across every page is as informative as what is present. There is no simulation mode, no test network, no fee or slippage guidance, no discussion of what happens when a provider rejects an order, and no mention of position sizing.

Trailing stops and take-profit orders are risk controls, not risk elimination, and a stop order on a thin token can fill far from its trigger. Anything you decide to automate here should be capped at a loss you have already accepted.

One package serves the CLI and four agent ecosystems

The published npm package is not a library. Its manifest describes a command line client, registers one binary, and lists four directories as its published contents: the compiled output, the skills folder, and the plugin manifests for two agent tools.

"files": [
    "dist",
    "skills",
    ".claude-plugin",
    ".cursor-plugin"
]

The repository goes further than that, carrying configuration directories for two more agent tools at the top level alongside a general agent instruction file.

So the same skill definitions are distributed into at least four agent ecosystems from one tarball, and each skill is a markdown file in its own folder under the skills directory. The README table lists them by slash command, from a general token skill through market, portfolio and wallet analysis to a due-diligence skill that returns a single zero-to-one-hundred verdict for one contract address.

One thing worth checking in your own checkout: the project summary names Python as its main language, while the manifest builds with a TypeScript compiler and ships a Node binary.

Configuration runs from the user directory down to the project

Credentials can live in two places, and the example file explains the precedence.

A file in the user's configuration directory works from any working directory, and a project-level file in the repository overrides it. The API key is described as required, obtained from the vendor's hosted page.

That ordering is the right default for a tool you run from wherever, but it has one sharp edge: the project-level file is the one people accidentally commit, and the example file exists precisely to be copied into the project root.

The signing key warning tells you to keep it out of version control and to restrict its permissions, and the repository does contain an ignore entry. What is not stated anywhere is whether a key in a project file takes precedence for order commands when a user-level key also exists, which is the case where a stale credential silently does nothing.

The analytics fields are named for what they detect

The token analytics section lists fields by their exact names, and the names are the documentation.

A counter for smart-money wallets. A field for holders considered influential. A ratio for volume attributed to insider or stealth wallets. A ratio for volume from bundled bot buys. A count of sniper wallets, defined as wallets that bought at the exact moment of launch. A suspected-insider hold rate. A fresh-wallet ratio. A rug score between zero and one, alongside a honeypot check and a wash-trading flag. And a bonding-curve flag that says whether a token has graduated to an open exchange.

These are vendor-computed indicators, not facts about a token, and the distinction matters more here than in most analytics: every one of them is derived from wallet behaviour that participants can deliberately mimic. A bundle of freshly created wallets buying at launch is exactly the pattern the bundler ratio is looking for, and it is also the cheapest pattern to reproduce.

Minimum one-minute granularity, and no snapshot cache

The data section is built around one constraint: nothing is cached.

Every query is described as live, with no snapshot cache, across four chains. Rankings come in windows from one minute up to a day, and the finest candle is one minute, with that one-minute floor stated twice.

For an agent driving decisions at a speed the README advertises, a one-minute floor is a real design constraint rather than an implementation detail. A token can move several percent inside a single candle, and the fields that matter most, insider and bundler ratios, are computed over volume windows that are larger still.

The README also claims more than five hundred data dimensions, which is a count of fields rather than a description of how they interact. Nothing in the visible documentation says which of them are reliable at which liquidity level.

Attested publishing beside a proxy-capable client

Two details in the manifest are worth noticing for opposite reasons.

The first is a publish script that enables npm provenance, the mechanism that publishes a signed attestation about where a package was built and from which source. For a package that carries trading skills and asks users to store a signing key, attested publishing is the right baseline, and its presence suggests the author takes supply-chain questions seriously.

The second is the dependency list. Four runtime packages: a command line parser, a dotenv loader, an HTTP client, and a SOCKS proxy library. That last one means the client can route its API traffic through a proxy, which is unremarkable for a tool with an international user base and worth knowing about if you are reasoning about where your requests go.

Node 18 is the floor, the licence is MIT, and the licence covers the client and the skill files, not the vendor's data or your keys.

Editorial conclusion

Read the risk section before the feature list, because this is a tool that moves money and the documentation leads with speed rather than with safety. Two things to settle before you run anything: where the signing key will live and who can read it, and whether your own workflow has a simulation step, since the repository describes none. If you use it, cap position sizes at the level you can afford to lose outright rather than relying on the take-profit and stop-loss orders the documentation covers.

Frequently asked questions

Official sources

1. GMGNAI/gmgn-skills on GitHub
2. Issues
3. License: MIT
4. Project website
5. README