What’s new

The root reward claims fix is now built into network upgrade 454

What changed: the fix for root reward claims, which we reported as a proposal, has now been merged into the network's code as upgrade 454. Root staking means parking TAO with the network as a whole and being paid out of every subnet. Some claims were failing for reasons that had nothing to do with the claim itself, for example stakes held elsewhere on other subnets, out of date records of which validators a wallet had backed, or holdings so small they rounded down to zero. The merged code is meant to stop those claims being blocked. Being merged is not the same as being live. Like the other upgrades in the queue, it still needs sign-off before it reaches the network.

Upgrade 455 stops restricted helper keys moving money by the back door

Bittensor lets a wallet owner hand a second key, called a proxy, limited permission to act on their behalf, a bit like giving a house sitter a key that opens the front door but not the safe. Two kinds of proxy are meant to be unable to move funds at all. Until now they could still reach the network's smart contract features and its crowdloan feature, a way of pooling money, and those routes could move value indirectly. Upgrade 455, now merged, blocks those routes entirely for both proxy types. This matters to anyone who has set up a restricted proxy on the assumption that it could not touch their money. It joins the queue of upgrades waiting for sign-off and is not live yet.

A proposal would let root fund managers trade inside their subnet baskets

Root validators, the operators who manage pooled TAO on behalf of stakers, can now spread that money across a chosen basket of subnet tokens. A new proposal, called swap basket, would let them trade between the tokens inside that basket. It pulls four earlier draft changes together into a single proposal. The public write-up gives little detail on limits or safeguards so far. What we would watch: how much freedom these managers get to move other people's stake, and what stops a manager from trading in ways that suit them more than the people who delegated to them. It is a proposal only and has not been approved.

Upgrade 453 is built and waiting, and the queue of unsigned upgrades keeps growing

The team behind Bittensor's core software published version 453, a bundle of safety fixes to the network's own rules: checking that the shared source of randomness the network uses for fair draws really is what it claims to be, tightening who is allowed to act on someone else's behalf when moving staked TAO, delaying new subnet registrations until they are properly settled, adding protection to transfers of a coldkey, which is the main wallet key holding a person's funds, and putting the deposits held in beta baskets into proper escrow. As with the versions before it, the automated build system has signed one half of the two signatures needed to switch it on, and it now waits for the foundation's three-person committee to add the second. Versions 448, 450 and 452 are all sitting in the same queue unsigned. Nothing here reaches ordinary holders until someone signs, so the practical news is not the fixes themselves but that a growing stack of security work is finished and parked.

A fix would stop root reward claims failing and charging a fee anyway

A proposed change to Bittensor's core code addresses two separate ways that claiming rewards from root, the network's central pool that pays out to people staking there, can simply fail. The first is a limit on how many entries a single claim can process: the test network now has more subnets, the independent projects that make up Bittensor, than that limit allows, so even the smallest claim is refused. The second is a rounding problem, where one holding small enough to round down to nothing cancels the entire claim, and the person is still charged the fee for it. Neither is a change to how much anyone is paid, it is about payouts going through at all. The change is written down and under discussion, not live, and like every other core change at the moment it would have to join the queue of upgrades waiting on signatures before it reaches the main network.

The wallet and randomness upgrade is now built and half signed

The next version of Bittensor's core software, numbered 453, has been merged into the main codebase and packaged as a finished release. It still is not live. Switching the network over needs two separate approvals, and only one is in: the automated build system has given its half, and the small group of people who hold the second key has not yet signed. The release itself is a set of hardening fixes rather than new features. It ties the outside source of random numbers the network draws on to a fingerprint of that draw, so a result cannot be swapped for a different one; it stops permission limits being lost when one account acts through a chain of stand-ins, which is how a restricted key could end up doing something it was never meant to; it delays new subnet registrations; it adds protection around transfers made from a coldkey, the offline key that actually holds someone's TAO; and it puts early-stage token baskets into escrow. What changed today is only the readiness, not the rollout, and 453 now joins a queue of earlier upgrades that are also built and still unsigned. Worth watching is whether that queue starts moving or keeps growing.

The next network upgrade tightens wallet transfers and fair random draws

Release 453, the newest version of the core software every Bittensor computer runs, has been finished and put in the queue to go live. Its contents are mostly security tightening rather than new features. It binds the outside source of random numbers the network uses for fair draws to a checkable fingerprint, so a tampered value cannot be slipped in. It closes a gap where permission handed to one account to act on your behalf could be passed along further than you intended. It adds extra protection around transfers from a coldkey, the main key that actually holds someone's funds. And it changes how deposits are held when someone registers a new subnet. As with the eight upgrades already waiting, the automated build system has signed its half and the change only takes effect when the three human keyholders produce the second signature, so none of this is live yet.

A proposal would let standing buy and sell orders last six months instead of a week

A limit order is a standing instruction to buy or sell a subnet's token at a price you choose, which sits there until the market reaches that price. Linked orders are pairs of them, where one firing cancels or triggers the other. Right now a linked order gives up and expires after seven days, which means anyone using them has to keep re-entering the same instruction week after week. The proposed change stretches that life to 180 days. It is written down and under discussion, not live. If it goes through it makes the on-chain order book usable for people who want to set a target once and leave it alone, rather than only for those watching the screen. It is filed as a bug fix rather than a new feature, which suggests the seven day limit was never a deliberate design choice.

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.

An investor says many subnet teams are quietly stuck with staff they cannot remove

Siam Kidd, who spends much of his time meeting the teams that run subnets and people hoping to launch new ones, says that in roughly 15 to 20 teams he has seen the same hidden problem: a founder or early employee who was paid, or overpaid, then gradually stopped doing the work, and who the subnet owner now wants out. He describes it as something that is not publicly known. This is one person's account and none of the teams involved have said anything themselves, so treat it as a claim rather than an established fact. If it is widespread it matters to holders for a plain reason: a subnet's token is a bet on a small team continuing to build, and a team carrying dead weight it cannot shed ships more slowly than its posts suggest.

A ninth network upgrade joins the queue, and still nothing has been signed

A new version of Bittensor's core software, called runtime 452, has been built and tagged as ready to go out. It cannot switch on by itself: the change needs two separate approvals before it takes effect, one from the automated build system, which has already given it, and one from the small group of signers who hold the second key. That second signature has not arrived, and it has not arrived for any of the upgrades stacked up behind it either, going back to runtime 447 in mid August. What it could mean is simply a scheduling backlog, with the signers planning to clear several at once. What is worth watching is how long the pile keeps growing, because every fix and improvement in those releases is finished code that no one on the network is running yet.

Network upgrade 452 is built and waiting on two signatures

The team that maintains Bittensor's core software has finished and published another upgrade to the network, labelled 452, and it is now sitting in a queue waiting to be switched on. Upgrades like this cannot be released by one person: two separate keyholders have to approve them, a safety measure called a two of two multisig, and the automated build system has already given one of those two approvals. Until a member of the small group that holds the second key signs, nothing changes for anyone using the network. This is the latest addition to a run of finished upgrades that are all still unsigned, so the thing worth watching is not the code itself but how long the queue keeps growing before any of it goes live.

