Feat/transfer stake destination hotkey

[MkDev11]

Description

When using transfer_stake, users previously couldn't specify a destination hotkey - the stake would transfer to a new coldkey but remain on the original hotkey. This was problematic because the new coldkey doesn't own that hotkey, so the stake wouldn't show up in btcli commands for the recipient.

This PR adds a destination_hotkey parameter to transfer_stake, allowing users to transfer stake to both a different coldkey AND a different hotkey in a single operation. This makes the transfer actually useful - recipients can now receive stake on their own hotkey.

What changed

The transfer_stake extrinsic now accepts:

• destination_coldkey - who receives the stake
• origin_hotkey - the hotkey to take stake from
• destination_hotkey - the hotkey to put stake on (NEW)
• origin_netuid / destination_netuid - subnet IDs
• alpha_amount - amount to transfer

Previously, the single hotkey parameter was used for both origin and destination.

Related Issue(s)

• Closes transfer_stake should be able to transfer to a new hotkey #1377

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Other (please describe):

Breaking Change

This is a breaking change for existing callers of transfer_stake:

Before:

transfer_stake(destination_coldkey, hotkey, origin_netuid, destination_netuid, alpha_amount)

After:

transfer_stake(destination_coldkey, origin_hotkey, destination_hotkey, origin_netuid, destination_netuid, alpha_amount)

Migration: Existing callers should pass the same hotkey for both origin_hotkey and destination_hotkey to maintain the previous behavior.

Affected interfaces:

• Substrate extrinsic (call_index 86)
• EVM precompile: transferStake(bytes32,bytes32,bytes32,uint256,uint256,uint256)
• Chain extension (function ID 6)
• ink! contract interface

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have run ./scripts/fix_rust.sh to ensure my code is formatted and linted correctly
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

Screenshots (if applicable)

Additional Notes

Files changed

File	Change
pallets/subtensor/src/macros/dispatches.rs	Added destination_hotkey parameter to dispatch
pallets/subtensor/src/staking/move_stake.rs	Updated do_transfer_stake to use both hotkeys
pallets/subtensor/src/macros/events.rs	Updated StakeTransferred event to include both hotkeys
precompiles/src/staking.rs	Updated EVM precompile signature
precompiles/src/solidity/stakingV2.sol	Updated Solidity interface
chain-extensions/src/lib.rs	Updated chain extension
contract-tests/bittensor/lib.rs	Updated ink! contract interface
pallets/transaction-fee/src/lib.rs	Updated pattern matching
docs/wasm-contracts.md	Updated documentation
Test files	Updated all tests + added new test

Why this matters

Before this change, if Alice transferred stake to Bob, the stake would end up on Alice's hotkey but owned by Bob's coldkey. Bob couldn't see or manage this stake easily because his btcli commands filter by his own hotkeys.

Now, Alice can transfer stake directly to Bob's hotkey, making the transfer actually useful for the recipient.

[MkDev11]

@sam0x17 Please check the PR and let me know the result. Thanks.

[camfairchild]

We should avoid updating EVM interfaces because they are breaking
Instead can add a new function and support the old behaviour

[MkDev11]

We should avoid updating EVM interfaces because they are breaking Instead can add a new function and support the old behaviour

@sam0x17 What do you think of that?

[sam0x17]

I would defer to vune on this one, unless there is a way you can make this non-breaking

[MkDev11]

I would defer to vune on this one, unless there is a way you can make this non-breaking

Just updated again. This has been made non-breaking. The original transferStake (5 params) is preserved for backward compatibility, and a new transferStakeV2 (6 params) was added for the new hotkey-to-hotkey transfer feature. Existing contracts will continue to work unchanged.