Daily digest of the Bittensor ecosystem

中文/EN

Daily edition
Oct 22, 2026

Bittensor Daily A 1T1B product
1T1B ↗
BITTENSOR DAILY
Network upgrades·eTao·

24H Market

01/10

Gainers
--Loading…--
Losers
--Loading…--

THE DAILY BRIEFING

Bittensor Daily — October 22, 2026

Bittensor rolled out runtime release v482, bundling a breaking change that lets coldkey swaps merge into already-used destination accounts alongside new Yuma payout and proxy-fee logic. Elsewhere, SN23 (Trishool) launched a paid EU AI Act compliance product while SN120 (Affine)'s scoring mechanism concentrated emissions on two coldkeys across multiple epochs.

Today's highlights

  1. 01

    Bittensor shipped runtime release v482, bundling a breaking change that lets coldkey swaps merge into already-used destination accounts along with new Yuma payout and proxy-fee logic.

    The release is a breaking change affecting anyone performing coldkey swaps and includes emission-handling adjustments relevant to validators network-wide.

  2. 02

    SN120 (Affine)'s revised scoring mechanism concentrated emissions on two coldkeys across multiple epochs, with miners noting the same operators repeatedly took 10 of 10 paid slots.

    The concentration raises questions about fairness in reward distribution under the subnet's current scoring design.

  3. 03

    SN23 (Trishool) launched HaloGuard EU, a paid product that blocks AI output classified as high-risk under the EU AI Act, priced at $30 per billion tokens, while its price rose 23.47%.

    The launch is the subnet's first commercial product tied to EU AI Act compliance, a new revenue angle for the subnet.

  4. 04

    SN92 (REAX) opened a new generalist model training competition based on its REAX 1 model with 12 entries, while also fixing a scoring-order bug that initially evaluated post-opening entries ahead of the opening cohort.

    The team rolled back a problematic release within about an hour, confirmed no miner lost weight, and compensated affected miners from its own funds during the competition launch.

  5. 05

    Community discussion centered on what stops a single top-stake validator from acting dishonestly under Null Consensus, which lets a subnet scale up to 2500 UIDs with only the top-stake validator setting weights.

    The trust model underlying Null Consensus is relevant to subnets like SN9 and SN93 that are considering this scaling option.

Subnet Community Pulse

5

SN92 24h +3.81%

REAX

What happened
SN92 (REAX) released REAX 1, an open decision model built on Perplexity Decider v1.2, as the base model for a new generalist model training competition that opened at 13:00 UTC with 12 entries in the opening cohort. The team also restructured champion-protection rules so that champions and former champions keep a 75/17/8 reward split and are shielded from immediate deregistration. During the week the subnet also had three validator-side issues: a scoring-display bug in release rc10, a capacity-probe timing bug affecting about 50 high-UID hotkeys, and a scoring-order bug that evaluated post-opening entries before the opening cohort. The team announced a four-part rule update, later corrected to take effect Friday, October 23, 2026, 13:00 UTC.
Community
Miners had pressed the team for weeks over co-champions losing emissions and registration fees upon deregistration, and some asked for protection to extend beyond a single round. Community members also flagged the rc10 scoring display issue and the capacity-probe anomaly, both of which the team confirmed and fixed; a miner's suggestion to reward 2nd and 3rd place in the opening generalist playoff was adopted.
Official
The team rolled back the rc10 release within about an hour, confirmed no miner lost weight, and later compensated affected miners roughly 6.5 alpha from the owner's own funds; it also confirmed and fixed the scoring-order bug, giving pruned opening-cohort entries a re-entry window until 07:30 UTC on October 22.

In debate · SN92 champion protection and deregistration fairness · 13 participants

  • Miners argued that co-champions could be deregistered in the next round without even earning back their registration fee, discouraging participation.

    “If anyone beats them in that next round, they won't even earn back the registration fee”

  • Some miners said protection for one round was not enough and asked for immunity across several rounds.

    “Only next round is insufficient. At least 3 next rounds.”

  • The team responded by formalizing champion protection with a fixed reward split for champions and former champions.

    “the champion gets 75 % of the engine share, the previous champion 17 %”

SN120 24h −2.42%

Affine

What happened
SN120 (Affine)'s revised scoring mechanism concentrated emissions on two coldkeys across multiple epochs, with miners noting the same operators repeatedly took 10 of 10 paid slots. The team posted epoch-by-epoch updates for epochs 72 through 75, reporting held-out benchmark scores that moved between .594 and .75 while payouts remained fixed at 10 UIDs with nothing burned. Separately, the team relaunched Affine Studio, a video tool aimed at providing an ultra-fast video model, and introduced a new mech-1 competition track alongside the existing mech-0.
Community
Miners repeatedly asked the team to publish the scoring mechanism and per-UID scores, questioning how two coldkeys could hold nearly all top slots across consecutive epochs. Some also raised concerns about private commits in the new mech-1 track.
Official
The team posted epoch-by-epoch scoring updates explaining that some unchanged weight windows were due to scoring taking longer than usual, and said epoch 76 training would drop unresolved rollouts rather than train on them.

In debate · Emission concentration and scoring transparency on Affine · 14 participants

  • A community member identifies two coldkeys taking nearly all paid slots, describing them as a likely single operator.

    “All 10 again sit with one likely operator: coldkey 5GEonQk8 has 6 (54% of the pay), 5EUFoUY7 has 3 (38%)”

  • Miners argue the lack of published scoring rules makes it impossible to verify how emissions are allocated and call for transparency.

    “This lucky hotkey is going to take almost all the emissions in the next epoch. is this fair to other miners?”

  • The team attributes a stretch of unchanged weights to scoring delays and reports per-epoch held-out scores while payouts stay fixed at 10 UIDs.

    “still 10 UIDs paid with nothing burned. Held-out on the e72 checkpoint came in at .719”

SN15 24h −1.48%

ORO

What happened
SN15 (ORO) miners asked the team for a specific timeline on upcoming changes to the incentive mechanism, but the team did not provide an exact date or race number. Several miners reported agents flagged by anti-cheating warnings or failures despite running previously published versions, and asked the team to investigate. One miner reported an agent stuck in the evaluation queue for four hours due to a recurring inference provider error.
Community
Miners repeatedly pressed for a concrete date on the incentive mechanism change, with some expressing frustration at the lack of specifics. Several miners flagged anti-cheating issues affecting agents they said were already using published code and asked for individual review via direct message.

SN22 24h −1.08%

Desearch

What happened
A miner raised concerns on SN22 (Desearch)'s channel that the subnet's task API is operated centrally and is not verifiable, arguing this lets the team favor certain actors; the debate extended across many messages on UID pressure and task allocation under the Desearch 2.0 mechanism. The team said it currently runs the task API centrally to iterate quickly and stated it is open to publishing logs via W&B or a similar tool. Separately, Desearch added embedding tasks to its main subnet, allowing GPU operators to embed crawled pages using Desearch-Embedding-4B, with validators re-embedding samples to check results. A Cloudflare R2 storage issue caused upload errors and locked at least one hotkey before being resolved.
Community
Community members were split: some argued the incentive design is broken and called the setup a black box, while others countered that UID count does not determine rewards and urged miners to optimize their own mining software instead of blaming the rules. One proposal discussed was having multiple miners complete the same task with only the fastest correct result paid, though another member questioned whether this would slow the network.
Official
The team said GPU task burn will be reduced toward zero in an upcoming release and acknowledged UID pressure issues without a clear fix yet, inviting concrete proposals from the community.

SN23 24h +23.47%

Trishool

What happened
SN23 (Trishool) launched HaloGuard EU, a paid product designed to block AI output banned or classified as high-risk under the EU AI Act, priced at $30 per billion tokens with a free trial available. The team also clarified the criteria for "suspected sentences" used in challenge templates, explaining that such sentences are ones that do not serve the persona, framing, or instruction of an attack. Separately, the team confirmed that the winning prompt from the challenge will remain hidden, while disqualified prompts will be disclosed.
Community
Community members asked for clarification on rule changes between challenge cards and requested a script to verify template compliance, which the team said it would not provide. Several members welcomed the HaloGuard EU launch, with one asking whether it would generate revenue for the subnet.
Official
The team said revenue from HaloGuard EU needs to grow before team size or compensation can change, describing the launch as the first of several planned products. It also said the paraphrase test used to disqualify prompts will be published so results can be reproduced.

More subnet community coverage every day in the Telegram channel →

Ecosystem debate

6 participants

Null Consensus: trust assumptions behind single-validator weight-setting

Under Null Consensus, only the top-stake validator sets weights, which the community says is cheaper to run than Yuma consensus and allows a subnet to scale up to 2500 UIDs. Several participants used SN9 and SN93 as examples of subnets that might use this scaling option. The discussion centered on what, if anything, stops the single top-stake validator from acting dishonestly.

Positions

  • Null Consensus exists mainly to cut costs and allow more UIDs than standard Yuma consensus supports.

    “Because Null Consensus is cheaper than running Yuma, and that allowed for more UIDs”

  • Some participants say there is no technical safeguard against the top-stake validator rewarding hotkeys it secretly controls, leaving stake movement as the only check.

    “Nothing prevents it technically, except for people moving their stake if they think something is off”

  • Others argue the trust problem is not new since primary validators already require trust today, with one participant proposing zk-proofs as a protocol-wide way to verify scoring was honestly run.

    “well without consensus it requires a lot more trust”
Official response
No official response from the team or Opentensor appears in the discussion.
What to watch
Whether the zk-proof verification idea for Null Consensus scoring develops further, and whether subnets such as SN9 or SN93 adopt Null Consensus at scale.

Voices on X

  • @opentensor

    @opentensor announced a Thursday Discord session on the eTAO protocol update, which lets subnet owners adjust Bittensor's emission split, hosted by a team member.

    View the original post on X ↗

  • @markjeffrey

    @markjeffrey said Bittensor subnets generate about $60M annually across 128 subnets, above Aave, and projected $100M by year-end and over $200M in Q1.

    View the original post on X ↗

  • @IOTA_SN9

    SN9 (IOTA) said its latest update speeds up merging by 5x, addressing a bottleneck in decentralized training.

    View the original post on X ↗

  • @conjectures_io

    @conjectures_io reported its miners proved a case of a 48-year-old Wilf conjecture from 1978, with the proof verified in Lean.

    View the original post on X ↗

  • @robotensor_ai

    @robotensor_ai said its Vector Level 1 robotics competition concluded, with the top model reaching 87.9% across 16 dual-arm tasks, outperforming fine-tuned pi0.5.

    View the original post on X ↗

  • @TheHackersNews

    @TheHackersNews reported a supply chain attack on LiteLLM 1.107.0, with malicious PyPI packages and Docker images delivering a credential stealer targeting cloud credentials, private keys, and AI tool credentials.

    View the original post on X ↗

  • @harnyx_ai

    @harnyx_ai said SN67 (Harnyx) removed its model allowlist on OpenRouter, allowing miners to build with any paid LLM or decision model available there.

    View the original post on X ↗

  • @taodaily_io

    @taodaily_io listed the top 10 Bittensor subnets by market cap, led by SN51 (Lium) at $189.16M, followed by SN64 (Chutes) at $120.49M and SN4 (Targon) at $94.80M.

    View the original post on X ↗

◆2026-10-22 · End of this edition

Protocol

6 PRs

New release · v482 Released

Subtensor v482: Coldkey swaps can merge into used Coldkeys, new Validate and Weights Proxy types, and a fix for the Null Consensus epoch scheduling stall

