What’s new

TPN Labs opens a contest to squeeze a large AI model onto an ordinary laptop

TPN Labs has started its third competition on Bittensor, called TPN-003. The task set for the miners, meaning the independent teams who compete for rewards on the network, is to take Gemma4-12b-uncensored, a large open AI model, and shrink it so it runs in under 8GB of memory while still scoring well across five standard tests. That 8GB ceiling is the point: it is roughly what a normal laptop or a consumer graphics card has, so a model that fits under it can run on a machine someone already owns instead of on rented data centre hardware. It is a contest rather than a finished product, so nothing is proven yet, and the thing worth watching is whether the winning entries hold up on the benchmarks or only look good on the scoreboard.

Tao.com says its new automatic sell orders are its most used feature this quarter

Tao.com, a trading site for TAO and subnet tokens, says the take profit and stop loss tools it added recently have been the most requested and most adopted feature it has launched this quarter, and that its best performing traders are using them. Take profit and stop loss are standing instructions to sell automatically if a price rises to a chosen level or falls to one, so a person does not have to sit and watch. The company says more advanced tools are coming. This is a product update on one venue rather than a change to Bittensor itself, and the claim about who is using it comes from the company with no figures attached.

Kusanagi sets up as a business layer around Bittensor rather than a subnet

A group called Kusanagi has launched itself as a growth layer around Bittensor, meaning it is not registering a subnet of its own but bundling four jobs under one name. It runs a validator, one of the machines that scores work and votes on who gets paid, rebranding the existing MUV validator as its own. It keeps TaoSwap, a site for buying and browsing subnet tokens, as its shop window. It offers to work with subnet teams on strategy and marketing, which is a service most subnets currently do without. And it says it is aiming at a regulated investment vehicle so that traditional money can hold TAO and subnet tokens without anyone having to set up wallets and learn the tooling first. Only the first three exist today, and the regulated vehicle comes with no named regulator, jurisdiction or date, so it is worth treating that part as an ambition until someone else confirms it.

Bittensor writes down who actually produces its blocks, and says that should change within a year

A documentation page was merged into Bittensor's core code that, for the first time in one place, states plainly how the chain itself is run. Right now it uses Proof of Authority, meaning a known, permissioned set of machines takes turns producing blocks and confirming them, rather than anyone with enough stake being able to do it. The page also sets out a non-binding aim to move to Nominated Proof of Stake, where block producers are chosen by how much TAO is staked behind them, within roughly the next year. It carefully separates this from Yuma Consensus, which is the separate scoring system that decides how subnet rewards are split. Nothing about the network changed today: this is a description, not a switch being thrown. What it could mean is that a part of Bittensor most holders never think about, who is trusted to keep the chain running, is now openly acknowledged as centralised with a stated intention to open it up. Worth watching is whether that timeline turns into actual code, since a roadmap target that is explicitly non-binding is a statement of intent and nothing more.

Ditto ships a search that returns decisions, not documents

Ditto, a Bittensor project, says it has shipped a new way of searching a team's own records. Most search tools look for where a word appears, so asking what your team decided about pricing in March returns a pile of documents that happen to mention pricing. Ditto's version combines three approaches at once: plain keyword search, embeddings, which match on meaning rather than exact wording, and a graph, which records how people, decisions and events connect to each other. The stated aim is to hand back the decision itself. It is a real shipped feature rather than a plan, though the claim about quality is the team's own and has not been independently tested, so the thing to watch is whether users report it actually finding the answer.

Upgrade 451 never made it to the live network, so its work now rides inside 452

Earlier this month the developers opened a branch for network upgrade 451, the numbered package of changes that every machine running Bittensor eventually installs. It was built but never got the two signatures it needed to go live on the main network, and two attempted release runs were cancelled. Rather than keep waiting on it, the team has merged a change that renumbers the current code to 452, folding 451's work plus a small internal fix into one package that can ship on its own. Nothing about the network has changed yet: 452 is still sitting in the queue waiting for signatures. What it means in practice is that 451 as a separate release is gone, and anyone tracking which upgrade is next should now be watching 452.

The tightening on built-in shortcuts is now merged

