QuipNetwork/quip-validator: a Substrate solochain node for quantum mining

What the Quip Network node actually is, and who it is for

This repository ships one binary, quip-network-node. It is a solochain: a single chain that does not rely on a relay chain for consensus, built on the Substrate framework and forked from the Polkadot SDK solochain template. The workspace members make the intent explicit: alongside the usual node and runtime crates there are pallets for quantum-pow, quantum-compute-mempool, miner-registry, faucet-ops, evm-chain-id and xqvm, plus crates named quantum-validation and transaction-crypto. That is a chain whose block production is tied to quantum mining work rather than to a plain balance-transfer testnet.

The audience is correspondingly narrow. You need Rust toolchain skills, a machine that can compile a Substrate runtime, and an interest in mining or validating rather than in deploying contracts. If you are looking for a hosted API or a managed node, nothing in the repository provides one. The README points at the Substrate install instructions for platform dependencies and offers Docker as an alternative path, which tells you the expected operator already knows how to run a node process and manage its database directory.

How the chain is assembled: pallets, consensus keys and chain specs

The architecture is the standard Substrate split. The node crate handles networking over libp2p, the RPC server, and consensus; the runtime crate defines state transition logic and is compiled to WebAssembly. Quip uses hybrid BABE and GRANDPA consensus, so block production and finality use separate key types. The README is explicit that operators must re-insert the H4 BABE and H2 GRANDPA keys, which means key material is not something the node derives for you on first start.

Chain selection is done entirely through the --chain flag, and the README supplies a table. Omitting the flag is not an error: it selects quip-testnet, the live public testnet with EIP-155 chain ID 20033. Aliases quip_testnet and testnet resolve to the same preset. --chain=local is a two-validator Alice and Bob chain, --chain=local3 is a three-validator Alice, Bob and Charlie chain, and --dev is Alice-only. All three local presets use EIP-155 chain ID 1337. A path argument instead of a preset name loads a JSON chain spec and uses the chain ID in its genesis.

The docker-compose.yml file documents a networking constraint that is worth reading before you write your own compose file. litep2p, the network backend, enumerates every local IPv4 interface when binding to a wildcard address, including 127.0.0.1, and only IPv6 link-local fe80:: addresses are filtered. Identify then advertises that set, and peers dial /ip4/127.0.0.1/tcp/30333 inside their own network namespace and reach themselves, failing the Noise handshake with error=Decrypt. The compose file's answer is a static container IP per node and --listen-addr=/ip4/172.30.0.10/tcp/30333, with --no-mdns kept as defense in depth. The comment also states that --public-addr does not fix this because it is additive to discovered addresses rather than exclusive.

Building the node and joining the public testnet

The README's getting-started section tells you to fetch the solochain template code, which is the upstream template repository rather than the Quip repository itself. If you want the Quip pallets, clone the Quip repository instead; the build command is the same.

git clone https://github.com/paritytech/polkadot-sdk-solochain-template.git solochain-template
cd solochain-template
cargo build --release

After the release build finishes, the binary lands under target/release. To join the live public testnet, run the node with no --chain flag at all. The README states this defaults to quip-testnet on EIP-155 20033.

./target/release/quip-network-node

You should see the node start, open its database, and begin syncing from the new genesis. The README gives a separate command for exploring the binary's parameters and subcommands, and a cargo doc invocation for the generated Rust documentation.

./target/release/solochain-template-node -h
cargo +nightly doc --open

For a disposable chain that does not persist state, pass --dev. The README notes this is Alice-only, uses EIP-155 1337, keeps state in a tmp folder while running, and preconfigures a sudo account plus pre-funded development accounts from node/src/chain_spec.rs. To keep that state between runs, add a base path.

./target/release/solochain-template-node --dev --base-path ./my-chain-state/
./target/release/solochain-template-node purge-chain --dev

The README shows that the base path then contains chains/dev with db, keystore and network subdirectories. For a multi-node local network you have two scripted options that use the same hardcoded libp2p node keys and bootnode peer ID, so they are interchangeable for development.

./scripts/start-local3.sh
docker compose up --build

The first builds the debug binary and starts Alice, Bob and Charlie against the embedded local3 chain spec. The second starts the same topology in containers. To interact with a running node, the README points at the hosted Polkadot/Substrate Portal at polkadot.js.org/apps with an rpc=ws://localhost:9944 parameter, and notes that Quip no longer requires custom types in Polkadot.js Apps, with usage notes in docs/polkadotjs/README.md.

Runtime 117 is a chain wipe, not an upgrade

The most consequential sentence in the README concerns the relaunch. Runtime 117 is described as the H2/H4 chain-wipe relaunch. It starts from fresh genesis and is not an in-place upgrade of the earlier H1/H3 network. Three operational consequences follow directly from that text: operators must use a fresh chain database, they must re-insert the H4 BABE and H2 GRANDPA keys, and they must sync from the new genesis. The README also states that old signed extrinsics are incompatible because transaction_version is 7.

