flybrainlabs/node

This repository is the authority-node and service-API code for flybrainlabs, a Solana-linked platform handling goal competitions, commit/reveal processing, replay, artifacts, tickets and accounting. It is not a standalone finance library you can drop into another codebase; adopting it means working inside flybrainlabs' own component and release system.

The problem

A developer wants to run or integrate with the back end that settles competitive goals, processes commit/reveal submissions, coordinates full replays and keeps an economic ledger. Reading this repository alone does not give a working system: the source is split across several repositories and only becomes buildable after a workspace tool assembles the exact pinned revisions. The change is that you no longer clone and build one repo; you obtain the infrastructure repository, check out the related projects with its workspace script and assemble a disposable layout, then run the relevant tests. The result is a maintained local workspace whose edits must flow back to the owning repositories rather than this one.

What's different

The distinctive mechanism is the component layout. component.json maps maintained files into a shared build layout, and dependencies are pinned by commit in an external release manifest, so the workspace script reconstructs a consistent cross-component snapshot. That makes it possible to keep authority logic, product APIs, the ledger and market code in separate repositories while still testing them together. The practical benefit is reproducible assembly of a multi-repo system; the trade-off is that this repository is not self-contained and its build instructions depend on another repository and a specific workspace workflow.

A second mechanism is the policy around sensitive material. Keys, wallets, customer inputs, node databases, private artifacts, browser profiles and model caches are deliberately kept outside Git and website exports. Public receipts for the wallet-mining work live in a contracts repository while private signers and full archives do not. This separation is sensible for a financial-adjacent system, but it also means outsiders cannot independently inspect the private operational side from the source.

The social service runs separately on loopback while sharing wallet sessions and SQLite/WAL, and adds a checksummed migration. The README states it starts no relayer or asset execution, which limits its blast radius but also means it is a narrower sidecar than the main authority flow.

Who should try it

This fits developers already collaborating with flybrainlabs or validating its release process: people who need the authority-node tests, the assembled workspace or the social-community service. It is a poor fit for someone looking for a general-purpose ledger, competition engine or Solana toolkit to use in an unrelated product, because the import layout and pinned releases assume the flybrainlabs component set. If you only need the social sidecar, the separate loopback service is a lighter entry point than the full authority stack, though it still requires the assembled workspace for its checks.

Requirements and limitations

You need Rust 1.90+ (edition 2024), Node 22+ and Python 3.11+, with the compatible Solana/Agave build tools for SBF builds; scientific Python extras are separate. The bigger constraint is assembly: cloning this repository alone does not supply external components, so the workspace checkout, assemble and npm ci steps are mandatory before the documented test commands mean anything. Maintained edits belong to the owning repositories, so any change made in the disposable layout must be synced and reviewed before publication.

Production payments are explicitly disabled, the marketplace catalog and checked financial domain are still in development, and paid work would require a newly frozen finite plan. Full-model and browser integration checks expect existing verified local resources and explicit arguments, and isolated chain checks need their own local bank. These are gating conditions, not optional polish.

See the development guide, architecture notes, current status and the repo's AGENTS.md.

HotRepo's take

HotRepo recorded 856 total stars on the JavaScript NEW-REPOSITORY board (#13) on 2026-10-25, against a repository created 2026-10-12. That is a dated snapshot, not a daily-growth measurement, and the stored coverage from 2026-10-24 to 2026-10-25 is insufficient to judge persistence. Before investing time, verify that the pinned revisions in the infrastructure release manifest still assemble and pass the documented authority tests; that is the real prerequisite for anything in this repository.