This is the first trial to share a general observation of certain user (users being defined in different personas categories, see below) challenges for a.) creating awareness in the ecosystem, b.) getting feedback on alignment or different views, and c.) evaluating the possibilities for solutions to tackle these challenges.
- Reserve-backed assets (USDT, USDC, BUSD, …)
- Parachain native assets (GLMR, ACA, …)
- Bridged assets (ETH, KSM on Polkadot)
- Non-fungible assets
- End-User or user acting as an end-user (customer of an exchange or custodian, etc.)
- Market Intermediaries like custodians, liquidity providers, market makers etc.
- Application developers
Write-up of the different scenarios based on before mentioned categories.
Scenario: Central Exchanges
1.1 Asset Cat 1: Reserve-backed Assets
Non-parachain native assets get minted on Statemint/e and reserve-transferred to other parachains. The issuer of these assets has control of the asset management (mint/burn). Exchanges or any other party purchases these assets from the issuer and gets them transferred to their Statemint/e-based account.
End-Users are acquiring the non-parachain native tokens from exchanges and get them withdrawn from the exchanges to Statemint/e. As Statmint/e doesn’t provide any meaningful functionality to the end-user, most of these assets will immediately be transferred further to one of the connected parachains.
It is not only cumbersome for the end-user to withdraw the asset to Statemint/e and initiate another transaction to transfer the asset to the expected parachain, requiring knowledge of XCM and multi-chain transactions. The user will also need to manage a Statemint/e account to accept the transfer and initiate the new one. The account could have a different account pattern, like for EVM chains. As Statemint/e is acting as an intermediary-only parachain in this case, it would be beneficial to the end-user if he could withdraw the asset directly to the parachain account without any interactions with Statemint/e.
1.2. Asset Cat 2: Parachain Native Assets
Parachain native assets currently get minted as the token distribution event through runtime upgrades following the initial crowdloan contribution and token distribution economic and are created under the balances pallet. Exchanges currently support parachain native assets through parachain-specific integrations. Parachain integrations currently are, at a minimum, running and maintaining a collator node as well as sidecar for every supported parachain.
End-Users are acquiring the parachain native tokens from the exchanges and get them withdrawn from the exchange to parachain.
With the growing number of parachains and potentially exponentially growing number of parathreads it becomes tremendously difficult for exchanges to support all of these networks with their integration. While this can be beneficial for only giving the most valuable parachains the possibility to integrate with exchanges, it is a resource-intensive process for multiple participants to coordinate. Precisely when it comes to maintaining release updates from parachain teams and ensuring the integrity between sidecar and collator nodes. It would be beneficial to exchanges if they could manage parachain native assets through as least as possible integrations or only one single integration, which could be Statemint/e, for example.
- Add `CreateOrigin` to Assets Pallet by joepetrowski · Pull Request #12586 · paritytech/substrate · GitHub
1.3. Asset Cat 3: DOT
DOT is the most widely distributed ecosystem token with various utilities on the relay chain and increasing use cases on the ever-growing parachains. Similar to Asset Cat 1: Non-Parachain Native Assets, end users acquire the DOT assets from the exchanges and withdraw them to their relay chain DOT account. Some users will choose to manage their DOT at this level, such as staking and governance. In contrast, other users may wish to direct these DOT onto Parachain destinations for different purposes.
As DOT has the best liquidity and the largest community, the ecosystem DeFi bootstrap its activities from DOT. From the exchange perspective, enabling Parachain withdrawal/deposit of DOT equals “one token, multi-chains”, meaning they will need to develop a separate wallet for each Parachain-DOT, adding operational burden to the exchanges, which could weaken their business considerations. While some Parachains have created user interfaces to move DOT into their turf, the ability to withdraw DOT directly into these destinations will significantly reduce users’ psychological barriers.
2.1. Asset Cat 2: Parachain Native Assets
For non-parachain native assets, this will always need the integration of Statemint/e. For parachain native assets support through custodians, it is similar to Szenario Exchanges: Parachain Native Assets support.
The problem statement for custodians supporting parachain native assets is similar to Szenario Exchanges: Parachain Native Assets support, but with different requirements. While exchanges require only the support of transferring assets, custodians need the support of all of the parachain native asset functionality. These are mostly asset transfer, staking and participating in the parachain-specific governance mechanism.
2.2. Asset Cat 3: DOT
Like Szenario Exchange: relay chain DOT, the default custodian support for DOT is solely on the relay chain level. As the ecosystem grows, the need from institutional asset holders who rely on custodians’ support to move the DOT between the relay chain and Parachains and across different Parachains should be served.
Scalability and maintenance difficulty is the key non-business considerations for custodians. Scalability includes if the XCM interface is the same for every Parachain. Some custodians feedback that the maintenance cost is high due to the frequent chain upgrades, and therefore they needed to halt the chain and chase the upgrades, causing user inconvenience.
Szenario: Market Maker, Trading Firms
3.1. All Asset Cat
For market markers and trading firms, the ability to operate seamlessly across marketplaces - whether DeFi products on different Parachains, or between DEXes and CEXes - is essential for them to contribute to the overall liquidity in our DeFi ecosystem, whether by way of shepherding liquidity or arbitrating.
The aforementioned exchange barriers for end users also apply to these market intermediaries, practically cutting off their line of DEX-CEX arbitrage which is often done via high-frequency trading (HFT) algorithms. There are too many steps for a market maker to manage liquidity transportation from a CEX (via relay chain or Statemint) to destination Parachains. For DEX-only arbitrages, trade batching (“wrap multiple trades across different DEXes into a single transaction”) is only possible on one chain via the batch_all extrinsic but not possible across Parachains using XCM as XCM is asynchronous (“fire and forget”). Flash loans (“uncollateralised loans without borrowing limits in which a user borrows funds and returns them in the same transaction”) are also not possible cross-Parachains because XCM calls necessarily take more than one block.