There is already multiple parachain teams building dexes here competing for liquidity. May the best of them win. This race has a technology but also an incentive component. A dex on Statemint sounds good from a usability standpoint. It makes it easy for someone to swap their Stables that are native on statemint instead of teleporting them to a dex parachain first and it in the end requires one less teleportation step to get to the right asset and then use it on Parachain X.
Overall though this fractures liquidity even more. An exchange is only as useful as it’s liquidity is deep. If polkadot wants to attract serious DeFi transactions then the dexes need to have very deep liquidity to accomadate for whale capital. Liquidity is where other Ecosystems are ahead and this needs to change. A Dex on Statemint that will be the default for most unsophisticated users is not a good solution as it diverts capital away from the more sophisticated and probably technically superior dexes that are currently in development/deployed.
This seems to be born out of bad usability and needs to be solved on a UI/XCM Level to make users not even notice that they are hoping chains.
When reading the news about StateSwap it sounds like there would be native BTC, ETH implemented, so not wrapped? How would that be possible on Polkadot relaychain?
Longer answer:
If you’re not on your native chain then it’s always ‘wrapped’ or as we call it a ‘derivative token’. BTC, ETH etc would behave effectively like reserve asset transfers do - i.e. a derivative token that represents the asset (that represents locked tokens on the original chain) would be exchanged. Any derivative token is only as good as the bridge that it went over (or mechaism that the original tokens are locked by). Snowbridge for example should be able to use ETH 2.0’s new finality via the bridge hub and mint into statemine/t. Bitcoin doesn’t have finalisation so other mechanisms are needed (for example interlay parachain are one way of getting bitcoin derivative tokens).
(personal opinion)
We need to separate out the concerns. Fears that there will be n+1 dexes on parachains rather than n dexes seem not well founded - there’s going to be a lot of dexes and we can’t prevent more of them opening. We need to not oppose a dex on statemint simply because it is one more dex.
I’ve been wondering about the ‘unfair’ playing field of only having one governance model rather than two that effectively most parachains have. There’s nothing special about how statemint does its governance. It’s possible that another parachain could choose to give up its own governance and route everything through the relay chain’s governance. (This could be undone via a relay chain vote, and parathreads might make this approach more palatable).
Wallets are likely to integrate with dexes that give their users the best rate and enable them to take a slightly larger fee for that work of sourcing the best deal. StateSwap is not likely to provide the best route for most pairs (I’m disapointed that I have not seen dex aggregators yet - if you’re building one, let me know).
I conceed that traffic from exchanges might likely choose to go via statemint but again statemint isn’t doing anything that another parachain can’t do, so it’s possible (though admitadly a bit less likely) that another parachain could act as an onramp parachain to exchanges. (and again there’s room for dex aggregators to not use the statemint dex). I think this is essential simplification of onboarding (for now).
Unfair liquidity incentivisation seems to be the main bone of contention. In some ways StateSwap is at a disadvantage because it can’t incentivise with its own token. Personally I’d like to see it apply for liquidity incentives in the same way as other parachains do through Rae.
I hope that we will look back next year and look on this as a storm in a tea cup. The fears are understandable but they don’t have to materialise. Everything will change over time and what is the right thing now might not be the right thing later on. The worst outcome would be that we’re afraid to try things.
Great. That’s how I imagined it and it’s the classic method. Some tweets then presented the whole thing in a somewhat shortened form. Stateswap would then partly use the help of other parachains (interlay), which is good as a cooperative, but would also lead to a kind of dependency on projects that are basically limited in time (lease period). I am very excited about the project and can hardly wait to invest in external blockchains with stored values from the Dotsama ecosystem. In particular, I think the functionally simple integration of BTC is a great thing.
And please: Let’s make stateswap intuitive and foolproof. Polkadot’s design by nerds for nerds reliably prevents mass adoption.
I believe the following discussion is relevant. In particular, if you object to the Statemine/Statemint DEX proposal, I’d be interested in whether my governance “blue-sky” suggestion would be attractive to you:
Regarding the name, DotSwap seems to be the best option.
It’s straight to the point and pretty clear about the product since you swap things paired with DOT, people may get confused by what “State” means in StateSwap and if we ever get a version on Kusama it would create even more confusion since Statemine also starts with “State”.
You actually bring up another interesting point that’s not discussed much. Are we going to see a dex deployment on Statemine? Any reason to NOT deployment a dex on Statemine IF there is one on Statemint? All the same reasons that applies to Statemint should apply to Statemine as well.
I understand the task of stateswap, among other things, to pair external values such as stablecoins, BTC, ETH with high liquidity in DOT. On the one hand, this requires cooperation with the operators of the stablecoins, on the other hand, the corresponding liquidity is also required on the other side (DOT, parachain token).
I could imagine that Kusama does not have the necessary monetary liquidity to convince in negotiations with external parties. Kusama as a concept is accordingly the test network, albeit with financial underpinning.
Apart from these thoughts, DOT is of course software. In my opinion, however, this argument is a bit hypocritical anyway, or at least ambiguous. Which is another topic.
In general, of course, there is nothing against a stateswap on Kusama. But maybe KSM’s bridge into the Polkadot ecosystem is the solution?
If I understand correctly, treasury is not supposed to provide liquidity. So there should not be an incentive to do this?
If trading fees are just high enough to at best compensate for lost staking rewards, that might not be enough for the purpose.
How to ensure that other participating tokens are available in sufficient quantity? Via a standard bootstrap program? And then always as a couple to DOT?
I would at least have concerns that the risk of imperanent loss outweighs possible gains.
Things would be a little clearer if you had the choice of a stablecoin as a counterpart to the selected tokens. If there is only the option of choosing DOT for this, there are always two variables that need to be considered. Who should provide liquidity here for 0.3% profit? (Except maybe the parachain teams themselves, just to prove their reputation. But here, too, a decision would probably have to be made by consensus in the projects.) Maybe I’m missing something or didn’t quite understand the matter. thoughts on this?
They are beginning to take place, at least there is already a Cross-chain swap- Aggregator between moonbeam and astar, in beta phase - through Phat Contracts
and one that is first starting out as an Aggregator with moonbeam’s dexs
A couple of notes on building an user interface for the DEX (now termed DotSwap?):
Firstly, I’d like to circulate Talisman’s Polkadot treasury proposal to build an interface for the DotSwap here. We believe there’s a need for at least one user-facing interface to support the exchange when it comes online, and this proposal aims to fulfil that need - any comments and feedback on the initiative would be appreciated.
Surfacing a conversation we had earlier this week regarding the potential for UI providers to receive a fee in return for facilitating the swap experience: it seems like one method of implementing such a fee would be to allow an interface like Talisman to register a rewards/fees address on Statemint and implement a system-wide parameter capping the maximum fee a UI can charge, and leaving each interface provider to define a fee within those bounds. Whilst doesn’t prevent an interface from sneakily batching a fee payment with the user’s intended action prior to signing (which seemed to be an early suggestion), it does provide a clear path and a “best practice” for interface providers if they did elect to receive a fee in the future. Fwiw, Talisman aren’t committing to implementing a fee or not, it was raised as a part of a broader conversation about building a UI for DotSwap and I thought the feature idea should be circulated here for discussion.
How would you implement that registration? The rewards address would effectively be some metadata about a provider. The runtime doesn’t know which interface the user used to generate an extrinsic, nor the wallet used to sign it; so this would need to come in as some additional argument in a transaction. Users could trivially circumvent it by changing that parameter to None or some equivalent variant, just like they could undo the batch with the fee transfer.
So if it doesn’t guarantee fees for providers, nor prevent providers from adding fees higher than the cap, it seems to add complexity without adding any guarantees for any user.
Naive question: Why isn’t the UI built by the Polkadot developers themselves and maybe financed from the treasury? Of course, it would have to be decided by corresponding proposals.
I think the benefit is that wallets could generally discourage unexpected “batchall” transfers. Or at least warn users: “Hey, there are multiple things going on”. If each wallet / UI implements its own version of the fee mechanism, it becomes quite hard to check whether it is doing what it should. Also for open-source devs and people who look at code.
Having the “UI tip” built-in seems like a simple, standardized way to handle this.
The alternative is to agree on a standardized “batchall UI fee” transaction template that can be used by all UIs and wallets.
In all fairness - it would be great to hear how other teams in other ecos handle this. There does not seem to be a “perfect” solution
But if the wallet constructs the transaction, it’s not going to warn you that it’s constructed something “bad”.
Yes, this is really off topic for the DEX IMO. A way to divert some extra fee/tip to an interface that provided a service (construction, signing) is a generic problem and a solution can be applied to any type of transaction.
