Research: XcmFeesToAccount fee manager - mitigate limitations affecting the bridges

[serban300]

Related to XcmFeesToAccount fee manager PR: paritytech/polkadot-sdk#1234

See this comment: paritytech/polkadot-sdk#1234 (comment)

Specifically:

For example, If our bridge (or any other one) is misconfigured, it could potentially drain TreasuryAccount empty, and potentially break other bridges who are also holding funds in that account.

[serban300]

XCM related issue: paritytech/polkadot-sdk#1549

[serban300]

Things that we want to cover here:

1. the possibility to set the target account where the XCM delivery fee is deposited based on the XCM message destination

• reason: Introduce XcmFeesToAccount fee manager polkadot-sdk#1234 (comment)
• XCM related issue: Add destination info in FeeManager::handle_fee polkadot-sdk#1549 .

2. the possibility to set the XCM delivery fee value based on XCM message destination

• here we can already set different delivery fees over the bridge based on destination, but only for our static fee, not the XCM dynamic delivery fee: https://github.com/paritytech/polkadot-sdk/pull/1352/files#diff-ea9251f22dd8abd9e29a6ecae8a27eba7f1548996c3413596af33b099efeb81eR613-R627 . We should think if this is enough.

I'm looking again over our entire workflow trying to research these points.

[serban300]

I will write here what I find and update this comment:

1. the possibility to set the target account where the XCM delivery fee is deposited based on the XCM message destination

Left a comment with a possible implementation idea (on how to provide the destination to the FeeManager) on the XCM-related issue: paritytech/polkadot-sdk#1549 (comment)

2. the possibility to set the XCM delivery fee value based on XCM message destination

For this point we can already set different delivery fees over the bridge based on destination, as mentioned above, and from what I understand, they are actually dynamic, computed according to the logic in the xcm-bridge-hub-router pallet. The logic is similar to the one in paritytech/polkadot-sdk#1234 , but we also take into consideration the bridge congestion, not only the XCMP queue congestion. After paritytech/polkadot-sdk#1234 is merged, we should probably keep only the bridge congestion logic, otherwise we'll tax twice for XCMP congestion.

So I think here, in terms of fees, what we have is enough. The problem is still the one at point 1. The fees get deposited in the same account.

[serban300]

Resolved in Resolved in by paritytech/polkadot-sdk#2021