boolafish
commented
5 years ago Possible designs
1) A funding tx that consumes the previous tx output and create DEX specific output 2) A funding tx that only contains message which indicates which tx output the user is willing to provide the fund 3) Pure funding message without any tx. Operator has special mechanism that handles the message.
A funding tx that consumes the previous tx output and create DEX specific output
This approach defines a new tx for funding. The funding tx would take a normal transaction UTXO as input and create a DEX specific tx output.
Pros
- simple and clear process.
- user cannot double spend the UTXO as it need a funding tx first
Cons
- leak users' intention on trade
- Need to wait a funding tx to be included on chain
A funding tx that only contains message which indicates which tx output the user is willing to provide the fund
This approach defines a new tx for funding. The funding tx would contains only message that indicate which UTXO the trader is willing to provide as trade fund.
Pros
- The message can be encrypted, little info leakage (an address is about to start a trade, no detail on the amount)
- Even operator does not know the info in advance
Cons
- More complex flow/design. Need to handle/mitigate the issue if user just transfer away the "funded" UTXO. Because the UTXO using here is just a normal UTXO so nothing would stop user from transfer the money away if without special mechanism.
- Need to wait a funding tx to be included on chain
Possible way to handle user transferring away fund
the funding message tx can be with a bond. If user decides to transfer away the funding UTXO, the bond would become the compensation for exchange.
Pure funding message without any tx. Operator has special mechanism that handles the message.
Similar with previous one, just without any tx on plasma chain.
Pros
- Nothing on chain, minimal info leakage
Cons
- More complex flow/design. Need to handle/mitigate the issue if user just transfer away the "funded" UTXO.
- Operator need special mechanism (eg. api) to handle pure message stuff. Also need to store the msg info too.
- UTXO Info is required to leak to Operator
Possible way to handle user transferring away fund
Upon operator receive the message, it flag the UTXO and block any tx that uses the UTXO. If user tries to IFE, operator might need to join the challenge game. (ah....this means our challenge game for normal tx need to take DEX design into consideration :( )
Description
As a exchange, I want a way to accept users fund, so that I can check whether the trader has enough fund for his/her order.
As a trader, I should be able to place a firm order ‘immediately’ if I can demonstrate that I have sufficient funds to place an order, So that I can have good experience using the exchange.
As a trader, I want the funding to be promised that exchange can only use my fund in my order, and not being able to steal it, So that I can have feel safe to keep my fund on exchange.
sub story of #53
Note
The essence of this requirement is that: (a) the network should support funds transfer to an exchange actor without the exchange being obligated to do anything with those funds, except to return them to the user at some point if they are not spent, (b) the exchange must support the ability to decouple funds transfer from actual order entry and track the funding requirements to ensure the user has sufficient funds available to participate at the desired level.
from F1 of requirement doc.
Successful Criteria