A change we reported earlier as a proposal has now been accepted into the main code. Bittensor lets Ethereum-style smart contracts reach network features through built-in shortcuts, called precompiles. The fix means a shortcut will now only run if it is genuinely being called at its own address, rather than being triggered from somewhere it does not belong. Simple cryptographic ones, which do not touch any stored data, are exempt because they cannot be misused this way. It brings Bittensor in line with the checks Ethereum tooling already applies. It is a defensive tightening rather than a response to anything going wrong, and it will reach the live network as part of upgrade 452.

The shortcut for new machines joining the network is now merged

We reported this as a proposal, and it has now been merged into Bittensor's code, so the status has changed from proposed to done. When a new computer joins the network it normally has to work through the entire history of the chain before it can be useful. Warp sync is a shortcut that lets it jump most of the way by following a trail of signed handover records instead. A one-off historical quirk on Finney, the live Bittensor network, broke that trail and left the shortcut unusable. The fix writes a trusted, known-good checkpoint into the network's settings file so the shortcut has a solid place to start from. For anyone running or setting up a node it means far less waiting, and for everyone else it means fewer barriers to new machines helping to run the network.

Fund prices get one agreed way of being written down

Different tools have been showing the price of a Root fund in different units, which makes two dashboards disagree about the same number for no real reason. Release 450 adds a single on-chain reference point, recording for each fund the starting rate and the block it started from, so every wallet, explorer and bot can convert to the same figure. Nothing about how much anyone owns changes. It is plumbing, but plumbing that decides whether the number you read in one place matches the number you read in another.

New machines joining the network get a trusted shortcut to catch up

A computer joining Bittensor has to work through the chain's history before it can take part. There is a fast path for this, but it needs a known good starting point, and without one new nodes could stall trying to verify their way in. This merged change ships that starting point inside the network's configuration file, a historical checkpoint plus the signatures that back it, so the fast catch up works out of the box. It lowers the effort of running your own node, which matters because a network is only as decentralised as the number of people who can afford to run one.

Bittensor's core code now comes with a rulebook for AI coding assistants

The main repository behind Bittensor has merged a written set of instructions aimed at the AI agents that increasingly help write code for it. The reason given is that submitted changes kept failing the same automated checks over and over: code formatted the wrong way, generated files left out of date, dependency lists not locked to exact versions, documentation not rebuilt. The guidance requires those checks to be run before a change is put forward rather than after it fails. It is housekeeping rather than a change anyone holding TAO will see, but it is a quiet sign of how much of the protocol's own code is now being drafted with machine help, and of the maintainers deciding to set rules for it rather than leave it informal.

A sync fault on the practice network has been fixed

Developers have merged a fix for the test network, the practice copy of Bittensor where changes are tried out before they touch real money. The fault was in the fast catch-up process a new machine uses to download the network's history without replaying every step from the beginning: it was checking one historical point against the wrong list of approvers, so the shortcut failed and the machine could not join. The fix points it at the correct list. This affects only people setting up test machines and changes nothing about the live network, but a broken test network slows down everything that gets tried out on it first.

Safety checks added to the kit developers use to move stake

The Bittensor team merged a set of fixes to its SDK, the ready made code that wallets, bots and tools use to talk to the network so they do not have to write everything from scratch. Six gaps were found while reviewing the upcoming version 448 software, all of them in places where a request could be sent in a state the network would not accept: private submissions that are hidden until they are processed, claiming staking rewards from root, and the sequence where someone claims rewards and then withdraws their stake in one go. The kit now refuses those requests up front instead of letting them fail somewhere later. Nothing changes for people who only use a wallet, but it lowers the chance of a tool built on top of Bittensor losing or stranding a transaction during the switch to the new version.

Green Compute says its GPU rental subnet is now live

Green Compute announced it has launched, and the post drawing attention to it lays out an unusual money flow: customers pay for long term access to GPUs, the specialist chips that AI models run on, and that income is used to buy the project's own token, called alpha. Miners on the subnet have bought the hardware themselves and take years to earn it back, which the supporter argues gives them less reason to sell what they are paid. The pitch is that demand comes from outside crypto, from businesses that want computing power rather than from traders. Two things are worth watching before treating that as proven: we have the team's own launch wording only second hand through a quoted post, and no customer, contract or revenue figure has been named, so the buying of the token described here is a design rather than something anyone can yet measure.

A version clash that was blocking the new software release has been cleared

