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”.
5 Likes
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.
2 Likes
I agree 
1 Like
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?
1 Like
I imagine external parties would see the value of testing on Statemine, accepting that total liquidity won’t match what is expected on Statemint.
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
1 Like
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.
1 Like
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.
1 Like
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.
aren’t teams building in the Polkadot ecosystem, “Polkadot developers” ? 
1 Like
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
1 Like
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.
I created a summary on the latest info about DotSwap
Video: Latest on DotSwap - February 2023 - YouTube
Subsocial: Latest on DotSwap - February 2023 - PolkaVerse
Tweet: https://twitter.com/alice_und_bob/status/1626215558906511363
10 Likes