New Tooling and Infrastructure to facilitate the Statemint roadmap

Tech Talk
1

Assets Transfer API, NoS and future workflow for Statemint

Intro: The Statemint Roadmap

A few months ago, Joe Petrowski posted a general roadmap for Statemint for the year 2023. The post mentioned that exchanges, custodians and other institutions currently need to run individual parachain infrastructure to process deposits and withdrawals, and maintain additional tools and libraries to construct transactions for each parachain. Obviously, this does not sound like a very scalable approach, specially in the long term with many more active parachains/parathreads. One of the main points made in this post was to make Statemint the main place for asset management in the Polkadot ecosystem. This should apply for parachain native assets, stablecoins, DOTs and even externally bridged assets.

The advantages of achieving this vision for Statemint relate to improving the user experience in the ecosystem and particularly, simplifying the integration process for any asset by entities previously mentioned. In other words, reducing the complexity in UX terms of a multi-chain ecosystem to a “single-chain” environment.

Practically, this implies that, with the adequate tooling, an exchange will just need to transact on one parachain (Statemint) and access every other without any infrastructure lift. The objective of this forum post is to introduce new tooling in this direction.

Facilitating the Vision for Statemint

The Integrations Team at Parity is currently working on specific tooling and infrastructure to simplify the integration of ecosystem assets in Statemint. Practically this boils down to two projects:

Assets Transfer API

Assets Transfer API is a simple and compact API to send transactions from Statemint to any chain in the Polkadot ecosystem. The API will expose a reduced set of methods and the user (f.e., a custodian) will just input a simple set of arguments as:

  • asset ID and asset amount
  • destination address and destination (para)chain ID.

Under the hood, the API will construct the right call for the corresponding extrinsic depending on the input arguments. For example, if the destination parachain is Statemint, this will simply be a transferKeepAlive call of the assets pallet. However, a reserveTransferAssets call of the XCM pallet would be constructed when the destination chain was any other parachain. This API will have other optional inputs, for example, to choose the fee paying asset, but the main functionality will be as simple as mentioned.

This way all the complexity of a multi-chain environment is abstracted away from the user. They do not need to know how the XCM format works, they only need to understand the basics for assets, accounts and (para)chain representation.

NoS

NoS stands for Node + (API) Sidecar and consists of a simple script to launch a full node of Statemint together with a running instance of API Sidecar on one host (a docker container, for example). This effectively simplifies the process of integrating with Statemint to a one-step process for exchanges or custodians.

Parity will maintain images for relay chain and system parachains, whereas parachain teams will be encouraged to do similarly for their chains.

Withdrawals User Journey Example

Let’s assume that a custodian is a consumer of the Assets Transfer API with a Statemint setup provided by running NoS. The user journey would then be:

  1. The end user requests the withdrawal of a certain parachain native asset to the custodian
  2. The custodian creates the transfer extrinsic using the Assets Transfer API
  3. The custodian submits the extrinsic using the Statemint node setup provided by NoS
  4. The custodian monitors the receiving chain for the relevant XCM message
    • Parachain teams could facilitate this by providing their own NoS images.

What’s Next

Several parachain teams are already aware of this initiative but with this post, the idea is to reach the remaining teams and gather feedback. In the meantime, the relevant entities (mainly exchanges and custodians) will be contacted regarding support for ecosystem assets and this tooling is a cornerstone to support the vision for Statemint.

In terms of the actual development of the new tooling:

  • Assets Transfer API is WIP in a private repo at the moment. The idea is to go public and have the first working release at the beginning of March 2023.
  • We are currently doing some internal demos for NoS. The plan is that in the next weeks it should be ready to be showcased to the relevant entities.

Summary

With this post, I wanted to introduce the new tooling and infra that the Integrations Team at Parity is building to facilitate the vision shared in the Statemint Roadmap post.

8 Likes
2

So this is only for institutions?

Is this a JS SDK? Or an API server? Can we just make a universal XCM SDK? Something like this: GitHub - polkawallet-io/bridge: Polkadot bridge js SDK with XCM transfer.

1 Like
3

Great!!

1 Like
4

Hey @xlc,

Thanks for the question. We are building the Asset Transfer API because we see the need to make transacting across parachains a lighter lift. We are taking into account the needs of institutions (namely exchanges) as a high priority to start because we believe this will have the greatest positive impact on the ecosystem in the short term. This being the case the goal is to provide the functionality that exchanges care about the most; transfers. This doesn’t mean that we would not also make this tool open to the public for anyone to use. In fact, I think it would make sense to have a publicly hosted instance of the Asset Transfer API available for anyone to use to perform reserve-based transfers.

I would consider the Asset Transfer API the first iteration of what you are suggesting though. Once we have a “universal transfer API” it would make sense to extend the tool to support all the other cool things that XCM is capable of, and after looking at the link you shared we could definitely learn from the patterns used in the Bridge SDK.

3 Likes
5

This is super exciting! The Asset Transfer API is going to bring a much needed injection – especially when the destination chain is another parachain besides Statemint and for assets other than DOT –

For the “assetID” input (and optional fee paying asset) of the Asset Transfer API, we would like to see a compact Multilocation format under the hood – ideally:

  • (a) XCMv3 only;
  • (b) specifically, (a) should include GlobalConsensus, as Joe mentioned with ETH being MultiLocation { parents: 2, interior: X1(GlobalConsensus(Ethereum)) }
  • (c) with some convention on symbol to distinguish between different asset origins, e.g. DAI.xyz can mean this DAI came from “xyz” chain

In particular, we have a community oriented project XCM Global Asset Registry that facilitates maps between multiple registries for assets like {DOT, USDT, DAI,…} which deserve updates to (a)-(c) in coordination with this super initiative.

There is not much to talk about if the scope is just DOT + USDT. But to cover all parachain assets from all kinds of asset origins, we encourage you to join the XCM GAR Telegram here

3 Likes
6

One stop/step integration of all parachain tokens into CEX-exchanges is absolutely needed and will be an enormous catalyst function throughout the Dotsama ecosystem. We need the Statemint DEX and the Dotsama one step asset integration for CEX-es as soon as possible. This is great news!!

1 Like
7

I am excited to update this post to say that the beta release of the Asset Transfer API is out:

Summarising, this beta release of the API allows to create cross (and intra) chain transactions to transfer tokens native to the relay chains or the AssetHubs. More features are to come in the following weeks.

For more details, refer to the release notes.

5 Likes
8

Wonderful and thanks​:clap:t2::clap:t2::clap:t2::pray:t2: