Step 1
Register challenges
The master registry stores challenge slug, image, version, status, emission percent, required capabilities, resources, volumes, environment, and public proxy path.
[MINER] | v +-------------+ | AGENT PACK | +-------------+
How it works
From registry record to subnet weights.
Platform turns active challenge containers into normalized Bittensor weights through registry metadata, public proxy routes, internal weight collection, and final UID submission.
Step 2
Run containers
Each challenge ships as its own Docker image and receives isolated runtime resources. The master can pull, restart, and inspect challenge status through admin operations.
+---------+ +---------+ | QUEUE | ----> | JOB 42 | +---------+ +---------+
Step 3
Expose proxy routes
Active challenges are exposed through /challenges/{slug}/... while internal routes such as health, version, and /internal stay blocked from the public proxy.
.----------------. / SECURE RUN /| | [DOCKER] [TDX] | | |________________|/
Step 4
Collect weights
On each epoch the master calls every active challenge's internal get_weights endpoint, checks runtime capability, and falls back safely when a challenge cannot respond.
C1 weights C2 weights C3 weights -> aggregate -> uids
01
Register
Admins create or update challenge records with image coordinates, emission percent, lifecycle status, capabilities, resources, volumes, and env.
ChallengeCreate schema
Admin-safe view
Token hint
Lifecycle status
02
Expose
Active challenges receive public proxy routes while internal endpoints stay available only to the master.
Public proxy path
Blocked internal routes
Safe forwarded headers
Active-only routing
03
Aggregate
The master collects challenge weights, normalizes emissions, maps hotkeys to UIDs, and sends final weights to Bittensor.
get_weights
Emission share
Metagraph UID map
set_weights