MVTRX SN79 0.6.0 prepares exchange agents while mainnet stays simulation-only

MVTRX SN79 version 0.6.0 gives strategy developers one interface for two market environments. The same program can respond to a simulated market or an exchange-style event stream.

Only one of those environments is active through the Bittensor subnet today.

The official migration guide says MVTRX mainnet remains simulation-only. Exchange mechanism testing in 0.6.0 is localnet-only, and the guide reports MechanismCountCurrent(79) = 1. The exchange mechanism is planned for a later mainnet release.

That distinction overrides secondary X posts that described the exchange framework as live on mainnet. A public exchange website or merged agent interface does not prove that Bittensor validators are assigning exchange-mechanism incentives on Finney.

One interface, two event environments

MVTRX describes itself as a market simulation subnet. Miners run agents inside simulated markets, and validators score their behavior.

Version 0.6.0 reorganizes the authoring interface so a developer does not need two unrelated codebases to target simulation and exchange-style tests. A program can branch on exchange_mode, receive mode-specific events and build its response through a shared make_response pattern.

The simulation path continues to provide the synthetic market environment already used by SN79. The exchange path introduces event and instruction types for an order-driven setting. Examples and compatibility tests show how one strategy can operate in both modes.

This is meaningful developer work. It lowers the conceptual distance between experimenting in a simulation and writing an agent for exchange plumbing. It does not make the two environments operationally equivalent.

Mainnet still has one mechanism

The migration guide provides the clearest status check. Mechanism ID 0, simulation, is active on mainnet. Mechanism ID 1, exchange, remains absent from mainnet in version 0.6.0. Developers can test the exchange mechanism on localnet. The guide also says the current chain query for SN79 returns one mechanism.

This means the 0.6.0 release exposes exchange wire types, configuration and authoring tools before the incentive mechanism reaches mainnet. That sequencing is common in protocol development. Interfaces need testing before validators and miners depend on them for live weights.

The boundary needs to stay visible because the word exchange carries assumptions. It can suggest a live order book, external liquidity, real fills, users and fee revenue. The migration guide establishes none of those things for the Bittensor mechanism.

Compatibility is part of the release

MVTRX says agents written before 0.6.0 remain compatible with the simulation path.

The repository adds tests for pre-0.6.0 miner programs, exchange-mode dispatch, notice parsing, account fields and response builders. A unified interface would offer little value if every existing simulation strategy required an immediate rewrite.

The new surface includes exchange event models and instructions, recent-trade handling and account-related fields. Example strategies include market-making, arbitrage, imbalance and order-option agents. These examples document how a developer can react to the local exchange environment.

They are not evidence that the strategies make money. They also do not establish execution quality or safety in a real venue. Test coverage can show that messages and interfaces behave as intended under the repository’s fixtures. It cannot substitute for live market observation.

Some exchange concepts remain deliberately limited

The migration guide identifies several differences developers must account for.

Borrowed position sizing is unavailable in the prepared exchange mode. close_position is a no-op and gives no guarantee that an open position is closed. Exchange notices should be treated as events, never as an authoritative account ledger. The account state supplied by the environment remains the source of truth.

Those cautions are more useful than an announcement that exchange support exists. They tell agent authors where simulation assumptions can fail when code is moved toward an order-driven environment.

A program that receives a fill notice, for example, should not build its own permanent balance ledger from notices alone. It needs to reconcile against the account state provided by the mechanism. This software contract says nothing about a live financial service.

The 0.6.0 merge also touches the simulator

The release is broader than the agent interface.

The commit includes simulation engine work, price-band logic, accounting and order-handling tests, agent retuning and protocol cleanup. Its message describes a next scoring revision and an LULD-style price band as published inert.

The word inert matters. Code can be present for testing or future activation without changing current incentives. The commit alone cannot establish the scoring revision or price-band work as active mainnet behavior.

Repository breadth does not prove production maturity. Version 0.6.0 changes many files, and file count is no benchmark. The project has packaged a common authoring interface and a localnet exchange test path while keeping simulation as the sole active mainnet mechanism.

Current SN79 status

A TaoSwap snapshot captured at 10:06 BRT on August 30 showed 212 active miners for MVTRX SN79 and an emission_value of 0.001449013.

That confirms an active subnet context. It provides no confirmation of the exchange mechanism, exchange users, liquidity, fills, revenue or profitable strategies. TaoSwap does not establish the 0.6.0 mechanism boundary. The official MVTRX migration guide does.

The next important evidence will be on-chain. When MechanismCountCurrent(79) changes and the project publishes mainnet activation details, the exchange path can be evaluated as an incentive mechanism rather than local development tooling.

For now, version 0.6.0 is a bridge between two environments. It lets builders prepare an agent for both. It does not put both environments on Finney.