release-454 - #3143
Conversation
The proxy origin-filter inheritance fix in release 453 (do_proxy now
propagates the caller's call filter into the proxied call) closed a real
filter-laundering loophole — but it also broke contracts that legitimately
execute transfer_stake through an explicit user proxy delegation.
An escrow contract deployed on this chain performs deposits as:
call_runtime(Proxy::proxy(real = depositor, TransferStake { .. }))
where the depositor has registered the contract as a proxy beforehand.
Pre-453 the inner TransferStake ran on a freshly authenticated origin and
succeeded; post-453 it must pass ContractCallFilter, which only whitelists
Proxy::proxy, so the inner call fails with CallFiltered inside
ProxyExecuted and every deposit reverts.
Whitelist the single inner call the flow needs. Security posture is
preserved: the transfer still requires the user's explicit proxy
delegation, and the inherited-filter mechanism keeps every other nested
call blocked.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🛡️ AI Review — Skeptic (security review)VERDICT: SAFE VERY HIGH scrutiny by account-age/public-repo tier, tempered by admin permission and substantial merged subtensor history; no Gittensor association; release-454 -> main. Reviewed the full 23-file release delta, including root-claim accounting, bounded migrations, share-pool dust handling, and the contract proxy filter. No AI-review trust-boundary files are changed. FindingsNo findings. ConclusionNo malicious behavior or exploitable security vulnerability was found. 🔍 AI Review — Auditor (domain review)VERDICT: 👎 UNKNOWN Gittensor association; profile metadata was unavailable, but the author has admin permission and substantial merged subtensor history. Duplicate workThis release branch includes the contract call-filter fix represented by #3139 via merged PR #3140. This PR is the better candidate. Recommend closing #3139. The updated PR description now accurately summarizes the release. Findings
Prior-comment reconciliation
ConclusionThe release description is now adequate, but the contract call-filter change still lacks regression coverage for the exact nested dispatch path it restores. Add that test before merging. 📜 Previous run (superseded)
|
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👍 |
Restore contract-proxied stake transfers
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| // previously execute transfer_stake on the user's behalf; allow | ||
| // that inner call again. Security is unchanged: the transfer still | ||
| // requires the user to have registered the contract as a proxy, | ||
| // and the inherited-filter fix keeps every other call blocked. |
There was a problem hiding this comment.
[MEDIUM] Add regression coverage for nested proxy filtering
This behavioral fix has no test proving that a contract-origin Proxy::proxy(transfer_stake) succeeds after inherited filtering while unrelated nested calls remain rejected. Add a runtime-level regression test covering both cases; otherwise this compatibility/security boundary can regress unnoticed.
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👎 |
Fix coldkey-wide root claims and stale staking relationships
| match call { | ||
| RuntimeCall::Proxy(inner) => matches!(inner, pallet_proxy::Call::proxy { .. }), | ||
| // Since the proxy origin-filter inheritance fix (release 453), calls | ||
| // dispatched *inside* Proxy::proxy must also pass this filter. A | ||
| // contract holding an explicit user proxy delegation could | ||
| // previously execute transfer_stake on the user's behalf; allow | ||
| // that inner call again. Security is unchanged: the transfer still | ||
| // requires the user to have registered the contract as a proxy, | ||
| // and the inherited-filter fix keeps every other call blocked. |
There was a problem hiding this comment.
[MEDIUM] Add regression coverage for nested proxy filtering
This compatibility fix still lacks a test exercising the complete path: a contract-origin call to Proxy::proxy, inherited ContractCallFilter evaluation of the inner transfer_stake, and rejection of an unrelated inner call. A direct Contains::contains assertion is insufficient because the regression arose from nested origin-filter propagation. Add runtime integration coverage before releasing this exception.
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👎 |
| RuntimeCall::Proxy(inner) => matches!(inner, pallet_proxy::Call::proxy { .. }), | ||
| // Since the proxy origin-filter inheritance fix (release 453), calls | ||
| // dispatched *inside* Proxy::proxy must also pass this filter. A | ||
| // contract holding an explicit user proxy delegation could | ||
| // previously execute transfer_stake on the user's behalf; allow | ||
| // that inner call again. Security is unchanged: the transfer still | ||
| // requires the user to have registered the contract as a proxy, | ||
| // and the inherited-filter fix keeps every other call blocked. |
There was a problem hiding this comment.
[MEDIUM] Add regression coverage for nested proxy filtering
The release restores a subtle contract → Proxy::proxy → transfer_stake path whose behavior depends on inherited origin filters, but no test exercises that composition. Add a runtime integration test proving the nested transfer_stake succeeds with an authorized proxy while another nested Subtensor call remains CallFiltered; testing ContractCallFilter::contains alone would not cover the behavior this change relies on.
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👎 |
Main shipped 454 (#3143), so this release moves to 455. SDK bindings and generated docs regenerated against the spec-455 node; this also picks up main's RootClaimTooHeavy wording and shifted source anchors, which was what the docs drift gate flagged. Co-authored-by: Cursor <cursoragent@cursor.com>
3 participants
Summary
Runtime release 454.
Included changes
Includes #3140 and #3141.
Runtime
spec_version: 454