Statemint Update / Roadmap

Tech Talk
1

I’d like to present here my vision for the next year of Statemint. I have spoken with people from other parachains, wallets, application developers, and service providers (custodians, exchanges, etc.) and think that it’s possible to make Statemint a lot more powerful for them and their users. These are the initiatives that some people at Parity are working on and I hope will be accepted by the DOT stakeholders in the referenda required to launch them.

The main features can be broken down into four tracks:

  1. Support for parachain native assets and bridged assets;
  2. More advanced NFT support;
  3. A decentralized exchange; and
  4. More advanced asset locking/reserving functionality.

Parachain Native Tokens and Bridged Assets

The current version of Statemint has one instance of the Assets pallet where anyone can permissionlessly claim an Asset ID and control that asset class from an “owner” account. But not every asset is controlled in that way.

The current Assets pallet uses integers to identify asset classes, with any metadata about them controlled by their creators. Just like on Ethereum where any user can deploy an ERC20 contract and call it “USD{x}”, anyone can do the same with an integer-based Asset ID on Statemint. This is not so big a problem, since users are already using the asset based on some trust in the creator. But when an asset class is actually controlled by a decentralized protocol, we can be more expressive of what that class is in its identifier.

A new (additional) instance of the Assets pallet on Statemint will use XCM MultiLocations to represent assets, and their corresponding origins to control them. This configuration will make it possible for parachains to send their native token to Statemint and use it with the API there. For example, Moonbeam’s native asset GLMR would have an ID of MultiLocation { parents: 1, interior: X1(Parachain(2004)) } and the corresponding origin, namely the Moonbeam parachain origin, would control the minting and burning of the asset on Statemint. With the upgrade to XCMv3 and the Global Consensus primitive, it can even represent assets from bridged chains, for example ETH would be MultiLocation { parents: 2, interior: X1(GlobalConsensus(Ethereum)) }.

This functionality serves a few purposes. In discussion with wallets, custodians, and exchanges, one of the pain points of integrating parachain tokens is that they require running individual parachain infrastructure like full nodes to process deposits, and require additional code to handle withdrawals because they need to be able to construct and broadcast transactions on each individual parachain. These parachains could use different balances pallets or order them differently. When we think of Polkadot hosting hundreds of parachains (and thousands of threads), this represents a huge obstacle (and cost) to network support. This is in contrast to for example adding support for an additional ERC20 token; the marginal effort is very small since an Ethereum node already serves all the data they need.

With support for these assets on Statemint, custodians/exchanges could just monitor one chain for deposits (applications and UIs would need to give the option to transfer to Statemint). For withdrawals, users could choose to withdraw to their address on Statemint (custodian makes an assets.transfer() call) or to their address on the parachain (custodian makes an xcm.reserveTransferAssets() call). There are two user experience bonuses here:

  1. For the custodian, they only need to transact on one parachain and can access every other without any infrastructure lift.
  2. For the user, they never actually need to “see” Statemint. It’s entirely abstracted away behind either the parachain wallet/application or the custodian.

Statemint support for bridged assets also keeps the Bridge Hub lean. It only needs to act as a message routing and forwarding service, but does not need to store any assets. The Bridge Hub origin would have permission on Statemint to manage the bridged assets via its messages. Like Statemint, the Bridge Hub can be completely abstracted out of user-view, with the Bridge Hub just providing an API to Statemint and other parachains. All fees can be taken at the origin parachain, and the user would never need to submit a transaction on the Bridge Hub.

Finally, Statemint support for parachain native assets will make it a gateway from DOT into these assets, and eventually a place where wallets can perform more advanced features with assets on Statemint (more on these below).

(cc @Peter from What needs to happen for our DeFi Ecosystem ASAP? - #4 by Peter)

Next Generation NFTs

Since launching Uniques on Statemine and Statemint, we’ve gotten a lot of community feedback from teams like Singular for application integration and have done our fair share of dogfooding by releasing NFTs there.

Earlier this year, we started an NFT working group with several community teams like RMRK, Phala, and Astar and got feedback from them about what kinds of features they wanted from native NFT functionality on a system parachain. This resulted in the Uniques V2 roadmap that has been under development (most of the heavy lifting by @jsidorenko).

The main features of this are the ability to buy/sell NFTs, including multi-asset support, smart attributes, and NFT fractionalization.

Smart attributes in particular have some interesting use cases. These allow the owner of an NFT to allow other entities (e.g. another account, an application, a parachain, a custom origin, etc.) to update certain attributes about the NFT. For example, a member of the Polkadot Technical Fellowship could have a membership badge that evolves over time by giving the Fellowship origin permission to update its attributes (e.g. Rank) on the badge directly. Smart attributes would also allow creators to participate in the future success of a collectible.

The final code for this is being reviewed and merged in FRAME, and we expect to launch it in the testnet Westmint before the holidays (devs - perhaps some holiday NFT tinkering?).

Decentralized Exchange

“Should Statemint have a DEX” has been a question since launch. For a long time I have fallen on the side of “no” (you will find many GitHub/Polkassembly posts from me stating as much), but from many discussions over the last year I have changed my mind.

I propose that we add a Uniswap V2 style DEX to Statemint, but am very interested to hear other arguments about this. Uniswap V2 is simple, well understood, and does not have privileged functions that control asset pairs. The design also plays nice with the Assets pallet; we could add a third instance of the pallet to represent the LP tokens where the DEX has control over these tokens.

A DEX on Statemint would serve as a path from DOT to any parachain native token (since they will be on Statemint too, as mentioned earlier). This gives parachain teams and their users permissionless, decentralized access to liquidity in the Polkadot network without relying on integration with third party custodians.

There have been several requests from people for a “trustless” DEX, i.e. one that would not be subject to any governance except Polkadot’s.

Finally, a DEX on Statemint improves its security and makes “sufficient” assets more adaptable and useful. For a long time, I thought we could get away with using a DEX on another parachain, but there are several scenarios where synchronous information enables more secure and flexible features. For example, right now governance has to be quite strict about what it considers a sufficient asset, because since that asset can pay transaction fees, and the owner of the asset can mint new tokens, they can buy unlimited execution for themselves. So governance must be conservative in only choosing “trusted” asset owners. By having a DEX on-chain that can synchronously handle the DOT fee to asset fee conversion, the network can be more lenient in allowing sufficiency since the protocol itself can handle any unscrupulous behavior from the asset owners by swapping the asset for DOT directly (removing DOT from the user’s point of view, and a large number of asset classes from the collators’).

Advanced Asset / Cross-Chain Features

Over the next year, one of the goals at Parity is to adapt the staking and governance related pallets so that they can work as parachains. Since DOT cannot be in two places at once, but both of these systems use overlapping locked DOT, we will need to be able to lock DOT in one place and “use” it somewhere else. One of the primitives for this, asset locking over XCM, comes with XCMv3.

We also want to extend this functionality to assets, as outlined in this tracking issue. This would allow assets on Statemint to be locked for simple things like vesting, but also for more complex applications like use in parachain protocols (or use in protocols on multiple different parachains). There are other advantages to this, e.g. what @xlc mentioned in How to Recover a Parachain - #16 by xlc.

Of course, parachain assets would always be “at home” on their native parachain and could be used there. This functionality just makes more things possible, but does not limit how anything on a particular parachain can function.

For parachains working with custodians and wallets/interfaces like Ledger Live, having this ability directly in Statemint allows them (and by extension, their users) to interact with parachains without needing to run nodes and infrastructure for them.

Summary

I hope this post gives people more clarity into the direction that I see Statemint going and what the team at Parity is working on.

47 Likes
2

Hello, @joepetrowski Thank you for your summary. Not sure how to implement Uniswap V2, but we have already implemented Uniswap V2 smart contracts written in ink! If this helps, let me know. We are happy to contribute.

9 Likes
3

A lot of good stuff in there, and plenty to talk about.

My thoughts Specifically about the DEX:

My initial position is NO to a DEX on statemine/t as thematically a marketplace does not belong on an asset registration chain.

Practically speaking, it is also mismatched to be on statemine. As a DEX you would want continued improvement and support. Whilst uniV2 is now ubiquitous, it is by no means efficient. The reason why we have a such a rich offering of pools (v3, balancer style multipools, curve’s price invariants) is because quite frankly univ2 slippage sucks compares to a central limit order book (CLOB) you’d find on a CEX.

Regarding the desire for “a trustless DEX”, I admit that would be interesting as an ecosystem primitive. For other projects and chains to be able to remote execute swaps via stateDEX (e.g. for DOT → USDT) and then back to their chain for any smaller MCAP assets. For the most part this is already achieved by existing smart contracts, you could quite simply deploy Uni’s contracts onto any EVM compatible parachain and you’re ready to go. What the true desire is behind this request then, is for concentrated and deep liquidity that all parachains can tap into permissionlessly, running on infrastructure which is relatively stable and not subject to bricking or hacks.

Another point against a stateDEX is that the swap fees from a DEX goes to fund all the other works and OpEx that goes into running a dex dApp. This includes the GraphQL, the FE development and maintainance, the growth initiatives and community management. In a world where a stateDEX which gobbles up all the liquidity (and hence all the fees), who exactly is supposed to build all the other components? How do they get paid?

Trying to solve the sufficiency problem is definitely worth looking into, but what about a dex-less solution? Options could include anything from delegated fees to the token deployer (with discounts based on gov or other params) to something exotic like pay-at-the-end-swaps (simulate the cross chain transaction and NACK it if it doesn’t return a portion of DOT for the fee).

My final point is, how much of this desire for a StateDEX goes away once SPREE is delivered?

3 Likes
5

Hi @joepetrowski - thank you for sharing the Statemint product roadmap with us.

I’m a contributor to Moonwell, the largest borrow/lend protocol in Dotsama, a Solidity Dapp on Moonbeam and Moonriver.

I might be misinterpreting the roadmap, so apologies in advance.

The primary challenge that the Polkadot ecosystem faces is that asset withdrawals from exchanges/custodians land on either the relay chain (DOT) or Statemint where there is no utility or smart contract execution environment. Thus, users must go through the painful act of transferring assets to a parachain where they are useful before they can do anything meaningful with these assets.

While these improvements will make it simpler for exchanges and custodians to support a single interface for deposit/withdrawal for multiple parachain assets, it doesn’t solve the primary challenge at all, and further introduces more friction. For example, if a users withdraws ACA (Acala token) from an exchange to Statemint, it’s easier for the exchange to support that withdrawal because it is the same interface they use for USDT withdrawals, however, it’s a worse user experience because now the user has ACA on Statemint that has no functional utility. They must use XCM to transfer ACA back to Acala’s parachain before it is useful.

So in many ways, while this is an improvement in quality of life for exchanges, it is a huge decrease in quality of life for end users and introduces even more friction. Please focus on the user. The exchanges matter, because ultimately exchange support is required for parachain assets to succeed, however, the user experience should be our highest priority, and until we can design a good user experience that competes with other L1 ecosystems (I can withdraw directly to a smart contract execution environment on almost every other competitive L1) we are not going to meaningfully compete with other ecosystems.

Last, having a Statemint native DEX would provide some nice utility and convenience for users that want to swap between assets, however, I think you are vastly underestimating the resources required to operate an effective DEX, and to do so would mean Parity is now meaningfully competing with apps on every parachain, with an unfair advantage (native withdrawals), so I believe it would do irreparable harm to the Dotsama ecosystem. Here are just a few of the challenges you’ll run into if you decide to build a native DEX:

  • Liquidity isn’t “free” - LPs won’t supply assets like DOT and USDT to a pool without some type of reward or incentive
  • If you don’t incentivize LPs, you’ll have thin liquidity, so users that want to swap more than a tiny amount of DOT will have high slippage and a bad experience.
  • If you do incentivize LPs with DOT rewards to get good liquidity, now you’re competing with parachains in a way that seems unfair
  • Operating a DEX will require a fulltime team of engineers. If you just deploy some contracts and do absolutely nothing, you end up with the thin liquidity problem above.

I hope this helps to illustrate some of the challenges we face on parachains. I would encourage you to look at the top smart contract L1 ecosystems to see what they are doing right. In every case I think you’ll see they’ve optimized the user experience to be as simple as this:

  • Withdraw token → Wallet → Interact with smart contract

Polkadot, however, is currently like this:

  • Withdraw token → Statemint (use Polkadot.js only) → Relay chain (now can use Talisman/Subwallet) → XCM to Parachain → Parachain wallet (either Substrate or EVM) → Interact with smart contract

Those extra step are brutal and are seriously harming adoption, both at a retail and institutional level. Thanks for listening to my concerns.

14 Likes
6

Actually the main point of this roadmap is to explicitly avoid this. This is what I meant by (especially 2):

The idea is that users would never directly use Polkadot JS or connect to a Statemint node themselves, providing exactly the flow you wish for:

Withdraw token → Wallet → Interact with smart contract

I really understand this, and have been on your side for a while. But I hear much more often the opposite, that Polkadot as a network is not able to compete with other L1s because it does not have a DEX. I overwhelmingly hear that not having a DEX is what’s causing irreparable harm to the Dotsama ecosystem.

Now, whether a DEX is in Statemint or elsewhere is another question. The reason it’s useful to have in Statemint, which was originally focused just on registering assets, is that it makes those assets more powerful. We can actually use the DEX synchronously in transaction payment so that any asset with a DOT pair can be used for fee payment. This would make UX better for anyone who does land on Statemint, as they won’t need to get DOT to get their asset off Statemint.

Finally, like you said, there’s a lot more to a DEX than just building it. I didn’t write anything about Parity operating it (in fact, if anyone has to “operate” it, then it’s not trustless). But I really don’t see it as a Parity-only project. I hope that a lot of people in the community will be involved in making it useful to the Polkadot network.

9 Likes
7

Ah, I missed that somehow. This actually does seem quite nice then. The part about “never having to interact with Statemint directly” is key. So for an exchange, is it as simple as specifying the target/destination parachain on the withdrawal transaction? That seems to solve a lot of the challenges. Thank you for clarifying.

I think if you are able to solve the exchange withdraw challenge in a meaningful way, this largely becomes a non-issue. Ethereum doesn’t have a native DEX either, but Uniswap and Curve have largely filled that role, and so long as users can easily get assets on any parachain that has a good DEX, that largely solves this issue.

There is another issue, and that is cross-parachain arbitrage, but even Ethereum has that same problem with L2s, and I think XCM and new DEX designs can largely solve that in a better way than Ethereum due to the fast finality vs. 7 day finality that you have between ETH L2 → L1.

Thanks for the quick response, and it sounds like a good strategy to me, if we can solve the “withdraw to any parachain” problem, the DEX issue largely goes away.

5 Likes
8

Yeah, we could have a few helpers for it at the tooling level. So to make an example (a few details might be off because I don’t know the Moonwell contract specifics, but this should illustrate):

Let’s call Moonwell “MW” and contract address 0x1234 on Moonbeam (Para ID 2004). Its Asset ID on Statemint would be:

let moonwell_token = { parents: 1, interior: X2(Parachain(2004), AccountId20(0x1234)) }

Now let’s say a user wants to withdraw this asset from an exchange. Just like when withdrawing USDT, an exchange might as, “which network (Ethereum, BSC, …)?”. Here, they could ask the same, with “Moonbeam” and “Statemint” as the options. This is pretty easy to code into a tool:

let user_address = 0xabcd...;
let network_choice = Networks::Moonbeam;
let mut tx;
match network_choice {
    Moonbeam => {
        assert!(is_moonbeam_formatted_address(user_address))?;
        tx = xcm.reserve_transfer_assets(
            dest: { parents: 1, interior: X1(Parachain(2004) },
            beneficiary: { parents: 1, interior: X2(Parachain(2004), AccountId20(user_address) },
            assets: moonwell_token,
            fee_asset_item: 0, // DOT, or something else that a DEX converts so the collator gets DOT
        );
    }
    Statemint => {
        assert!(is_statemint_formatted_address(user_address))?;
        tx = foreign_assets.transfer(
            id: moonwell_token,
            dest: user_address,
            amount: balance,
        );
    }
}

// sign transaction
// broadcast transaction

So when a user selects “Moonbeam” at the exchange, Statemint will act as an interface for the exchange, but the user will just see their MW arrive in their wallet on Moonbeam.

6 Likes
9

Awesome, that sounds like exactly what most parachains and apps need.

If we solve this challenge, is the Statemint DEX still necessary? I would prefer to see the trading volume go to DEXes built on parachains rather than a Parity DEX.

7 Likes
10

It would be nice to have wider Polkadot and Substrate community involved in creating new standards. We weren’t involved in the NFT working group but we are using Uniques and our own wrapper of NFTs heavily for art on Basilisk, we have native Auction pallet for native NFTs and we use them for Liquidity mining positions and also Omnipool LP positions on HydraDX so each decision affects us greatly it is in the core of our protocol.

As for the reasoning for DEX → I do strongly agree that the UX to allow exogenous assets for fee payment is necessary and were advocating for it from begining and we do use it ourselves. We have a function that is triggered by create account hook. It sets your fee payment currency to the one that triggered the create which means users don’t need to do anything manually. But I don’t see a good reason to spend valuable resources that you have to build another DEX which is competing with all of the other DEXes in the ecosystem, scattering the liquidity even more making the UX worse in the end.

There is another question about who provides liquidity to Statemint? It would need to attract LPs or you would need to convert some of the treasury assets (significant amount) to be able to provide a good service. Does statemint also build liquidity mining program?

Generally I think DEX’s should be a core part of the ecosystem but not necessarily in a way it’s portrayed here.

What I think would be a much better solution is to use aggregated oracles which are longer-length and will be feeding from other parachains which have a DEX. I know that Acala has oracle pallet. We’re building one exactly for this reason and we’ll also use it to limit toxic flows and protect our users and other chains from hacks. I generally think it’s not “safe” to use spot price for transaction fee payment and it’s not efficient if you trade in DEX on every transaction. If you use oracle with some weighting, you can have just one more read and collect all of the fees in one pot and DCA to sell it through any DEX in ecosystem in batches. This would allow us to focus on more important stuff like XCM use-cases instead of rebuilding what we have. And would allow us for statemint to have aggregated oracle which I think is much more in line with it than having a DEX.

2 Likes
11

As a followup I really want to say that I love the Advanced Asset and Cross-Chain features as it could solve real problems and allow new great use-cases.

5 Likes
12

I think that the focus of statemint at this stage should be to make the core asset functions better in user experience. Having user-friendly and integration-friendly core asset functions is a prerequisite for adding more interesting new functions to become valuable.

2 Likes
13

I think one very important thing that is often missed in discussions is that how can a common good parachain serving the whole Polkadot ecosystem, including other parachains.

IMO using the appchain way of thinking, each parachain should have a focus. The focus for Statemine/t obviously is assets. In a hypothetical world where no duplicated functionality exists, Statemint will be the parachain handles asset transfers. Every exchange, custodians, hardware wallets, only need to support Statemint. For all other parachain tokens, they can simply transfer to Statemint first before deposit into exchange address. With good UX design and batch call, we can completely hide the existence of Statemint from user point of view and exchanges only need to support a single parachain to be able to serve all the other parachains in Polkadot.

From that, we can see Statemint needs to support assets on foreign parachains, and create a unified interface for everyone (wallets, exchanges, service providers etc) to handle token metadata and transfers.

This should cover both fungible assets and non-fungible assets. This should be compatible with different kinds of assets including native Substrate pallet assets and EVM / ink! managed assets.

Statemint should be a solid foundation to handle assets so other parachains does not need to worry about it. Parachains only need to be able to transfer assets in/out from Statemint and then automatically be supported by every exchange and custodians.

18 Likes
14

Thank you all for the quick and precious feedback so far :pray: a couple of thoughts around the Statemint/e DEX:

Last, having a Statemint native DEX would provide some nice utility and convenience for users that want to swap between assets, however, I think you are vastly underestimating the resources required to operate an effective DEX, and to do so would mean Parity is now meaningfully competing with apps on every parachain, with an unfair advantage (native withdrawals), so I believe it would do irreparable harm to the Dotsama ecosystem. Here are just a few of the challenges you’ll run into if you decide to build a native DEX:

In my expectations, it might be the opposite regarding usage and user personas, the Statemint/e DEX might act much more as a system-level DEX for other parachains/projects with minimal usage from retail-users. So focusing on a very conservative but proven and mature implementation will have its benefits over the fast-changing and feature-rich modern AMM/DEX/Omni implementations.

As for the reasoning for DEX → I do strongly agree that the UX to allow exogenous assets for fee payment is necessary and were advocating for it from begining and we do use it ourselves. We have a function that is triggered by create account hook. It sets your fee payment currency to the one that triggered the create which means users don’t need to do anything manually. But I don’t see a good reason to spend valuable resources that you have to build another DEX which is competing with all of the other DEXes in the ecosystem, scattering the liquidity even more making the UX worse in the end.
There is another question about who provides liquidity to Statemint? It would need to attract LPs or you would need to convert some of the treasury assets (significant amount) to be able to provide a good service. Does statemint also build liquidity mining program?
Generally I think DEX’s should be a core part of the ecosystem but not necessarily in a way it’s portrayed here.

Therefore, it would not compete with any other DEX/teams in the ecosystem as all of them are building to have their unique edges (as you said, liquidity programs, currency hooks, bring your fees, etc.). Still, it should potentially support them with liquidity. This would mean the focus should be on code- and logic-level reliability, highly secure interactions, mature and traditional pools/curves setups. Basically, support from multiple custodians and easy-to-use multi-sig support (just as the first list of examples).
I hope we can have an in-depth discussion around this in Lisbon; it needs to be a community effort. It hopefully will also give us a chance to create something unique to the Polkadot technology, as it feels there is a lot of room to utilize these features for the benefit of everybody. At the same time, it will require us to go away from the idea of; that’s what everybody else is doing.
Btw. it is also the first write-up of ideas in this thread that can be persuaded with Statemint/e; everybody is highly encouraged to participate in the discussion and help form the future roadmap.

5 Likes
15

It would be a system-chain DEX. Is volume and chain-specific TVL the right metric to judge? It has evolved as the go-to metric in the mono-chain DeFi world (same consensus system), but what does it represent for the end-user needs? Specifically in a multi-chain and even more in a multi-consensus world?

1 Like
16

This is a very important question. As Ben pointed out, the sensible direction for the system functionality for asset/value exchange is rather 2B or 2B2C. DEX is also ops heavy, as Luke mentioned. As such, it is unlikely to me that the ecosystem trading volume and activities will concentrate here (think of OTC / bulk trade vs CEX). Actually, I see this as unlocking more liquidity, since it will simplify things for many participants, and directing it to the DEXes in the ecosystem, with them sending offers to fulfil orders for instance.

3 Likes
17

regarding the DEX:

You should have clarity on what goal the DEX should serve. Is it primarily intended to buy tokens to allow people to buy execution time? Then it’s good. For all other use cases, I would advise against it, because I think you would be vastly underestimating the effort of building a DEX.

Why?

Building a DEX is to the least extent a technological challenge and to the most extent an economical and political challenge. And even building the tech requires effort and carries a lot of uncertainty.

The Tech:
We are only scratching the surface of what is possible with DeFi. While xyk is the dominant form of building a simple AMM, we don’t know yet how the field will change in the coming years. When you are building a DEX, do you want to be competitive or just provide ANY mechanism to exchange tokens?

Providing ANY mechanism is easy, but if you want to be competitive you have to choose a direction, make more complex design decisions, make trade-offs, do research, and spend a lot of resources. Should Parity/Web 3 resources be spent on competing with entities within Polkadot when your core mission is to make Polkadot successful?

Any failure to execute in the most diligent manner and any loss of funds will be directly attributed to Polkadot itself.

The Economics & Politics

The most critical question when building a DEX is not how to build the AMM, but:

How do you build liquidity?

Most of DeFi builds on creating inflated expectations and renting liquidity. Will Polkadot/Kusama be renting liquidity? With what token? DOT/KSM? Which pair will get what incentives? How would you defend the redistributing of relay-chain token purchasing power to value-extracting entities?

How often is the grand policy updated by governance? How many resources do you allocate to update the grand policy? Who is getting the policy levers to update incentive parameters on a regular basis?

Who is doing the business development and deal-making that is needed to onboard liquidity? How is power structured in such a case? What power gets delegated to the deal-makers? How do they communicate with governance? How often? How quickly?

All of this would drag Polkadot and Kusama down into the very dirty pits of

  • policy infighting around who gets to extract the most value from incentives
  • expose DOT/KSM to the praying eyes of adversarial entities specialized in extracting value. It would suddenly become a token that offers value extractors a mean do gain dominance over each other

And if you are saying: “No, let’s just build the machine and leave the politics out of the game” - why just build a DEX in the first place? Because without an aggressive liquidity building strategy the DEX would end up with marginal TVL and not be competitive

For these reasons I suggest to either not build a DEX or only focus it on providing initial gas to users wanting to onboard to other chains.

9 Likes
18

ANY mechanism (as long as it is the most secure, reliable, mature…) should be the goal with an focus on native Parachain asset support and deep liquidity. As stated before, it wouldn’t make sense for Statemint to compete with all the fancy and elegant solutions available and currently being worked on in the ecosystem.

2 Likes
19

Isn’t it open source, open protocol, open government? Anybody could potentially make suggestions, proposals, act in favor of the protocol. If there is enough interest, it will get taken up and handled, no?

3 Likes
20

Please forgive me if I’m misinterpreting this, but it sounds like what you’re suggesting is that Parachain DEXes become more like “DEX aggregators,” similar to 1inch, Paraswap, etc, where they simply route trades to either the Statemint DEX or wherever there is the most liquidity and lowest fee trade.

If this is what you’re suggesting, I strongly encourage you to talk to some of the leading DEXes in the ecosystem (StellaSwap on Moonbeam, Solarbeam on Moonriver, Acala, etc). Many of them will not be happy having Parity compete with their core business and relegating them to an aggregator/order router role in the ecosystem. DEX aggregators are typically a “race to the bottom” and we quickly get to a 0 fee environment where it is almost impossible for them to pay their devs a salary.

Not to mention, you’ll still have the liquidity problems I mentioned earlier. The current DeFi model is to “rent” liquidity from LPs and you can’t just ignore this problem and expect LPs to provide liquidity with zero incentives when other ecosystems are offering generous incentives. If the goal is to have Statemint operate a “system DEX” and the parachain DEXes become more like order routers to Statemint’s DEX, that liquidity all has to live on Statemint, and you’ll need a team of people to operate the DEX, incentivize various trading pairs with DOT/KSM, and talk to large LPs (institutions, crypto funds, and others) to encourage them to provide liquidity.

Is this a serious question? Every electronic exchange that sells securities, tokens, or other assets measures their performance in terms of volume and depth of liquidity, because it directly correlates with profit and low trading fees/slippage. Of course it’s the right metric for a DEX, unless you can think of better ones. Apologies if this sounds harsh, but this fundamental misunderstanding tells me Parity should not be operating a DEX.

1 Like
21

This is very insightful and highlights a lot of the reasons Parity should not operate a DEX. The technology to create a simple zyk (Uniswapv2 style) DEX is ridiculously easy to deploy from a tech standpoint, but all of the human economics and politics required to run a successful DEX are much greater than people estimate.

2 Likes