The automated process that publishes Bittensor's Python software, the version most developers install, failed when it tried to ship the code for the coming version 448 upgrade. The cause was mundane: one of the packages still carried a version number that had already been published, and the system refuses to release the same number twice. The number has now been raised to 0.1.4 across the files that declare it, and the release can go out. Nothing about how the network behaves is affected, but it removes an obstacle to developers getting the tools that match the upgrade waiting to go live.

Moving stake between subnets can be capped at a price you choose

Staking means locking TAO behind a subnet so it earns a share of that subnet's rewards, and each subnet has its own token whose price moves as people buy and sell it. That means a large move of stake from one subnet to another can push the price against you while it is happening, and finish at a noticeably worse rate than the one you saw when you started. Code now merged into release 448 lets you name the worst price you are willing to accept and then pick one of two behaviours: take the whole amount at that price or none of it at all, or take as much as fits under your limit and leave the rest. This is standard protection in ordinary trading and its absence has been a real cost for anyone moving size. It is written and merged, but only takes effect once the 448 upgrade is signed and goes live.

One command now closes every staking position at once

Stake is usually spread out: across several subnets, and across several hotkeys, which are the named keys identifying who you have staked to. Getting out completely used to mean repeating the exit for each one by hand, which is slow and easy to get wrong. A merged change to the command line tool adds an option that finds every live position you hold, removes any duplicates, and submits them all together as a single batch so they either all go through or none do. It is a convenience most of the time, but it also matters when someone wants out of something quickly and every extra step costs them minutes.

The tidy-up that stops the chain remembering old stake links is now merged

Previously reported as a proposal, this change has now been merged into the code. The chain keeps a note of which staking keys a wallet is linked to, and those notes were left behind even after the stake itself was gone, so the records slowly filled up with connections that no longer meant anything. The merged version clears each link once the pair genuinely has nothing staked anywhere, while keeping it if stake still exists on another subnet. It is housekeeping rather than a change anyone will feel, but stale records are what make chain data hard to read and slow to search over time.

Bitstarter turns on a validator that funnels its fees back into new subnet teams

Bitstarter has switched on a validator, which is one of the machines that checks work on the Bittensor network and takes a cut of the payouts for doing so. The unusual part is what it says it will do with that cut: share earnings with the teams it backs and put the fees into buying those teams' tokens, rather than keeping them. The same group says its Pitchtensor competition raised over 800 TAO in its first round and produced two new subnets heading for launch, and it is running the format again at another conference aimed at machine learning teams. It is an attempt to build a funding pipeline for new projects on the network, and the test of it is whether the two subnets it has already funded reach launch and stay there.

The tighter rule for taking over a subnet is now merged into the code

A subnet is one of the specialist marketplaces that make up Bittensor, and each one has an owner who collects a share of what that market pays out. Until now, ownership could change hands when the combined stake of several separate accounts, measured as conviction, meaning stake deliberately locked in place, passed 10 percent of the subnet's eligible tokens. That let unrelated holders be counted together, including stake belonging to the current owner, so a takeover could be triggered by people who were not acting together at all. The rewritten rule, previously only a proposal and now merged into the code, requires a single account to hold conviction above 18 percent on its own before it can take a subnet over. It sits inside network upgrade 447, which is built but still waiting on the second of the two signatures needed to deploy it, so what changed today is that the code is settled, not that the rule is live yet.

The old command line tool now warns on its download page that it has been replaced

Bittensor's command line tool, the program people type commands into to manage a wallet and move stake, was reorganised a while back: the separate bittensor-cli package was folded into the main bittensor one. The problem was that the download page for the old package, on PyPI which is the public library that Python programs are fetched from, gave no sign of that. A warning had been added, but it was written in a format only GitHub understands, so it showed up as raw punctuation instead of a notice. Release 9.23.2 rewrites it in plain text with links to the current package and the documentation. It changes nothing about how the network itself runs, but it does mean someone searching for the tool is less likely to install the wrong one and then wonder why it is out of date.

The code search on Bittensor's developer site stops breaking

The search box that lets developers look through Bittensor's own source code had been failing outright, returning a server error every time it was used, because it tried to read a copy of the code that was not actually present on the machine serving the page. A fix has now been merged: a searchable snapshot of the code is built in advance and shipped with the site, so the search answers from a file it definitely has. This changes nothing for holders and nothing about how the network pays out, but a broken code search on the official developer site is the kind of small friction that quietly puts off the people who might build on it.

Moving stake between subnets can now be capped at a price

