Skip to main content
PRISM runs as a FastAPI application with SQLite state, internal BASE authentication, and GPU evaluation through the Docker broker. The challenge owns the data and the evaluation; the validator re-executes the miner’s training loop under a forced random init and computes the score itself. Source: docs/architecture.md:1-7.

​
High-level pipeline

Source: docs/architecture.md:11-23.

​
Main components

Source: docs/architecture.md:27-37.

​
Subnet integration

BASE is responsible for miner-facing upload security. It verifies signatures, timestamps, nonces, and hotkey identity before forwarding a submission to PRISM. PRISM receives verified submissions on the internal bridge route:
This is an internal route. The bridge trusts only internal authentication and the verified hotkey header (X-Platform-Verified-Hotkey); miner-supplied identity headers are not trusted.
Source: src/prism_challenge/app.py:68-75; docs/architecture.md:39-52.

​
Execution model

PRISM does not execute miner submissions directly in the master process. The worker performs static inspection and the LLM hard gate, then sends the project to an isolated evaluator container through the Docker broker:
The pre-GPU static gates run in this order, and a rejection at any of them is terminal before the LLM review and before any GPU work:
  1. AST sandbox hard-blocks over both scripts.
  2. Forced-seed build_model instantiation and the 150M parameter cap.
  3. The multi-GPU static contract and single-node bound.
Source: docs/architecture.md:64-80.

​
Forced-init re-execution (anti-cheat core)

The challenge harness drives every scored run; the miner code only supplies the model and the loop body.
  1. The harness writes a challenge-owned runner that imports the miner’s architecture.py and training.py, sets the global seeds and deterministic flags before any miner code runs, then launches torchrun --standalone --nnodes=1 --nproc-per-node=1.
  2. The runner installs an instrumented loss capture. The data iterator yields fresh, single-pass batches from the read-only locked train split in a challenge-controlled order, and the challenge records each per-batch loss before the optimizer updates on it. Because the data is single-pass, this online training loss is the prequential code-length by construction.
  3. The challenge authors prism_run_manifest.v2.json from the captured stream. Any manifest the miner writes is discarded; any metric the miner reports is ignored.
The eval container is non-root, runs with a read-only rootfs except artifacts_dir, uses network=none, and is bounded by a wall-clock budget that is only a safety cap, never part of the score. Source: docs/architecture.md:82-102.

​
State model

PRISM stores state in SQLite. Important tables include miners, submissions, eval_jobs, gpu_leases, scores, submission_sources, llm_reviews, plagiarism_reviews, and epochs.
  • eval_jobs tracks each evaluation attempt (including the level='l1' static-tracking placeholder created at submission time, which is not GPU work).
  • gpu_leases records the exclusive single-GPU lease for a scored run.
  • scores holds the challenge-computed prequential bits-per-byte final_score and its metrics payload.
Source: docs/architecture.md:104-121; src/prism_challenge/db.py:100-159.

​
Scoring flow

After the forced-init re-execution completes with a valid challenge-authored prism_run_manifest.v2.json, scoring computes everything from the challenge-owned capture:
  • the prequential bits-per-byte primary score (lower bpb yields a better final_score);
  • the held-out delta-over-random-init tie-breaker on the secret val split;
  • the train-vs-held-out anti-memorization gap, which penalizes an excessive gap;
  • a step-0 / smuggled-weights anomaly multiplier that zeroes an anomalous run.
The leaderboard orders by final_score with a deterministic earliest-commit-wins tie-break, and get_weights returns one normalized, dry-run weight per hotkey. Weights are never written on-chain. Source: docs/architecture.md:123-146; src/prism_challenge/repository.py:506; src/prism_challenge/weights.py:21-31.

​
The weights module

get_weights converts completed scores into normalized weights: it reads each epoch’s score rows and keeps, per hotkey, the best final_score, then normalizes the survivors to sum to 1.0. Weights are always dry-run.
Earlier versions split rewards across separate architecture and training pools. The live weights path normalizes the best final_score per hotkey and the v1-NAS architecture/training ownership pools are retired from the score.
Source: src/prism_challenge/weights.py:21-31; docs/scoring.md:80-89; docs/architecture.md:162.

​
Failure handling

A submission ends in one of these states: pending, running, completed, failed, rejected, or held.
  • Rejected - failed static review, the two-script contract, the LLM hard gate, or duplicate review.
  • Failed - passed the gates but failed the re-execution, scoring, or infrastructure.
  • Held - quarantined by the LLM review pending operator attention.
Source: docs/architecture.md:148-162. See PRISM API for the full route list and Running PRISM for deployment.