
Overview
Registration Activity
Neuron registration trends

Neuron registration trends
The alpha price in τ, day by day, and what moved it each way.
Log change over the last 30 days +86.88%: protocol buys 0.00%, root sells −93.75%, users net +70.27%, cross-subnet +110.36%, unattributed −0.0004%.
The chart follows the alpha price in τ. Each period starts at its opening price and steps through the mechanisms below, in a fixed order, to its closing price: a step that rises pushed the price up, one that falls pushed it down, and its height is how far it moved the price. A thin line carries each close into the next period’s open; it is dashed where the two differ. The faint candle behind each period is the market’s own open, high, low and close, for context.
With many periods on screen (90 days, or hours), the steps would be too thin to read, so the chart draws the price as a line instead and colours each period by the mechanism that moved it most. Hover a period for the full step-by-step breakdown.
Not here, because they do not move the spot price: the per-block TAO injection into the pool, and burns.
All figures are log changes, not simple percentage changes, so the parts add up exactly to the total; on big moves the two differ (a 10% log fall is a 9.5% price fall).
2026-11-04 UTC, as of ≈22:06 UTC (block 9,435,522)
The day isn’t over yet, so these figures keep changing. They are in no daily total, average or rank.
Emission history is being recalculated from on-chain allocation.
Physics-informed optimization tasks—predicting battery aging, designing thermal systems, optimizing mechanical components—require both specialized domain knowledge and rigorous validation. Centralized approaches struggle to scale research participation and validation capacity. A decentralized network of researchers (miners) and evaluators (validators) allows distributed development of strategies with verifiable, independent scoring on shared benchmarks.
Carbon implements this as a Bittensor subnet where miners develop neural network strategies locally, practice on public cases, and submit frozen candidates to validators. Validators independently reconstruct each strategy using pinned software and validator-controlled randomness, score results on hidden benchmark cases, and publish performance rankings to the chain. Miners are rewarded based on strategy quality, while validators are incentivized to maintain rigorous evaluation standards.
The system enforces reproducibility through deterministic reconstruction settings, isolates miner research from validator evaluation logic, and supports multi-validator submission so strategies are verified across independent evaluators.
Commitment transactions optionally bind submissions to the chain, creating an auditable record of what was submitted and when.
Auto-generated from the GitHub repository and may not reflect the latest changes.
Carbon is a Bittensor subnet (netuid 567) for AI research and optimization. It provides a platform where miners develop and submit neural network strategies that are reconstructed and evaluated by validators on hidden benchmark cases. The subnet enables distributed research on physics-informed optimization tasks like battery aging and thermal design, with miners receiving rewards based on the quality of their submitted models.
Carbon is a distributed research optimization subnet. Miners use a local Control Center (Python HTTP server) to run research campaigns driven by AI agents (Graphite, custom MCP agents, or Hermes). Miners connect to inference providers (Engy, Chutes) and computational backends (CPU, GPU, remote SSH-Docker).
They develop strategies, practice on public cases, freeze candidates, and submit to validators through an authenticated HTTPS intake. Validators run a persistent daemon that admits submissions via btauth/1 authentication, binds submissions to replay journals and per-hotkey windows, reconstructs strategies on declared GPU or CPU backends with validator-controlled randomness, scores results on hidden cases, and publishes weights to the chain under owner-approved policies. A single miner hotkey is registered on Bittensor testnet netuid 567; the same hotkey signs research requests and submissions.
The miner's private hotkey never enters Carbon code—an external signer (carbon-miner-signer) holds it. Validators store private roots, seed journals, pool state, and service keys on secure host instances. Multi-validator submission is supported: one frozen strategy can be sent to multiple validators' intakes simultaneously.
Commitments are optional (testnet now); mainnet will bind submissions to on-chain recipe-hash commitments. The platform enforces deterministic reconstruction via pinned software, determinism settings, and DEVELOPMENT-only testing; production qualification remains separate.
Miners develop strategies through local practice on public cases, freeze a strategy with a contract digest, optionally post that digest on-chain as a commitment, then submit to a validator's intake. The validator rebuilds the strategy using validator-controlled randomness (seed), evaluates it on hidden cases, and returns a sealed verdict only after the material's registered release window. Scoring gates mandate reference validity, infrastructure success, and decision-quality thresholds.
Admission windows per hotkey per 360-block window limit submissions. Validators rank admitted submissions and publish weights via testnet_winner_publication. Testnet mining grants no earnings; mainnet registration, policy bounds, coldkey custody, and payment qualification are owner decisions not yet made.
The intake authenticates via btauth/1 (Bittensor v11 HTTP auth), journals against replay, and enforces per-hotkey rate limits.
The sections above were auto-generated from the GitHub repository and may not reflect the latest changes. View repository (github.com, opens in a new tab, external site)
Transforming engineering simulations through machine learning
This information was auto-extracted from the GitHub repository and may be incomplete or out of date. Always refer to the subnet's GitHub repository (github.com, opens in a new tab, external site) for the latest instructions.
Not yet verified: GPU, Storage, CPU cores, Network, Notes
Not yet verified: GPU model, GPU count, CPU cores, OS, Network, Notes
Machine-extracted from the subnet's repository docs; may be wrong or out of date. Check the repository before buying or renting hardware. Open the repository (github.com, opens in a new tab, external site) · Extracted 2 Nov 2026
Clone the Carbon repository
git clone https://github.com/carbonphysicsai/Carbon.git ~/carbon
Run the installer to set up the environment, build images, and start the Control Center. Add --gpu for GPU worker, --service for systemd integration.
~/carbon/scripts/install_miner.sh
Start the external signer in a separate terminal to hold your hotkey and sign requests
~/carbon/.venv/bin/carbon-miner-signer --wallet YOUR_WALLET --hotkey YOUR_HOTKEY
Access the Control Center web interface for setup and campaign management
Open browser to address printed by Control Center with the printed session token
Configure profile through the Control Center UI (Inference → Compute → Agent → Review)
Complete setup steps: confirm registration, select inference provider, configure compute, choose agent
Choose a Challenge and begin research campaign with selected agent and compute
Select Challenge and launch campaign through Campaigns tab
Iterate, freeze candidate strategy, and submit to validator intake for evaluation
Practise on CPU or GPU, freeze strategy, optionally commit digest on-chain, then submit
Update to latest main; rebuilds images and re-checks setup(optional)
~/carbon/scripts/install_miner.sh --update
Prepare intake configuration as owner-only JSON file mode 0600
Write intake configuration file (carbon.battery.intake.v1 schema) with deployment, transport journal, inbox, receiver hotkey, host/port bindings
Prepare validator service configuration as owner-only JSON file mode 0600
Write service configuration file (carbon.battery.validator-service.v1 schema) with intake, state_dir, backups, practice_images, run_every_s
Create initial backup of root, journal, state before any changes
python -m scripts.dev.battery_validator_service backup --config S
Run comprehensive preflight checks including Docker, images, deployment upgrade, exposure, and parity
python -m scripts.dev.battery_validator_service preflight --config S
Verify validator's images match pinned practice manifests that miners use
python -m scripts.dev.battery_validator_service parity --config S
Generate systemd user units and install them for intake and daemon(optional)
python -m scripts.dev.battery_validator_service units --config S --out <units dir> && cp <units dir>/carbon-battery-*.service ~/.config/systemd/user/
Start the intake and validator daemon services via systemd(optional)
systemctl --user daemon-reload && systemctl --user enable --now carbon-battery-intake.service carbon-battery-validator.service
Verify both services are healthy and intake is serving requests
python -m scripts.dev.battery_validator_service status --config S
Confirm intake is responding with correct network, netuid 567, Challenge, and receiver
curl -s http://127.0.0.1:8467/carbon/v1/battery/intake
Configure TLS and public binding only after owner approval and security review(optional)
For public exposure: update intake config with host, exposure_record, tls_cert, tls_key; then preflight and restart
Backup deployment state before any code or image updates(optional)
python -m scripts.dev.battery_validator_service backup --config S
Upgrade deployment to new rule/image/material when needed(optional)
python -m carbon.battery.operate upgrade --config <deployment.json>