An eighth network upgrade joins the queue, still waiting to be signed

A new version of the Bittensor software, numbered 452, has been built and tagged, and it is now sitting in the same queue as the ones before it. Upgrades to the network need two separate approvals before they can go live: the automated build system has given one, and the small group of trusted signers known as the triumvirate has to give the second. None of the recent upgrades have had that second signature yet, so the pile keeps growing rather than shrinking. Nothing in this release affects anyone holding TAO until it is signed and switched on, but a queue this long is worth watching, because it means the people who can approve changes are not approving them, and the reason has not been said publicly.

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.

Proposed fix would stop delegated accounts quietly missing their root rewards

Bittensor lets an owner hand limited powers to a second account, called a proxy, so they do not have to sign every routine action with their main key. One of those power sets is the staking proxy, meant to cover everything to do with staking. The problem is that root rewards, the payouts owed to TAO staked into the network's shared root pool, only actually arrive when someone runs a specific claim command, and that command sits outside what the staking proxy is allowed to touch. So an owner who thought they had delegated their staking silently stops collecting, and has to sign a second, separate delegation for a right they believed they had already given. This proposal adds the claim command to the staking proxy's list. It is written down and under discussion, not live. If it goes through it removes a trap that costs people money without telling them, which matters more for anyone running their stake through a custodian or a management setup than for someone holding directly.

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.

An idea doing the rounds would let subnets choose to take less of the TAO they are owed

A community proposal known as fractal emissions is being discussed, and it would let each subnet voluntarily accept a fraction of the new TAO it is entitled to: all of it, half, a quarter, an eighth, or less. New TAO paid out to a subnet gets shared with the people holding that subnet's own token, so taking less would mean fewer new tokens created and less dilution, which is the effect where existing holders own a smaller slice as more tokens appear. Supporters argue it would give young teams a way to survive on a slower burn rather than being forced to spend heavily to keep their place. Nothing here is written into the network's code yet, and it is being argued about in public rather than queued for release, so it is worth watching what the foundation and larger subnets make of it.

A seventh network upgrade is now waiting, and none of the queue has been signed

Bittensor's core software gets updated through numbered releases, and each one needs two separate approvals before it goes live: the automated build system signs first, then a small group of trusted holders called the triumvirate has to add the second signature. Version 452 was built and had its first signature added on 29 August, joining 447, 448 and 450, which are all still sitting unsigned. Nothing in that queue is live on the network yet, so the fixes and changes inside them are written but not running. A backlog this long is worth watching for two reasons: the longer it sits, the more changes land in one go when it finally clears, and it raises the question of why the second set of signatures is not arriving.

A sixth network upgrade is now queued, and the pile of unsigned ones keeps growing

Bittensor's build system has packaged another upgrade to the network's core software, version 452, and submitted the first of the two approvals needed to switch it on. Upgrades here need two signatures: one from the automated build system, which is already given, and one from the small group of trusted signers known as the triumvirate. Version 452 joins 447, 448 and 450, which are all still sitting in the same waiting room. Nothing about the network changes until those second signatures arrive, so for now this is code that is written, tested and idle. The build itself is routine housekeeping, but the queue is not: several upgrades stacking up unsigned means fixes and improvements that were finished weeks ago are still not reaching the people using the network. What we would watch is whether these get signed off in a batch, and whether anyone explains what is holding them.

A fifth network upgrade joins the queue, and still nothing has been signed off

Bittensor's core software is updated in numbered releases, and each one needs two separate approvals before it goes live: the automated build system signs first, then a small group of trusted signers has to add the second signature. Version 452 has now been built and had its first signature added, joining versions 447, 448 and 450 in the same waiting room. That makes a queue five deep with none of them yet switched on. Nothing here is broken and none of these changes affect anyone until they are signed, but a backlog this long is worth noticing: either the signers are working through them slowly, or several changes are being held back to go live together. The question we would ask is whether a queue of this size means more sits untested on the live network when it finally moves.

Proposed fix stops the network overquoting the fee to claim root rewards

A proposed change to Bittensor's core code lowers the fee quoted when someone claims their root rewards, the payout that goes to people who stake into the network's shared pool rather than a single subnet. The quote is worked out from how many subnets the claim has to touch, and it was being calculated as if there were more of them than the network actually allows, so the number shown was higher than the work involved. The change caps it at 128, the real ceiling on subnet count. It is written down and under discussion, not live, and it does not change how much anyone is paid, only what they are told a claim will cost them.

A narrow permission slip would let someone set root weights and nothing else

A proposed change to Bittensor's code adds a new kind of proxy, which is a permission slip one wallet gives another so it can act on its behalf. Today, letting somebody manage which subnets your root stake backs means handing over a wider set of powers than the job needs. The new proxy type, called SetRootWeights, would cover that one task only, so an owner can delegate the curation of their root basket without also handing over the ability to do other things with the account. The authors deliberately made it a fresh permission rather than reviving an older retired one, because reusing the old slot could have silently switched delegations back on that people had long since forgotten about. It is written down and under discussion, not live.

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.

Bittensor updates the maths library that guards its number handling

A proposed change to Bittensor's core software updates two small building blocks it depends on: safe-bigmath, a library for doing arithmetic on very large numbers without silently producing a wrong answer when a figure grows too big for the space it is stored in, and lencode, which packs data into a compact form for storage and transmission. Nothing about how the network behaves changes for users, and no feature is added. It is the software equivalent of replacing a part with a newer version of the same part, done so the rest of the code keeps building cleanly. It is worth noting only because the network counts stake and rewards in very large numbers, so the tools that do that arithmetic are ones people would rather see kept current than left to drift. The change is written down and under review, not yet live.

An outside tracker puts subnet earnings at 32 to 35 million dollars a year

A researcher's index, shared on Friday by the ReadyAI team, estimates that Bittensor's subnets, meaning the independent projects that make up the network, are between them bringing in roughly 32 to 35 million dollars a year from paying customers, spread across about 25 of them. The same index projects a path past 100 million a year. Real outside revenue is the thing critics say the network lacks, so a number attached to it is worth noting, but this is one person's estimate compiled from public figures rather than audited accounts, and none of the subnets named have confirmed the totals themselves. What we would watch is whether individual teams start publishing their own revenue figures, which would let anyone check the index rather than take it on trust.

A version number mix-up blocked the toolkit release, and a fix is proposed

The automated process that packages Bittensor's developer toolkit, the software libraries other people use to build on the network, failed part way through. The reason was mundane: one of the packages was still labelled with a version number that had already been published, and the system refuses to publish the same label twice. A proposed change bumps that label so the release can go out. Nothing about the network itself changes here, and holders are not affected, but until it is merged the newest toolkit does not reach the public package archive where developers download it from, which slows anyone building against the latest network upgrade.

The next upgrade would have the network publish one official price for staking baskets

