Statemint Update / Roadmap

Tech Talk
82

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
83

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

84

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

1 Like
85

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
86

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
87

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.

88

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
89

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.

90

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
91

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
92

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
93

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
94

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
95

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:

image
image1608×1053 135 KB

** 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
96

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
97

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
98

Good points. But let’s talk ERC-20’s and whatever Ink! tokens are called. Those aren’t necessarily at the sovereign level. Those are just smart contracts which are then pooled together into a DEX receipt token. So to access the swap function of that receipt function would require a smart contract function call.

So that Solidity/Ink/Move function call swap would need to be available at the Substrate level into a parachain industry standard. Else there will just be a mess imo.

If I look at Matt’s comment, Astar and Moonbeam are already diverging into separate standards. Which if Parachain’s continue to diverge will make alignment on something like this increasingly hard.

99

Also another thing to consider with this design is that it would allow Statemint to become an Oracle for the entire ecosystem.

Vitalik proposed something like this for Uniswap awhile back UNI should become an oracle token - Proposal Discussion - Uniswap Governance

It certainly wouldn’t be easy, but it would make Polkadot have something that no other Layer 0 has. A public good Oracle.

It would take away Chainlink’s monopoly and save huge amounts of money for Parachains that are looking into getting Oracle feeds to drive advanced DeFi tooling.

One of the biggest issues with price feed Oracle’s is making sure they’re not susceptible to price manipulation. For example, let’s say I get a loan on WBTC on Aave and Aave was using a DEX’s price feed to get the value of WBTC, a malicious actor could get a flash loan and manipulate that DEX’s price feed. This is how a lot of hacks occur. It’s because the liquidity is sourced from one place and only has one failure point. So what Chainlink do to mitigate this is that they source their price feeds from a collection of CEX’s and DEX’s so that any attacker would have to attack multiple sources and have a huge amount of capital in order to perform the attack.

With having a virtual AMM fed from liquidity throughout all Parachains, any potential malicious actor looking to exploit price feeds would have to exploit numerous DEX’s on numerous parachains. They also wouldn’t be able to use flash loans due to the distributed nature of the liquidity.

This Statemint Oracle would even be able to at some stage be able to provide price feeds for long tail assets. Which currently is a very hard problem, that no Oracle has solved adequately.

100

Not at all, that’s the nice thing about the XCM VM. Statemint does not need to know anything about the semantics of Astar/Moonbeam/Acala/etc’s internal representation of assets or logic associated with them. Those chains can transact as entities themselves on Statemint.

101

That’s a good point.

But there is an implicit assumption there on what tokens DotSwap will support. Currently DotSwap will only support DOT pairs, if I’m not mistaken.

So if I’m a dApp builder and I’m launching a token, if I want to future proof my token so that it has an ability to get CEX listings in the future, I’m forced to mint my token on Statemint, but also to add my liquidity there. So if I’m building on a specific parachain, I’m also going to want to have some local liquidity there. So I now have to find enough funds to seed two liquidity pools for my token. This seems unlikely and most dApp builders would just launch their token on DotSwap.

Or the alternative is that I launch my liquidity on a parachain and get CEX access there. This is not ideal, as it means every Parachain has to build on ramps to CEX’s. That is a very bad place to be imo.

Having a virtual AMM on DotSwap solves this issue.

Another important point is that DotSwap is xy =k. This means concentrated liquidity will naturally start popping up in the parachains. There is a lot of innovation associated with concentrated liquidity such as the excellent Arrakis PALM concept in which projects bootstrapping liquidity, don’t have to front such a high listing cost therefore providing much better efficiency for creating depth and eliminating slippage. Having DotSwap gobble up all the blue chips due will be detrimental to that innovation imo. Even more important will be where does lending source their liquidations from? DotSwap? That doesn’t seem ideal. Perhaps the Moonwell team would have some thoughts on this.

DotSwap will never move as agile or be as hungry as independent teams and will fall behind on innovation relatively quickly. A virtual AMM also provides the benefit that if Liquidity has to be upgraded to a new version, there is no actual movement of funds. If you’ve ever been through a liquidity migration of more than 100 million dollars, it’s a stressful awful time for users and engineers alike.