quip-validator: a Substrate solochain whose default network is the public testnet

Omitting `--chain` joins the live public testnet, not a local chain

The chain spec table is the first thing to read, because the default is a shared network. Leave `--chain` off and the node joins the live public Quip Testnet, preset `quip-testnet`, on EIP-155 chain ID `20033`. The same result comes from passing `--chain=quip-testnet`, and the aliases `quip_testnet` and `testnet` resolve to it as well. A path argument loads that JSON file and takes the chain ID from its genesis.

The local presets all sit on `1337`, which makes them easy to confuse in a script. `--dev` or `--chain=dev` is the Alice-only Development chain. `--chain=local` is the Local Testnet with Alice and Bob. `--chain=local3` is the Local Testnet with three validators, Alice, Bob and Charlie. All three are labelled as not the public testnet.

A development chain keeps its state in a `tmp` folder while the node runs, uses the Alice account as the sole validator authority and as the default `sudo` account, and is preconfigured with a genesis state in `node/src/chain_spec.rs` that includes several pre-funded development accounts.

Runtime 117 is a chain wipe, so old signed extrinsics stop validating

Runtime 117 is described as the H2/H4 chain-wipe relaunch, and the sentence that follows it is the important part: it starts from fresh genesis and is not an in-place upgrade of the earlier H1/H3 network.

That has three operational consequences. Operators must use a fresh chain database rather than migrating the existing one. They must re-insert the H4 BABE and H2 GRANDPA keys, which matters because Quip uses hybrid BABE and GRANDPA consensus keys, so both halves of the key set belong to the new run. And they must sync from the new genesis rather than resuming from a stored best block.

Anything already signed against the earlier network is dead. The documentation states that old signed extrinsics are incompatible because `transaction_version` is 7, which is the concrete signal to check before replaying a queued batch of transactions. Treat the bump as a new chain with a familiar name, not as a patch release.

The binary is `quip-network-node`, but half the README still says `solochain-template-node`

The README opens by naming the artefact `quip-network-node`, and the live testnet command uses that name. Several other commands do not. The embedded docs command, the single-node development chain, the purge-chain command, the backtrace example and the base-path example all invoke `./target/release/solochain-template-node`, the name of the upstream template binary rather than this fork's.

The setup instructions make the same point by omission. They fetch the upstream template and build it in release mode, without launching anything:

git clone https://github.com/paritytech/polkadot-sdk-solochain-template.git solochain-template

cd solochain-template

cargo build --release

The build target name in the workspace is `node`, and the workspace also carries a `pallets/template` member, so template scaffolding is still present in the fork.

Practical effect: a reader who copies the dev-chain block verbatim will be looking for a binary name that the build may not produce. Check `ls target/release` after `cargo build --release` and use the name that is actually there rather than assuming either one.

Consensus is hybrid BABE and GRANDPA, and Polkadot.js Apps needs no custom types

Quip runs hybrid BABE and GRANDPA consensus keys, which is why a validator operator holds two separate sets of keys rather than one, and why the runtime 117 note has to mention re-inserting both the H4 BABE and the H2 GRANDPA keys. The underlying mechanisms come from the standard Substrate menu, where custom consensus engines and several built-in mechanisms are both offered.

On the client side the project reports a simplification. Polkadot.js Apps does not require custom types for Quip anymore. You connect a node to the hosted Polkadot/Substrate Portal at the local WebSocket endpoint on port 9944, and a hosted copy is also available on IPFS. If you would rather run your own, the source and instructions are in the `polkadot-js/apps` repository.

The dev compose file sets `--rpc-port=9944` on its first service, so that default endpoint lines up with what the portal expects.

Static container IPs exist because a wildcard bind makes litep2p advertise loopback

The three-validator compose file pins `ipv4_address: 172.30.0.10` and passes an explicit `--listen-addr`, and the header comment explains why in unusual detail. litep2p enumerates every local IPv4 interface when binding to a wildcard address, loopback included, and only the IPv6 link-local `fe80::` range is filtered. Identify then advertises that whole set to peers, who dial `/ip4/127.0.0.1/tcp/30333` inside their own network namespace, reach themselves, and fail the Noise handshake with `error=Decrypt`.

One workaround is explicitly ruled out. `--public-addr` does not help because it is additive to discovered addresses rather than exclusive, per substrate#7518. The only fix is binding a single specific IP. `--no-mdns` is kept as defence in depth, since mDNS broadcasts can leak interface lists across bridged networks.

