interlay / bridge Goto Github PK
View Code? Open in Web Editor NEWThis project forked from polkawallet-io/bridge
Polkadot bridge js SDK with XCM transfer.
License: Apache License 2.0
This project forked from polkawallet-io/bridge
Polkadot bridge js SDK with XCM transfer.
License: Apache License 2.0
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 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.
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.
We want to bump our polkadot-js dependency to align it with the version that will be used by the lib and UI soon.
@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.
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/
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:
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.
... 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.
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.
To bifrost adapter
Support XCM between Karura and Kintsugi for LKSM
Split off from #41 as LKSM transfer capabilities are not a must-have prior to launch.
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 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.
Interlay.spec is currently failing on the statemint tests. Test is being skipped for now but should be fixed at some point.
Support XCM for Statemint and Statemine:
Add support to transfer vKSM from Bifrost
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
Support XCM between Bifrost and Kintsugi for:
Support XCM between Parallel Heiko and Kintsugi for:
Split off (not a must-have for launch):
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:
Support XCM between Moonriver and Kintsugi for wstKSM
Split off from #40 , as it is not a must-have XCM option for launch.
Notes:
See discussion here:
https://discord.com/channels/745259537707040778/1154823186563739739
Support XCM between Parallel Heiko and Kintsugi for sKSM.
Split off from #43 as it is not a must-have prior to launch.
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
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:
src/configs/chains
),scripts/
),.github/workflows/xcm-tests.yml
)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.
In particular for transfers FROM interlay.
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.
Uncomment code parts to re-enable USDT xcm to/from Interlay/Kintsugi <-> Statemint/Statemine
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:
Related to / dependent on #54 .
Expand tests to check that:
Prerequisite for some of the points on UI meta issue interlay/interbtc-ui#842
Support XCM between Moonriver and Kintsugi for:
Support XCM between Moonbeam and Interlay for:
TBC
Split off (not a must-have for launch):
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.