pearl-research-labs/pearl

Pearl is a young L1 chain, not a drop-in library: adopting it means running daemons and, if you want to mine, sizing GPU infrastructure. Worth an afternoon of exploration if you are curious how a proof-of-useful-work chain is wired together, less so if you need a settled production chain.

The problem

Someone with GPU capacity wants it to earn while also checking the chain's accounting: getting a mining address, pointing a node at it, and seeing whether the work is accepted. With most chains the friction is splitting mining hardware from the ledger software and reconciling two sets of credentials and configs. Pearl bundles the node (pearld), a wallet daemon (oyster), a CLI (prlctl, oystercli), and a GPU miner in one monorepo, so the flow becomes build, create wallet, start node, start miner. The result is a local mainnet node with a mining address and a gateway that talks to it over JSON-RPC.

What's different

Mining here is a by-product of arbitrary matrix multiplication, based on the project's Proof-of-Useful-Work paper; the repository ships a vLLM miner built around vLLM and CUDA, plus a ZK proof-of-work circuit (Plonky2/STARKy). The setup is therefore closer to a GPU serving stack than to a CPU miner: the Docker path mounts a Hugging Face cache and the 70B Llama instruct model named in the README, and requires --gpus all, host networking and an 8g shared-memory size. That is a meaningful resource decision, not a footnote.

The chain code is forked from btcd/btcwallet/neutrino, with XMSS post-quantum signatures and an SPV light client using compact block filters. The practical benefit is one coherent toolchain and documented network ports across mainnet, testnet and simnet; the trade-off is that this is a substantial, multi-language build (Go, Rust, C, Python/uv) with several moving daemons, so casual reading of the code is easier than casual operation.

Who should try it

Good fit: a technically comfortable operator with an NVIDIA GPU setup who wants to understand or experiment with this chain's mining economics and tooling, or a blockchain engineer reading the ZK proof-of-work and post-quantum signature pieces. Poor fit: someone who wants a finished wallet with an app-store-style experience, or who cannot afford to commit GPU capacity and a heavy toolchain. The documented prebuilt binaries and oystercli interactive client lower the entry bar for node and wallet use, but they do not remove the GPU requirement for the shipped vLLM miner. The README documents an install script path for macOS, Linux and Windows, so a source build is not strictly mandatory for the chain tools; check node/docs/installation.md before committing.

Requirements and limitations

Building everything needs Go 1.26+, a Rust toolchain, a C compiler, Python 3.12 with uv, the Task runner, and the CUDA toolkit. Those are broad requirements: reproducing the full test/build matrix is a multi-toolchain exercise, and partial builds are the sensible path for most readers. The mining path needs an NVIDIA GPU and a model download, so budget disk and VRAM accordingly. Installer defaults are localhost-only mainnet with shared RPC credentials; if you expose RPC with --rpclisten, understand what you are exposing. The token economics, mining rewards and long-term consensus behavior are not explained in the supplied README, so evaluate those from the protocol paper and project docs rather than assuming them.

HotRepo's take

On a weekly Go board dated 2026-10-25, Pearl recorded +28 stars at #19, five days after HotRepo began tracking it; the sample covers only 2026-10-24 to 2026-10-25, so momentum and persistence cannot be judged from that window. The repository is 188 days old at that snapshot. Before spending a weekend on it, verify that the vLLM miner's documented model and CUDA path match your hardware and that the testnet ports you plan to use are active for your target release.