AUTORESEARCH BACKEND
Architecture Overview
Post, train, validate, and pay only for confirmed progress.
Current Production Path¶
The reward-active SN94 path is coordinator-backed autoresearch. The legacy AutoML-Zero relay/SOTA flow has been moved to the AutoML-Zero archive.
flowchart LR
Owner[Problem owner] -->|admin task post| Backend[Autoresearch backend]
Miner[Miner or agent] -->|signed claim + submission| Backend
Backend -->|signed replay worklist| Validator[Public validator runner]
Validator -->|observed metrics| Backend
Backend -->|reward snapshot| Pool[Pool / claim service]
Pool -->|Merkle root| Contract[Merkle claim contract]
Pool -->|proof package| Miner
Miner -->|claim transaction| Contract
Backend -->|validator_weights| Setter[Backend weight setter]
Setter -->|set_weights| Chain[Bittensor SN94]
Chain -->|emissions| Hotkey[Pool contract hotkey]Runtime Boundaries¶
| Component | Current responsibility | Public actor |
|---|---|---|
| Autoresearch backend | Tasks, onboarding, claims, submissions, validator jobs, best results, reward snapshots. | Miners, validators, operators. |
| Public task repos | Benchmark code, setup command, result contract, allowed edit surface. | Miners and validators clone them. |
SN94-BitSota |
Public miner helpers, Codex/manual mining docs, validator runner, backend weight setter, claim helpers. | Miners and validators. |
| Validator runner | Replays submissions against stored replay specs and posts observed metrics. | Allowlisted validators. |
| Pool / claim service | Converts accepted reward data into Merkle claim epochs and proofs. | Pool operator, miners claiming rewards. |
| Bittensor SN94 | Validator-set subnet weights and emissions. | Validators. |
Production Endpoints¶
| Purpose | Endpoint |
|---|---|
| Production coordinator | https://autoresearch.bitsota.com |
| Task catalog | GET /api/v1/tasks |
| Task onboarding | GET /api/v1/tasks/{task_id}/onboard.md |
| Miner claim | POST /api/v1/tasks/{task_id}/claim |
| Miner submission | POST /api/v1/submissions |
| Validator worklist | POST /api/v1/validator/submissions/scan |
| Validator result | POST /api/v1/validator/jobs/{job_id}/result |
| Reward snapshot | GET /api/v1/reward-snapshot |
Main Data Flow¶
- A problem owner works with an operator to post a replayable task.
- Miners list live tasks and read the generated onboarding markdown.
- A miner signs a claim with a hotkey.
- The miner submits a patch, artifact, or both.
- The backend stores an immutable replay spec for the submission.
- Validators replay the stored spec and post observed metrics.
- Accepted submissions update best-result and reward state.
- The reward snapshot feeds Pool/Merkle claims and validator weight policy.
Current Task Shape¶
Live tasks are backend records, not hardcoded client constants. Each task defines:
- public repository and pinned base ref;
- setup and benchmark commands;
- result path and metric extraction contract;
- allowed patch paths;
- metric direction and optional Pareto secondary metric;
- competition mode:
standard,centerless, orpeer_evaluation; - time budget and onboarding markdown.
Use:
Validation Model¶
For standard and centerless tasks, claimed metrics do not decide acceptance.
The validator replay output is the canonical score.
For peer_evaluation tasks, miners submit peer evaluations until the configured
threshold is reached.
For artifact-first tasks, validators download the public artifact, verify its SHA-256 and byte size when provided, and expose it to the benchmark. The backend stores artifact metadata, not artifact bytes.
Current Weight Model¶
Production validators should use backend-directed weights from:
The current intended split is:
Validators must resolve hotkeys dynamically through the metagraph. Do not hardcode the contract UID.