Mining workflow
Download, build, search, submit and read the outcome of a computation.
Mining searches a frozen stimulus space for a response that meets a registered numerical objective. It uses the complete prepared graph and records the required backgrounds. A task is payable only when it belongs to an admitted, funded discovery unit.
Connect the wallet first#
The primary mining entry asks you to connect a Wallet Standard wallet, then sign in. It does not start a simulation or download the complete model when you select Connect wallet. After that, review preparation, the available task and finite credit. A connected wallet cannot reopen a completed budget.
Read the active preparation phase#
Three stages of a mining session
- 01Download brain dataTransfer and verify registered resources
- 02Build the brain modelConstruct execution from verified inputs
- 03Start miningExplicitly search an eligible frozen task
Download brain data. The browser obtains the registered resources, tracks bytes and verifies their declared digests. Successful chunks remain available for later sessions.
Build the brain model. The preparation controller constructs the execution representation from verified resources. Download completion and model readiness are distinct checkpoints.
Start mining. Once prerequisites are satisfied, an explicit start action searches eligible candidates using browser workers and the WebAssembly numerical core. The display focuses on the current phase rather than presenting three competing panels.
Only the current stage heading and its controls are visible. Download and build headings disappear once the model is ready; this does not delete their cached data. The prepared stage is separate from task availability.
The initial Devnet acceptance plan is completed. A separately frozen two-FBW task-supply stage now supports two new calibrated goals, one FBW per unique verified winner. When the authority has an open target, the page displays Current goal open and its round evidence. Connect and sign in, prepare or restore the retained model, and provide valid finite rent credit before starting rewarded work. When supply is exhausted, Check for new tasks synchronizes availability without starting a worker. A retained ready model and a usable task remain separate prerequisites.
Work controls and telemetry#
| Control or value | Meaning |
|---|---|
| Worker setting | The selected parallel computation capacity; more workers can increase memory pressure |
| Actual throughput | Measured neural updates per second during execution |
| Progress | Work completed within the current trial/background scope |
| Pause/resume | Temporarily suspend and continue controlled work |
| Stop | End the current work path; check what was actually completed and retained |
| Save/export | Preserve a recoverable result or package explicitly |
| Graphics switch | Control visualization independently of scientific execution |
| Logs | Preparation, work, submission and failure information for this session |
Throughput is a performance measurement, not an eligibility score or a reward formula. The count of complete required backgrounds matters to verification; time spent and worker count do not independently create compensation.
From candidate to outcome#
From candidate to verified outcome
- 01Qualify + admitLocal evaluation; funded intent finalized first
- 02Commit + revealPrivate upload and deadline checks
- 03Complete replayEvery required background executes
- 04Winner + reconcileReceipt sequence; finalized payment evidence
The candidate is first evaluated locally under the frozen rule. A qualifying candidate is committed, its complete background material is uploaded through the private path, and it is revealed. For funded V3 work, its durable financial intent must be finalized before scientific commit.
Authorized verifiers replay every required background. The authority selects the earliest eligible verified commitment according to its receipt sequence. A faster local clock or an earlier verification finish does not change the rule. Tasks and competition explains eligibility and deadlines.
Understand the distinct states#
A local qualified result has not necessarily been uploaded. An accepted upload has not necessarily passed replay. A verified candidate has not necessarily won. A scientific winner has not necessarily received a token payment. A received reward requires finalized financial evidence tied to the original beneficiary.
If a stage has no remaining tasks, the interface waits for new calibrated supply. Repeating a solved task, renaming it or changing a wallet does not create another payable discovery.
Interruptions and recovery#
Keep saved candidates, model chunks and snapshots. Reloading the page never automatically starts another run. Recovery checks the frozen identity and available storage before continuing retained work; financial reconciliation follows accepted intents even after a scientific terminal state.
Do not delete the full cache to fix a graphics or RPC error. Model cache and recovery covers persistent state, and Troubleshooting provides targeted steps.
See feature availability for release scope and pending acceptance.