The current design of participating in the decentralised DutchX trading protocol is not very user friendly. Mainly, this is by limitations of the Ethereum blockchain. However, picture a way around it to make the experience more user friendly - finding a workable solution and implementing this idea is your challenge.
What makes the current implementation not as user friendly? By technology restrictions, at the moment, a user of the DutchX must sign several transactions for proceeding with the order (i.e. an exchange of two tokens). On top of this, a participant must then come back after the auction has finished to claim and withdraw the tokens he/she receives in return. Not only having to sign several transactions but also having to claim and withdraw only at the end of the auction cycle, requires patience and a lot of attention of the user. The user has to actively do something before the tokens are back in his/her wallet.
We are looking for a team to design an “end-to-end-participation” solution, which will allow any user to submit one transaction only - to a smart contract that then interacts with the DutchX protocol. The smart contract would go through the various transactions and claim and withdraw the funds at the end of the auction to then automatically transfer the tokens back to the user’s wallet. The user still profits from the slow execution of the order in the auction based model, however, does not have the pain of returning to claim.
A business model could be merely the collection of Magnolia. Additionally, a service fee could easily be placed on top by adding a small “service” fee for executing the smart contract on behalf of the user. The team would also have to solve for the gas challenge as well as setting an incentive for the smart contract to trigger the claim & withdraw from the DutchX protocol.
More specifics to this issue:
Currently these are the transactions that a seller has to go through:
Wrapping ETH (if WETH is not available, which should be assumed)
Paying with OWL (if available and the user chooses to); ideally this is also available in the solution to this challenge.
Allowance specific token (can be a one-time high allowance but otherwise might be for every transaction).
Confirmation of Order
Claim and Withdraw (depending on functions used, this might be one or two separate transactions)
To go through a transaction cycle, try it on https://slow.trade - a graphical interface that let’s the user interact with the DutchX smart protocol.
Within the following graph you may see which transactions happen within the DutchX smart contract layer and which are with the user’s wallet:
Intended user story:
User sends Token A from their wallet to this specific smart contract address and does nothing else. Will automatically have the receive Token back in his/her wallet after the time of the auction has passed.
One will have to solve for some problems:
The user has to set an allowance to the smart contract
Smart contract must know how much comes from which address and allocate the exchanged token to the respective addresses
Must overcome gas problem (your smart contract will spent on gas which somehow has to be rolled over to the user, possibly by setting a fee)
Must overcome problem that the pre-set gas limit in most applications might be too low to do one transaction up to confirmation of order.
Consider how to calculate the fee level that is passed onto the user and how. Are all users treated equally with the rate of the smart contract?
Consider how to fairly distribute Magnolia or offset with gas incurred by the smart contract.
Further requirements:
User’s funds should always be secured and safely stored in a smart contract
Calculation and transfers should happen on-chain
Should host a simple interface or alternatively a telegram bot (or similar), with which non-technical users can interact with.
Should ideally be a generic smart contract such that other projects may build on top (e.g. simple sell-widgets)
It should always be possible for the user to claim/withdraw from this smart contract also, in case it is not automatically sent (which is the goal of course)
Optional: Consider how to optimise for gas usage.
Optional: Consider how to distribute Magnolia back to the user - not, they would have to be unlocked at once to transfer (however, could also be used by the smart contract to reduce fees).
Decrease complexity by considering:
Implementing this for a certain auction pair only (and possibly only for one auction, e.g. sending ETH to obtain RDN)
Implementing this only for the participation as a seller
Background
The current design of participating in the decentralised DutchX trading protocol is not very user friendly. Mainly, this is by limitations of the Ethereum blockchain. However, picture a way around it to make the experience more user friendly - finding a workable solution and implementing this idea is your challenge. What makes the current implementation not as user friendly? By technology restrictions, at the moment, a user of the DutchX must sign several transactions for proceeding with the order (i.e. an exchange of two tokens). On top of this, a participant must then come back after the auction has finished to claim and withdraw the tokens he/she receives in return. Not only having to sign several transactions but also having to claim and withdraw only at the end of the auction cycle, requires patience and a lot of attention of the user. The user has to actively do something before the tokens are back in his/her wallet.
We are looking for a team to design an “end-to-end-participation” solution, which will allow any user to submit one transaction only - to a smart contract that then interacts with the DutchX protocol. The smart contract would go through the various transactions and claim and withdraw the funds at the end of the auction to then automatically transfer the tokens back to the user’s wallet. The user still profits from the slow execution of the order in the auction based model, however, does not have the pain of returning to claim. A business model could be merely the collection of Magnolia. Additionally, a service fee could easily be placed on top by adding a small “service” fee for executing the smart contract on behalf of the user. The team would also have to solve for the gas challenge as well as setting an incentive for the smart contract to trigger the claim & withdraw from the DutchX protocol.
More specifics to this issue:
Currently these are the transactions that a seller has to go through:
To go through a transaction cycle, try it on https://slow.trade - a graphical interface that let’s the user interact with the DutchX smart protocol.
Within the following graph you may see which transactions happen within the DutchX smart contract layer and which are with the user’s wallet:
Intended user story:
User sends Token A from their wallet to this specific smart contract address and does nothing else. Will automatically have the receive Token back in his/her wallet after the time of the auction has passed.
One will have to solve for some problems:
Further requirements:
Decrease complexity by considering: