Dates and verification labels belong to the original edition. A past verified announcement can now be outdated. Historical project names are retained; an SN filter searches the slot across registrations. All keywords must match the story text or subnet label. Ratings describe editorial priority, not investment quality.
Exploit follow-up: Brandtensor outlines marketing support for subnet teams
Gordon Frayne’s October 4 interview post and Brandtensor’s response bring attention to the agency’s work on subnet positioning, product proof, developer education and reaching customers beyond the Bittensor audience. Its introduction was actually published September 25; this is a late-found conference follow-up, not an October 5 launch. The practical question is whether technical progress can be explained through clear use cases and verified evidence. The announcement does not establish new client revenue or independently audited results.
A dated, directly confirmed ecosystem-service introduction adds useful conference context without manufacturing a new launch date.
SN8 Vanta reports $20,000 from external network users in October’s first three days
After yesterday’s research cutoff, SN8 Vanta’s Arrash reported $20,000 in revenue during October’s first three days from entities other than Vanta Trading. He says these operators pay alpha to access the network’s funding infrastructure, demonstrating the intended platform model: other firms can build on the subnet rather than all activity coming from its own trading brand. This is a team-reported figure for those external entities, not an extra $20,000 of Vanta Trading revenue or an independently audited cash statement. The Vanta Trading buyback wallet and external operators’ purchases should not be combined without a reconciled ledger.
Reported demand from independent operators is a meaningful commercial signal beyond an internal product, while the revenue attribution and verification limits remain clear.
SN9 iota reportedly restores activations after temporary Redis errors
The October 4 team-attributed brief says transient Redis errors affecting SN9 iota’s TAH service were resolved and activations are flowing again, with a permanent fix in staging. That is a reported operational recovery, not proof the staged fix has been deployed. The IOTA SDK described in the same recap remains a preview already covered earlier this week; it is not presented as a new finished SDK release.
A newly reported recovery is useful service context while the staged fix and existing SDK preview retain their proper status.
SN11 TrajectoryRL releases v0.7.4 with a $0.30 scenario cap
SN11 TrajectoryRL v0.7.4 makes the evaluation budget specific to the scoring contract: SPEC 27 uses $0.30 per scenario across 20 scenarios, or a $6 maximum before infrastructure reruns, while older SPEC 26 evaluations retain their $1 cap. Validators now default to following the published winner and setting weights; running sandbox evaluations requires an explicit opt-in. This prevents different validator versions from silently applying different budgets to the same scoring rules. The channel brief targets epoch 4005 and evaluation UID 74, but this scan checked the release code rather than confirming every validator’s activation or resolving yesterday’s missing-reward report.
The released budget and operating-mode changes materially affect validator cost and comparable evaluation, with rollout and incident limits stated.
SN15 ORO reports a fairness review and a separate Race 2 recovery
SN15 ORO’s October 4 team-attributed brief reports no evidence in its review that inference caching, bring-your-own keys or provider routing systematically improves scores. It also reports a short Race 2 disruption was corrected and agents restored, with the three-race scoring average unchanged. These are team findings, not an independent fairness audit. The proposed copied-agent cooldown rules remain operational guidance, and the Race 2 update does not by itself close yesterday’s separately reported Race 11 pause or confirm all rewards settled.
A specific reported recovery and fairness review are relevant, with race identities and the limits of the team’s investigation retained.
SN22 Desearch targets Monday, October 5 for more tasks and lower burn
The October 4 team-attributed brief says SN22 Desearch’s new release is in testing and targets Monday, October 5. It is intended to expand currently limited task availability and reduce the burn rate. This provides a dated next step for the validator slowdown tracked October 2–3; it does not establish that the new tasks or lower burn are already active. No specific new burn percentage or completed distribution repair was independently confirmed.
A dated recovery and allocation plan advances an unresolved miner-impacting issue, with activation still ahead.
SN23 Trishool clarifies winner timing when a validator goes down
The October 4 team-attributed brief says SN23 Trishool will wait until all scores are published before announcing a winner if a validator goes down. The team has been notified about the current question and expects to address it next day. This is a reported judging procedure and pending follow-up, not a confirmed completed repair or a new winner announcement.
The clarification helps participants understand why a winner may be delayed, with resolution still pending.
SN25 UR records a large lock reduction and a replacement lock in the same block
At block 9210497, recorded at 15:48 UTC on October 4, SubnetRadar shows the same SN25 UR hotkey reducing 550,000 alpha of locked mass and adding a new lock of approximately 463,035 alpha. Both events belong together: the reduction alone should not be read as 550,000 alpha sold, and the new lock alone is not proof of that much fresh buying. The feed does not establish the holder’s motive or a matched market trade. Separately, today’s public development deadline concerns mainnet code qualification; production signing and deployment remain a distinct launch phase.
A substantial conviction change is material chain context, with paired events and the distinction from trading or production launch made explicit.
SN34 BitMind investigates an audio leaderboard concern
SN34 BitMind’s October 4 team-attributed brief says the team is looking into an audio leaderboard concern. Discussion about submission order, reign assignment and a historical September 27–28 calculation error is not a completed independently checked finding. This scan did not establish a recalculated leaderboard, reward settlement or misconduct by a participant. The new development is the reported investigation, rather than a confirmed network-wide scoring failure.
An acknowledged evaluation concern warrants visibility without turning disputed historical calculations into settled facts.
SN44 Score reports 90.1% on its worksite PPE task, clearing the 90% target
SN44 Score says miners lifted its worksite Personal Protective Equipment task from a 46.6% baseline to a 90.1% live score, passing the 90% target in days. The task covers hard hats, vests and eyewear, with hourly evaluations and open weights. Harder worksite footage is being added rather than retiring the task at its first successful result. The practical story is a model improving through subnet competition on a defined workplace problem. These are the team’s task measurements, not an independently reproduced safety certification or proof that every real worksite is covered.
A specific baseline-to-target result, open weights and continued harder evaluations are substantial product progress, with benchmark scope preserved.
SN44 Score’s zero-score incident remains open alongside the PPE milestone
SN44 Score’s October 4 team-attributed brief reports zero scores associated with SN64 Chutes warmup failures. It says those scores will not be removed and describes a possible allowance of up to two zero scores in averaging next week. The brief also reports interruption in person and petrol detection. These operational reports are separate from today’s PPE benchmark result: hitting a model target does not establish every evaluation service is healthy. The future averaging change and complete service recovery were not independently verified.
New incident handling affects miners and prevents a strong benchmark result from being mistaken for an operational all-clear.
SN51 lium.io protects running rentals when a provider is banned
SN51 lium.io’s new validator code keeps verification running for a GPU node that still has a renter’s pod, even when a provider or GPU ban prevents new rentals. Previously, stopping verification could make the node stale and interrupt renter billing and payouts. The ban still blocks new rentals; the change is about maintaining an existing customer’s service, not removing the ban or declaring faulty hardware safe. This is an inspected code merge, with deployment across all validators not independently confirmed.
Existing customer continuity is a concrete reliability improvement at a major emission recipient, with ban enforcement and rollout scope preserved.
SN62 Ridges reports a brief leaderboard recovery and improves public-result loading
The October 4 team-attributed brief says SN62 Ridges’ competition 28 leaderboard was restored within an hour. Public code now caches each agent’s evaluation view for 60 seconds and avoids fetching large patch and execution fields that the public response does not use. That is a defined performance improvement rather than a measured speed claim across the whole service. The team attributes differences between validator results to nondeterministic model inference; this scan did not independently reproduce that explanation or verify every displayed result.
A reported outage recovery and inspectable result-loading improvement are useful operational updates without overstating measurement or evaluation agreement.
SN71 Leadpoet adds one recovery attempt for a proven scoring-host failure
SN71 Leadpoet’s new recovery rule allows a final attempt when an authenticated scoring-host failure occurs before any provider call, cost entry or output, within the frozen scoring window. It preserves the original input and prior records. This is a narrow infrastructure exception, not a free retry for any low score or evidence that the upstream provider incident is fully resolved. The channel also describes temporary slot limits and planned changes to reduce spam incentives; removing those limits is still a plan, and the brief’s reference to October 5 is not reported as an event that has already happened.
A carefully scoped recovery path addresses lost scoring work while preserving fairness boundaries and prospective scaling changes.
SN74 Gittensor releases SparkInfer v0.6.20 with scoped serving gains
SN74 Gittensor’s SparkInfer v0.6.20 is published. Its RTX 5090 test on Qwen3.6-35B-A3B UD-Q4_K_M reports 12% and 13% higher output throughput at 16 and 32 simultaneous requests versus v0.6.19, reaching 1,517 and 1,716 tokens per second. The release also states that vLLM still leads those high-concurrency tests; different quantization formats and workloads matter. A preceding fix rejects out-of-vocabulary token IDs as a bad request instead of losing the CUDA context and disrupting later requests. These are scoped release measurements and a concrete reliability fix, not a universal speed lead.
A published version improves measured serving performance and request isolation while disclosing the competitor lead in other conditions.
SN78 UMI adds automatic endpoint work claims; admission and rewards remain gated
SN78 UMI’s latest code completes endpoint enrollment by retaining both a signed participation request and a service-work claim, then retrying them automatically after temporary failures. A certified endpoint and assigned work slot still do not promise a score or reward before completed work and cohort settlement. At 17:39 UTC on October 4, the public API retained 203 accepted submissions but returned admission_accepting_new false, admission_phase unverified, rewards_active false and chain_submission_authorized false. This changes yesterday’s observed open-admission status; it is not evidence that C5 has finished or payments restarted.
A concrete enrollment improvement and a changed live admission state are actionable competition information, with the API overriding broad launch claims.
SN80 OpenRoboto catch-up: the September 27 real-robot season has public results
Today’s check of SN80 OpenRoboto’s results page found the completed π0.5 competition 3, whose physical xArm 6 evaluations ended September 27 at 12:00 UTC. It lists ten entries, two qualified miners and champion UID 47 passing 10 of 70 formal trials, above the nine-success champion line. Each counted run has a linked recording. This is a specific real-robot result, separate from the nearly 90% simulation figure covered October 2. The project page reports a 30,260.6-alpha reward pool and 1,740 alpha unlocked by October 4, with transfers listed; this scan inspected the page, not an independent chain reconstruction. The champion share unlocks over 120 days, so the full pool is not already paid. This is a late-found September 27 result, not a new competition completed today.
Inspectable physical-robot results and a defined settlement schedule add material evidence beyond simulation, with the modest trial success rate and actual event date clear.
SN81 Reliquary reportedly opens another 100,000-prompt code corpus job
The October 4 team-attributed brief reports code-qwen38-27b-v2 live with 100,000 prompts using the same model and setup as its first code job. It says the earlier code, instruction-following and logic jobs are full, while math-omi still has capacity. Public code also prepares support for agentic corpus tasks and keeps their grading separate from judge-only processes. The new code-job availability is a reported live update; agentic tasks described as coming soon and yesterday’s dormant science profile are not treated as newly paying competitions.
A specific new job expands reported mining capacity, with current corpus work separated from prospective agentic and science activation.
SN91 Cascade diversifies its evaluation pool and releases idle GPU pods
SN91 Cascade’s October 3 code lowers the per-feed panel cap from 25 series to five to draw from more distinct sources in its daily evaluation pool. This is a pool change, not a new validator release or independently proven benchmark gain. Another merge releases a champion’s GPU pod once training, benchmarking and queued verification have finished; a later check waits for the next pod without losing an attempt. Releasing an idle pod does not dethrone the champion. Both changes target evaluation coverage and unnecessary operating cost.
Specific pool and compute-management changes improve operational design without inventing customer adoption, measured savings or a new model win.
SN94 Cathedral asks the community to help choose its mining launch model
SN94 Cathedral’s October 4 team-attributed brief describes four mining models under discussion, ranging from initially self-seeded nodes to permissionless routing based on track record. The team says the final choice will be made openly and targets public compute-test results next week. This is a consultation about how to launch, not confirmation that unrestricted public mining or the promised tests are already live.
A defined mining-access decision is useful roadmap context, with the final model and activation unresolved.
Searches published headlines and summaries, not private bookmarks, unpublished leads or source-page contents. Duplicate headlines within an edition appear once; separate editions remain separate so follow-ups are preserved. Share the page URL to retain your filters.
