Allow treasury to send XCM calls

[samelamin]

Closes #18

This PR would make it possible for treasury spends via xcm but its currently blocked awaiting an audit so this is an interim solution that should achieve a similar result

How I envisage this working with treasury spends:

Treasurer track to ensure we avoid spend limits

batch { 
spend(ParachainSovereignAccount), 
// Notify destination of funds sent
send(dest: para, xcm: [ReserveAssetDeposited, ..]) 
}

[xlc]

need to ensure this can't be used to bypass the spender limit, or only support treasury origin which doesn't have the limit

[samelamin]

need to ensure this can't be used to bypass the spender limit, or only support treasury origin which doesn't have the limit

That's a good point. I have changed it so it only uses the treasurer origin

But speaking to Bryan it might make sense to add xcm spends on the treasury pallet to allow spend limits there and dispatch the call from the pallet itself

[KiChjang]

The XCM config looks fine to me, but I am unsure about the implications of allowing the treasury to use the send extrinsic. Like what @xlc says, we want to ensure that this cannot be used to bypass existing limitations.

[xlc]

The new code only allow Treasurer origin, which does not have any spend limits so should be fine. However I do think some e2e tests will be helpful to ensure this indeed working as expected.

[samelamin]

@xlc i don't mind building an integration test for this, but the current codebase doesn't have any integration tests

I could add some and follow what Cumulus are/was using, i.e. xcm-emulator

But again I am unsure if that's what's required here because most of the tests seem to be reusing macros from test-utils -> https://github.com/polkadot-fellows/runtimes/blob/main/system-parachains/asset-hubs/asset-hub-kusama/tests/tests.rs#L497

So I dont know if xcm emulator should be used in here. TBH, I do not see why not but it's always best to check

@bkchr @ggwpez what would make the most sense here?

[bkchr]

I already discussed this briefly with @xlc and we should support chopstick tests inside this repo here.

[samelamin]

Fair enough. In that case this is what I propose

1. Commit a dummy github actions file into main to run the test. We need the initial github actions file merged before we can run it as part of this pr

2. Use chopsticks to spin up a local network of both assethub and kusama and validate that we can send an xcm message using a treasury origin to assethub

Does the above sound reasonable?

[bkchr]

Sounds reasonable :)

[samelamin]

Closing this as raised a separate pr on the polkadot-sdk repo

[samelamin]

Reopening PR based on @bkchr comments

I can build a chopsticks test to run this but unfortunately, I will need a build runner that is powerful enough to run the actual test

In the meantime what I can do is build it via the free version of github actions until the build runner is built

That's essentially what I suggested here

Commit a dummy github actions file into main to run the test. We need the initial github actions file merged before we can run it as part of this pr

However, one thing to note is that reserve transfers are disabled from the relaychain to assethub and Penpal

So we can either

1. Allow reserve transfers from the relay to Penpal
2. Assert that the kusama XCM event is sent

The current xcm simulator tests on polkadot-sdk does 2.

However, not all chains will want to do this and I noticed that the parachain template also does this, is this intentional? Given that historically teams start off using the template would we want to define the barrier as so?

TLDR; What should the test assert on?

XCM event sent + balance reduction of sender

or

allowing a particular runtime to accept reserve transfers and doing the above + balance of receiver?

[samelamin]

Also, this pr will need a companion pr to XCM to convert the xcm location of the treasury

The XCM crate is currently pointing to the archived repo https://github.com/paritytech/polkadot.git

https://github.com/polkadot-fellows/runtimes/blob/main/relay/kusama/Cargo.toml#L103

Should I submit the companion PR to the archived Polkadot repo or the new XCM repo? https://github.com/paritytech/xcm

[bkchr]

Stale