I actually support this, some replies ( dex devs) are kinda not going forward with this out of these points
Polkadot is a layer 0 so no need for a dex.
Well in this eco , having user centric mindset is important. And yes DEXs do want any competition for liquidity, but we want to achieve better UX.
And this is not up to parity to decide is up to the users.
Secondly, lots of projects will benefit if we have central place like gas station or just an exchanger thats it. No any fancy functionalities.
And as @shawntabrizi said , we must do some experinments and let people votes. We shouldnt be afraid.
i see one mention of oracle.
imho would be nice statemine to be xcm oracle.
it would use oracle data to decide ed and byog fees.
how oracle would get data? from other chains via xcm.
there are many design to do ex and need to manage them actively.
but all exes and lendings and bridged oracles on other chains, they can feed statemine.
oracle on statemine will ease to bootstrap new chains.
so one could skip dex and do directly derivatives chain on oracle.
they will not use centralised http oracles if there is xcm oracle. now all use centralised directly, which is off chain and attack risk on centralised infra.
also it will simplify asset pricing for byog and fees on launch on any new chain.
also it feets nicely xcm dynamic fees discovery, reducing risk of asset loss or tx fail.
and it is nice real world use case for xcm transact.
plus not risk or need to fill and arbitrage pools.
and parity is best in game theory and cross chain protocols to do oracle.
so there is block space, so can we have oracle data space service too?
usdt on statemine is oracle from circle. can that be explored more?
also inet search shows iso curve dex flaws and how complex bot dynamics systems these should be to be amms. so why statemine needs simple dex? so space can be explored by univ3, phala ob, else something new?
as oracle, statemine could be registered with external dexes and probe them via xcm swap to get proves of price provided. if price off the predicted, slash or drain. this way will get unified exchange xcm interface. so statemine can be central hub for all swaps, and yet not holding liquidity, just routing. oracle fpr pricea, oracle for routing.
also did you considered frequency of swap operations for dex? would not it to big and make other usages of statemine imposible?
there are morw oracles to explore. governance ia general oracle, or ecointer os people oracle. what about verifiable builds veto oracle for wasm upgrades? ao these are other cgp.
also give us faster block times, faster finality proves for light clients, spree or zk proves of bridge transfers, xcm v4, faster substrate. and people will do dexes.
as oracle and router and assets topology provider statemine can help with stablecoins and reserve to verifiable teleport migration.
A DEX on Statemint would improve the usability of Snowbridge (a common-good Ethereum bridge).
For cross-chain transfers from Statemint->Ethereum, users need to pay a fee in wrapped Ether (wETH). Without a DEX on Statemint, users would need to obtain wETH from a third-party parachain. This reduces usability and increases latency.
I suspect the Polkadot<->Kusama bridge would have a similar desire for a Statemint DEX if it uses wDOT and wKSM for fees.
An interesting discussion in the twitter spaces earlier. I wanted to followup with a post here since time was limited in the spaces. I get the point that statemint can provide a valuable service as an onramp and access point to get to parachain assets. And that having an integral dex solves a lot of practical challenges faced on statemint. The use cases of (1) utility for fee payments and (2) creating easy paths to parachain gas tokens i can see – some have been calling this a “gas station.” But when i hear a goal of the statemint dex is to create “deep liquidity” in pairs such as DOT<>USDT, DOT<>ETH, DOT<>GLMR, DOT<>ACA, etc. And that the DOT treasury and investors need a “trusted dex” to use. This feels quite competitive to existing defi parachains and dapps in the ecosystem. It would be much better to support one or more existing dexes in the ecosystem for this purpose. Making all of the pools DOT based and limiting the functionality of the dex to x*y=k doesn’t really address this concern. The liquidity will have to come from somewhere.
Building deep liquidity will require incentives. Without incentives i can’t really see this happening. And it will require significant incentives to bootstrap and maintain liquidity to support large trades or large scale treasury diversification. Either that or some combination of advanced features such as concentrated liquidity, TWAMMs, etc. But if incentives and / or advanced features are deployed, i don’t see how the statemint dex isn’t directly competing with ecosystem parachains and dapps for DOT and other liquidity.
I can understand the first 2 goals of fee utility and an easy path to gas tokens. But I don’t agree with the third goal of providing deep liquidity. Instead of building a state run dex for this, i would recommend putting out an RFP with the requirements, security, slippage, features, and otherwise, that the DOT treasury has, to the community. This would energize teams in the ecosystem to win the opportunity to provide this service vs de-energizing them with the thought that the state is coming in to directly compete with them.
There are a couple questions that don’t seem to be clear to the ecosystem teams quite yet. These are a couple that have bubbled up as some of the most important.
Would there be liquidity incentives to drive liquidity to the pairs on the Parity DEX if the DEX’s launch is approved by the community via governance vote?
Would there be a frontend to the Parity DEX if the DEX’s launch is approved by the community via governance vote?
I globally like the idea to have a DEX inside statemine/t with all native asset of parachain and asset mint inside statemine/t as USDT with only DOT.
Why I like it, it’s because currently we don’t see this inside the ecosystem.
They are no DEX currently with pool for 100% of native token of parachain.
Currently, user need to go to so many different place to swap token, it’s very complex to know where you can swap which native token of parachain.
And each time we need to go in many interface to make cross chain, many step, to have the good token inside the good parachain to make a swap.
We need to simplified the life of user inside the ecosystem.
We have a great technology but currently a bad User Experience for random crypto user not focus on Polkadot.
One objective for my point of view is to focus to simplify the User Experience.
So, we mustn’t only create the dex module inside Statemine/t, but we need to have a great interface, where parachain are invisible.
If we want to success, we need than user don’t need to know in which parachain are his token to used the dex inside Statemine/t.
We need than a user who connect inside the website see all his native asset for all parachain, whatever their location.
And the user need to have the capacity to make direct swap without need to make cross chain transfer to send before the token inside Statemine/t.
The technology manage to make cross chain transfer, swap as only one operation on user side.
Polkadot will success the day of Parachain are transparent in user experience.
When Polkadot will be one big ecosystem and not many small parachain ecosystem disconnected.
There are a lot of high level discussion here but I would like to focus on the next thing: implementation plan.
I would like to see a detailed implementation with: problems to solve, how to solve, milestones, estimated amount of work, timeline estimation, technical details etc. i.e. everything required for a treasury proposal. In the end, I see this is just another proposal to the community.
Also as a complete consumer facing product, the blockchain part is hardly half of it. So I would like to see the plan including frontend, UI/UX design, operational, maintenance, marketing, etc.
I don’t think the currently provided roadmap have enough details and leave too much room for interpretation. Everyone has their own thinking of the Statemint DEX is going to look like and conclude it is good or bad. How about let’s define the topic further first.
That’s fair, and I agree this thread has wandered into a lot of speculation. This thread is about the “Statemint roadmap”, and Statemint is a blockchain protocol. So while I agree that the blockchain part is hardly half of it, that’s what this thread was meant to focus on.
I find these questions difficult to answer because they are based on the incorrect assumption that protocols and end-user products are bundled together into a silo. All the Statemint code is open source, anyone can run a node, there are public RPC endpoints, etc. So there will be front ends (<-emphasis on the plural) if people make them. Just like there are lots of ways to interact with other protocols (directly in wallet, on mobile, in browser connected to wallet, etc.), there can be lots of ways to interact with a Statemint DEX.
We will put this together. But on the blockchain protocol side, we’ve discussed quite a lot. In the original post here I wrote Uniswap v2, although with further discussion around the goals being DOT<>Stable and DOT<>Parachain Native tokens, we’re going in the direction of requiring DOT to be an asset in a pair, which is more like a Uniswap v1 protocol. This also hopefully makes some of the design tradeoffs more clear: the protocol is not trying to optimize for e.g. stable<>stable pairs.
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.
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:
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.
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.
This is an important note. We are running into a few sets of competing hypotheses:
Statemint DEX competing with the ecosystem over the same liquidity vs. Statemint DEX growing the pie and adding liquidity to the ecosystem
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.
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:
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!
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
using (2), aggregating swap opportunities together and executing on the “best swap” on parallel presented
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?
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?
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.
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.
