metaboss: a command line tool for minting and reading Solana NFTs

What it covers, and the two standards it straddles

Metaboss is a command-line tool for managing Solana NFTs and tokens via the Metaplex standard. The listed operations are mint, update, transfer, burn, verify, decode, snapshot and airdrop, and the last line of that sentence is the important one: it works for both legacy Token Metadata and Metaplex Core assets.

That dual support is the defining characteristic of the project. Token Metadata is the established format that the original Metaplex tooling produced, and Metaplex Core is the newer asset model built around a different set of programs. Any tool that touches Solana NFTs has to deal with both, because collections in the wild are split between them, and a tool that handles only one leaves you maintaining two toolchains.

The description in the repository is The Metaplex NFT-standard Swiss Army Knife tool, and the package metadata calls it a description of the same idea, with a version of 0.49.0 and the edition set to 2021.

There is a warning attached to all of it, and it is the right warning to read first. Use at your own risk. Always test commands on devnet before running against production NFTs. Minting and burning are irreversible on a chain, and an NFT with a mistake in its metadata is not a support ticket, it is a permanent record.

The documentation is at metaboss.dev, and the README closes with Suggestions and PRs welcome. The author is Samuel van der Waal, and the contact details are an email, a Twitter account and a Discord handle.

Installing it: a shell script, a release binary, or cargo

There are four install routes, and the fastest one is also the one that deserves the most thought.

The primary route pipes a script straight into your shell:

