TAO.Daily
The network itself

What changed in Bittensor

Changes to Bittensor itself, not to any one subnet. This is the part that normally arrives as code and proposals, so we write it out in plain English first. If you have never read a commit in your life, this page is for you.

This weekThis month3 monthsEverything
EverythingLive nowOnly proposedBeing discussed

The rule setting each project's income was changed, then changed back

Live nowBig deal

On 10 August the network stopped reducing a project's share of the daily payout when that project held back pay from its own workers. Two days later it put that rule back. So a project that withholds worker pay once again earns a smaller share of network income.

Why this matters to you

This is the formula deciding how much money every project on the network receives. It was reversed inside 48 hours. If you are judging a project on its income right now, be aware the rule producing that number changed twice in a week and could change again.

The technical version

v444 removed the (1 - MinerBurned) weighting from subnet emission shares, leaving shares determined purely by price EMA through the emission gate. PR #3071 restored price_share x (1 - MinerBurned) and renormalises burn-adjusted weights before the gate is applied.

Every fee paid on the network now reduces the amount of new TAO created

Live nowBig deal

Fees used to be paid to the operators who produce blocks. Now they are destroyed instead, and the network creates that much less new TAO to compensate. In simple terms, the more the network gets used, the more slowly new supply appears.

Why this matters to you

This links usage to supply for the first time. Every holder benefits a little when activity rises, rather than the fees going to block producers. It also means anyone calculating staking returns using figures from before this change is overstating them, because fee income has been removed from operators.

The technical version

Native TAO fees and tips are recycled by reducing issuance rather than rewarded to block authors. Alpha-denominated fees swap to TAO and recycle atomically. EVM base and priority fees use the same path. Bundled into release v444 as PR #3053.

Smart contracts on Bittensor can now do almost everything the main network can

Live nowBig deal

Bittensor has a second layer that runs smart contracts, the same kind of programs used on Ethereum. Until now those programs could only reach a limited set of the network's features. This update opens up nearly all of them, adding five new access points and well over a hundred new functions.

Why this matters to you

This does not move any prices by itself. What it does is remove the technical reason there were almost no automated financial products built on Bittensor. If lending, trading or automated strategies start appearing, this is the change that made them possible. Watching for new contracts being deployed is a reasonable early signal.

The technical version

Adds Scheduler (0x80f), Drand (0x810), Timestamp (0x811), RuntimeConfiguration (0x812) and PrecompileRegistry (0x813), 31 functions across five new addresses, plus 68 state-changing methods and 67 typed views on existing precompiles. State-changing calls dispatch as the mapped EVM signer so pallet authorisation and rate limits still apply. Integrators should avoid hard-coded gas limits.

Hardware wallet users can now read what they are signing when placing orders

Live now

People who keep their TAO on a hardware wallet used to be shown an unreadable code when placing an order. They now see a plain description of the order they are about to approve.

Why this matters to you

It removes a real barrier for anyone holding large amounts in cold storage, who previously had to approve orders blind. Making it safe for cautious, larger holders to trade on-chain is a prerequisite for deeper liquidity.

The technical version

Ledger signing payload for limit orders carries a readable ASCII description rather than an opaque order-id hash. Purely additive, order ids unchanged, so no replay risk.

Around 600,000 pointless transactions a month will now be rejected before they waste space

Live now

Two common mistakes, submitting work too quickly and submitting from an account that is not permitted, were being accepted into blocks and only then failing. They are now refused up front.

Why this matters to you

Roughly 605,000 doomed transactions a month stop consuming block space, which leaves more room for real activity and reduces congestion for everyone.

The technical version

Pre-dispatch validation rejects CommittingWeightsTooFast (about 448,600 failures per 30 days) and AccountNotAllowedCommit (about 156,220 per 30 days) at the transaction pool.

The command line tool gains multisig support and clearer dry runs

Live now

The main tool people use to manage wallets now supports wallets requiring several approvals, shows clearer staking information, and can print a machine readable plan of what a command would do before doing it.

Why this matters to you

Multisig support matters for anyone holding funds that should not sit behind a single key, which includes teams and funds. It is a small step towards Bittensor being usable by organisations rather than individuals.

The technical version

btcli v11 adds multisig wallet-name support, improved stake UX, machine readable --dry-run --json plans, secret hygiene, call-name resolution and multisig funding preflight. Fixes CheckNonce so alpha-only coldkeys can use the alpha fee fallback.

A loophole showing returns of up to 40,000 percent a year has been closed

Live nowBig deal

The new fund system shipped with an error. If an operator held TAO at the top level but was not properly registered there, the maths credited its whole reward as if earned on a single project instead. Operators holding tiny amounts of a project's token were displaying annual returns between 7,000 and 40,000 percent. Those returns were never real, but the money chasing them was.

Why this matters to you

Some projects have been attracting deposits because of returns that did not genuinely exist. If a project looked unusually popular in the past fortnight, this may be why, and that support has no reason to stay now the error is fixed.

The technical version

calculate_dividend_distribution now always keeps root x tao_weight in the split denominator, so ALPHA claims only alpha / (alpha + weighted_root). Root basket credit still requires a root UID. Bumps spec_version 441 to 442.

A feature launched days earlier has been switched off again

Live now

Paying directly into the new operator funds was disabled almost immediately after launch, while the team checks how much storage each deposit consumes. Every deposit can create a new record for each project an operator supports, and every later withdrawal has to read through all of them.

Why this matters to you

A brand new feature being turned off within days is worth noticing. It suggests the fund system went live before its costs were fully understood, so more adjustments are likely.

The technical version

stake_into_basket now returns CallDisabled. Signature, call index 147, params and declared weight are unchanged so runtime metadata is unaffected.

Staking rewards at the top level now go into a fund instead of straight back to you

Live nowBig deal

If you stake TAO at the network's top level, your rewards used to return to you directly. They now go into a fund attached to whichever operator you staked with, and that operator decides which projects the money supports. When you put money in, your shares are priced at the fund's value beforehand, so people joining later cannot dilute you.

Why this matters to you

You no longer choose where your staking rewards are invested. The operator you picked does. Their preferences used to be a technical footnote and are now the thing deciding where a large stream of money lands, so they are worth checking before you stake.

The technical version

Root dividends are reinvested into per-validator beta baskets held under a global escrow coldkey, allocated by the validator's root weight vector stored in Weights[ROOT]. Deposits mint fund shares at pre-deposit realizable NAV valued at executable quotes. Shipped as a gated launch with a resumable multi-block seed migration.