Add lock-aware stake transfer extrinsic#2717
Conversation
gztensor
added
the
skip-cargo-audit
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| let alpha_amount = lock_aware_transfer | ||
| .map(|locked| { | ||
| alpha_amount.min(Self::lock_aware_transferable_alpha( | ||
| origin_coldkey, | ||
| origin_netuid, | ||
| locked, | ||
| )) | ||
| }) | ||
| .unwrap_or(alpha_amount); |
There was a problem hiding this comment.
[HIGH] Capped lock-aware amount can mutate stake before failing minimum check
For same-subnet lock-aware transfers, this cap can reduce a caller-supplied alpha_amount to a dust-sized selected bucket after any transaction-extension or input-level minimum checks have seen the original amount. The capped value then reaches transfer_stake_within_subnet, which calls transfer_lock and decreases/increases stake before computing tao_equivalent and returning AmountTooLow for sub-minimum transfers. A caller can submit a large alpha_amount, have it capped to a below-minimum locked/unlocked remainder, and still move stake/lock state through a dispatch that reports failure. Validate the capped move_amount against DefaultMinStake before any lock/stake mutation, or move the same-netuid minimum check ahead of transfer_lock and the stake balance updates.
🛡️ AI Review — Skeptic (security review)VERDICT: VULNERABLE BASELINE scrutiny: author has write permission, substantial prior subtensor activity, matching commit author, no Gittensor allowlist hit; branch feat/transfer-free-locked-alpha -> devnet-ready. No Findings
Prior-comment reconciliation
ConclusionThe PR introduces a lock-aware transfer path that can move lock state based on coldkey-level locked stake while debiting stake from any caller-selected hotkey. This can detach locks from the stake they are meant to constrain, so the current diff is vulnerable. 🔍 AI Review — Auditor (domain review)VERDICT: 👎 Gittensor: LIKELY by recent subtensor-focused PR history; established contributor with write permission. Prior cross-subnet lock finding remains. PR description is substantive. I did not run builds/tests; the blocking issue is visible statically. I checked local Findings
Prior-comment reconciliation
ConclusionBlocking because 📜 Previous run (superseded)
|
|
🔄 AI review updated — Skeptic: VULNERABLE |
| let tao_moved = Self::transition_stake_internal( | ||
| &coldkey, | ||
| &destination_coldkey, | ||
| &hotkey, | ||
| &hotkey, | ||
| origin_netuid, | ||
| destination_netuid, | ||
| alpha_amount, | ||
| None, | ||
| None, | ||
| true, | ||
| false, | ||
| Some(locked), |
There was a problem hiding this comment.
[HIGH] Cross-subnet locked transfers do not move lock state
Some(locked) is passed into the generic transition path even when origin_netuid != destination_netuid, but the cross-subnet branch later uses unstake_from_subnet and stake_into_subnet rather than transfer_lock. That means no lock state is moved to the destination subnet/coldkey. Worse, validate_stake_transition still enforces ensure_available_to_unstake for cross-subnet moves, so a fully locked position fails with StakeUnavailable, while a partially locked position with enough unlocked alpha can succeed by moving unlocked stake and leaving the source lock behind. This contradicts the new extrinsic docs and the PR body claim that locked transfers preserve/move the lock state. Either reject origin_netuid != destination_netuid for this extrinsic, or implement explicit cross-subnet lock migration and add a test that locked=true moves lock state across netuids.
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👎 |
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👎 |
| let alpha_amount = lock_aware_transfer | ||
| .map(|locked| { | ||
| alpha_amount.min(Self::lock_aware_transferable_alpha( |
There was a problem hiding this comment.
[HIGH] Lock-aware cap is not bound to the selected hotkey
lock_aware_transferable_alpha() only looks at (coldkey, netuid), while the actual debit later happens from (origin_hotkey, origin_coldkey, netuid). A coldkey with locked stake on hotkey A and unlocked stake on hotkey B can call transfer_stake_lock_aware(..., hotkey = B, locked = true): this cap permits the transfer because the coldkey has locked alpha, transfer_lock() moves/reduces the lock for hotkey A, but transfer_stake_within_subnet() debits hotkey B. That detaches the lock from the stake it was protecting and can effectively free the originally locked hotkey A stake. Bind the selected bucket to origin_hotkey before capping/debiting: for locked = true, require the coldkey lock hotkey to equal origin_hotkey and cap by that lock; for locked = false, cap by stake on origin_hotkey minus any lock on that same hotkey.
|
🔄 AI review updated — Skeptic: VULNERABLE |
1 participant
Description
This change adds
transfer_stake_lock_awareextrinsic, a variant oftransfer_stakethat lets callers choose whether to transfer from the locked or unlocked portion of stake via a newlockedboolean. The transition path now caps the requested amount to the selected bucket, so it transfers the maximum available amount without erroring when the request exceeds locked or unlocked alpha. For locked transfers, the existing lock state follows the moved stake and preserves the lock hotkey and proportional conviction; for unlocked transfers, only free stake moves and lock state remains untouched.Type of Change
Checklist
./scripts/fix_rust.shto ensure my code is formatted and linted correctly