Statemint Update / Roadmap

Tech Talk
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.

4 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.

1 Like
102

hey @joepetrowski. It’s great to see that Binance is enabling deposits and withdrawals in USDT for Statemint. I would appreciate it if you could provide some clarification regarding any ongoing efforts to enable direct USDT withdrawals to parachains. thank you in advance!

103

You mean like from Binance to a parachain directly? @IkerParity has been working on the tools to do that, I think his team will have some updates soon especially now that Kusama’s Asset Hub supports foreign assets.

1 Like
104

yeah, that’s exactly what I mean, it will be just an amazing and life-saving feature. if you don’t mind, I’ll clarify, will this be possible in the Binance UI? or will it be implemented in some other way?

105

Well we can’t make anyone put anything in their UI, but for sure the objective is to provide the tools (and suggestions) to simplify and encourage exactly that from any custodian/third-party service.

2 Likes
106

just amazing, thank you very much for the info, very useful, I appreciate it. it seems that many users are really waiting for this!