This release lets a Coldkey swap merge into a destination Coldkey that already has Stake, Hotkeys or other holdings, and adds a safer announcement flow for swaps. It adds two narrow Proxy types for Validator operations and extends fee payment to three Proxy levels. It also changes Yuma Consensus Miner payouts, enables Emission by default on new Subnets, and fixes a scheduling stall caused by Null Consensus Subnets.

Read the upgrade report →

#3231 Affects emission

Run a due Null epoch first so earlier subnets cannot starve it

What
Fixes the epoch scheduling order so a subnet due to run under Null consensus is processed first instead of being skipped.
Why
The previous ordering let earlier subnets run ahead of a due Null-consensus subnet indefinitely, which also blocked the epochs of subnets scheduled after it.
Who it affects
Affects validators and miners on the subnet that uses Null consensus, and indirectly subnets queued behind it, by restoring timely epoch processing and emissions; ordinary TAO holders see no direct change.

#3267 Breaking change

Allow coldkey swaps to merge into already-used destinations

What
Allows a coldkey swap to merge into a destination coldkey that is already in use, instead of being blocked.
Why
The prior rule rejected swaps to any destination that already had an association, preventing holders from consolidating keys; this change removes that restriction and defines how stake, locks, and registrations merge.
Who it affects
Affects TAO holders who perform coldkey swaps or consolidations, since swap outcomes and merge behavior change; this is a breaking change to existing swap logic.

#3271 Breaking change Affects emission

release-482: coldkey-swap merge, Yuma payouts, Validate/Weights proxies, proxy fee depth, emission default-on

What
Bundles the coldkey-swap merge changes, new swap-related calls, proxy fee-payment depth, and related adjustments into the spec_version 482 runtime release.
Why
Consolidates several related fixes and features, including coldkey swap v2 and proxy handling, into a single coordinated network upgrade.
Who it affects
Affects all network participants as a runtime upgrade; most directly affects those using coldkey swaps or layered proxy setups, and validators relying on correct emission handling.

#3272

Prevent destination dusting from deleting auto-stake policy during coldkey swap

What
Fixes a race condition in coldkey swap v2 where sending funds to the reserved destination account before the swap executes could cause the source's auto-stake policy to be deleted instead of transferred.
Why
The swap logic could mistakenly treat the destination as already funded and skip carrying over the auto-stake policy if someone deposited funds into it during the announcement period.
Who it affects
Affects TAO holders performing coldkey swaps who have auto-stake settings, ensuring those settings are correctly preserved; no effect for users not using coldkey swaps.

#3270

Support fee payment through three proxy levels

What
Extends fee-payment resolution to support a third level of nested proxy calls.
Why
The system previously only resolved who pays the fee for up to two levels of proxy nesting; some setups use a third layer.
Who it affects
Affects validators or miners who use multi-layered proxy configurations; no effect on ordinary TAO holders or standard single-level proxy use.

#3274

node-24: move website and deploy jobs to Node 24

What
Moves the website and deployment CI jobs from Node 20 to Node 24.
Why
Node 20 has reached end of life and needed to be replaced with a supported version.
Who it affects
This is an infrastructure/tooling change only; it affects no one outside the development team and has no effect on chain behavior, miners, validators, or TAO holders.

Recent upgrades

Recent editions

Past editions +
2026-10-222026-10-212026-10-202026-10-192026-10-182026-10-172026-10-162026-10-152026-10-142026-10-132026-10-122026-10-112026-10-102026-10-092026-10-082026-10-072026-10-062026-10-052026-10-042026-10-032026-10-022026-10-012026-09-302026-09-292026-09-282026-09-272026-09-262026-09-252026-09-242026-09-232026-09-222026-09-212026-09-202026-09-192026-09-182026-09-172026-09-162026-09-152026-09-142026-09-132026-09-122026-09-112026-09-102026-09-092026-09-082026-09-072026-09-06