Two things in that file deserve a second look before reuse. The service runs with `--unsafe-rpc-external` and `--rpc-cors=all`, which is fine on a private bridge network and wrong anywhere else. And although the header says peering happens entirely inside the docker network with no host mapping for 30333, the service ports list includes a `30333:30333` mapping.

The Dockerfile pins Rust 1.95.0 because 1.96.0 broke the runtime link

`ARG RUST_VERSION=1.95.0` on Debian bookworm is not a stale habit, and the comment above it says why. 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 `undefined symbol: ext_*`. The pin has to move in lockstep with the CI toolchain image at `.gitlab/ci-toolchain.Dockerfile`, and both are to be bumped together after verification.

The build stage installs `clang libclang-dev protobuf-compiler pkg-config libssl-dev cmake`, then adds the `wasm32v1-none` target and the `rust-src` component. Two more adjustments matter for anyone building behind a firewall. Git is configured to rewrite `ssh://[email protected]/` to `https://gitlab.com/` so cargo can fetch public dependencies without an SSH key in the build context, and the cargo network settings are forced to HTTP/1.1 with ten retries, because HTTP/2 multiplexing stalls against crates.io from VMs and CI with a timeout after ten bytes in thirty seconds.

The Substrate dependency packages are deliberately not version pinned at the Debian level, with the note that pinning system lib versions across Debian point releases is brittle and that this is a build-only stage.

Thirteen workspace members, and the Python signer is kept out of the workspace

The Cargo workspace lists seventeen members: the four `crates/` packages `quantum-validation`, `transaction-crypto-core`, `transaction-crypto-wasm` and `transaction-crypto`, then `node`, then ten pallets named `emission-controller`, `validator-admission`, `slash-policy`, `evm-chain-id`, `faucet-ops`, `miner-registry`, `quantum-compute-mempool`, `quantum-pow`, `template` and `xqvm`, plus `runtime` and `runtime-testnet`. The package version is 0.4.1 on edition 2021.

One crate is excluded rather than listed. `crates/transaction-crypto-py` is a PyO3 extension-module cdylib, excluded so that its macOS `dynamic_lookup` link requirement, which maturin injects, never perturbs the runtime and node builds. It depends on `transaction-crypto-core` by path and is built with maturin rather than as part of the workspace. The Makefile reflects the same split, staging the Python signer into its own venv under `target/` and setting `PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1` so PyO3 can build abi3 against a newer CPython than the pinned version knows about.

One licensing detail to settle before you build on it. The workspace declares `license = "MIT-0"`, while the repository's license field reads Unlicense. They are not the same grant, so check the `LICENSE` file for the terms you actually need.

The Makefile defaults to one developer's home directory and to an SSH clone

`QUIP_PROTOCOL_ROOT` defaults to `/Users/romanuseinov/projects/quip/quip-protocol`, and the derived virtual environment path is built from it. Any target that touches `quantum-validation` therefore points at a home directory that exists on exactly one machine, and you have to override the variable before those targets mean anything locally.

The SDK target has the same shape from the other direction. `make polkadot-sdk` runs `git clone --branch polkadot-stable2603 [email protected]:QuipNetwork/polkadot-sdk.git`, which is an SSH URL and needs a key with access to that repository. That is a fork of the Substrate SDK on a named stable branch, so a fork build is part of the intended workflow rather than an accident.

For the local network there is one target, `make local-3-node`, which runs `./scripts/start-local3.sh` and builds the debug binary before starting Alice, Bob and Charlie against the embedded `local3` spec. `make wasm-signer` is stricter still: it tests `wasm-pack --version` against the required `wasm-pack 0.12.1` and exits with an error otherwise. The repository has no GitHub releases, and the last push was on 2026-11-02, so there is no tag to pin to and the branch is the version marker.

Editorial conclusion

Use quip-validator if you intend to run a Quip solochain node and can accept a Rust 1.95.0 toolchain plus Substrate build dependencies, since the Docker image pins the Rust version. Do not treat the no-flag launch as a sandbox, because that is the live public testnet, and do not expect an in-place upgrade across runtime 117, which starts from fresh genesis and invalidates old signed extrinsics. Verify the chain ID your keys belong to before inserting BABE and GRANDPA keys, and note that the repository publishes no tagged releases, so the last push on 2026-11-02 is the only version marker.

Frequently asked questions

Official sources

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