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: gztensor has write permission and substantial prior subtensor activity; no Gittensor allowlist hit found. Branch is feat/no-capping-on-locked-transfers -> main.

Static review found no .github/ai-review/* or Copilot-instruction changes, no dependency/build-script changes, and no code-level malicious pattern in the runtime diff. The blocking issue is the PR's direct-to-main targeting without an explicit hotfix or deployment rationale in the PR body.

Findings

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

Other findings

• [HIGH] Direct-to-main PR lacks explicit hotfix justification (PR body / baseRefName=main) — This PR targets main from feat/no-capping-on-locked-transfers, but the body describes the change as a new feature for community discussion and does not explicitly justify bypassing the normal devnet-ready flow as a hotfix or deployment PR. The branch policy requires direct-to-main PRs to be hotfixes or deployment PRs with that rationale stated clearly; otherwise the change can skip the normal rollout path and later be overwritten by branch promotion. Add an explicit hotfix/deployment justification to the PR body, or retarget this PR to devnet-ready.

Conclusion

The code changes themselves look consistent with the stated locked-alpha transfer behavior, but the branch-strategy rule requires a direct main PR to be explicitly justified as a hotfix or deployment PR. Until that is documented or the PR is retargeted, this is a blocking process/security issue.

---

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

[github-actions]

🔄 AI review updated — Skeptic: VULNERABLE