Skip to content

Feat: Proxy aware chain extensions#2383

Open
LandynDev wants to merge 1 commit intoopentensor:devnet-readyfrom
LandynDev:feat/proxy-aware-chain-exts
Open

Feat: Proxy aware chain extensions#2383
LandynDev wants to merge 1 commit intoopentensor:devnet-readyfrom
LandynDev:feat/proxy-aware-chain-exts

Conversation

@LandynDev
Copy link
Copy Markdown

@LandynDev LandynDev commented Jan 29, 2026

Description

Adds 12 proxy-delegated chain extension variants that allow a smart contract with proxy rights to manage on behalf of a proxied coldkey. Each handler accepts an on_behalf_of: AccountId parameter, verifies the ProxyType and dispatches the operation as the proxied account. ProxyType::Any is accepted as a superset of all types.

Related Issue

Closes #2566

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

This PR does not create a breaking change.
This introduces new proxy chain extensions to wrap runtime calls with correct proxy perms.

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

Screenshots

Unit Tests:
image

Additional Notes

@LandynDev LandynDev marked this pull request as ready for review January 29, 2026 19:05
pallet_proxy::Pallet::<T>::find_proxy(
&real_coldkey,
&caller,
Some(ProxyType::Staking),
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we check other ProxyType like Any also enable the add_stake call.

@open-junius
Copy link
Copy Markdown
Contributor

All V2 extensions are not the upgrade or replace of V1. Could use the name like proxy_xxx.
Do you consider use the unique extension to implement them all. like proxy_execute(real_coldkey: AccountId, call: RuntimeCall). like in EVM precompile https://github.com/opentensor/subtensor/blob/main/precompiles/src/proxy.rs#L146.

@LandynDev

This comment was marked as outdated.

@LandynDev LandynDev force-pushed the feat/proxy-aware-chain-exts branch from bab4fe2 to 59072b0 Compare April 4, 2026 18:43
Add 12 proxy-delegated chain extension variants that allow a smart
contract with proxy rights to manage stake on behalf of a proxied
coldkey. Each handler verifies proxy authorization via zero-delay
proxy storage lookup before dispatching as the proxied account.

- verify_proxy: checks Proxies storage for matching delegate with
  correct ProxyType (Staking for most ops, Transfer for transfer_stake)
- 12 Proxy* FunctionId variants in types.rs with NotAuthorizedProxy output
- ink! contract bindings for all 12 proxy functions
- 17 proxy tests (5 auth verification + 12 per-operation success)
- 2 discriminant stability tests
- Updated wasm-contracts.md documentation
@LandynDev LandynDev force-pushed the feat/proxy-aware-chain-exts branch from 59072b0 to e4e98d5 Compare April 4, 2026 18:50
@LandynDev
Copy link
Copy Markdown
Author

All V2 extensions are not the upgrade or replace of V1. Could use the name like proxy_xxx. Do you consider use the unique extension to implement them all. like proxy_execute(real_coldkey: AccountId, call: RuntimeCall). like in EVM precompile https://github.com/opentensor/subtensor/blob/main/precompiles/src/proxy.rs#L146.

I went ahead and implemented this with Proxy* variants (e.g. ProxyAddStakeV1, ProxyRemoveStakeV1, etc.).

Regarding a single proxy_execute(real_coldkey, call: RuntimeCall) — I actually started with that approach (a generic proxy_call dispatcher that took SCALE-encoded RuntimeCall bytes). The problem is that ink! contract developers would have to manually SCALE-encode the target function selector and all arguments into raw bytes. Found it to be error-prone and a poor developer experience.

I pretty much just implemented it how the Caller* variants were done in #2550.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants