Platform is a decentralized evaluation framework that enables trustless assessment of miner submissions through configurable challenges on the Bittensor network. By connecting multiple validators through a Byzantine fault-tolerant consensus mechanism, Platform ensures honest and reproducible evaluation while preventing gaming and manipulation.
Want to run a validator? See the Validator Guide for setup instructions.
- Decentralized Evaluation: Multiple validators independently evaluate submissions
- Challenge-Based Architecture: Modular Docker containers define custom evaluation logic
-
Byzantine Fault Tolerance: PBFT consensus with
$2f+1$ threshold ensures correctness - Secure Weight Submission: Weights submitted to Bittensor at epoch boundaries
- Centralized Coordination: Platform-server provides HTTP/WebSocket APIs for validators
- Multi-Mechanism Support: Each challenge maps to a Bittensor mechanism for independent weight setting
- Stake-Weighted Security: Minimum 1000 TAO stake required for validator participation
Platform involves three main participants:
- Miners: Submit code/models to challenges for evaluation
- Validators: Run challenge containers, evaluate submissions, and submit weights to Bittensor
- Sudo Owner: Configures challenges via signed
SudoActionmessages
The coordination between validators ensures that only verified, consensus-validated results influence the weight distribution on Bittensor.
┌─────────────────────────────────────────────────────────────────────────────┐
│ SUDO OWNER │
│ (Creates, Updates, Removes Challenges) │
└─────────────────────────────────┬───────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ SHARED BLOCKCHAIN STATE │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Challenge A │ │ Challenge B │ │ Challenge C │ │ ... │ │
│ │ (Docker) │ │ (Docker) │ │ (Docker) │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ Platform Server (chain.platform.network) │ │
│ │ PostgreSQL Database • HTTP API • WebSocket Events │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────┬───────────────────────────────────────────┘
│
┌─────────────────────┼─────────────────────┐
│ │ │
▼ ▼ ▼
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ VALIDATOR 1 │ │ VALIDATOR 2 │ │ VALIDATOR N │
├───────────────────┤ ├───────────────────┤ ├───────────────────┤
│ ┌───────────────┐ │ │ ┌───────────────┐ │ │ ┌───────────────┐ │
│ │ Challenge A │ │ │ │ Challenge A │ │ │ │ Challenge A │ │
│ │ Challenge B │ │ │ │ Challenge B │ │ │ │ Challenge B │ │
│ │ Challenge C │ │ │ │ Challenge C │ │ │ │ Challenge C │ │
│ └───────────────┘ │ │ └───────────────┘ │ │ └───────────────┘ │
│ │ │ │ │ │
│ Evaluates miners │ │ Evaluates miners │ │ Evaluates miners │
│ Shares results │ │ Shares results │ │ Shares results │
└─────────┬─────────┘ └─────────┬─────────┘ └─────────┬─────────┘
│ │ │
└─────────────────────┼─────────────────────┘
│
▼
┌───────────────────────┐
│ BITTENSOR CHAIN │
│ (Weight Submission) │
│ Each Epoch (~72min) │
└───────────────────────┘
-
Development:
- Miners develop solutions that solve challenge-specific tasks
- Solutions are packaged as code submissions with metadata
-
Submission:
- Submit to any validator via HTTP API
- Submission is stored in PostgreSQL database at platform-server
- Submission includes: source code, miner hotkey, metadata
-
Evaluation:
- All validators independently evaluate the submission
- Evaluation runs in isolated Docker containers (challenge-specific logic)
- Results are stored in PostgreSQL database at platform-server
-
Weight Distribution:
- At epoch end, validators aggregate scores
- Weights are submitted to Bittensor proportional to miner performance
-
Submission:
$S_i = (code, hotkey_i, metadata)$ -
Submission Hash:
$h_i = \text{SHA256}(S_i)$ -
Evaluation Score:
$s_i^v \in [0, 1]$ - score from validator$v$ for submission$i$
-
Challenge Synchronization:
- Pull challenge Docker images configured by Sudo owner
- All validators run identical challenge containers
- Health monitoring ensures container availability
-
Submission Evaluation:
- Receive submissions via platform-server HTTP API
- Execute evaluation in sandboxed Docker environment
- Compute score
$s \in [0, 1]$ based on challenge criteria
-
Result Sharing:
- Submit
EvaluationResultto platform-server via HTTP API - Results stored in PostgreSQL database at platform-server
- Platform-server broadcasts events to validators via WebSocket
- Submit
-
Score Aggregation:
- Collect evaluations from all validators for each submission
- Compute stake-weighted average to aggregate scores
- Detect and exclude outlier validators (2σ threshold)
-
Weight Calculation:
- Convert aggregated scores to normalized weights
- Apply softmax or linear normalization
-
Weight Submission:
- Submit weights to Bittensor per-mechanism at epoch boundaries
-
Evaluation:
$E_i^v = (h_i, s_i^v, t, sig_v)$ where$sig_v$ is validator signature - Aggregated Score (stake-weighted mean, after outlier removal):
Where
- Confidence Score:
Where
Platform supports two normalization methods:
Converts scores to probability distribution using temperature-scaled softmax:
Where:
-
$w_i$ - normalized weight for submission$i$ -
$s_i$ - aggregated score for submission$i$ -
$T$ - temperature parameter (higher = more distributed) -
$\mathcal{M}$ - set of all evaluated submissions
Simple proportional distribution:
Weights are converted to Bittensor u16 format:
Platform uses simplified PBFT for validator consensus:
For
-
Propose: Leader broadcasts
Proposal(action, block_height) -
Vote: Validators verify and broadcast
Vote(proposal_id, approve/reject) -
Commit: If
$\geq \text{threshold}$ approvals received, apply action
SudoAction::AddChallenge- Add new challenge containerSudoAction::UpdateChallenge- Update challenge configurationSudoAction::RemoveChallenge- Remove challengeSudoAction::SetRequiredVersion- Mandatory version updateNewBlock- State checkpoint
Platform-server (run by subnet owner at chain.platform.network) maintains authoritative state:
- PostgreSQL Database: Stores all submissions, evaluations, and scores
- HTTP API (port 8080): Validators submit and retrieve data
- WebSocket Events: Real-time notifications to connected validators
Each validator's score is weighted by their stake:
Where
Validators with anomalous scores are detected using z-score:
Where
Validators with
Agreement among validators determines confidence:
Low confidence (high variance) may exclude submission from weights.
- Minimum Stake: 1000 TAO required for validator participation
- Sybil Resistance: Creating fake validators requires significant capital
- Stake Validation: All API requests verified against metagraph stakes
| Protection | Configuration |
|---|---|
| Rate Limiting | 100 msg/sec per peer |
| Connection Limiting | 5 connections per IP |
| Blacklist Duration | 1 hour for violations |
| Failed Attempt Limit | 10 before blacklist |
- Docker Sandboxing: Agents run in isolated containers
- Resource Limits: Memory, CPU, and time constraints
- Deterministic Execution: All validators run identical containers
- Centralized Database: Platform-server maintains authoritative PostgreSQL state
- Signature Verification: All API requests signed by validator keys
- WebSocket Sync: Validators receive real-time state updates
Miners maximize reward by submitting high-performing solutions:
Subject to:
- Submission must pass validation
- Score determined by challenge criteria
-
Byzantine Tolerance: System remains correct with up to
$f = \lfloor(n-1)/3\rfloor$ faulty validators -
Evaluation Fairness:
- Deterministic Docker execution
- Outlier detection excludes manipulators
- Stake weighting resists Sybil attacks
-
Liveness: System progresses if
$> 2/3$ validators are honest and connected
Each Bittensor epoch (~360 blocks, ~72 minutes):
Evaluation runs continuously throughout the entire epoch. Validators constantly:
- Receive and process submissions from challenges
- Execute evaluations in Docker containers
- Submit results to platform-server via HTTP API
- Aggregate scores from all validators
At the end of each epoch, validators submit weights to Bittensor based on aggregated scores.
git clone https://github.com/PlatformNetwork/platform.git
cd platform
cp .env.example .env
# Edit .env: add your VALIDATOR_SECRET_KEY (BIP39 mnemonic)
docker compose up -dThe validator will auto-connect to platform-server at chain.platform.network and sync.
| Resource | Minimum | Recommended |
|---|---|---|
| CPU | 4 vCPU | 8 vCPU |
| RAM | 16 GB | 32 GB |
| Storage | 250 GB SSD | 500 GB NVMe |
| Network | 100 Mbps | 100 Mbps |
Note: Hardware requirements may increase over time as more challenges are added to the network. Each challenge runs in its own Docker container and may have specific resource needs. Monitor your validator's resource usage and scale accordingly.
| Port | Protocol | Usage |
|---|---|---|
| 8080/tcp | HTTP | Platform-server API |
| 8090/tcp | WebSocket | Container Broker (challenge communication) |
Standard REST endpoints for submissions, evaluations, and challenges.
| Endpoint | Description |
|---|---|
/ws |
Validator events |
/ws/challenge |
Challenge container events |
| Endpoint | Description |
|---|---|
/api/v1/bridge/{challenge_id}/* |
Proxy to challenge containers |
| Variable | Description | Default | Required |
|---|---|---|---|
VALIDATOR_SECRET_KEY |
BIP39 mnemonic or hex key | - | Yes |
SUBTENSOR_ENDPOINT |
Bittensor RPC endpoint | wss://entrypoint-finney.opentensor.ai:443 |
No |
NETUID |
Subnet UID | 100 |
No |
RUST_LOG |
Log level | info |
No |
PLATFORM_SERVER_URL |
Platform server URL | https://chain.platform.network |
No |
PLATFORM_PUBLIC_URL |
Public URL for challenge containers | - | Yes |
DATABASE_URL |
PostgreSQL connection (server only) | - | Yes (server) |
OWNER_HOTKEY |
Subnet owner hotkey | - | Yes (server) |
BROKER_WS_PORT |
Container broker WebSocket port | 8090 |
No |
BROKER_JWT_SECRET |
JWT secret for broker authentication | - | Yes |
The unified platform binary supports two subcommands:
platform server- Run the platform-server (subnet owner only)platform validator- Run a validator node
All validators MUST use auto-update. Watchtower checks for new images at synchronized times (:00, :05, :10, :15...) so all validators update together.
If validators run different versions:
- Consensus fails (state hash mismatch)
- Weight submissions rejected
- Network forks
Do not disable Watchtower.
Platform creates a trustless, decentralized framework for evaluating miner submissions on Bittensor. By combining:
- PBFT Consensus for Byzantine fault tolerance
- Stake-Weighted Aggregation for Sybil resistance
- Docker Isolation for deterministic evaluation (challenge-specific logic)
- Centralized Platform Server for authoritative state management
The system ensures that only genuine, high-performing submissions receive rewards, while making manipulation economically infeasible. Validators are incentivized to provide accurate evaluations through reputation mechanics, and miners are incentivized to submit quality solutions through the weight distribution mechanism.
MIT
