chainbase-labs/manuscript-core: a Rust streaming framework for on-chain and off-chain data

What Manuscript actually solves, and for whom

The README frames Manuscript as a bridge inside the Chainbase ecosystem: "If we compare Chainbase's global data network to a country, then Manuscript would be the language of this data network nation." The concrete problem is moving blockchain data out of Chainbase and into somewhere you can query it. That includes raw chain data, decoded contract events, token metadata and token prices, judging by the example directories: examples/02_contract_evt_decode/, examples/06_token_prices_with_AI/ and examples/07_token_metas_to_postgres/. The audience is developers building data pipelines on Chainbase rather than general-purpose ETL teams. The README's stated ambition is wider than that. It lists any language (Golang, Rust, Python, Node.js, Java, C/C++, Zig, WASM), any method (SQL, DataFrames, HTTPS, gRPC, FTP, WebDAV, FUSE), any data format (JSON, CSV, ORC, XML, XLSX, BLOB) and any service (RPC, S3, IPFS, Azblob, HDFS, Google Drive, BigQuery, WebDAV, MySQL, PostgreSQL). Those are goals, not a shipped feature matrix, and the README does not map each item to an implemented component. Treat the list as direction of travel.

New Solana parser and the Rust core behind the CLI

The repository is mostly Rust, with a Go CLI and a separate GUI. The Makefile builds two binaries, manuscript-cli from cli/ and manuscript-gui from gui/target/release/, and injects git commit, build date, Go version and Rust version into the CLI through Go linker flags. That tells you the CLI is a thin Go wrapper around a Rust engine, not the engine itself. The runtime pieces live in flink/, decoders/ and common/, with manuscripts/ holding the job definitions and examples/ holding runnable starting points. Version 1.5.0 added a Solana on-chain parser, which the README calls "the latest feature", and the release history shows v1.5.1, v1.5.2 and v1.5.3 following it through late 2025. The last push to the default branch was on 2026-08-09, so the project is not archived and is not dormant, but the release cadence stops at v1.5.3 in December 2025.

Installing the Manuscript CLI and running a first job

The README lists one requirement: Docker Desktop 25.1 or later. Both the CLI and the GUI install through a shell script fetched from the repository. The CLI script is the one to use if you want to script jobs.

curl -fsSL  https://github.com/chainbase-labs/manuscript-core/raw/main/install.sh | bash

After that, manuscript-cli should be on your PATH. Running it with no arguments prints the command list, which the README shows as init, list, logs, stop and deploy. The prose in that help output describes deploy as "Deploy Manuscript to a local environment or the Chainbase net", so the same command targets both.

manuscript-cli --help

A first run starts with init, which the help text describes as "Initialize and start local manuscript containers". That is where Docker comes in: the CLI is orchestrating containers rather than running the pipeline in-process.

manuscript-cli init

From there the workflow is deploy a job, then list it, then read its logs. The README's GUI walkthrough splits the same flow into selecting data and creating local tasks, then waiting for the task to run and using the data. The examples/README.md is the place to look for job definitions, since the top-level README does not show one.

The Docker dependency is a real constraint, not a footnote

Requiring Docker Desktop 25.1+ rules out a large class of environments. A Kubernetes cluster running containers directly, a serverless function, a CI runner with no daemon, or a locked-down machine where you cannot install Docker Desktop: none of those can run manuscript-cli as documented. The GUI has the same requirement. If your pipeline needs to run as a single static binary, Manuscript's architecture works against you, because the CLI's job is to start and manage containers. The README also does not document rollback. There is a stop command for a job and a logs command, but nothing in the README covers what happens to partially written data when a streaming job fails midway, whether jobs resume from a checkpoint, or how to undo a deploy. For a streaming framework that writes into Postgres and files, those are the questions that decide whether it is safe in production, and the README is silent on all of them. Anyone evaluating Manuscript should treat failure recovery as unverified until they find it in the docs at docs.chainbase.com or in the source.

Manuscript versus writing your own indexer

The obvious alternative is a purpose-built indexer such as a Subgraph, or a general stream processor like Apache Flink wired directly to an RPC endpoint. The difference is where the data comes from. A self-hosted indexer reads from an RPC node you control and you own the whole path from block to table. Manuscript reads from the Chainbase network and gives you a declarative job plus a CLI to schedule it. That is less work if you are already a Chainbase customer and more lock-in if you are not. The flink/ directory in the repository is worth noting here: Manuscript appears to build on Flink rather than replace it, so if you already run Flink, the comparison is between Manuscript's job format and your own Flink jobs, not between two unrelated systems. The README's monetization section describes a Chainbase-side data marketplace where "Creators can monetize their processed data through Manuscript", which is a Chainbase ecosystem feature rather than something the open source repository provides on its own.

Licence, upgrades and what maintenance costs you

The repository is Apache-2.0. That permits commercial use, modification and redistribution, and it includes an explicit patent grant, which matters for a project that touches blockchain infrastructure. It also means you can vendor the code if you need to. The practical caveat is scope: the licence covers the code in this repository, not the Chainbase network it talks to, and the README does not state which parts of the system (the network, the data marketplace, hosted decoding) are open source and which are a paid service. Check that boundary before you assume a deployment is fully self-contained. On upgrades, the release history shows three patch releases between September and December 2025, so the project does ship fixes. The Makefile pins a VERSION variable and validates it against an X.Y.Z pattern, and injects build metadata into the CLI, so a built binary can tell you exactly which commit and toolchain produced it. That is a small but genuine operational affordance.

Editorial conclusion

Manuscript is the right tool if you already work inside the Chainbase network and want the CLI and GUI to move on-chain data into Postgres, files or other stores without writing your own pipeline. It is the wrong tool if your data does not come from Chainbase, if you need a documented rollback story, or if you want to read the source of the runtime you depend on. Before adopting it, verify the install script's contents, the actual state of cli/ and flink/, and whether the Apache-2.0 licence covers the decoders and examples you plan to ship.

Frequently asked questions

Official sources

1. chainbase-labs/manuscript-core on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases