As discussed yesterday in telegram, here is a draft proposal for DutchX.
I let you review it and propose some changes. And I’ll submit the updated version on the dxDAO.
On question I don’t have a strong opinion is:
Fork fairdex and slow.trade to allow trading of all ERC20 tokens with this badge.
Should we only display tokens with a DutchX badge or display all ERC20 ones (with the DutchX badge ones on top):
- DutchX badge only: Higher quality tokens, more incentives to get DutchX badge and then get whitelisted. More MGN generating tokens.
- All ERC20: More tokens to trade, probably more volume (and dangerous tokens do not generate MGN).
I think the latter. Let anything trade. Might be some emergent effects/tokens that could take off which we would have otherwise rejected. DutchX wants volume. And one of the big benefits of the alternate interfaces is censorship resistance, or so we hope.
I updated the proposal to list all tokens with ERC20 badges.
The proposal is formally submitted to the dxDAO.
You can predict/vote.
Thanks for proposal. Unfortunately it is very hard to vote “For”
I 100% support idea of forking frontend interfaces, but I am against building a walls for new listing tokens. I am a fan of original ideas - token listing is completely permissionless and decentralized: anyone can add a token pair based on the same rules of smart contract; no central entity decides on which tokens become tradable; is completely free (no fees); a token that is available to trade is not the same as a MGN generation token. Low barriers to entry to DutchX. If someone fork DutchX frontend he is free to create own token badge, for example like Fairdex badge or slow.trade badge at the moment
The main issue with the dutchX is not the whitelist for MGN rewards.
Everyone can create an auction right now for any ERC-20 token via command line tool. There is no easy frontend/dapp available right now. Slow.trade and fairdex.org don`t provide this kind of functionality (auction any ERC-20 token) as they would get legal issues.
I don`t believe the whitelist is an issue but rather the missing frontends. Adding a more complex whitelisting process is not necessary as the DAO can easily decide if a token is worth to be enabled for MGN rewards by simply checking the volume/activity of the specific token.
That’s the sense of the proposal (the proposal I submitted is updated to list all tokens with ERC20 badges).
Fork fairdex and slow.trade to allow trading of all tokens with a ERC20 badge. Tokens with a DutchX badge would have additional attention drawn to them by being displayed first.
The proposed listing is permissionless using a curated registry. To be listed tokens need to:
- Have their information correct (i.e reject a token registered as “MGN - Magnolia” if it is not the address of the “real” MGN token).
- ERC20 (i.e don’t register non-ERC20 tokens which would make the application buggy like BNB which is not ERC20 and was stucked in uniswap contracts due to that).
So beside verifying users won’t lose their money by getting “scammed” with wrong token addresses or using non-ERC20 tokens which would be stucked, there is no additional restrictions on token listing.
if we are going to fork frontends and host it on IPFS/ENS we would be in control of the ERC-20 whitelist. Having a review of this list before we point the ENS domain to the IPFS content hash would make sure that no ERC-20 token is a scam, or will be stucked.
So the question is if we want to whitelist on chain or on the frontend level?
And what is our whitelisting criteria and procedure.
@clesaege suggested one option…
I do think we need to formalize listing criteria and procedure. Maybe different ones for general listing and for mgn generation.
If we decide to use our own TCR we can promote it as a public resource for verified token contract addresses. Something that is very needed for a lot of services eg etherscan
The Token² Curated Registry is already live with a significant amount of tokens and ERC20 badges. By using the same ERC20, we also benefit from people registering tokens and badges because they want the token to be listed somewhere else.
For the DutchX badge (certifying the token satisfies the criterion for MGN generation), we’d need to create a list of criteria. A tentative list is attached in this proposal, if it is accept, the final list will be the topic of another proposal.