The Opentensor Foundation is introducing a more structured development cadence for the Bittensor ecosystem.
Following discussions at OpenDev, the foundation confirmed a new release strategy designed to make upgrades more predictable for developers, validators, miners, and infrastructure teams.
Alongside this scheduling change, a significant mainnet upgrade is scheduled for Tuesday, March 17, bringing the long anticipated MEV (Maximal Extractible Value) Shield feature along with several protocol improvements.
A New Weekly Release Schedule
To improve stability across the ecosystem, Opentensor Foundation will now follow a fixed weekly release cadence.
The new structure is straightforward:
a. Tuesday becomes the standard deployment day,
b. Releases will alternate between testnet and mainnet, and
c. New upgrades will remain on testnet for roughly one week before being deployed to mainnet.
This predictable cycle is intended to benefit several groups across the network:
a. Client developers building wallets and interfaces,
b. Indexer teams maintaining analytics and data services,
c. Subnet validators and miners operating infrastructure, and
d. Developers testing new protocol features.
By encouraging consistent testing on testnet before each mainnet upgrade, the foundation hopes to improve reliability while increasing activity in the development environment.
Improving Transparency in Development
Alongside the release schedule, the foundation is also introducing stricter standards for development documentation.
Going forward, pull requests merged into the protocol will be required to include clear titles and detailed descriptions explaining the changes being introduced.
This policy will apply both to internal development contributions and external community contributions, and would provide better context around protocol changes, making it easier for ecosystem participants to understand what each upgrade modifies or improves.
Mainnet Upgrade Scheduled for March 17
The next major upgrade to Bittensor mainnet is scheduled for Tuesday, March 17. This deployment will introduce the long-anticipated MEV Shield upgrade, along with a collection of additional protocol improvements.
The rollout will occur in two stages, separated by a short node upgrade. The upgrade sequence is as follows:
a. Runtime Upgrade: This upgrade incorporates improvements, and during this phase, MEV Shield will be temporarily disabled while the network prepares for the next step.
Transactions submitted through the MEV Shield mechanism during this window will fail and will not become decryptable.
b. Block Builder Node Upgrade: This upgrade applies only to block builder nodes, so standard node operators will not need to update during this stage.
c. Second Runtime Upgrade: The final upgrade re-activates MEV Shield under the new protocol design. All components of this upgrade are already live on testnet, allowing ecosystem participants to begin testing ahead of the mainnet deployment.
Key Features Included in the Upgrade
Once the upgrade process completes, several new features and protocol changes will become available across the network.
a. MEV Protection: After the second upgrade, systematic MEV frontrunning and sandwich attacks should become effectively impossible under the new MEV Shield design.
Speculative frontrunning based solely on the submitting wallet may still occur, though this remains risky for MEV bots.
b. Voting Power for Subnets: A new voting power feature will be introduced, giving subnet participants additional governance capabilities.
c. Subnet Mechanism Expansion: Network administrators will gain the ability to configure and raise the maximum number of subnet mechanisms, enabling greater flexibility for subnet development.
d. Updated Fee Structure: Transaction economics will also change as base transaction fees increase by 10 times, and staking and transaction fees will now go to block builders.
e. Additional Protocol Improvements:
Several quality of life updates are included:
1. Ability to configure proxy fee attribution so the proxy owner pays fees instead of the delegate,
2. Introduction of the add_stake_burn feature,
3. Coldkey swap bug fix, and
4. Hotkey swap improvements, including the ability to revert to a previous hotkey if needed.
What Happens Next
Client teams across the Bittensor ecosystem are currently preparing updated versions of their tools to support the new protocol features.
Many updated clients have already been released, with more expected in the coming days.
The Opentensor Foundation will announce the official start of the upgrade window on Tuesday, with the process expected to begin between 3:00 PM and 5:00 PM EDT (Eastern Daylight Time)
A More Predictable Development Cycle for Bittensor
The introduction of a structured release cadence marks an important operational shift for the network.
By standardizing deployment schedules, improving documentation standards, and encouraging greater participation on testnet, the Opentensor Foundation aims to create a more stable development environment for the rapidly growing Bittensor ecosystem.
Combined with the upcoming MEV Shield upgrade, these changes represent another step toward a more mature and resilient infrastructure layer for decentralized machine intelligence.
Be the first to comment