-
Notifications
You must be signed in to change notification settings - Fork 43
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
RFC: agent instructions #42
base: master
Are you sure you want to change the base?
Conversation
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/xcm-rfc-agent-instructions/3819/1 |
``` | ||
|
||
### Implementation details | ||
These three instruction allow for different implementations of proxying transactions via an |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These three instruction allow for different implementations of proxying transactions via an | |
These three instruction allow for different implementations of proxying extrinsics via an |
## Summary | ||
|
||
The RFC introduces the addition of agent instructions into XCM, specifically introducing three | ||
new instructions: SetAgent, RemoveAgent, and TransactAsAgent. These instructions allow a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Throughout
new instructions: SetAgent, RemoveAgent, and TransactAsAgent. These instructions allow a | |
new instructions: `SetAgent`, `RemoveAgent`, and `TransactAsAgent`. These instructions allow a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There seems to be a general misuse of the term "transaction". This introduces confusion when discussing actual transactions (i.e. signed extrinsics submitted directly to a runtime) vs. transacting through means such as cross-chain messaging.
I think it would also be worthwhile to note, although implementation-dependent, that a single agent
could be set with multiple permission
s, just like you can designate an account as both a Staking
and Governance
proxy. The implementation of instructions like RemoveAgent
will need to consider this, meaning whatever stores agents locally (e.g. Proxy pallet) will need a data structure that is friendly to finding all agents with a given MultiLocation
. An alternative would be to change the signature of RemoveAgent
to remove just one particular agent and/or add a RemoveAllAgents
instruction that a chain could choose not to implement should its agent storage structure not be conducive to removing many.
Summary
The RFC introduces the addition of agent instructions into XCM, specifically introducing three
new instructions: SetAgent, RemoveAgent, and TransactAsAgent. These instructions empower a
location to designate an agent to operate on its behalf, enabling the agent to dispatch calls on behalf of the origin. This is particularly beneficial for local accounts, which can act as
agents for remote locations. This reduces the number of Transact instructions the remote
location needs to send. An agent is also able to dispatch calls via XCM using the
TransactAsAgent instruction.