When you shift your stake from one subnet to another, the price you get can move between the moment you press the button and the moment the change goes through. Buying and selling already had a protection against that, a limit you set so the deal only happens at a price you accept, but simply moving stake did not. That has now changed in the code: a move can carry a minimum price, and you can choose whether it fills partly or not at all if the price slips past your limit. We reported this as a proposal, and it has now been merged, which means it is written into the software and waiting on the next network upgrade to reach the live chain.

The overcharge on claiming root rewards is fixed in the code

Claiming rewards from root staking, the oldest and simplest way to back the network, shows you a fee estimate before you confirm. That estimate assumed far more work than the job actually involves, because the network cannot hold more than 128 subnets and the quote was not written against that ceiling. The correction has now been merged rather than merely proposed, so the number people are shown should match what the work really costs. Nobody was losing money on the difference, but a quote that is wildly too high puts people off doing something perfectly ordinary.

Linked limit orders are now written into the code

A limit order is a standing instruction to move stake only at a price you name, rather than at whatever price happens to be there. The second version, now merged, lets one order be sized from what an earlier order actually produced, so instructions can be chained: do this first, then put a set share of whatever came out of it into the next step. Orders written the old way keep behaving exactly as they did. What has changed since we last mentioned this is that it is no longer a proposal under discussion, it is in the software.

The chain now keeps a running total of the stake in each subnet

Every subnet issues its own token, called alpha, and people lock that token up to back the operators working in that subnet. Until now the chain kept no single figure for how much alpha was locked in a given subnet, so anything that needed the number had to add up thousands of separate entries one by one. The change adding that running total has moved from proposal to merged. It sounds like bookkeeping, and it is, but it is the kind of figure wallets, dashboards and future rules all lean on, and totting it up by hand is both slow and easy to get wrong.

Bitstarter switches on its own validator

Bitstarter, which helps new teams get started on Bittensor, has turned on its own validator. A validator is one of the machines that judges the work being done on the network and earns a share of the payouts for doing it. Bitstarter says it will use that position to help shape how new teams are scored from their first day, share what it earns with those teams, pay something back to people who stake with it, and put its fees into the tokens of the teams it backs. The validator is live now. How much any of that recycling is actually worth depends on how much stake it attracts, which is worth watching rather than assuming.

Apps built on the Ethereum bridge can now read a wallet's staking list

Bittensor can be used from apps written for Ethereum, the other large blockchain, through a piece of translation software known as a bridge. Those apps had no simple way to ask which accounts a given wallet had staked with, so showing a person their own position was harder than it should be. A merged change adds that lookup, handed over in pages so a very long list does not choke the request. This is plumbing for developers rather than anything a holder will see directly, but it is the sort of gap that quietly decides whether outside wallets and dashboards bother to support the network.

Bittensor's pitch contest says it raised over 800 TAO and sent two teams towards launch

Bitstarter runs Pitchtensor, a live contest where teams pitch an idea for a subnet, one of the specialist networks inside Bittensor that pays people to do a particular kind of AI work, and the room funds the ones it believes in. The organisers say the first round, held at the Proof of Talk conference, raised more than 800 TAO and that two of the subnets pitched there are now building towards going live on the main network. Applications are open for a second round at the Exploit Summit, this time limited to machine learning teams. The figures come from the organisers themselves, and a team heading towards the main network is still a long way from a working product.

The repair to the subnet ownership counters is now merged

Every subnet keeps a running count of its own token, known as alpha, and those counts decide how much backing someone needs before they can take a subnet over. Two of those counters had drifted away from reality over time. The repair was written up earlier this month as a proposal and has now been merged into the code, arriving as part of network upgrade 446, so this has moved from being discussed to being agreed. It only corrects the bookkeeping: it does not create new tokens, move anyone's stake, or undo past transactions. It also narrows the pool of tokens that counts towards a takeover attempt, leaving out holdings that could never support a challenger anyway, which means the bar for seizing a subnet is now measured against a smaller and more honest number.

Leftover data from before last year's big rebuild gets swept off the chain

Every machine that helps run Bittensor keeps a full copy of the network's records, so anything left lying in there costs disk space and time for everyone, forever. A change now merged into the code clears out two kinds of junk: entries from before dTAO, the 2025 rebuild that gave each subnet its own token, and rows that were only ever storing a zero or a default value. It is written to work in small bounded batches and remember where it got to, so the sweep does not stall the network while it runs, and anything holding a real non zero value is left untouched. This is housekeeping rather than a new feature, and nobody using Bittensor will see anything change, but it makes running a node slightly cheaper and slows the steady growth of the chain's stored history.

Nearly half a million doomed transactions a month now get turned away earlier

Every action on Bittensor is written into a block, a permanent page in the network's shared record, and until now some actions that were certain to fail were still being written down before failing. A merged change counts the scale of it: in the last thirty days, 448,600 attempts failed simply because a validator, one of the participants that scores the work miners do, submitted its scores sooner than the rules allow, plus a second batch that failed because the account submitting scores was not permitted to submit them for that subnet. Both are now checked before the attempt is allowed into a block, so they are refused up front instead of consuming space in the record. Nobody's pay changes and no new feature appears: the effect is a slimmer chain and faster, clearer rejections for anyone running validating software.

Leftover data from removed subnet slots is now cleaned up

Every participant on a subnet holds a numbered slot, and attached to that slot they can leave small pieces of data on the chain: sealed submissions waiting to be opened, notes, and the deposits held against them. Until now, when a subnet reduced the number of slots it offers, the participants pushed out left all of that behind permanently. A merged change adds a proper clean-up step so the chain stops carrying records for people who are no longer there. Ordinary slot swaps, where one participant simply replaces another, work exactly as before. It is housekeeping rather than a new feature, it does not change anyone's pay or stake, and it takes effect with the next network upgrade.

Shared wallet transactions stop being charged for work they did not use

Bittensor lets one account act on behalf of another, a setup called a proxy, which is how shared wallets, team accounts and delegated signing work. Until now, when a transaction was sent through a proxy the network charged it for the worst case amount of work the instruction could possibly take, and then quietly threw away the refund when the real work turned out to be less. Direct transactions got that refund, proxy ones did not, so anyone using a shared wallet was paying more in fees than they needed to and taking up more room in each block. This fix passes the real cost back so proxy transactions are billed for what they actually used. It is merged and part of the code now going out. Small on its own, but it is the kind of quiet accounting error that makes the safer, shared way of holding an account cost more than the simple one.

The network stops docking pay from subnets that hold back miner rewards

Every day the network prints new TAO and splits it between subnets, and each subnet is meant to pass a share of that on to its miners, the people running the computers that do the actual work. A recent rule shrank a subnet's slice of the network's payouts if it burned that miner share, meaning destroyed it rather than paying it out, a trick some teams use to support their own token. Upgrade 444, now merged and carried forward into the later upgrades, removes that weighting entirely: a subnet's share is decided by its price average alone, regardless of how it treats miner pay. The same release bundles a batch of smaller repairs, including one that stopped proxy accounts, which let one key act on behalf of another, being overcharged transaction fees. The question worth asking is what is left to encourage subnets to keep paying the miners they depend on, now that withholding that money no longer costs them anything at the network level.

Hardware wallet owners can now read a trade before they approve it

A limit order is a standing instruction to buy or sell a subnet's token only at a price you pick. Until now, anyone using a Ledger, the small physical device people keep their coins on, had to approve one of these by signing a long meaningless string of letters and numbers, so the screen never told them what they were actually agreeing to. A change merged into Bittensor's core code lets the device display the order in ordinary readable words instead. Nothing is taken away, the old method still works alongside it, so this is a safety improvement rather than a new feature. It matters because approving something you cannot read is one of the easiest ways to lose money by accident.

TrendBTC says it handled 200,000 predictions in a single day

TrendBTC, an app where people guess whether the price of Bitcoin, Ethereum or Solana will be higher or lower five minutes from now, says it took more than 200,000 of those guesses in one day, the busiest day it has ever recorded. The number comes from the project itself and nobody outside it has checked it. It is also worth knowing that the app pays people in its own token, called TREND, for taking part, so a high count of guesses shows the product is live and being used but does not tell you how many people would still use it with no reward attached. The claim is a usage milestone, not new revenue or a partnership.

Broken sealed submissions are thrown out on arrival

On some subnets, miners submit their work sealed, meaning it is locked with a time based key so nobody can read or copy it until the network opens everything at an agreed moment. Some of those sealed packages turn up malformed, with the header fields the wrong size, and until now the network stored them anyway and only discovered the problem when it tried to open them. A merged change checks that both header fields are exactly the right size before anything is accepted, and rejects the rest immediately. It is housekeeping rather than a rule change: nobody's rewards move, but junk submissions no longer sit in the network's storage or get in the way of the round where real ones are opened. It lands alongside the earlier repair that stopped valid sealed work being wiped when the network failed to open it.

