Fix silent cap on transferred alpha amount by lock-available

[l0r1s]

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: l0r1s is an established write-permission contributor with substantial prior subtensor activity; no Gittensor allowlist match found. Branch is no-cap-alpha-transfers -> main, hotfix-labeled.

I found no malicious code, supply-chain changes, .github prompt/workflow changes, or runtime panic/backdoor pattern in the diff. The runtime change removes the silent alpha cap and continues to rely on validate_stake_transition to reject over-available stake before movement.

Findings

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

Other findings

• [HIGH] Direct-to-main hotfix lacks explicit PR-body justification (PR body) — This PR targets main from no-cap-alpha-transfers, and the head is not testnet. The trusted branch policy allows direct-to-main PRs only for hotfixes or deployment flow, and the Skeptic instructions require the PR description to justify this explicitly. The body describes the behavior change and even says it is suitable for community discussion/vote, but it does not explain why this needs to skip devnet-ready/devnet/testnet as an urgent hotfix. Add an explicit hotfix justification to the PR body or retarget through the normal branch flow.

Conclusion

Verdict is VULNERABLE because the PR targets main directly while the PR body does not explicitly justify why this must bypass the normal branch flow. The code diff itself looks security-clean under static review.

---

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

[github-actions]

🔄 AI review updated — Skeptic: VULNERABLE