This is a real limitation rather than a footnote. Anyone with an existing database, a saved keystore, or a queue of prepared transactions has to discard all three. There is no migration path documented, and the README does not describe a way to export balances or state from the old network. If your workflow depends on continuity of chain history, this project is the wrong tool at this stage of its life. The honest read is that the network is being restarted deliberately, and the node repository is the client for the new chain only.

The pinned toolchain, and why Rust 1.96.0 breaks the build

The Dockerfile pins Rust 1.95.0 on Debian bookworm and explains why in a comment: the runtime-to-host ABI, meaning the sp-io ext_* host functions, is toolchain-sensitive, and Rust 1.96.0 regressed the wasm32v1-none runtime link with an undefined symbol error on those ext_* functions. The same comment instructs you to keep the version in lockstep with the CI toolchain image at .gitlab/ci-toolchain.Dockerfile and to bump both together after verifying.

That is a maintenance cost you inherit. A Substrate runtime is compiled to WebAssembly and linked against host functions provided by the node binary, so a toolchain change can break the link even when your own code is untouched. The build stage also installs clang, libclang-dev, protobuf-compiler, pkg-config, libssl-dev and cmake, and adds the wasm32v1-none target plus the rust-src component.

Two more details in the Dockerfile are practical rather than cosmetic. It rewrites ssh://[email protected]/ to https://gitlab.com/ so cargo can fetch public dependencies such as quip.network/xq-rs without an SSH key, and it sets CARGO_NET_GIT_FETCH_WITH_CLI=true because cargo's libgit2 backend ignores git's url.insteadOf. It also disables HTTP multiplexing and raises the retry count, with the comment attributing this to cargo's HTTP/2 multiplexing stalling against crates.io from VMs and CI runners. If you build on a workstation with good connectivity you may never hit that, but on a CI runner you probably will.

Licence: Unlicense on the repository, MIT-0 in the workspace manifest

The repository is listed as Unlicense, and the LICENSE file sits at the top level. The workspace Cargo.toml, however, declares license = "MIT-0" under [workspace.package], with the author line Quip Network <[email protected]> and a homepage of quip.network. Both are permissive and neither imposes a copyleft obligation on your own code, but they are not the same text. If your organisation records licence identifiers for dependency review, the two sources disagree and you should resolve which one governs the crates you actually depend on before you rely on either. This is not legal advice, and the repository does not explain the discrepancy.

One packaging detail matters for anyone embedding the signing code. The transaction-crypto-py crate is excluded from the workspace because it is a PyO3 extension-module cdylib, and the comment states it is excluded so its macOS dynamic_lookup link requirement, injected by maturin, never perturbs the runtime or node builds. It depends on transaction-crypto-core by path and is built through maturin rather than as a workspace member. The Makefile confirms this with a PY_SIGNER_CRATE variable pointing at crates/transaction-crypto-py and a PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 escape for building against a CPython newer than the pinned pyo3 knows about.

What the README leaves out, and how it compares to the upstream template

The README is inherited from the solochain template and has not been fully rewritten. Its getting-started section clones paritytech/polkadot-sdk-solochain-template, and several commands invoke ./target/release/solochain-template-node rather than quip-network-node. Both names appear in the same document. That is not fatal, since the binary name is set by the node crate, but it means you should not copy commands blindly and expect the template binary to exist in a Quip checkout.

More seriously, the README does not document rollback, does not describe how to obtain the H4 BABE and H2 GRANDPA keys it tells you to re-insert, and does not explain what quantum-pow actually computes or how a miner registers. The pallet names imply a mining workflow, and the Makefile references a separate quip-protocol repository and a quantum-validation fixture generator, but the validator repository does not contain that protocol code. Anyone evaluating whether mining is profitable has to leave this repository to find out.

Compared with the upstream solochain template, the difference is not the node skeleton, which is largely the same, but the runtime. The template gives you a system pallet, balances and sudo. Quip adds quantum-pow, quantum-compute-mempool, miner-registry, faucet-ops, evm-chain-id and xqvm, and it ships a Docker Compose topology with static IPs to work around the litep2p loopback advertisement problem. If you want a plain template to learn Substrate on, the upstream repository is the simpler choice. If you want the quantum mining pallets, you need this one, and you accept that the documentation is thinner than the code.

Editorial conclusion

Adopt it if you already run Substrate infrastructure and want to mine or validate on the Quip testnet; the build is a standard cargo build --release and the local three-validator topology is scripted for you. Do not adopt it if you want a stable public chain: runtime 117 starts from fresh genesis and the README states old signed extrinsics are incompatible, so any prior state is worthless. Before committing hardware, verify the chain database is fresh, that you hold H4 BABE and H2 GRANDPA keys, and that you accept Unlicense terms on the code while the workspace Cargo.toml still declares MIT-0.

Frequently asked questions

Official sources

1. Issues
2. License: Unlicense
3. QuipNetwork/quip-validator on GitHub
4. README