Root Reborn's record move is spread out so the chain keeps running

Root Reborn is the change that stops rewards from staking to Root, the network's default pool, being paid out and reinvests them instead. Switching it on means moving every existing claim record into a new format, and that move was written to happen all at once, inside the single block where the upgrade lands. A block is one step of the chain, taken roughly every twelve seconds, and doing heavy work inside one of them can slow or stall the network for everyone. This change spreads the move across many blocks and lets it resume where it left off if it is interrupted. Nothing about who is owed what changes, only how the records get there.

The step that makes a transaction permanent gets a bookkeeping fix

A change to Bittensor itself has been merged that tidies up how the network records who is allowed to declare a block final, meaning settled for good and impossible to undo. A small group of appointed signers does that job, and the chain keeps a counter saying which version of that group is currently in charge. If the counter and the group drift apart in the saved history, a computer joining the network from scratch can refuse to trust the records it is downloading. The fix keeps the two in step whenever an administrator changes the signer group, and applies a one off correction for an old mistake in Bittensor's own history at the moment a new machine begins catching up rather than later on. A companion change for the practice network developers test on has been proposed but not yet merged. Nothing about how TAO is earned or paid changes here: the effect is that new machines can join the network and check its history for themselves without needing anyone's help, which is the thing that keeps the chain verifiable by outsiders rather than only by insiders.

Network upgrade 445 ships as a clear-out rather than a rule change

Version 445 of the software that runs Bittensor is out as a finished release, not one sitting and waiting on approvals like the two behind it. It is maintenance rather than new rules: transactions that are guaranteed to fail are now turned away before they are packed into a block, so they stop taking up space and burning fees for nothing; empty and out of date entries are deleted from the chain's storage; and old notes left behind by machines that have long since left the network are purged. None of this changes who gets paid what. It matters because every record the chain keeps forever has to be stored by every machine running it, so a tidier chain is cheaper to run, and cheap to run is what keeps the cost of ordinary actions from drifting upwards.

Paying straight into a Root Reborn basket is switched off while its cost is checked

Root Reborn, the change that reinvests staking rewards instead of paying them out, holds each participant's share in what the code calls a basket. Developers have temporarily closed the route that let someone deposit directly into one of those baskets. The reason is storage: each direct deposit spreads across a validator's full list of scores and can create a fresh record on the chain for every slot it touches, so they want to measure how quickly that would grow the data every node has to keep before letting it carry on. The gate covers that one deposit route, not staking in general, and it is described as temporary pending the review. What we would watch is whether the route comes back with a limit attached or stays shut.

Subnets that hold back miner pay lose part of their share of the network's payouts

Bittensor prints new TAO every day and splits it between its subnets, the separate projects that run on the network, based largely on the market price of each subnet's own token. Subnet owners are allowed to withhold some of the pay meant for their miners, the people running the machines that do the actual work, either recycling that value or destroying it. A change merged on 12 August restores an older rule that takes the withheld portion into account: a subnet's slice of the network-wide payout is scaled down by whatever it did not really hand to its miners. In plain terms, a subnet can no longer keep money back from the people doing the work and still claim the same share of what the whole network pays out. The code is merged but rides out with the next signed network upgrade rather than taking effect straight away, so the thing to watch is whether subnets that have been withholding a large share of miner pay change that once it is live.

Malformed sealed submissions now get thrown out at the door

Some subnets ask miners to publish their work sealed, meaning encrypted so nobody can copy it, and unsealed later at a fixed time. A merged change makes the network check that the two header fields on a sealed message are exactly the right size before it tries to unseal anything, and reject the message outright if they are not. Badly formed submissions no longer sit in storage or get in the way when other miners' work is opened. It is a small piece of housekeeping in the same part of the code as last week's fix for lost submissions, and it mainly saves the network wasted effort rather than changing anything a holder would notice.

Network upgrade 445 is live, mostly tidying up

Runtime 445, the software every machine running Bittensor uses, has shipped. Nothing in it changes what anyone earns. It rejects transactions that were always going to fail before they take up room in a block, deletes storage entries the chain no longer uses, clears out old miner commitments, and makes proxy accounts, which let one wallet act on behalf of another, behave consistently across more actions. For an ordinary holder the effect is a leaner and cheaper chain to run, and it matters mainly as the base that the larger upgrades 446 and 447 are built on top of.

A fix for the bug that could leave a new node stuck

Any machine joining Bittensor has to verify the chain's history before it can follow along, and it does that using a set of signatures whose version number must line up exactly. A mismatch in how that number was advanced could leave a fast-syncing node unable to prove the history and unable to catch up. The fix, now merged, keeps the signature set and its version number changing together in one step, and applies a one-off correction for the main network's early history. A matching correction for the test network is proposed and not yet merged. Nobody holding TAO has to do anything differently, but a chain that new operators can join without hand-holding is a chain more people can afford to run.

Subnets that hold back miner pay now see it reflected in what the network pays them

Every subnet receives a share of the new TAO the network issues each day, worked out from that subnet's price and demand relative to the others. A change merged on 12 August restores an older adjustment to that calculation. If a subnet's owner chooses not to pay out part of the money set aside for its miners, the people running the machines that do the actual work, that withheld portion now scales the subnet's slice of network-wide rewards down too. It applies whether the held-back amount is recycled back into the pot or destroyed outright. It closes a gap where a subnet could keep its full standing in the network while distributing less than the network assumed it was distributing. For anyone holding a subnet's token, it means the reward a subnet draws from the network lines up more closely with what it genuinely hands out.

Subnets get a choice about which scores their reward maths compares against

This shipped quietly inside network upgrade 446 and is live now. Bittensor pays validators partly on how closely their scoring of miners matches everyone else's, and a bond is the record of a validator's backing for a miner that builds up over time. The change lets each subnet pick which round of scores the bond maths compares against: the current round, the previous one, or an automatic setting that uses the previous round when the penalty for disagreeing is at its harshest and the current one the rest of the time. Automatic is the default, so subnets that do nothing get the middle path. It is a dial for subnet owners rather than something a holder can act on, and it does not change how much TAO the network hands out. What it could mean: fewer validators penalised for scores that were right when they made them, though it also gives each subnet one more setting to get wrong.

Root staking rewards get reinvested instead of paid out

Bittensor lets you stake your TAO to the network as a whole rather than backing one particular subnet, an option known as root. A change called Root Reborn, now merged into the code that runs the network, alters what happens to the rewards a root position earns: rather than arriving as a payout, root dividends are automatically reinvested into a basket of subnet holdings on the staker's behalf. It has been prepared for the live network with a gated launch and a migration that moves the old root claim records into the new basket system gradually, across many blocks, instead of all at once. For anyone holding TAO at root this could mean ending up with exposure to individual subnets they did not personally choose, so the things worth watching are how those baskets get composed and how simple it is to step back out.

Network upgrade 446 fixes the counters behind subnet ownership

Every subnet issues its own token, called alpha, and the network keeps running totals of how much of it exists. Release 446, now merged, repairs two historical errors in those totals, which had drifted from reality, and backfills alpha that was burned before the network started tracking burns properly. It also gives each subnet a choice of how a reward smoothing mechanism called liquid alpha reads consensus scores, makes failed decryptions of time locked messages visible in the record rather than silent, and fixes a bug that stopped some nodes catching up with the chain. None of it changes anyone's balance: the release corrects the accounting rather than moving money. It matters because the same counters decide who is eligible to take ownership of a subnet, so wrong numbers there had real consequences.

TAO wallets can now be held on a Ledger device

The TAO Wallet browser extension from tao.com now supports Ledger, the hardware wallet maker whose devices keep the secret key that controls your coins on a small offline gadget instead of on your computer. The practical effect is that malicious software on a laptop cannot move your funds on its own, because every transaction has to be approved by physically pressing a button on the device. Support from an established hardware maker is a normal sign of infrastructure maturing. Worth noting that tao.com is also giving away three Ledger devices as a promotion, so several of the posts circulating about this are marketing rather than news.

Limit orders arrive in tao.com wallets

tao.com has switched on limit orders across its wallets. A limit order is an instruction to buy or sell only at a price you set in advance, instead of accepting whatever the price happens to be the moment you press the button. Subnet tokens are often thinly traded, meaning a single sizeable order can move the price a long way, so this gives holders a way to avoid being filled at a price they never intended. The company says more features are planned and is asking users what to build next.