> For the complete documentation index, see [llms.txt](https://docs.brainnetwork.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.brainnetwork.app/how-it-works/browser-nodes.md). # Browser nodes A browser node is a tab on [brainnetwork.app/earn](https://brainnetwork.app/earn). Nothing is installed. The whole lifecycle runs in that tab against the server, and every step of it is real. ```mermaid stateDiagram-v2 [*] --> Detect Detect --> Challenge: WebGPU adapter found Challenge --> Benchmarking: server-seeded kernel runs Benchmarking --> Standby: server scores on its clock Standby --> Online: you click Join Online --> Computing: unit assigned Computing --> Online: unit verified / failed Online --> Offline: no heartbeat Offline --> Online: heartbeat resumes ``` ## Detect `navigator.gpu.requestAdapter()`, `adapter.info`, limits and features, plus the WebGL unmasked renderer and `navigator.*` fields. Each field carries its source. Anything the browser does not expose is shown as *unavailable*, never guessed. VRAM is always unavailable, because no browser exposes it. The device class (M4 Max, RTX 4090, "other WebGPU") comes from the adapter string and is for display only. The adapter's maximum buffer size is recorded, and half of it becomes `advertisedMemoryGb`: the pool memory BRAIN is willing to schedule against. On the live network this averages 0.9 GB per tab. ## Challenge and benchmark The server issues a secret-seeded challenge. The tab runs a WGSL integer kernel (`mix_u32`) on the GPU and returns the result. The server recomputes secret blocks, checks them, and scores the node on its own clock. The score is not a TFLOPS figure and the client's own timing is ignored. The node is registered on standby. ## Join Clicking Join flips the node to online. The join counter on the site increments by exactly your node, and the `NODE xxxx JOINED` event comes from the server's event bus over SSE. From here the tab heartbeats and polls for work. ## Work Three kinds of work reach a browser node: * **Distributed jobs.** A parallel `u32` matrix multiplication split into up to 64 work units across the online fleet, each unit a row block of C = A × B. The server spot-checks secret rows, reassigns units whose node disappears, and fails the job with a reason if it cannot finish. When customer traffic alone would leave the fleet idle, the scheduler dispatches operator baseline jobs of the same kind (labelled `scheduled by operator (network-baseline)` on the receipt). They carry no customer charge and pay verified units through the hourly pool exactly like any other work. * **Canaries.** Full-answer jobs with a known result. * **Inference stages.** In NETWORK mode a tab holds one layer-range of a Qwen3 model and runs it for every decoding step. See [Network inference](/how-it-works/network-inference.md). Each poll that finds nothing returns a `retryMs` so idle tabs do not hammer the database, and distributed work wakes them early over the event stream. ## Heartbeat and state State is derived server-side from heartbeats and outcomes. A tab that stops heartbeating goes offline and its assigned units are reassigned. Uptime is heartbeats observed divided by heartbeats expected, on the server's records. ## What your node page shows `/node/` reads only server records: jobs completed, failed and verified, verification rate, reassignment rate, median latency from assignment to verification, uptime, reputation. Nothing is client-reported. ## Pay Verified units from this tab are attributed to the wallet you connect (Phantom, Solflare, Backpack, or Privy email). At the top of each hour the previous hour settles and your share of the fixed SOL pool becomes claimable on [/rewards](https://brainnetwork.app/rewards). See [How contributors are paid](/economics/how-contributors-are-paid.md). ## Deploys reach the fleet Each poll response includes the deployed build id. A long-lived tab compares it between polls and reloads at an idle moment when it changes, so a deploy reaches the whole fleet without anyone refreshing. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.brainnetwork.app/how-it-works/browser-nodes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.