Feat: allow borrow automation

[mustermeiszer]

Description

Currently, we are on/off-ramping tokens from/to AssetHub frequently. Unfortunately, Circle does not recognize token transfers made through XCM. I.e. tokens are lost, because Circle does not know which account send them. My best guess would be, that the internal XCM transfer logic, using only traits does not trigger a single event that Circle can rely on.

But with the new remote account derivation logic that was introduces to AssetHub, we can fix this by doing a Transact(pallet_assets::transfer(..)) from the users remote account.

• Spec in detail is here - this PR uses Option A.

The proposed solution in our case here will look like:

• Deposit into Circle: batch_all(xtokens::transfer(..), palletXcm::send(..)).
  The first extrinsic will send a transfer tokens XCM, that will deposit the tokens in the remote account of the user, the second extrinsic will call Transact(pallet_assets::transfer(.., dest: Circle)) with the remote account of the user as the origin.
• Withdraw from Circle: batch_all(palletXcm::send(..)).
  • The extrinsic will call Transact(palletXcm::transfer(.., dest: Centrifuge)) with the remote account of the user as the origin. Sending the already existing tokens from the users account on AssetHub via XCM to Centrifuge*

Changes and Descriptions

• Allow dispatch of pallet_xcm::send(..) by any Origin::signed(..) - NOTE: No harm here, as we are not executing that on our chain. Messages is send straigt to destination
• LocalOriginToLocation fix - uses correct NetworkId now

Tasks

• Implement above changes
• Write integration tests for our AccountConverter - The thing is too important and we should have some hardcoded derivations to know that it is not changing might flieght
• Test with choopsticks and live state from Polkadot and Centrifuge

Checklist:

• I have added Rust doc comments to structs, enums, traits and functions
• I have made corresponding changes to the documentation
• I have performed a self-review of my code
• I have added tests that prove my fix is effective or that my feature works

[mustermeiszer]

@onnovisser and @annamehr this PR will allow to make on/off-ramping mostly automatic from the UI side. Which XCM to actually generate in the end I will post here and we can test it then in the UI. Unfortunately, I think we need to test the UI in the production network. But lets see.

[wischli]

But with the new remote account derivation logic that was introduces to AssetHub, we can fix this by doing a Transact(pallet_assets::transfer(..)) from the users remote account.

• Spec in detail is here - this PR uses Option A.

Another reason to upgrade to Polkadot v1.1.0 ASAP because that's the earliest version which supports remote account derivation AFAICS.

[mustermeiszer]

Yes, but we already got that in with out own custom deriation. So there is no need for that to enable that feature, but for sure polkadot upgrade is well needed now.

[mustermeiszer]

@wischli I would merge this one now that you have confirmed that it is working. The fees and all around that are AH related.

[lemunozm]

NIT. Maybe can be moved directly inside line 126

[mustermeiszer]

Not sure what you mean?

[lemunozm]

Seems like info is used only in line 126 under an already parachain_state(). So maybe call.get_dispatch_info() can be moved there. But a super NIT thing.

[wischli]

I was wondering whether we want to add RtApi calls to generate the derived accounts depending on the remote location. If at all, probably something for a subsequent PR. Right now, AH is the only expected remote location such that Apps could hardcode the derivation.

[mustermeiszer]

Already possible with the conversion_of api