The proposal behind the pending 450 upgrade says what that upgrade actually does, and it is about numbers agreeing. When you stake TAO you often hand it to a validator, one of the machines that checks the network's work, and your share sits in what the code calls a basket. Today each wallet, explorer and app works out what that share is worth using its own arithmetic, so the same holding can show a different value depending on where you look. The change would make the network itself publish those figures: the raw price, a display price adjusted so baskets can be compared with each other, the yield a staker is earning, and a total return price. It is written down and waiting on the same two signatures every upgrade needs, so it is not live yet. If it lands, the practical effect is that the number you see in one place should match the number you see in another, which matters most when someone is trying to check what they hold rather than take a site's word for it.

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.

Three network upgrades are now stacked up waiting on the same two signatures

Bittensor's core software is updated in numbered releases, and each one only goes live when two key holders sign it off: an automated system submits the first half of the approval, and a small group of humans has to provide the second. Release 448 was built and submitted on 21 August and is still sitting there unsigned. Since then 450 and 452 have been built and submitted too, so three separate upgrades are now queued behind the same pair of signatures. Nothing is broken and nothing about the network has changed, because code that has not been signed does not run. What it could mean is that these fixes arrive together in one burst rather than steadily, and that the pace of network improvements depends on how quickly a handful of signers get to them. Worth watching: whether 448 is ever signed at all, or quietly folded into a later release, which is what happened to the unshipped 449 when its work was rolled into a bigger release numbered 500.

Proposed shortcut lets a new node trust a known signpost instead of replaying years of history

A proposed change to Bittensor's core software would let a computer joining the network start from a trusted signpost written into its setup file, rather than checking every block of history from the very beginning. The signpost is a historical record of which validators were in charge at a given moment, along with the signatures proving it. Bittensor already had a one-off patch of this kind baked in for the main network, and this proposal turns that special case into a proper, reusable setting. In plain terms it is about how quickly and cheaply someone can spin up a node, the machine that holds a copy of the network and helps run it. If it is accepted, running your own node gets less demanding, which matters because a network is only as decentralised as the number of people who can afford to participate. The trade-off worth watching is that trusting a signpost means trusting whoever put it in the file, so the question is who decides what goes there. It is written down and under discussion, not live.

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.

Proposed tightening stops built-in shortcuts being called from the wrong place

Bittensor's chain has a set of built-in shortcuts, known as precompiles, that let smart contracts call ready-made network functions such as staking without writing that logic themselves. A newly opened proposal would require that a shortcut is only run when the contract actually being executed is the shortcut itself, rather than allowing one contract to reach for it while pretending to be somewhere else. Pure cryptography helpers, which hold no state and cannot be abused this way, are exempt. It brings Bittensor in line with a check that already exists in Frontier, the shared codebase it borrows its Ethereum compatibility from. It is written down and under review, not live, and for an ordinary holder it changes nothing visible: it is housekeeping meant to close off a class of trickery before anyone finds a use for it.

The branch for the next network upgrade, 451, is opened

Bittensor's core developers have opened the branch for the next network upgrade, numbered 451. A branch is simply a labelled copy of the code where the next release gets assembled before anyone votes on it. Right now it holds nothing at all: it is identical to the main code, changes no behaviour for anyone running the network, and needs no action from holders. Its only meaning today is one of pace, that work on the release after 450 has formally begun while 450 itself is still waiting on its second signature. What actually gets added to it over the coming days is the part worth watching.

Root payout fix protects subnet owners' rewards and unblocks stuck baskets

A proposed change to Bittensor's code tightens up Root Reborn, the rebuilt version of Root where TAO staked at the network level sits in baskets run by fund managers. It does three things. First, a basket that has run dry or grown unusually large no longer stops healthy claims from other people going through, so one broken pot cannot hold up everyone else's withdrawal. Second, it adds automated tests that prove the accounts belonging to subnet owners keep their Root rewards instead of having them destroyed, which is the kind of quiet accounting bug that only shows up once real money has already gone missing. Third, it removes a leftover check from the changeover to the new system, now that the changeover is finished on the live network. This is written down and under review, not live yet, and it is maintenance rather than new capability: the value is in what it prevents.

Network upgrade 450 is built and waiting on two signatures

The next upgrade to Bittensor's core software, numbered 450, has been packaged and half approved. Upgrades here need two signatures before they go live: the automated build system has given one, and the group of trusted signers known as the triumvirate has to give the second. The headline part of this release is the change that was proposed earlier in the month, giving fund prices one agreed way of being written down: the network itself will now publish the price and performance figures for validator baskets, which are the pooled stakes people put money into. Until now wallets, explorers and dashboards each worked those numbers out their own way, so the same basket could show a different value depending on where you looked. Once signed, everyone reads the same number from the same place. Nothing changes for holders until that second signature arrives.

The unshipped 449 upgrade is folded into a bigger release numbered 500

Bittensor's core software ships in numbered bundles called releases. Release 449 was written but never went live, and its main change was the rule letting Root fund managers choose which subnets they back, with a ceiling of one sixteenth on any single bet. That work is now being rolled into a new bundle numbered 500, alongside a standard way of recording fund prices on the network itself, so wallets, explorers and other apps all read the same figure rather than each working it out their own way. The change since we last covered 449 is that it is no longer shipping on its own. Nothing here is live: this is a proposal still under review, and a release only takes effect once two separate signing keys approve it.

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.

Developer toolkit would check you can afford a transaction before you sign it

A proposed change to the Bittensor software development kit, the toolkit developers use to build things on the network, would tighten up its practice run feature. A practice run lets you see what a transaction would do before you commit to it. At the moment a practice run can come back looking fine even when the wallet behind it does not actually hold enough to cover the cost, because the price of registering on Root moves and things like fees, locked balances and the small minimum a wallet must keep are not all counted. The change works out the real cost up front, shows it as planned spend, and refuses to go ahead if the money is not there. It is not live yet, it is written down and under review, and if it lands it mostly means fewer failed transactions and fewer wasted fees for people building on 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.

Standing orders that last six months will finally keep their paperwork that long

The chain supports advanced orders that stay open until filled or cancelled, signed to last 180 days. A developer spotted that the record other systems need in order to read such an order was being thrown away after only seven days, so an order could still be live while the trail connecting it to anything downstream had already expired. The proposed fix raises that retention to 180 days so the two match, and bumps the runtime version from 450 to 451. It is not live yet, and it is a good example of a mismatch that would only have shown up weeks after the fact.

Proposal keeps the forwarding address alive when an account is swapped out

Accounts on Bittensor use a hotkey, the key that signs day to day activity. When someone swaps to a new hotkey the chain keeps a note pointing from the old one to the new one, so automated contracts can still find where the money went. Right now that note gets wiped if the account is also removed from a subnet shortly afterwards, which can happen in the same batch of transactions, leaving a contract with a dead end. The proposal keeps the forwarding note until the subnet itself is shut down. For an ordinary holder this is invisible until it is not: it is the difference between funds being locatable and being stranded.

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.

The wrapped version of TAO moves into the main codebase

