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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.