move_lock

Call v411 → v424, v432 → current #137

Moves an existing lock to a new destination hotkey on the same subnet , preserving locked mass but resetting conviction .

View calls on chain

Click items to navigate. Pan and zoom to explore.

Used by: stakersdelegatorssubnet owners

The Big Picture

Move preserves the economic commitment (locked alpha stays locked) but resets the conviction clock. It's the escape hatch when you want to change validators without starting over from liquid stake.

Why This Matters

Locks are sticky on purpose, but validators sometimes need to be changed. move_lock lets you switch the target hotkey without losing your locked position.

Example Scenario

You locked 1000 alpha on subnet 7 to ValidatorA last month. ValidatorA is going offline. You call move_lock(destination_hotkey=ValidatorB, netuid=7). Your alpha stays locked but is now attributed to ValidatorB; your conviction on B starts at zero.

Common Questions

Do I keep the conviction I built?
No. Conviction resets to zero on move. The locked mass carries over, but the time-weighted weight does not.

Use Cases

  • Switch which validator carries your conviction without unlocking
  • Move a lock when a validator becomes unreliable
  • Reassign conviction during a hotkey swap

From Chain Metadata

Moves an existing lock for a coldkey on a subnet from one hotkey to another. The lock is rolled forward to the current block before switching the associated hotkey, preserving the decayed locked mass. The conviction is reset to zero.

Part of: Lock & Conviction

Migration Notes

v424 v432 Breaking

netuid changed from u16 to NetUid

Update decoders: SCALE encoding is positional, so any signature change (added, removed, or type-changed fields, or storage shape changes) shifts byte offsets and existing decoders will misparse this item. Re-derive types from the new metadata.

Input Parameters

#NameTypeDescription
0
destination_hotkey
AccountId Hotkey the lock should target after the move (hex -> SS58)
1
netuid
NetUid Subnet the lock exists on

Permissions

Origin
Signed
Required Role
Any

Permission data inferred from metadata. May be incomplete.

Requirements

  • Coldkey signs the call
  • A lock exists for (coldkey, subnet); otherwise NoExistingLock is returned

Effects

Events Emitted

LockMoved

Postconditions

  • Lock decay rolled forward to current block
  • Lock associated hotkey switched to destination_hotkey
  • Conviction reset to zero
  • LockMoved event emitted

Side Effects

  • Previous hotkey loses the locked mass attributed to this coldkey
  • Destination hotkey gains it
  • Conviction starts accruing from zero against the new hotkey

Code Examples

import { createClient, Binary } from "polkadot-api";
import { getWsProvider } from "polkadot-api/ws";
import { sub } from "@polkadot-api/descriptors"; // generated by: npx papi add sub -w wss://entrypoint-finney.opentensor.ai:443

const client = createClient(getWsProvider("wss://entrypoint-finney.opentensor.ai:443"));
const api = client.getTypedApi(sub);

// Build move_lock call (typed, named args)
const destination_hotkey = "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY";
const netuid = 1;

const tx = api.tx.SubtensorModule.move_lock({
  destination_hotkey,
  netuid,
});

Version History

v411 block 8,283,784 2 args
v432 block 8,636,190 2 args Current

Runtime Info

View Source
Pallet Index
7
Call Index
137
First Version
v411
Current Version
v472
Back to SubtensorModule Calls