WTAO is a wrapper: a smart contract that holds your TAO and gives you a token representing it, in the standard format that most on-chain applications know how to handle. It has been maintained separately until now. This proposal copies the contract, its tests and its deployment setup into Bittensor's main repository, unchanged, so it is versioned and reviewed alongside everything else. It does not create anything new for holders to use today, but keeping the contract that stands between users and their TAO in the main tree makes it harder for it to drift out of sight.

Wallet balances would stop showing nine decimal places

A proposed change to btcli, the command line tool people use to manage their wallets, rounds displayed balances to three decimal places instead of nine. The exact figure is still kept behind the scenes and in machine readable output, so nothing about accounting changes, it is only what a human is shown. Small, but it removes a wall of digits from the screen most holders look at most often.

Bittensor plans to hand block production to stakers within a year

New official documentation, now merged into Bittensor's core code, spells out how the chain itself is run today and where that is heading. Right now blocks are produced under Proof of Authority, meaning a small set of approved computers run by the foundation keep the chain moving. The docs state a roadmap target of moving to Nominated Proof of Stake within roughly the next year, a system where anyone staking TAO can back the machines that produce blocks, spreading that job across the community instead of one organisation. It is described as a non-binding target, so treat it as a stated direction rather than a promise, but it is the clearest written commitment yet to decentralising the base of the network.

The following network upgrade is now built and half approved

Runtime 448, the network upgrade after the one already waiting to go live, has moved from being prepared to being fully built and tagged. Deploying it needs two signatures, and the first has been submitted automatically by the build system; it goes live once the council that oversees upgrades adds the second. A runtime upgrade is a change to the rules the whole network runs on, so the steady cadence here, one upgrade queued and the next already signed off halfway, shows the core developers shipping on a regular rhythm.

Six more safety checks added to the developer kit before the next upgrade

The SDK, which is the kit outside developers use to build tools that move TAO for people, is getting six more safety checks written into it. They were found while reviewing how the software behaves under release 448, the network upgrade currently waiting on a final approval, and every one of them concerns an action that moves money: sending a shielded transaction, meaning one kept hidden until it is settled, claiming rewards from root staking, running an action wrapped on someone else's behalf, claiming and unstaking in a single step, and confirming a transaction is genuinely final. In each case the tool could previously go ahead in situations where the limits a user had set should have stopped it. The change makes those checks run first and refuse outright rather than continue. It is written and under review, not merged, so nothing has changed in the software people are running today.

One command would close staking positions across all your keys at once

A proposed addition to btcli, the official command line tool for Bittensor, would let someone exit every staking position they hold in a single command rather than one key at a time. Staking here means locking TAO behind a key to back a subnet and earn a share of what it pays out, and anyone who has been active a while tends to end up with positions scattered across several keys and several subnets. The new option finds every live position, removes any key it has already counted, and submits all the exits together as one batched transaction, so either they all go through or none do, which avoids the half finished exit you can get by running them separately. It does not change what unstaking costs or how long it takes, and it is still under review rather than merged.

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.

The code search on Bittensor's developer site stops erroring

The website that documents Bittensor's own source code has a search box, and in production it has been returning an error instead of results. The reason is mundane: the search was trying to read through a copy of the code on the server every time somebody typed a query, but the hosting service the site runs on does not keep that copy around. A proposed fix builds a searchable snapshot of the code once, when the site itself is built, and ships that snapshot alongside the pages. It is a small repair and it only affects people reading the code rather than anyone holding or staking TAO, but a broken search on the main reference site is a real obstacle for new developers trying to understand how the network works. It is written and under review, not yet live.

The next network upgrade now needs just one more approval

The version of Bittensor's core software known as runtime 448, which we last reported as being prepared behind the release before it, has now been formally submitted for deployment. The change has moved on: the code is frozen at a tagged version, and the automated build system has already given the first of the two approvals needed to push it onto the live network. A network upgrade here requires two separate signatures before it can go anywhere, a safeguard so that no single party can change the rules by themselves. The second must come from the small group of custodians who hold the network's administrative keys. Until one of them signs, nothing changes for anyone using the network, and the upgrade sits in a queue rather than being live.

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.

Subnet owners could soon change a payout setting from code instead of by hand

A proposed change to Bittensor's own software would let programs running on the network read and change a subnet's liquid alpha consensus mode. Liquid alpha is one of the dials that decides how strictly a subnet's judges have to agree with each other before workers get paid, and today that dial is set manually by whoever runs the subnet. The change would expose it to smart contracts, which are small self-running programs, so a subnet could adjust the setting automatically or hand control to a group vote instead of one person. It is written down and under discussion, not live, and the trade-off worth watching is that anything a contract can set automatically can also be set wrongly at speed.

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.

The release after the one waiting to go live is already being prepared

A proposal numbered 3109 raises the network's internal version number from 448 to 449. That is bookkeeping and nothing else: no rule, no payout and no piece of behaviour changes, it simply gives the next batch of work a label so that computers running the network can tell it apart from the version currently waiting on signatures to go live. It is a small but useful signal of pace, because it means work has already moved on to the release after the one still queued.

Tools would be able to ask for the last block that can never be reversed

A proposal adds a way for software to ask the network not just for the newest block, meaning the latest batch of recorded transactions, but for the newest one that has been finalised and so can no longer be undone. On a blockchain the most recent block can still be replaced in rare cases, and anything built on top of it can end up acting on something that never really happened. Exchanges, dashboards and trading tools generally want the finalised number instead. The change is for people building on Bittensor rather than for ordinary holders, and it is still a proposal.

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.

The next network upgrade is built and waiting on two signatures

Bittensor's core software is updated in numbered releases called runtimes, and version 448 has now been packaged and put forward for approval. Switching it on needs two separate approvals from a small group of key holders, and the automated build system has already given one of them, so the code sits finished and unused until the second arrives. The release carries two changes an ordinary holder would notice: clearer quotes for the fee charged when claiming root staking rewards, and the ability to set a price limit when moving stake between subnets. Nothing changes for anyone on the live network until that second signature lands, so the gap between a release being tagged and being approved is the period where the network is running on older code than the one that has been written.

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.

A proposal would let people buy subnet stake with dollars from a MetaMask wallet

A new proposal, written down but not accepted, would build an official route from dollar stablecoins into staked subnet tokens on Bittensor. USDC is a token that tracks the US dollar, and MetaMask is the browser wallet most people outside this ecosystem already have. Under the plan each subnet would get a matching token on the outside chain, created only when genuine subnet stake is locked in escrow to back it one for one, and that balance would grow by itself as the locked stake earns rewards. Selling would unwind the position back into dollars. Today anyone wanting exposure has to learn Bittensor's own wallet software first, so the barrier this removes is a large one, and that is exactly why the design details matter: who holds the escrow, who is allowed to create the outside tokens, and what happens if the two sides ever stop matching. It is at the design stage, so those are questions to ask rather than answered.

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.

Smart contracts would be able to claim root staking rewards on their own

Root is the base layer of Bittensor where TAO can be staked without picking a particular subnet, and the rewards there have to be actively claimed rather than simply arriving. At present that claim has to come from a person holding a wallet. This proposal adds a hook so that an automated program running on Bittensor's contract layer can make the claim itself when it is the one holding the stake. The practical effect, if it ships, is that products which stake on behalf of many people at once could collect and reinvest rewards without anyone pressing a button, which is how most automated savings products in this space work. It is proposed and under discussion, not live.

Holders would be able to watch their stake while a subnet is wound down

Subnets can be closed down, and when that happens the people holding stake in them currently get little visibility into what is left and at what point. A proposal adds a plainly recorded status for every subnet, showing whether it is registered, running, marked for closure or actively being dissolved, and keeps reporting each holder's remaining stake through the whole process. Nothing about how a shutdown actually works or how money is settled changes here. It only makes the state of things readable, which matters mainly to anyone who has been holding a subnet token when its team walks away.

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.

A second correction to the fee quoted when claiming root staking rewards

A new proposal has been filed to fix the fee estimate shown to someone claiming rewards from root, the shared pool where people can stake TAO without picking a particular subnet. This follows an earlier fix for the same area and deals with a narrower case: a wallet using a single operating key was still being quoted more than the claim should cost. Nothing here changes how much reward anyone earns, only the number displayed before they confirm. It is written down and under review, not yet live on the network. What it could mean: fee quotes that come in high are the kind of small friction that quietly discourages people from claiming at all, so a pair of corrections in a week suggests the team is treating the claim path as something worth polishing.

Bittensor's core code repository writes a checklist for AI coding assistants

A proposal adds a set of house rules to the main Bittensor code repository aimed specifically at automated coding agents, the AI assistants now submitting patches alongside human developers. It grew out of a pattern of failed automated checks: agents were sending in work that broke formatting, skipped regenerated documentation, or drifted from the locked list of approved software versions. The rules ask them to run those checks before submitting rather than after. It is proposed and under discussion. What it could mean: the people maintaining the chain that Bittensor runs on now consider AI contributors a large enough share of incoming work to write guidance at them directly, which is a quiet but real change in how the protocol gets built.

Bittensor writes down who actually runs its blockchain, and how that is meant to change

A new page proposed for Bittensor's developer documentation sets out in one place how the underlying blockchain is secured today: by a fixed, permissioned set of block producers, an arrangement known as Proof of Authority. It names the two pieces of software involved, Aura, which decides whose turn it is to produce the next block, and GRANDPA, which decides when a block is final and can no longer be reversed. The page also states a roadmap target, described as non-binding, of moving within roughly the next year to Nominated Proof of Stake, where a producer earns its turn by having enough TAO staked behind it rather than by being on a chosen list. It deliberately separates this from Yuma Consensus, the entirely different scoring system that decides how subnet rewards get shared out, because the two are routinely confused. Nothing changes today, this is a document rather than code, but it puts an official intention and a rough timeframe on a shift that would widen who controls the chain itself.

A tidy-up would stop the chain remembering stake you no longer have

When you stake TAO you create a record linking your wallet to the validator key you staked to. A proposed change points out that this link is currently left behind even after you have taken every last token back out, so the chain accumulates a list of connections that no longer mean anything. The change deletes the link once a wallet and key genuinely have nothing staked anywhere, while keeping it if there is still stake on another subnet or a balance waiting to move. No balance is affected and nothing looks different to a normal user. The gain is housekeeping: less dead data for the chain to carry and for wallets and dashboards to read through, the sort of change that keeps things quick rather than adding anything visible.

An official JavaScript toolkit for Bittensor is put forward

Most websites and apps are built in JavaScript, but until now anyone wanting to connect one to Bittensor had to rebuild the tricky parts themselves: handling the secret keys that control a wallet, signing instructions the network will accept, and reading data back off the chain. A proposal on Bittensor's code repository adds a first-party TypeScript toolkit, TypeScript being the version of JavaScript most professional web teams use, so those pieces come ready made and are shared with the same underlying code the network itself runs. It is written down and under review, not live, so nothing changes today. If it is accepted, the practical effect is that building a normal web app on top of Bittensor becomes closer to ordinary work than specialist work, which is usually what decides how many people bother to try.

Another network upgrade, number 446, is packaged and waiting for a second signature

Bittensor's core software gets updated in numbered releases, and each one has to be approved by two separate holders of keys before it goes live on the main network, a safeguard so no single person can push code onto the chain. The automated build system has already given its approval for release 446 and the code is tagged and ready, but it will not take effect until the second group of signers, a three-person council known as the triumvirate, adds its approval. Until then nothing changes for anyone using the network. Worth noting that this is one of several releases sitting in the queue rather than a single isolated one, so the thing to watch is not the code itself but how quickly signatures arrive.

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.

Network upgrade 447 is built and waiting on the second signature

Bittensor's rules live in software running on the chain itself, and changing them means shipping a numbered upgrade. Version 447 has been built and tagged, and the automated half of a two signature approval has already been given. It goes live only when the second signature arrives from the small group that holds it, so until that happens nothing on the live network has changed. The tag is the exact code that will be deployed, which is how anyone can check in advance what they are about to receive.

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.

A proposal would let validators work from a limited key

Validators are the machines that score the work miners do and decide who gets paid, and today the key that signs that scoring can normally do everything else the account can do, including moving the money behind it. A proposal now in review adds a restricted key, called a Validate proxy, that is allowed to do validator jobs only: setting and revealing scores, publishing the address a validator answers on, and linking an Ethereum address. If it is accepted, whoever owns the stake could hand that limited key to whoever runs the machines day to day without handing over the funds, so stealing the key would buy an attacker much less. It is written down and under discussion, not live.

The fee quoted for claiming root rewards would be cut to match reality

Root staking is the way to back the network as a whole rather than one subnet, and claiming the rewards from it costs a fee that scales with how many subnets have to be touched. The chain has been quoting that fee against a fixed ceiling of 256 subnets even though far fewer exist, so people were shown a bill far larger than the work actually being done. Two proposals would fix it, first by capping the quote at 128 and then by reading the live number of subnets instead, and by ignoring leftover records of subnets that no longer exist so those ghost entries stop padding the total. Nothing is live yet: the work is packaged into a proposed network upgrade, spec 448, which needs approval before it reaches the main network.

Limit orders for moving stake would gain linked orders

A limit order is an instruction to buy or sell at a price you set rather than whatever the price happens to be at the time, and Bittensor has been building that directly into the chain for moving stake between subnets. A new proposal, called Limit Orders v2, adds linked orders, meaning orders tied to one another so that one of them firing changes what happens to the other rather than each sitting there alone. The proposal was filed with almost no written description, so how the linking actually behaves is not spelled out in public yet, and none of it is live: this is code offered up for review.

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.

A proposed fix would change how pay is totalled in subnets running several contests at once

A subnet can run more than one competition side by side, each scoring its participants separately, and the network has to combine what each competition owes before it pays anyone. A developer has pointed out that the current code combines figures that are not measured on the same footing, which can distort the split between the people running the machines and the people scoring their work. The proposed change adds the payouts across the competitions as a straight total instead. It is written down and under discussion rather than live, and if adopted it would mostly affect the handful of subnets already using the multiple competition setup, not every holder.

A proposal would repair the ownership locks an earlier upgrade recorded wrongly

To challenge for ownership of a subnet, one of the small networks that make up Bittensor, someone has to lock up alpha, the subnet's own token, to show they are serious. That is called conviction. A proposal now open on the code repository says an earlier network upgrade, runtime 443, moved one of those locks forward without updating the running totals behind it, so on some subnets the figures the takeover rule is measured against are simply wrong. The change would correct that accounting, repair the entries left in a bad state, make an ownership handover update each holder's own lock rather than only the shared total, and require a challenger to meet the threshold on their own rather than leaning on stake locked by unrelated people, including the sitting owner. It is written down and under discussion, not live, and part of the same ground has since been covered by the tougher single holder gate that was merged into the next upgrade. What is worth watching is whether the repair lands before the new rule is judged against numbers nobody has yet confirmed are accurate.

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.

A paused way of spreading a stake across many subnets would be switched back on

Bittensor has a feature that lets someone put TAO into a basket, a single pot that holds stake across several subnets at once, a bit like an index fund rather than picking one project. It was switched off in an earlier change while developers checked how much extra record keeping it would force onto the chain. This proposal turns it back on with the pricing of deposits corrected: joining a basket is now priced in the same units the basket actually holds, alpha, which is the token each subnet issues, instead of being priced against the basket's headline TAO value. In plain terms, that is meant to stop someone paying in at a price that does not match what they would get back on the way out. It is written down and under discussion, not live.

A proposal would make the wait on handed-over validator keys the same everywhere

Bittensor lets a validator hand part of its earning power to a second key, called a childkey, so another operator can do the work on its behalf. A new childkey does not count straight away: there is a cooling-off wait first, which stops someone shuffling keys around to game the payouts. Today that wait is counted in blocks, the fixed ticks of the chain, but each subnet runs its scoring round on its own clock, so the same wait lands very differently depending on which subnet you are on. The proposal, part of a draft release numbered 441, would count the wait in the subnet's own rounds instead, two of them, so the delay means roughly the same thing everywhere. It is written down and under discussion, not live.

A proposal would stop server operators waiting on paperwork for the software the network is already running

When Bittensor upgrades itself, the ready-made software package that the people running the network's servers install is only published once a release has been approved by hand. That leaves a window where the live network is running new code and the operators cannot easily get the matching build. The proposal adds an automatic watcher that checks the live chain every ten minutes and publishes the matching package itself, but only after confirming the code it is about to publish really is the code the network is running. For an ordinary holder this changes nothing directly: it is plumbing, and its value is fewer machines running out-of-date software during an upgrade. It is a proposal, not yet in force.

A proposal would stop Bittensor quietly breaking apps built on its Ethereum bridge

Bittensor lets Ethereum-style software talk to it through small built-in shortcuts called precompiles, which give outside apps a direct line to things like staking, balances and transfers. A proposal now on the table would publish documentation for every one of those shortcuts, both the ones that exist and the ones being planned, and set rules for changing them: each version has to be labelled, older versions have to keep working, and any change that would force developers to rewrite their code has to offer a migration path before it reaches the live network. It is written down and under discussion, not in force. For someone who does not code this matters only at one remove, but it is the difference between a wallet or dashboard that keeps working and one that breaks overnight, and it is the sort of dull promise that outside teams look for before they commit to building on a network at all.

A fix would stop one unsigned upgrade holding up the next one

New versions of Bittensor's core software go out through an approval queue: a release is built, then named people have to sign off before it can be published. Right now that queue is shared across every version, so a release nobody has got round to approving can sit in the way and hold up a newer one behind it. This proposal gives each version its own slot in the queue, so a stalled approval only stalls its own release and later work can still go out. Nothing about how the network pays people or how staking works changes here, it is purely about how quickly finished work reaches users. It is topical because two upgrades, 446 and 447, are both sitting and waiting on signatures at the same time.

A proposal would keep a running total of the stake held in each subnet

A change proposed to Bittensor's core software would add a single running total of all the stake held inside each subnet. Stake here means alpha, the token each subnet issues to the people who put money behind it. Right now, to know how much alpha a subnet holds in total, the chain has to add up every individual holder's balance one at a time, which is slow and easy to get subtly wrong. The proposal keeps one number per subnet and updates it every time anyone's stake moves, so the total is always available instantly. Nothing about pay, emissions or who owns what would change. It matters because several recent repairs to the network, including the fixes to the rules on taking over a subnet, were needed precisely because these totals had drifted out of line with reality. This is written down and under discussion, not live, and it would still need to pass through a signed network upgrade before anyone sees it.

A proposal would add a limit when moving stake between subnets

A new proposal has been opened on Bittensor's own code, titled Move Stake Limit. Moving stake means shifting the TAO you have committed to one subnet across to another, and today that move goes through at whatever rate exists at the moment it lands. A limit would let the person doing it set the worst rate they are willing to accept, so a move made while prices are shifting cannot complete on much worse terms than expected. The write-up attached to the proposal is bare, pointing only at an earlier issue rather than explaining the change, so the exact scope is not yet spelled out in public. It is a proposal, not live code, and nothing changes for anyone until it is reviewed and included in a network upgrade.

Claiming root staking rewards would leave one chain entry instead of about 38

A proposed change to Bittensor's code would make claiming root staking rewards far lighter on the network. Root staking is where someone stakes TAO to the network as a whole rather than to a single subnet, and the reward now comes back as a basket of many different subnet tokens. Today each claim writes a separate transfer record for every holding in that basket, roughly 38 records for one claim, which clogs the chain's history and costs more to process. The change would quietly deduct from each source and write a single combined credit instead. It is written down and under discussion, not live. If it lands, claiming should be cheaper and the chain's record smaller, with no change to what a staker actually receives.

The tougher rule against subnet takeovers is now said to be in force

Each of Bittensor's subnets, the separate marketplaces that make up the network, has an owner, and ownership can be taken from that owner by whoever locks up enough of the subnet's own token to prove commitment, a measure the code calls conviction. We reported this rule being rewritten and packaged into network upgrade 447, at which point it was merged into the software but still waiting on the two signatures needed to deploy it. A widely followed Bittensor analysis account now describes that change as having shipped last week, with the bar for a challenger moved from 10% of the eligible tokens added up across many accounts to 18% held by one single account. The people who run the upgrade have not themselves announced it as live, so treat the timing as unconfirmed, but if it is in force then seizing a subnet is now considerably more expensive and much harder to do by quietly pooling several small holdings. Worth watching: whether any subnet changes hands under the new bar, and whether the foundation confirms the deployment.

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.

Stripe is reported to be buying the AI marketplace OpenRouter

OpenRouter is a shop front for artificial intelligence: an app sends it a request, and it passes that request on to whichever company's AI model will answer it, so a developer can reach dozens of models through one connection instead of signing up to each one. A Bloomberg report, relayed into the TAO community on X, says the payments company Stripe has agreed to buy it for more than seven billion dollars, which is over five times the 1.3 billion dollar value put on the company in a fundraise less than three months earlier. Neither Stripe nor OpenRouter has said so in their own words in anything we have seen, so this is a report rather than a settled fact. It is worth noting here because several Bittensor subnets sell access to AI models for a living, and OpenRouter is one of the places buyers go looking, so who owns that shop front, and what it decides to charge for, is something we would keep an eye on.

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.

