flybrainlabs/miner

This is not a standalone application you can casually run; it is one component of a cross-repository workspace with a sharply limited, partly disabled financial reward layer. Only consider it if you work inside the flybrainlabs stack.

The problem

A researcher wants to run a deterministic integer LIF simulation in a browser while, in a separate flow, participate in a finite Devnet wallet-mining exercise and keep model and result data persistently. Today that means stitching together a native simulator, a WASM build, browser workers and a chain-test harness by hand. The project assembles these pieces under one shared build layout, so execution state drives rendering and results persist across cancellation and recovery. What changes is that the simulation and the mining workflow share one recoverable record instead of being ad hoc scripts; what you get is a reproducible computation pipeline, not an out-of-the-box app.

What's different

The scope is explicitly deterministic integer LIF simulation with a WASM engine, browser workers, persistent model/result storage and a three-stage mining flow that supports cancellation and recovery. Rendering is driven by actual execution state, which matters when you need to observe a computation as it runs rather than reconstruct it afterward from logs. The build relies on a component ownership model: each imported file has one owning repository, and component.json maps files into a shared build layout, so maintained edits belong to the owning repos and you use workspace.py sync for intentional changes. The most important trade-off is that cloning miner alone does not supply its external components; the workspace assembler is mandatory. That design keeps cross-component imports and pinned dependency versions consistent, but it raises the cost of contributing or even building locally. A second trade-off is that full-model and browser integration checks require existing verified local resources and explicit arguments, so they don't self-provision a model or reset a browser profile.

Who should try it

This fits a developer already familiar with the flybrainlabs workspace who needs to modify or verify simulation and mining components across repositories. It does not fit someone who wants a ready simulation package or a usable mining client; the README does not present either. The documented setup path requires assembling the exact source revisions from flybrainlabs/infra via the development guide, not a standalone clone, and that determines who can use the project.

Requirements and limitations

You need Rust 1.90 or newer (edition 2024), Node 22 or newer and Python 3.11 or newer; SBF builds additionally need compatible Solana/Agave build tools. Optional scientific Python dependencies live in the assembled workspace, and build steps require the infrastructure release manifest plus running the assembler. Full-model and browser integration checks need pre-existing verified local resources, and isolated chain checks need their own local bank; production funds and addresses are never substituted. The wallet-mining extension is a finite Devnet activity whose payment and reward configuration is disabled until asset identities, authorities, funds and operating gates are satisfied, with a completed two-unit acceptance budget. Expect ongoing upkeep in the form of dependency pinning and workspace sync discipline rather than a one-time install.

HotRepo's take

HotRepo first tracked this 12-day-old repository on 2026-10-24; it was observed on the NEW-REPOSITORY board (新项目榜, not the overall Trending board) at 595 total stars and #25 on 2026-10-25, but that single snapshot is a total-star reading, not a growth series. With no comparable daily-board history, persistence cannot yet be judged. Before spending time, verify whether the API and expected inputs of Rust 1.90 and the flybrainlabs/infra assembler are compatible, since the workspace requirement gates every subsequent step.