Statemint Update / Roadmap

I was asked by Robert to share my recording of yesterday’s Twitter Space. The recording starts about 4 minutes after the full hour and to my knowledge nothing substantial is missing.

10 Likes

Let me rephrase to be a bit more clear.

  1. Will Parity or Web3 Foundation build a user-facing frontend for the new Parity DEX on Statemint, or only the protocol?

Unanswered question for Parity:

  1. Would there be liquidity incentives to drive “deep liquidity” to the pairs on the Parity DEX if the DEX’s launch is approved by the community. This would put the Parity DEX in direct competition with parachains and ecosystem DApps for liquidity. @Ben @Rae or anyone else who can help clear this up for the parachain teams.
2 Likes

There are no concrete plans for this. But I’m sure Parity/Web3 would support teams wanting to work on these.

I will let @Ben or @Rae comment on the question part, but I disagree with the follow up statement. Yes, liquidity within a walled garden is zero sum, and if all this accomplishes is removing liquidity from existing DEXs then we should declare it a failed experiment and remove it. My opinion is that a DEX on Statemint would bring new liquidity into the ecosystem, and with the improved UX that the Statemint DEX plus support for parachain native tokens provide would provide a path for making other parachains more accessible to users and liquidity providers.

1 Like

This is an important note. We are running into a few sets of competing hypotheses:

  1. Statemint DEX competing with the ecosystem over the same liquidity vs. Statemint DEX growing the pie and adding liquidity to the ecosystem
  2. Teams being able to differentiate and compete on yield, efficiency, etc. vs. Statemint DEX being perceived as the only DEX on Polkadot, reducing competition

There are strong arguments you could make for either side of either argument. The truth is that we simply do not and cannot know which hypothesis will be correct. Given that, it seems reasonable to express the roadmap in terms of “testing hypothesis X and Y” and establish an expectation through governance that a lack of evidence for X and Y over time should mean that the project is not continued.

5 Likes

For 2023, we (Colorful Notion, developers of polkaholic.io) are going to try redoing polkaholic.io by combining polkadot.js apps with Polkaholic APIs (or other third party APIs, on par with polkadot.js apps block explorer links). In particular, we would like to model Statemine/Statemint DEX pools/swap alongside other Parachain DEXs in the Substrate ecosystem, having sort of tried it across a bunch of defi parachains this fall. Key subgoals relating to Statemine vs Parachain DEXes:

  1. develop a XCM Global Asset Registry with “MultiLocation” at the center – see here – plug: if you are in the middle of this messy MultiLocation registry soup and/or want to sponsor this, please volunteer or who should contribute from your team in 2023 via this repo!
  2. develop an “API plugin” architecture where DEXes (pools, routers) can be uniformly modeled with MultiLocation-centric APIs; here, the goal is to have “routers” or parachain DEX modeled uniformly; for example, Statemint new dex pallet would have a trivial way to get the answer to "if I put X of MultiLocation { parents: 1, interior: X1(Parachain(2004)) }, how much Y of `MultiLocation { parents: 1, interior: X1(Parachain(2000)) } do I get out … and ALL Parachains DEX models would have the same output
  3. using (2), aggregating swap opportunities together and executing on the “best swap” on parallel presented
  4. furthermore, trying to get parachains to model themselves well

We believe this means that 2023 will see 4 categories
(A) Parachain DEXes
(B) Users of Parachain DEXes – swappers, liquidity providers, …
(C) [NEW] Statemine/Statemint DEX who are notably different than (A) in NOT being as transaction fee driven for their own survival and have no deep sibling rivalry / competition for users/TVL/liquidity
(D) [NEW] DEX Aggregators (and DEX Aggregator Aggregators, DAOs that maximize your yield, etc.) in dapps like 1inch or wallets akin to Metamask swap fees

Assuming
(A) becomes healthy by virtue of sufficient { USDC/USDT/ETH/… onboarding with execution on Circle + Snowfork, adequate LP incentives, } via (C)
then short-term
(D) needs a Polkadot equivalent of 1inch/Metamask swap fee earning mechanism, since it’s clear that (A) doesn’t really want to be aggregated in (2) … right?

I believe buyer’s agent (C) + (D) “front-ends” naturally belong together “in front of” all the seller’s agent (A) “front-ends” in a nice trusted place like polkadot.js apps or wallets (augmented with APIs until everything can be done with RPCs), made suitably multi-chain. We could imagine that if you do most of your DEX activity in one specific parachain (A) (because it specializes in X, or has the best fees model), and that specific parachain ALSO shows you the same thing as (C)+(D), you just stick with that parachain. There are no parachain dapps that have DEX aggregator qualities (or are there?) now, but the end game could be that the devil will be in the details of how much DEX fees are relative to XCM fees, and where your assets are exactly.