New subnets would start with a tiny pool and a cap on their own price

Starting a new subnet means paying a large registration fee, and today most of that money is dropped straight into the subnet's own trading pool, which is what sets the opening price of its token. A proposal in the core code would change that: every new pool would open with the same tiny amount, one TAO matched against one of the subnet's own tokens, and the rest of the fee would be recycled back into the network rather than injected into the pool. It would also cap the price a shallow pool can claim when the network works out how much of the daily payout each subnet gets, because a pool holding very little money can be moved a long way by a small trade. The stated aim is to stop a cheap price push on a brand new subnet turning into a real slice of everyone's emissions, the TAO the network hands out each day. It is written down and being discussed, not live.

Hardware wallet holders would get to sign shared accounts from the command line

Some decisions on Bittensor need more than one person to sign off, through what is called a multisig: an account controlled by several keys, where a set number of them have to approve before anything happens. At the moment the official command line tool expects every signer to have a wallet file sitting on the machine they are typing on, which effectively shuts out anyone who keeps their key on a hardware device, in a vault or in a browser extension. A proposed change would let those signers approve from wherever their key actually lives, and cleans up the prompts so the tool asks who is signing instead of simply failing. This is housekeeping rather than a change to any rule, but it decides who can realistically take part in the approvals that network upgrades depend on.

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.

The command line tool stops showing subnet owners the same settings list twice

btcli is the official command line program that subnet owners use to change their subnet's settings, the numbers that control how it pays out and how it scores work. When an owner ran the settings command without naming a specific setting, the tool printed a table of all the current values, then printed a near identical second table underneath it purely so they could pick a number from it. A proposed change puts the selection numbers onto the first table and deletes the duplicate, so there is one list instead of two. Nothing about how the network behaves changes, but it removes a spot where it was easy to read one table and click a number from the other. It is written and under review, not yet in the released tool.

A proposed way to move between subnet tokens in one instruction

Bittensor developers have written up a new kind of trade order for the network. Each subnet has its own token, called alpha, and today moving out of one subnet's alpha and into another's takes two separate steps, with the awkward part being that you have to guess the size of the second step before you sign it, because you do not yet know what the first step will produce. The proposal adds linked orders, where the second instruction is sized as a fraction of whatever the first one actually returned, so a rotation out of subnet 7 and into somewhere else can be written once and left to run. It also adds limit orders, meaning an order that only goes through at a price you set rather than whatever the market happens to offer at that second. This is written down and under review, not live, so nothing changes for anyone yet. If it does ship, it would make shifting between subnets less fiddly and less exposed to the price moving in the gap between the two steps, which is the sort of plumbing that quietly shapes how much trading happens.

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.

Developer tools would gain a direct way to ask which blocks are final

The software kit developers use to talk to Bittensor is proposed to get one small addition: a single instruction that returns the most recent finalised block, meaning the latest batch of network activity that can no longer be undone. Anyone building a wallet, a dashboard or a payment tool currently has to work that out themselves, and getting it wrong means telling a user their transfer has settled before it truly has. This is proposed rather than merged, and it changes nothing for a reader who does not write code, but it is the sort of detail that decides whether the apps people use report a payment as done at the right moment.

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.

Upgrades get rehearsed harder on a copy of the live network

Before a change to Bittensor goes out, it is run against a clone of the real chain. This proposal makes that rehearsal stricter: it fails automatically if building a single block takes four seconds or more, or if the chain stops making progress for twelve seconds, and it adds a longer run covering complete payout rounds, called epochs, on every active subnet. An epoch is the round in which the network works out who gets paid. None of this changes a rule that affects holders. It is a check on whether an upgrade quietly slows the network down, which is the kind of fault that only shows up under real load.

A sync fix for the practice network developers test on

Bittensor runs a test network, a full copy of the system using worthless coins so developers can try things without risking money. New machines joining it can use a shortcut called warp sync, which skips replaying years of history and instead trusts a handful of signed checkpoints. Those checkpoints named the wrong group of signers, so the check failed and the shortcut did not work. This proposal lists the correct signers for each checkpoint. Nothing on the live network changes and no holder is affected, but a test network that is awkward to join makes it slower for anyone building on Bittensor to try their work safely first.

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.

Subnet owners would get about a day to save their slot before being pushed out

Bittensor caps how many subnets, the independent networks that run on top of it, can exist at once. Today, when someone registers a new one at that cap, the cheapest existing subnet is dissolved in the very same transaction, with no notice to whoever owns it. A proposal on the main Bittensor codebase would put a step in front of that: the registration is recorded as a priced offer and parked for roughly a day, and the owner of the subnet at risk can pay the same amount to keep the slot. This is a different thing from the recent rules about taking a subnet over by buying up enough of its token; this one is about being evicted entirely to make room for a newcomer. It is written down and under discussion rather than live, and the question worth asking is whether about a day is long enough for an owner who is asleep, travelling or short of funds to react.

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.

Subnets can now choose how quickly validator scores are counted

A change merged into the next network upgrade gives each subnet control over one of the dials behind how rewards are worked out. On Bittensor, validators score the miners doing the work, and the network keeps a running record of which validator backed which miner, called a bond. Liquid Alpha is the setting that decides how fast that record reacts. The new version lets a subnet pick whether the calculation uses this round's agreed scores or the previous round's, with a default that switches between the two automatically depending on how heavily bonds are being penalised. The point is to make it harder for a validator to profit by simply copying whatever everyone else scored. It is not live yet: it ships as part of upgrade 446, which is still waiting on approval signatures, so nothing changes for miners or validators until that goes through.

dFusion is said to have launched Personas for 750,000 users

A post circulating in the Bittensor community says dFusion AI has launched Personas, and that more than 750,000 users will now verify their identity through the project's Proof of Humanhood system, a check designed to prove an account belongs to a real and unique person rather than a bot. Personas are described as AI stand-ins that dFusion builds from each contributor's own online activity, so the system has something specific to check against. If the number holds up it would be one of the larger user figures attached to any Bittensor project, and it would matter because most subnets are still measured by code shipped rather than people using them. We are flagging it as unverified: the claim reaches us second hand through other accounts, and dFusion has not stated it in its own words in anything we have collected, so the user count in particular is worth waiting on.

Two network upgrades sit tagged and one approval short of going live

The code for network upgrades 446 and 447 has been tagged for the live network, and the automated build system has signed the first half of the two signatures required to deploy it. Both now wait on the second, held by the foundation's small signing group. Upgrade 446 repairs long standing miscounts in the network's internal accounting of subnet tokens, gives each subnet a choice about which set of scores its reward maths compares against, and records why a sealed submission failed to open instead of quietly discarding it. Upgrade 447 is the stricter rule for taking over a subnet, which now requires one single holder controlling more than 18 percent rather than several holders adding up to 10 percent between them. Neither is live, and nothing changes for anyone holding or staking until that second approval is given.

