Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Any Proxies Copyable from a Configured Source #3288

Open
joepetrowski opened this issue Feb 12, 2024 · 1 comment
Open

Make Any Proxies Copyable from a Configured Source #3288

joepetrowski opened this issue Feb 12, 2024 · 1 comment
Labels
T2-pallets This PR/Issue is related to a particular pallet. T6-XCM This PR/Issue is related to XCM.

Comments

@joepetrowski
Copy link
Contributor

It should be possible to recreate pure proxy relationships on remote chains (given a few conditions). The problem is that while "normal" proxied accounts can be set up on each chain, a pure proxy relationship cannot be recreated.

There has been some debate on multi-chain proxies, namely around the scope of permissions that a proxy has. For example, declaring a NonTransfer proxy on the Relay Chain means something, but a NonTransfer proxy on Asset Hub has additional functionality available, that the original setter may not have intended to grant to the proxy holder.

I'd like to propose that an Any proxy on a system chain really means Anything within the Polkadot system. That is, an Any proxy on one system chain (para or relay) should be able to create the same proxy-proxied pair on another chain in the system. Other parachains could obviously opt-in to recognize this if they wanted to, or ignore it if they don't.

Potential Solutions

This is relatively simple but there are tradeoffs. It will need to use XCM (I think) but there is no specific instruction for it (although we have discussed SetAgent).

The first idea that comes to mind is an extension pallet with a handler that will call Transact on a destination chain. Of course the pallet can know the call encoding of its own calls, but it would need to know the pallet index on the destination chain. That means either an agreed "this pallet is always at index x" or a table chain => index. The latter would mean needing governance to upgrade the source chains to support new chains that want to opt in to this feature.

@joepetrowski joepetrowski added T6-XCM This PR/Issue is related to XCM. T2-pallets This PR/Issue is related to a particular pallet. labels Feb 12, 2024
@Polkadot-Forum
Copy link

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/23

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T2-pallets This PR/Issue is related to a particular pallet. T6-XCM This PR/Issue is related to XCM.
Projects
Status: Backlog
Development

No branches or pull requests

2 participants