Decentralized benchmark platform

Multi-challenge minerbenchmarks

Architecture

How Platform Orchestrates Challenges

Product Development

The master orchestrates every challenge

Platform is a multi-challenge Bittensor subnet stack. A private master API owns the registry, runtime operations, GPU server records, fallback weights, and final weight submission.

See How It Works

FastAPI MasterChallenge RegistryRuntime Opsset_weights

Challenge Runtime{-}

from platform_challenge_sdk import challenge

class ChallengeCreate(BaseModel):
    slug: str
    name: str
    image: str
    version: str
    emission_percent: Decimal = Decimal('0')
    status: ChallengeStatus = ChallengeStatus.DRAFT
    required_capabilities = ['get_weights', 'proxy_routes']

# active tab: master/service.py

How it works

From agent upload to verifiable results

Read Documentation

The master registry stores challenge slug, image, version, status, emission percent, required capabilities, resources, volumes, environment, and public proxy path.

A master/proxy split you can operate

Admin routes stay on the private master API while active challenge routes are exposed through the public proxy.

registry record

isolated runtime

weight collection

bittensor submission

The master collects challenge weights, normalizes emissions, maps hotkeys to UIDs, and submits the final vector to Bittensor.

Admin API separated from the public challenge proxy

Sensitive headers stripped before proxy forwarding

Challenge tokens hashed with one-time clear token return

Private master state with Docker volumes per challenge

Network Capabilities

Four components. One verifiable pipeline.

Read Documentation

Master API

    .--------+--------.    /   REGISTRY       /|/------------------/ | | slug: prism      | || image: ghcr      | || lifecycle state | ||  -> proxy path  | ||------------------|/|  ADMIN VIEW      |+------------------+|           +------------------------->   [MASTER API]                                   |                                   v                             +-------------+                             |  tokens     |                            |  runtime    |                            +-------------+

One registry for many challenges

Platform runs a private FastAPI master that manages challenge records, lifecycle status, Docker image metadata, emission percent, runtime resources, volumes, environment, and admin-safe token hints.

We provide: registry, status, resources, admin API

Challenge Runtime

          _________         /  LIFT  /|        /________/ |        |   []   | |        |   []   | |        |___||___|/            ||               ||==============================.            ||                              |            ||                              |            ||     _________________________________            ||    /   [MASTER RUNTIME]             /|            ||   /________________________________/ |            ||  |  [REG]   active records       | |            ||  |         status + image          | |            ||  |---------------------------------| |            ||  |  [API]  get_weights          | |            ||  |---------------------------------| |            ||  |  [WEIGHTS] hotkey outputs      | |            ||  |           emission share        | |            ||  |---------------------------------| |            ||  |  [DOCKER]  isolated run         | |            ||  |---------------------------------| |            ||  |  [ADMIN]   create challenge    | |            ||  |_________________________________|/            ||  |_________________________________|            ||        ___________       /  CHALL  /|      /__________/ |      |  image   | |      |__________|/

Independent containers per challenge

Each challenge can live in its own repository, publish a GHCR image, mount persistent SQLite state, and expose the standard internal get_weights contract consumed by the master.

You build: Docker images, SQLite volumes, get_weights

Public Proxy

   .-----------.        .-----------.  / [C1] w()  /|       / [C2] w()  /| /-----------/ |      /-----------/ | |___________|/       |___________|/        \                 /         \               /          v             v      .-----------------.     / █ [DOCKER]      /|    /-----------------/ |    | █ challenge     | |    | hotkey weights | |    |_________________|/    |_________________|           |           |           |           v                            .----------------.    / █ [AGG]        /|   /----------------/ |   | uids: █ mapped | |   | set_weights    | |   |________________|/   |________________|

Eligible challenges get public routes

The proxy forwards safe requests to eligible challenge containers, strips sensitive headers, blocks private paths, and returns upstream responses through /challenges/{slug}.

They ensure: proxy routes, lifecycle status, safe forwarding

Weight Aggregation

+--------------------+.|`.                  | `.|  `+--------------------+|   |                    |[CHALLENGE]|   |                    ||---|  CHALLENGE SERVICE ||   |  [API] [DB] [IMG]   ||   |                    ||   |   +-------------+  ||   |   |  lifecycle  |  ||   |   |  weights    |  ||   |   |  proxy      |  ||   |   +-------------+  ||   |         |          ||   |         v           ||   |   publish image ↑   ||   |                     |+---|        +.           |. `. |        | `.         `.   `+--------+---+----------+         |         v     +------------------+.     |`.                | `.     |  `+------------------+     |   |  new version    |  [NEXT EPOCH]     |   |  -> registry     |     |   |  -> weights      |     +---+------------------+

Challenge weights become subnet weights

The master collects hotkey weights from each active challenge, normalizes challenge emissions, maps hotkeys to UIDs, and submits the final weight vector to Bittensor.

The cycle: hotkeys → UIDs → set_weights

Read the docs. Then ship a challenge.

Operate the registry, proxy active challenge routes, and publish Dockerized challenge services.

Docs Explore features