interlay / bridge Goto Github PK

Support XCM between Moonriver and Kintsugi for:

• MOVR
• kBTC
• KINT

Support XCM between Moonbeam and Interlay for:
TBC

Split off (not a must-have for launch):

• #47

We need to upgrade to version 10.3.1 or newer as part of the runtime upgrade to 1.25.0
If possible go to the latest version.

We disabled automated chopsticks tests in PR #129

Blocked by issue raised upstream: AcalaNetwork/chopsticks/issues/547

Once the chopsticks issue has been resolved, and the upstream fix has been merged to our fork, we can reenable these tests.

Interlay.spec is currently failing on the statemint tests. Test is being skipped for now but should be fixed at some point.

The current configuration for the existential deposit (ed) of 1_000 for USDT on Statemint is incorrect.
It should be 700_000.

assets.asset(1984) returns (around block ~3_300_000):

{
  owner: 15uPcYeUE2XaMiMJuR6W7QGW2LsLdKXX7F3PxKG8gcizPh3X
  issuer: 15uPcYeUE2XaMiMJuR6W7QGW2LsLdKXX7F3PxKG8gcizPh3X
  admin: 15uPcYeUE2XaMiMJuR6W7QGW2LsLdKXX7F3PxKG8gcizPh3X
  freezer: 15uPcYeUE2XaMiMJuR6W7QGW2LsLdKXX7F3PxKG8gcizPh3X
  supply: 7,998,764,144,702
  deposit: 1,000,000,000,000
  minBalance: 700,000
  isSufficient: true
  accounts: 290
  sufficients: 164
  approvals: 2
  status: Live
}

Note: ed of 1_000 is correct for Statemine.

In particular for transfers FROM interlay.

To bifrost adapter

Support XCM between Bifrost and Kintsugi for:

• vKSM

idea: cron job in github action on bridge/UI repo to test XCM every X hours with chopsticks to validate that XCM is still working considering runtime upgrades

If we ignore the UI part, it'll be straight forward to test - we can just have a ts script that does a bunch of xcm transfers, and then checks if the tokens arrived. I would suggest doing this in 2 steps:

• Write TS script to make and check xcm transfers
• Write a cron job or bash script to start a new chopsticks instance, and to launch the script (and report errors if there are any)

We want to prepare all adapters for an upcoming change in XcmVersionedMultiLocation versions.
This is similar to the work done previously for Polkadot and Statemint adapters in PR #73

These adapters need work to prepare for version changes:

• Acala
• Astar
• HydraDX
• Interlay
• Parallel

Support XCM for Statemint and Statemine:

• DOT to and from Interlay
• KSM to and from Kintsugi

See discussion here:
https://discord.com/channels/745259537707040778/1154823186563739739

Support XCM between Parallel Heiko and Kintsugi for:

• kBTC

Split off (not a must-have for launch):

• #49

With the name changes of May/July:
Statemint -> Polkadot Asset Hub, and
Statemine -> Kusama Asset Hub

It would be beneficial to update the internal chain ids used in the bridge, too.
Beware this is a breaking change, so please make sure known downstream dependencies are informed early (eg. UI team) so they know when this comes down the pipeline.

The anticipated places the id change will impact are:

• chain configuration files (src/configs/chains),
• various tests that mention "statemint" and "statemine" explicitly,
• automated xcm test scripts (under scripts/),
• github actions (.github/workflows/xcm-tests.yml)
• upstream, we may need to adjust the config file names and contents in our fork of chopsticks
• README code snippets

With xTokens updates probably applying to all parachains, we need to future-proof all the adapters that use xTokens.transfer.

See this PR as and example.

Recent changes to the AssetHub's logic broke chopsticks tests when sending USDC or USDT from Interlay to AssetHub.

The main change was that the USDC/T amounts are converted to DOT before sent as fees. That seems to make the tests fail even though the destination fee estimates are set high enough.

Find out which evaluation logic fails, fix it, and reenable the test cases.

For reference: the test case was disabled in commit 9b3fb50

Our bridge doesn't have a way to get DOT or KSM to their respective Asset Hubs (formerly known as Statemint/e).
However, in order to transfer USDT from Asset Hub, we need DOT/KSM there.

We can transfer DOT/KSM to Polkadot/Kusama, so adding a route from Polkadot/Kusama to Asset Hub allows us to move the funds needed.

With Astar switching from using the polkadotXcm pallet to using xTokens instead, we need to update how our bridge implementation handles this.

We can use polkawallet.io's implementation as reference:
https://github.com/polkawallet-io/bridge/blob/4d8aed2d06d313d44a0980e68ec47cb9cf23263f/src/adapters/astar.ts#L273-L351

For context, the update from Astar:

We have integrated the xtokens pallet to enable the sending of XCM assets from Astar.

🔧 Action Required for UI Providers:
Partners who provide a UI for sending XCM transactions from Astar will need to implement updates since the polkadotXcm pallet has been deprecated.