What is the fee earning mechanism that would support DEX Aggregators?

2 Likes

Thank you Dan! I created a dedicated thread for this discussion.

Thank you!
you do such great work in DOT world, keep it up mate.

1 Like

How? Can you provide more supporting arguments?

Improved UX? But you said there is no plan on building frontend. Let community build it is a valid approach but it doesn’t necessary mean improved UX? Or are you talking about user able to acquire parachain native token seamlessly? What makes Statemint so unique that it can provide improved UX compare to other parachains?

2 Likes

Primarily by giving more options and having more resources working on it. Like Rob said, we simply do not know, and the only way to find out is to test. I don’t have much more to add than what I’ve said in previous responses in this thread: I understand why people see a Statemint DEX as detrimental, but I believe that not having a Statemint DEX is hurting Polkadot.

I quite agree with what @lucasvo wrote in Why not just Statemint needs an AMM but (likely) every parachain and we should do our best to agree on a shared interface. To accomplish this, we need to stop thinking of liquidity as a static value that’s divvied up among some parachains.

Speaking generally, not just about liquidity, but people/projects with a “slice of the pie” mentality will not succeed in the long run. If we only see things in terms of fighting over what value (whether it’s liquidity, number of Substrate developers, etc.) exists at a particular snapshot in time, then as a whole we have already lost. We need to build more and attract more value for Polkadot to succeed. Like @shawntabrizi said in Statemint Update / Roadmap - #35 by shawntabrizi, if you work on a dedicated DEX/DeFi parachain, I really do not see how this is a competitor.

I am not talking about “direct to user” UX here, there is a lot more to UX than that. If you go back to the original post, a lot of the motivation in the roadmap is actually to abstract Statemint away from the end user. The improved UX here comes from:

  • Ability to pay fees (securely) in more assets
    • → Allows other UIs/wallets to create better UX
    • → Creates better UX for parachain devs to interact with Statemint over XCM
  • Ability to access parachain native tokens
    • → Allows parachains to create better onboarding from DOT into their ecosystem, even if they are not listed on a centralized exchange.
    • → Allows centralized exchanges to support more assets within Polkadot without running more infrastructure, and
    • → Allows users to “bypass” Statemint by withdrawing direct from a centralized exchange to a parachain.

Well, nothing, it’s another parachain. I don’t understand the “compared to other parachains” part. Having better UX and onboarding in the Polkadot ecosystem is not a mutually exclusive design area. Just because UX on Statemint improves does not mean that UX on other parachains is hurt.

7 Likes

A predetermined sunset for StateSwap

Wouldn’t a compromise solution be to launch StateSwap with the understanding that it would be maintained only for as long as necessary, and not a moment longer? What if the StateSwap proposal included agreed-upon targets for user numbers and liquidity that would determine the point at which the DEX would be “decommissioned”? The assumption being that parachain projects would at that point have the critical mass to continue onboarding users by themselves.

We are already seeing this kind of sunsetting process with Gov1 now being phased out. Gov1 was never the desired outcome; it is being used only until the conditions for full reliance on OpenGov are met.

Similarly, if everyone agrees from the outset that StateSwap is strictly a temporary solution, parachain DEXes might be less tempted to see it as competition and feel more willing to contribute to its success. Furthermore, everyone will be relieved in knowing that the ecosystem as a whole will not permanently take on the political and economic burden of running an “impartial” DEX.

I can’t see it being that temporary as on-chain oracles are non-trivial and would cover only a subset of the facilities that a dex covers. That said defi is so early that anything and everything is likely to change drastically over the next few years. The focus for now has to be on ease of use for newcomers to the Polkadot ecosystem and having a dex on statemint is one of several interlocking improvements (noted above) that will improve the on-boarding process. Despite our disagreements, we’re all focused on what’s best for the Polkadot ecosystem as a whole.

2 Likes

I agree that 1) we’re all focused on what’s best for Polkadot and 2) ease of use for newcomers is a priority. However, we shouldn’t underestimate the cost of an onboarding solution that would create an organizational and political burden for the ecosystem (the issues of treasury use, allocation of incentives, and liquidity provision being so thorny). StateSwap would also compete in many ways against the ecosystem’s own DE-FI parachain projects.
By temporary I don’t mean “just a couple of months”; we might want it to run for years. I just think that the conditions for StateDex’s sunsetting should be defined and agreed upon democratically. This would give clarity to DEX parachains and to the entire community about the project’s intentions and long-term plan.

This is very important, As each parachain has its own token, the fragmentation of the ecosystem results into bad UX. This will solve and making easy even for someone to use any token for gas inside paraverse. I know there will be some drawbacks but UX and security must come first.

1 Like

And the parachains who see this as a direct competition should really reconsider. We are not fighting between ourselves, we are trying as collectively to improve UX between fragmented community within dotsama.

If this will improve Pokadot it then will improve accessibility to other parachains. Currently even the main users of parachains are just other users from other parachains. This is because of uneasy accessing of specific parachain gas fee token.

1 Like

as @gilescope said, Defi is in early stages and statemint dex will only provide subset of features to the ecosystem. For parachains that see this as a direct competitor should really step up in their game. First of all A defi parachain wll offer more features and innovation as Defi continues to grow. Polkadot not having statemint dex is hurting the ecosystem.

5 Likes

Is there really a tentative date for this? this can really make it easier for there to be more liquidity in the ecosystem, and when Binance accepts USDT on Statemint, it can be used directly on all parachains

this really sounds great

1 Like

It’s hard to put a concrete date on something like this because it’s not one feature but rather a collection of features, tools, and integration patterns. But many people are working on getting there.

I need to finish this PR and then get it onto Statemint once it’s had some testing on Statemine. It also requires some of the tools that @IkerParity outlined in New Tooling and Infrastructure to facilitate the Statemint roadmap. And of course demos/documentation to show people how to do it.

4 Likes

Very interesting discussion and it’s apparent that the decision made here will have major ramifications for the broader community.

I’ve been doing some tinkering on what could be a cool, pragmatic middle ground. I drafted something on FigJam here https://www.figma.com/file/WKXpQAHdkVIbsSXxvmUOKi/Stateswap?node-id=0%3A1&t=kOk1eeI487ljVGhg-1

But you can see it here as a screenshot:

** Please be patient with me** I haven’t built anything on Polkadot before, so some of my assumptions may be incorrect or poorly formed.

Two major issues I see at the moment is the poor onboarding into the ecosystem and the fragmented liquidity inherent in the current design.

My idea hopefully solves both.

If we allow DEX’s to virtually share their liquidity with Statemint we will be able to create a virtual AMM on Statemint that doesn’t need to compete for liquidity. This virtual AMM will be able to provide price endpoints for the tokens that need to be traded and the settlement orders can then be executed on the Parachain DEX with the best price action.

Remote locking on XCM V3 may be an interesting MVP use case to test it’s viability.

Let’s walk through a very simple example of how the flow would work:

Alice would like to buy $BOKKE. Bokke is a new parachain for betting on the upcoming Rugby World Cup. However Alice is on Acala. She’s comfortable there and couldn’t be bothered figuring out a new ecosystem. She just wants to speculate on the token. Problem is that there is no liquidity for $BOKKE on Acala.

So she goes to a Swap widget for Polkadot, she wants to swap 1 xcDOT on Acala for xcBOKKE and keep custody of the xcBOKKE on Acala.

The Swap widget, queries the virtual AMM on Statemint and comes back with the current best price point based on the DEX there Kolbe. It’s 1 DOT for 5 $BOKKE.

Alice is happy with the price point and clicks to execute the order.

  • On Acala, 1 xcDOT leaves her wallet and gets sent Statemint
  • Statemint executes the swap on the KOLBE DEX
  • Statemint sends the $BOKKE token to Alice’s wallet on Acala

There are a few issues here which could potentially make this technically unfeasible:

  • Statemint has an ability and permissions to remotely execute swaps on other Parachains. I don’t believe this is currently possible. If we look just at Astar, Acala and Moonbeam, they use Solidity contracts which wouldn’t be exposed to substrate level calls. So this would need to built as a pallet that Parachains would need to opt into in order to connect their parachains to StateSwap. Oak Network may have some interesting thoughts on this piece.
  • Latency may be very poor. If we have 6 seconds for finality, then this simple example may already get us past 15 seconds. Which is definitely below par outside of Ethereum L1. On other chains where latency provides a poor UX, there has emerged off chain settlors that will settle immediately for a small fee. This could be explored further.
  • Slippage due to latency and lack of composability. There is a risk that the settlement may fail if there is big price movement on the Kolbe DEX before settlement occurs. Probably further justification for off chain settlors

Anyway those are my thoughts.

They’ll probably evolve over time but it may be useful as a talking point.

1 Like

Why would this be necessary? In the example you gave (I like the UX flow), Acala would have some native DOT on Statemint. So as part of the order it would have Alice burn her local “xcDOT”, and then Acala’s sovereign account on Statemint would use its DOT in the order (knowing how much xcDOT was provided. Then it would send back the BOKKE. It might take a little extra DOT to cover execution fees on Statemint.

1 Like

Per Joe’s comment above, this may not be required, but Astar and Moonbeam are solving this with wrapper(s) that allow EVM calls via XCM from another parachain/thread.
See:
Astar XVM
Moonbeam Remote EVM Calls through XCM

I imagine that Acala has a similar solution but I’m less familiar with their EVM+ roadmap.

1 Like