Skip to content

Expose proxy type filtering rules via runtime api#2703

Open
basfroman wants to merge 9 commits into
devnet-readyfrom
feat/basfroman/add-proxytype-runtime-apis
Open

Expose proxy type filtering rules via runtime api#2703
basfroman wants to merge 9 commits into
devnet-readyfrom
feat/basfroman/add-proxytype-runtime-apis

Conversation

@basfroman
Copy link
Copy Markdown
Collaborator

Description

Adds two new runtime api methods to ProxyFilterRuntimeApi:

  • get_proxy_types() — returns all ProxyType variants with their index, name, and deprecation status
  • get_proxy_filter(proxy_type: Option<u8>) — returns the filtering rules for each proxy type, including which extrinsics are allowed/denied, wildcard pallet rules, value conditions, and nested call requirements

The core change is a define_proxy_filters! proc-macro that serves as a single source of truth — it generates both the on-chain InstanceFilter::filter() logic and the runtime api metadata from one declarative definition. this eliminates the previous duplication where filter rules and api data had to be maintained separately and could drift apart.

If a new ProxyType variant is added without updating the macro, the compiler will reject the build due to non-exhaustive match. if a call name in the dsl doesn't exist in the pallet, the compiler will also reject it.

Data types added to subtensor-runtime-common: CallInfo, CallCondition, FilterMode, ProxyFilterInfo, ProxyTypeInfo. clients (python, js) can call these methods via standard substrate rpc to get the full picture of proxy permissions without hardcoding anything.

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

Nope

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

Additional Notes

Usage from python (bittensor sdk / async-substrate-interface, e.t.c.):

# get all proxy types with their indices and deprecation status
proxy_types = subtensor.query_runtime_api(
    runtime_api="ProxyFilterRuntimeApi",
    method="get_proxy_types",
    params=[],
)
# returns: [{'name': 'Owner', 'index': 1, 'deprecated': False}, ...]

# get filtering rules for all proxy types
all_filters = subtensor.query_runtime_api(
    runtime_api="ProxyFilterRuntimeApi",
    method="get_proxy_filter",
    params=[None],
)

# get filtering rules for a specific proxy type by index
owner_filter = subtensor.query_runtime_api(
    runtime_api="ProxyFilterRuntimeApi",
    method="get_proxy_filter",
    params=[1],
)

response structure for get_proxy_filter:

  • filter_mode — one of AllowAll, DenyAll, Allow, Deny
  • calls — list of extrinsics the rule applies to. each entry has pallet_name, pallet_index, call_name (null for whole-pallet wildcard), call_index (null for wildcard), and optional condition
  • exceptions — calls excluded from the allow list (only relevant when filter_mode is Allow)
  • name — proxy type name
  • deprecated — whether this proxy type is deprecated

interpreting filter_mode:

  • AllowAll — proxy can execute any extrinsic, calls is empty
  • DenyAll — proxy cannot execute anything (deprecated types), calls is empty
  • Allow — proxy can only execute extrinsics listed in calls (minus exceptions)
  • Deny — proxy can execute everything except extrinsics listed in calls

@basfroman basfroman self-assigned this May 30, 2026
@basfroman basfroman requested review from gztensor, l0r1s and sam0x17 May 30, 2026 06:21
@opentensor opentensor deleted a comment from github-actions Bot May 30, 2026
@opentensor opentensor deleted a comment from github-actions Bot May 30, 2026
@github-actions
Copy link
Copy Markdown
Contributor

# 🛡️ AI Review — Skeptic (security review) has not yet run on this PR.


🔍 AI Review — Auditor (domain review)

VERDICT: 👍

Gittensor: LIKELY; basfroman is not in the allowlists but has repo write permission and a long subtensor PR history, so I treated this as established-contributor work.

PR body is substantive and matches the implementation. The macro-generated filter arms preserve the prior InstanceFilter behavior, and the new runtime API metadata is derived from the same DSL. spec_version is bumped from 412 to 413. Overlapping open PRs appear to be unrelated shared-runtime/proxy-type work, so there is no duplicate-work recommendation. No auto-fixes were applied.

Verification attempted: RUSTUP_TOOLCHAIN=stable cargo test -p node-subtensor-runtime --test pallet_proxy proxy_filter_api, but Cargo could not write the git dependency cache under read-only /home/runner/.cargo; the default toolchain path also failed because rustup could not create temp files under read-only /home/runner/.rustup. The devnet spec-version RPC query also could not be verified because DNS resolution failed in this sandbox.

Findings

No findings.

Conclusion

I did not find a blocking correctness issue. The main residual risk is environmental: targeted tests and live spec-version confirmation could not run here, so CI should cover those.

@github-actions
Copy link
Copy Markdown
Contributor

🔄 AI review updated — Skeptic: SAFE Auditor: 👍

@basfroman basfroman added the skip-cargo-audit This PR fails cargo audit but needs to be merged anyway label May 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

skip-cargo-audit This PR fails cargo audit but needs to be merged anyway

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant