Bittensor SDK

Bittensor v10.0 introduces support for multiple incentive mechanisms per subnet. Many methods that interact with weights, bonds, or metagraphs now require a mechid (mechanism ID) parameter to specify which mechanism to query.

By default, mechid=0 refers to the first (or only) incentive mechanism in a subnet.

Methods requiring mechid (parameter order: netuid, mechid=0, block=None):

• subtensor.bonds(netuid, mechid=0, block=None)
• subtensor.weights(netuid, mechid=0, block=None)
• subtensor.metagraph(netuid, mechid=0, lite=True, block=None)
• subtensor.get_metagraph_info(netuid, mechid=0, ...)
• subtensor.get_timelocked_weight_commits(netuid, mechid=0, block=None)
• subtensor.commit_weights(wallet, netuid, uids, weights, mechid=0, ...)
• subtensor.reveal_weights(wallet, netuid, uids, weights, mechid=0, ...)
• subtensor.set_weights(wallet, netuid, uids, weights, mechid=0, ...)

Note on MetagraphInfo: The MetagraphInfo class now requires mechid as a mandatory parameter.

Bittensor 10.0 supports multiple independent incentive mechanisms within a single subnet. Each mechanism has its own weight matrices, bond pools, and emission distributions.

• mechid (Mechanism ID): An integer used to identify the mechanism. The first mechanism is 0, the second is 1, etc.
• Default Behavior: All SDK methods default to mechid=0. Existing single-mechanism subnets remain backward compatible and require no changes.

Setting Weights for a Specific Mechanism

Validators must specify the mechid when setting weights to ensure they target the correct mechanism:

# Set weights for a specific mechanism (mechid)
response = subtensor.set_weights(
    wallet,
    netuid=1,
    uids=[0, 1, 2],
    weights=[0.5, 0.3, 0.2],
    mechid=0  # Mechanism ID (default: 0)
)

# For subnets with multiple mechanisms, set weights for each:
mechanism1_response = subtensor.set_weights(wallet, netuid=1, uids, weights1, mechid=0)
mechanism2_response = subtensor.set_weights(wallet, netuid=1, uids, weights2, mechid=1)

Querying Mechanism-Specific Data

All metagraph queries now accept a mechid parameter to retrieve data for a specific mechanism:

# Get metagraph for specific mechanism
metagraph = subtensor.metagraph(netuid=1, mechid=0)

# Get weights for specific mechanism
weights = subtensor.weights(netuid=1, mechid=0)

# Get bonds for specific mechanism
bonds = subtensor.bonds(netuid=1, mechid=0)

# Get timelocked weight commits for a mechanism
commits = subtensor.get_timelocked_weight_commits(netuid=1, mechid=0)

In Bittensor 10.0, all functions that submit extrinsics to the Subtensor blockchain now return an ExtrinsicResponse object instead of a bool or tuple.

Key fields in ExtrinsicResponse:

• success: True if transaction succeeded, False otherwise.
• message: User-friendly status string.
• extrinsic_fee: Network fee paid to validators.
• transaction_tao_fee: 0.05% TAO fee for swap-based staking.
• transaction_alpha_fee: 0.05% Alpha fee for swap-based staking.
• extrinsic_receipt: Contains block number, hash, and events (if wait_for_inclusion=True).
• data: Operation-specific results (e.g., uid for registration, reveal_round for weight commits).
• error: Python exception (if raise_error=False).

Note: If raise_error=False, the function will not raise exceptions; you must check the success or error fields. If raise_error=True, exceptions are raised directly.

Release branches prepare a new production release by allowing minor bug fixes and metadata updates (like version numbers).

1. Create the branch from staging:

git checkout -b release/3.4.0/descriptive-message/creators_name staging

2. Update the version: Use the provided script to bump the version:

./scripts/update_version.sh major
# OR
./scripts/update_version.sh minor

3. Commit version changes:

git commit -a -m "Updated version to 3.4.0"

4. Finish the release (Merge to master and tag):

git checkout master
git merge --no-ff release/3.4.0/optional-descriptive-message
git tag -a v3.4.0 -m "Releasing v3.4.0: some comment about it"
git push origin master
git push origin --tags

5. Sync back to staging: To ensure any fixes made in the release branch are preserved, merge it back into staging:

git checkout staging
git merge --no-ff release/3.4.0/optional-descriptive-message

git checkout -b release/3.4.0/descriptive-message/creators_name staging
./scripts/update_version.sh major|minor
git commit -a -m "Updated version to 3.4.0"

To maintain a clean and understandable project history, follow these six rules for Git commits:

1. Atomic Commits: Each commit should revolve around one single task or fix. Avoid joint commits for unrelated changes, but you may commit a layout file, its code-behind file, and associated resources together if they constitute a single complete feature/task.
2. Separate subject from body with a blank line: Use a single line for simple changes. For complex changes, use a proper text editor to write a body that provides context, separated from the subject by one blank line.
3. Limit the subject line to 50 characters: Keep subject lines concise. While not a hard limit, it ensures readability and prevents truncation in Git logs.
4. Use the imperative mood in the subject line: Write the subject as if giving a command. A good test is: "If applied, this commit will <your subject line here>".
5. Wrap the body at 72 characters: Manually wrap your commit body text at 72 characters to ensure it remains readable in various Git tools.
6. Use the body to explain what and why vs. how: Focus the body on the reasoning behind the change (the context, the problem, and the solution) rather than describing the implementation details, which should be evident from the code itself.