bash <(curl -sSf https://raw.githubusercontent.com/samuelvanderwaal/metaboss/main/scripts/install.sh)

The convenience is real, and so is the caveat. This fetches a script from a branch of a repository and executes it immediately, which means you are trusting whatever is at that URL at that moment rather than a pinned release. The script lives in the scripts/ directory of the repository, so it is at least visible before you run it, and for a tool that signs transactions that is the difference between a bad day and a very bad day.

If the install produces errors, the README names the dependencies needed on Ubuntu:

sudo apt install libudev-dev pkg-config

The libudev part is the giveaway that this tool talks to a hardware wallet. A CLI that can move NFTs and has a udev dependency is one that supports signing with a physical device, which is the right design for irreversible operations.

The other two routes avoid the script entirely. Linux and macOS binaries are available in the releases, and for a Rust tool the crates.io route is a single command:

cargo install metaboss

Building from source requires Rust 1.75 or later, and the README gives the rustup install line, the clone over SSH or over HTTPS, and then either cargo install --path ./ or cargo build --release.

So there is a pinned option available at every level, binary, crate or source, and the curl-pipe route is the one that trades safety for convenience.

The dependency list, and what it says about the two standards

The Cargo.toml is where the two standards are visible side by side, and it is worth reading the two clusters rather than the whole list.

The Solana side is pinned hard. solana-client, solana-account-decoder, solana-logger and solana-sdk are all at =2.3.1, solana-program at =2.3.0 and solana-sdk-ids at =2.2.1. The exact pins mean the Solana SDK version is fixed rather than floating, which for a tool that constructs and submits transactions is a deliberate choice.

The SPL token crates are pinned to major lines with the tilde operator. spl-associated-token-account is at ~7.0, spl-token and spl-token-2022 at ~8.0, spl-pod at ~0.5.1, and the two metadata interface crates, spl-token-metadata-interface at ~0.7 and spl-token-group-interface at ~0.6. The split between spl-token and spl-token-2022 is the two token programme generations, and the two interface crates are the shared interfaces a collection is expected to honour.

And then the two Metaplex crates, which is the point. mpl-token-metadata is at 5.1.1 with the serde feature, and mpl-core is at 0.11.1. The first is the legacy Token Metadata library and the second is the Core one, and the version numbers say something useful on their own: the legacy library is on a 5.x line and the Core one is on 0.x.

The rest of the list is the usual CLI and async furniture. tokio 1.35.1 for the runtime, reqwest with the json feature, default features off, rustls-tls-webpki-roots and blocking, which is an interesting combination since it means the HTTP client is rustls based with webpki roots rather than the platform certificate store, and it is built with a blocking feature. indicatif with the rayon feature for progress bars, ratelimit 0.4.4 and retry 1.3.1 for pacing and retries, rayon and num_cpus for parallelism, and structopt for the argument parsing, which is the older clap 2 wrapper.

There is also a separate metaboss_lib crate at 0.24.0, and the fact that the CLI depends on a published library version of its own core is a sign of a deliberate split between the reusable logic and the command line surface.

The justfile, and a test layout that mirrors the commands

The repository uses just rather than make, and the justfile is short enough to read in full, which tells you how the project expects to be worked on.

The default recipe lists the available commands. There is test, which runs the unit tests with cargo test --lib. There is integration-tests, which runs a specific list of integration test binaries and is annotated as requiring solana-test-validator. There is fmt, clippy with warnings denied, build, and check for a fast compilation check including test code.

The integration test command is the interesting one, because the test file names are the command names:

cargo test --test integration_tests --test collection_tests --test create_mint_tests --test decode_tests --test set_tests --test update_tests --test verify_tests -- --ignored --test-threads=1

So there is a test binary for collections, one for creating a mint, one for decoding, one for setting, one for updating and one for verifying, alongside a general integration_tests binary. The --ignored flag and the --test-threads=1 constraint tell you the shape of these tests, because they are marked ignored by default and they have to run one at a time.

That combination means the integration tests need a real validator, they are slow enough to be excluded from the default run, and they are not safe to run in parallel, which is exactly what you would expect from tests that start a local chain and submit transactions to it. A test that talks to a shared validator cannot run concurrently with another test doing the same thing.

The ci recipe is the subset that runs on every push: a format check across the workspace, clippy with warnings denied, and the unit tests. The integration suite is separate and slower, which is the usual split for a project with a real chain dependency in its test path.

The rest of the repository, and how the tool documents itself

The top level of the repository is small and tells you what the project considers its own artefacts.

There is a src/ directory for the crate, tests/ for the test suites, a scripts/ directory holding the install script, and a docs/ directory alongside a docs-src/ directory, which is the usual split for generated documentation with its source. There is a justfile for the tasks, a Cargo.lock for reproducible builds, a LICENSE file for the Apache-2.0 licence, and the release machinery, with RELEASE_NOTES.md and an ORCHESTRATOR.md.

ORCHESTRATOR.md is a file worth knowing about. Its name suggests it describes how a piece of the work is divided up across contributors, which is a reasonable convention for a project that is large enough to need it, and the CHANGELOG-equivalent RELEASE_NOTES.md at the root suggests the project keeps a human-readable record of what changed in each release rather than relying on git tags alone.

The release history backs that up. v0.49.0 was published on 2026-04-23, v0.48.0 on 2026-04-14 and v0.47.0 on 2026-03-24, so three releases in a two-month window, with the version number tracking the crate rather than the library dependency, since the crate version and the metaboss_lib version in the dependencies move independently.

The last push to the repository was on 2026-05-21 and the repository is not archived. The crates.io badges show the published version and the download count, and the build status badge points at a CI workflow, which is the same CI the justfile's ci recipe describes.

So the pattern is a CLI whose logic lives in a published library, whose tests need a local validator, and whose releases are frequent enough that the release notes are worth reading before you upgrade.

Editorial conclusion

Adopt metaboss if you work with Metaplex assets from a terminal, since a single command that handles both the legacy Token Metadata and the newer Core standard saves you from maintaining two sets of scripts. Do not adopt it as a library for a service, because the surface is a command line interface and the npm, Rust and Metaplex Core split in the dependencies means the two asset models are not fully unified under one abstraction. Before you run anything against real assets, read the warning about testing on devnet, and check which standard your collection actually uses before you pick a subcommand.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. samuelvanderwaal/metaboss on GitHub