🧪 Example Transaction Details:
Transfer from Astar to Interlay
INTR: https://astar.subscan.io/extrinsic/0x20dec131afe8d1ca1296bf469d240ff6c61b5f48f9c6fbe410a1d1a502073326

📝 Notes
You can test sending transactions on our portal https://portal.astar.network/

Adapters throw an error when trying to query the balance for their native token - if the native token isn't configured as a transferable token.

We want to provide a method to query for the native token's balance specifically. Even if it is not transferable.

Add support to transfer vKSM from Bifrost

Related to / dependent on #54 .

Expand tests to check that:

• actual XCM fees were below estimated fees

Support XCM between Karura and Kintsugi for LKSM

Split off from #41 as LKSM transfer capabilities are not a must-have prior to launch.

Uncomment code parts to re-enable USDT xcm to/from Interlay/Kintsugi <-> Statemint/Statemine

When signing and sending a transaction, we can provide an option assetId: AnyNumber to use that asset to pay for the submitted extrinsic.

eg. to pay for sending USDT from Asset Hub to Interlay, and pay the submission in USDT too, we would submit something like this:

transaction
            .signAndSend(account, { nonce: -1, assetId: 1984 }, (result: ISubmittableResult) => callback({ unsubscribe, result }))
            .then((u: () => void) => (unsubscribe = u))
            .catch((error) => reject(error));

This feature request is to provide an API to get a list of asset ids by token name so the consumer (our UI) can use that number to feed into the assetId option.

Currently the automated chopsticks tests use configuration files with a single, hard-coded wss link as rpc endpoint.
If, for some reason, there are issues with the rpc endpoint, chopsticks will run into errors, or may just not start correctly. This then leads to test errors which more often than not are false negatives.

Instead of using a fixed wss link, we want to use a collection of wss links, with backups mirroring the ones we use in the UI .
We can attempt a connection race in a test perparation/setup script, similiar to how the XCM lib does it for the api providers, and then use the endpoints that responded to construct the configuration yaml file using the wss link of the connection that won.

Support XCM between Karura and Kintsugi for:

• kBTC
• KINT

Split off (not a must-have for launch):

• #48

Support XCM between Parallel Heiko and Kintsugi for sKSM.

Split off from #43 as it is not a must-have prior to launch.

Prerequisite for some of the points on UI meta issue interlay/interbtc-ui#842

• iBTC, INTR - Acala
• iBTC, INTR - Parallel
• iBTC, INTR - Astar

My concern is that we might forget to add that "latest addition" and then run into issues down the line.
Perhaps we can check the static list against the actually implemented we find as we navigate the adapters' routes?
Again: I'm fine with adding that as a todo/issue to be addressed outside of this PR.

Originally posted by @bvotteler in #57 (comment)

We chose to disable chopsticks tests for HydraDX due to a large number of false negatives when chopsticks ran into issues getting data from HydraDX rpcs.

This goal of this issue is to reenable and rerun at least 10 tests over the span of a day or two to check the reliability. If it has improved (ie. no failed tests due to connection problems), then reenable the test case.

For reference, the PR disabling the test is here: #137

We still have duplicated code left for adapters using polkadotXcm pallet methods such as limitedTeleportAssets.
(See also the related comment in PR#105.)

We want to deduplicate the logic similar to how we did for the xTokens pallet. For reference, see the xTokens-helper file.

Support XCM between Moonriver and Kintsugi for wstKSM

Split off from #40 , as it is not a must-have XCM option for launch.

Notes:

• wstKSM is blocked on Lido at the moment.

... and reduce the pulled in dependencies to the minimum needed.

Currently, we only support XCM transfers between Interlay/Kintsugi on the one side and on the other side Polkadot/Kusama, Statemint/Statemine.

The other adapters are needed for the original project, but are only really clutter for our use-case. We can bring them back over from polkawallet-io/bridge as needed when we expand the XCM options from our side.

Acala/Karura is a case where they support XCM from their dapp, but we do not support sending yet, but keeping the adapter requires a lot of unnecessary dependencies being pulled in.

@bvotteler Dom's suggestion is to switch to using the repo we forked from for our xcm bridge. I'm not entirely sure what that means—could you add some details to the ticket?

Some of this work will be done on the UI, so that unresponsiveness XCM channels are disabled individually rather than blocking the bridge from loading.

We want to bump our polkadot-js dependency to align it with the version that will be used by the lib and UI soon.

HydraDX has a feature to set a different extrinsics fee currency which then is used for future extrinsic submissions.
Our xcm lib does not take that into account and assumes the fee currency will be the native currency (HDX).
Therefore, the xcm bridge can run into errors when the user doesn't have enough fee currency available to submit the xcm extrinsic (but has enough HDX if the fees were still in HDX).

Therefore, we want to add:

• an adapter or balance adapter method that gets the fee currency. The default implementation returns the native currency, and
• HydraDX's implementation discovers and returns the actual set currency, and
• the fee estimation implementation should be modified to utilize those methods to provide the estimated extrinsic submission fee correctly.