search

paritytech / parity-bridges-common

Collection of Useful Bridge Building Tools 🏗️
GNU General Public License v3.0
270 stars 133 forks source link

Research: XcmFeesToAccount fee manager - mitigate limitations affecting the bridges #2554

Closed serban300 closed 11 months ago

serban300 commented 1 year ago

Related to XcmFeesToAccount fee manager PR: https://github.com/paritytech/polkadot-sdk/pull/1234

See this comment: https://github.com/paritytech/polkadot-sdk/pull/1234#discussion_r1321437977

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 commented 1 year ago

XCM related issue: https://github.com/paritytech/polkadot-sdk/issues/1549

serban300 commented 1 year ago

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
  2. the possibility to set the XCM delivery fee value based on XCM message destination

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

serban300 commented 1 year ago

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: https://github.com/paritytech/polkadot-sdk/issues/1549#issuecomment-1741007923

  1. 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 https://github.com/paritytech/polkadot-sdk/pull/1234 , but we also take into consideration the bridge congestion, not only the XCMP queue congestion. After https://github.com/paritytech/polkadot-sdk/pull/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 commented 11 months ago

Resolved in Resolved in by https://github.com/paritytech/polkadot-sdk/pull/2021