Direct XCM ExportMessage fees for different bridges to different receiver accounts

[serban300]

Related to #1549 and paritytech/parity-bridges-common#2554

[svyatonik]

LGTM. During review, I realized that I've been sure that we will be distributing fees between different bridges at the sending chain (AH). But obviously I was wrong and BH is the right place to do that.

[svyatonik]

Do not know if there was some design solution behind having Get<Option<AccountId>> in the previous version? Maybe some storage parameter was intended to be used - so fees still may be burnt unless governance has configured chain properly? But in any case - new version looks cleaner to me, just stumbled upon it

[serban300]

I think Get<Option<AccountId>> was needed in order to support the case where we wanted to waive the fees for some locations and burn the ones for the other locations using the XcmFeeToAccount.

But now, that we have a separate component for handling fees, we can use XcmFeeManagerFromComponents to specify the set of waived locations and the handling logic independently. And we can use XcmFeeManagerFromComponents<WaivedLocations, ()> for the scenario above.

[bkontur]

lgtm

[vgeddes]

This is also good for Snowbridge. In our case a portion of the collected export fee will be routed to the sovereign account of the parachain from which the computed origin descends. So we will likely implement a custom XcmFeesToAccount that does this routing.

[KiChjang]

I still think the appropriate place for this is in XcmContext. There may be situations where it's useful for configurable items to know what the ultimate destination for an XCM program is. The problem is whether we should include intermediate destinations -- maybe a BoundedVec<MultiLocation, ConstU32<8>> would do?

[serban300]

@KiChjang

I still think the appropriate place for this is in XcmContext. There may be situations where it's useful for configurable items to know what the ultimate destination for an XCM program is.

I experimented with this a bit, but I'm not sure if I understood correctly. I tried to add a destination field to the XcmContext as Option<MultiLocation> and set it whenever executing an instruction that has a destination. Like TransferReserveAsset, ExportMessage, etc. Is this what you are suggesting ? If so, I don't think this would be the ultimate destination of the XCM program. What about programs that have multiple instructions that call send (not sure, but I guess it's possible) ? For example

Xcm([
    ExportMessage( network: A, destination: A-para-1, xcm: ..),
    ClearOrigin,
    ExportMessage( network: B, destination: B-para-1, xcm: ..),
])

Each instruction could have a different destination, and some instructions might not have any destination at all (would be executed only locally). So considering that this destination is not "ultimate", do you think it would still make sense to add it ?

The problem is whether we should include intermediate destinations -- maybe a BoundedVec<MultiLocation, ConstU32<8>> would do?

I'm not sure if this is possible. From what I understand, the intermediate destinations unfold as we execute the sub-parts of the XCM message on different chains, and the XCM itself doesn't hold a state across multiple chains. Only if we add a separate intermediate_destinations argument to each instruction, or an instruction SetIntermediateDestinations. Or maybe I'm missing something. Could you add more details on this suggestion please ?

[KiChjang]

What does "intermediate destinations unfold as we execute the sub-parts" mean? Why is it not as simple as looking into the xcm parameter in instructions like InitiateTeleport or InitiateReserveWithdraw, and looking for specific arguments in certain instructions, such as the dest parameter of a TransferReserveAsset/DepositReserveAsset/InitiateTeleport instruction?

[serban300]

What does "intermediate destinations unfold as we execute the sub-parts" mean? Why is it not as simple as looking into the xcm parameter in instructions like InitiateTeleport or InitiateReserveWithdraw, and looking for specific arguments in certain instructions, such as the dest parameter of a TransferReserveAsset/DepositReserveAsset/InitiateTeleport instruction?

Sorry, you're right. I don't remember what I was thinking about. Anyway, yes, it would work if we parse the entire message beforehand. But still I think we would have multiple branches, and not an ultimate destination and the route to it.