No capping on locked alpha transfers

[gztensor]

Description

Note: This is a good PR for the community to discuss and possibly vote.

When transferring alpha between subnets, the extrinsics currently silently cap transfer amount by available alpha: If more alpha is requested to transfer, the extrinsic transfers only what's available and succeeds. There are two concurrent and conflicting issues:

1. If the chain silently caps (current behavior): The extrinsic reports success and mis-accounting may occur because less alpha was transferred than was requested yet the extrinsic result is Ok.
2. If the chain does not silently cap (new behavior implemented in this PR): When the user requests exactly available alpha to transfer and has no TAO on the signing coldkey, the tx fees are paid in alpha before the transfer amount is checked, which results in transaction error (and loss of fees). The client software needs to account for alpha fees to prevent this.

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

Some clients may be broken if they request transfer amounts above the unlocked alpha.

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

[github-actions]

🚨🚨🚨 HOTFIX DETECTED 🚨🚨🚨

It looks like you are trying to merge a hotfix PR into main. If this isn't what you wanted to do, and you just wanted to make a regular PR, please close this PR, base your changes off the devnet-ready branch and open a new PR into devnet ready.

If you are trying to merge a hotfix PR, please complete the following essential steps:

1. go ahead and get this PR into main merged, so we can get the change in as quickly as possible!
2. merge main into testnet, bumping spec_version
3. deploy testnet
4. merge testnet into devnet, bumping spec_version
5. deploy devnet
6. merge devnet into devnet-ready

If you do not complete these steps, your hotfix may be inadvertently removed in the future when branches are promoted to main, so it is essential that you do so.

[github-actions]

🛡️ AI Review — Skeptic (security review)

VERDICT: VULNERABLE

BASELINE scrutiny: author has write permission, account is >2 years old with substantial subtensor history; branch is feat/no-capping-on-locked-transfers-v2 -> main.

The code diff is narrow and I did not find malicious logic, new dependencies, .github/ prompt/workflow edits, or runtime panic sources in the changed lines. The blocker is branch-policy/security process: this is a direct-to-main PR from a feature branch, and the PR body does not explicitly justify it as an urgent hotfix.

Findings

Sev	File	Finding
HIGH	PR body / branch metadata	Direct-to-main PR lacks explicit hotfix justification	(off-diff)

Other findings

• [HIGH] Direct-to-main PR lacks explicit hotfix justification (PR body / branch metadata) — This PR targets main from feat/no-capping-on-locked-transfers-v2 instead of the normal devnet-ready flow. The body labels the change as a new feature, says it is suitable for community discussion/voting, and notes possible client breakage; it does not explicitly justify why this must bypass the standard promotion path as a hotfix. Per branch strategy, direct-to-main is only acceptable for a clearly justified hotfix or deployment PR. Retarget this to devnet-ready, or update the PR description with the emergency rationale and required promotion/backport plan.

Conclusion

Verdict is VULNERABLE because the PR targets main directly without an explicit hotfix rationale in the PR description. Retarget to devnet-ready, or document the emergency hotfix justification and promotion/backport plan before merge.

---

# 🔍 AI Review — Auditor (domain review) has not yet run on this PR.

[github-actions]

🔄 AI review updated — Skeptic: VULNERABLE