The official Bittensor tool stops asking the same question twice

Bittensor has an official command line tool, btcli, which is the text based program people use to run things on the network. When someone who operates a subnet, meaning one of the independent projects that make up Bittensor, went to change one of its settings, the tool printed a table of every setting and then printed a second, almost identical table before asking which one they wanted. A proposed change puts the selection numbers on the first table and deletes the duplicate. It is a small tidy up rather than a change to how the network works, and it only touches the handful of people who administer a subnet, but it removes a step where it was easy to pick the wrong number.

Developers get a simpler way to ask which records are final

Most developers do not talk to Bittensor directly, they use a Python library that does the talking for them. A proposed addition gives that library a single instruction that returns the most recent finalised block, meaning the latest batch of network records that everyone has agreed is permanent and will not be undone. Until now anyone building a tool had to work that out for themselves, and getting it wrong meant reading numbers that could still change underneath them. Nobody using the website or holding TAO will notice this, but it makes the software people build on top of the network a little less likely to report something that later turns out not to have happened.

A proposed way to swap between subnet tokens without watching the screen

Every subnet on Bittensor has its own token, called alpha, and moving from one subnet's token to another today means doing it by hand at whatever price is on offer at that moment. A proposed change introduces limit orders, which are standing instructions to trade only at a price you set in advance, and adds linked orders on top: a second order can be sized as a share of whatever the first one produced, so someone can set up a rotation, sell the subnet 7 token and put the TAO that comes out into another subnet, without knowing the exact amount at the time of signing. This is written down and under discussion, not live. It could mean less sitting in front of a screen for ordinary holders, and the questions worth watching are how these orders are matched and whether standing instructions make it easier for large holders to move size quietly.

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.

Upgrades would be rehearsed against every live subnet before shipping

A proposed testing job would run a copy of the real network through complete epochs, an epoch being one full round of scoring miners and paying them out, for every active subnet, and fail the test if a block takes four seconds or more to build or the chain stops making progress for twelve seconds. Blocks are the steps the network takes, so slow blocks mean everything downstream slows with them. This changes nothing about the rules of the network, only about how thoroughly an upgrade is tried out first. It could mean fewer upgrades that look fine in isolation and then behave differently under real load.

The test network gets the same fix that unstuck new machines

A computer joining a blockchain can skip most of the history using checkpoints, which are signed markers proving everything up to a certain point rather than replaying years of blocks. The main network recently got a fix for checkpoints that did not match the list of who had actually signed them, which could leave a fresh machine stuck. This proposed change applies the same correction to the test network, naming the correct group of six signers for the stored proofs so a new node can catch up and carry on by itself. The test network is the practice ground developers use before touching anything with real money on it, so this affects people building subnets rather than people holding TAO.

The official command line tool learns another network name

btcli is the command line tool people use to stake, transfer and manage subnets. A proposed change adds a shortcut for a network called blockmachine, so instead of typing out a long connection address a user can name the network directly. It is a convenience for anyone who connects to that network rather than the main one, and nothing about the main network changes.

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.

Subnet owners could get a day to save their slot from being taken

Bittensor limits how many subnets, the independent projects that make up the network, can exist at once. Today, registering a new subnet when the network is full instantly dissolves the cheapest existing one inside the same transaction, with no warning to its owner and no chance to respond. A proposal would turn that into a priced offer that is parked for roughly a day, giving the owner the option to match the price and keep the slot. It is written down and under discussion, not live. If it lands, sitting at the bottom of the list stops being sudden death and becomes a bill you can choose to pay, which protects existing teams and the people holding their tokens, and raises the question of whether it makes the last slots harder for newcomers to win.

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.

The rule for taking over a subnet is rewritten again, and now needs one big holder

Bittensor is made up of subnets, separate projects that share the network's daily rewards, and each subnet has an owner. There is a rule for how someone can take that ownership away from them. Until now the test added up the locked support, called conviction, of everyone backing a challenge and triggered once the total passed 10 percent of the subnet's own token, known as alpha. The version merged on 14 August replaces that with a much narrower test: one single wallet, on its own, has to hold more than 18 percent, and the maths now excludes tokens that could never support a challenger, including the current owner's. This is a real change from the earlier proposal we covered, which counted everyone together. The code is tagged as network upgrade 447 and one of the two required approvals has been submitted, so it only goes live when the second signature arrives. In plain terms, a takeover would have to be one committed party rather than a crowd that happens to add up to enough.

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.

The harder rule for taking over a subnet is now written and waiting on two signatures

When we last mentioned this it was only a proposal. The code has now been merged and packaged into network upgrade 447, which is sitting in a queue waiting for approval signatures before it can go live on the main network. It changes who can seize control of a subnet, meaning one of the independent networks that together make up Bittensor. The old rule counted the combined holdings of every account locked behind a challenge and required that total to pass 10 percent of the subnet's alpha, which is the subnet's own token. That sum swept in holdings that had nothing to do with the challenge, including the current owner's. The new rule requires a single account to hold more than 18 percent on its own. It is agreed code but not yet in force, so nothing has changed on the network today. What it could mean: taking a subnet away from the team running it becomes markedly harder, which is protection for anyone building on one, and a much higher wall for anyone who believes an underused subnet should change hands.

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.

Proposed upgrade raises the bar for taking over a subnet

A subnet can change hands if a challenger locks up enough of that subnet's own token, a measure the code calls conviction. The next upgrade, runtime 447, changes the test: a single account key would need conviction above 18 percent of the eligible token supply, where the old rule added up the conviction of every key together and compared that to 10 percent. The old approach could count locks that had nothing to do with a challenger, including the current owner's own, which made the gate easier to trip than intended. The code is tagged and half the two of two approval needed to deploy it has been submitted, with the remaining signature resting with the foundation's three person council, so this is written and waiting rather than live. If it goes through, taking a subnet from its owner becomes something one well funded party has to do openly, rather than something an accidental sum of unrelated positions can trigger.

Proposal would let one trade automatically feed the next

A proposed change would add a new kind of limit order, an instruction to trade only at a price you set rather than whatever the market gives you. The new part is linking orders together: the second order is sized as a share of whatever the first one actually produced, instead of a fixed amount you have to guess when you sign. The case driving it is rotating between subnets, where you sell one subnet's token and want to put the resulting TAO straight into another without knowing in advance exactly how much TAO you will end up with. It is written down and under discussion, not live. If it ships it removes a genuinely awkward step for anyone moving between subnets, though it also makes it easier to move large positions quickly, which cuts both ways.

Proposal would give subnet owners a chance to save their slot

There is a hard limit on how many subnets can exist at once. Today, when someone registers a new one at that limit, the cheapest existing subnet is dissolved instantly inside the same transaction, and its owner has no say and no warning. A proposed change would park the new registration as a priced offer instead, giving the existing owner roughly a day to match that price and keep their slot. It adds two new commands, one to exercise that right and one to cancel a pending registration. It is under discussion and not live. It would make eviction survivable for an owner who is paying attention, though it also slows down the process of clearing out subnets nobody is using.

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.