Because exchange contract runs in parallel. A user could construct a transaction to transfer and then create order atomicly, but unless the order is filled immediately they will have to execute a withdrawal later.
You are viewing a single comment's thread from:
I think , if they're fully in parallel, then the two things (deposit then create order) are hard if not impossible to be processed atomically if there're two operations in one transaction. The deposit itself has to be a message from a user to the token contract, after it's done, communication should be made between the token contract and the exchange contract. Either the exchange contract explicitly ask the token contract to make sure the deposit is done, which requires a lock and perhaps a delay, or the token contract need to send a message to the exchange contract, which will need a delay as well, and contains the user's info when the user requested the deposit, but in this case, the user can directly request an "order creation" in the same way, so doesn't need a single "deposit" feature. When an order is filled, the exchange contract can immediately talk to another token contract directly to deposit the funds back to the user, so don't need the user to request a withdrawal. I do agree that simple deposit and withdrawal features are acceptable, which will help keep state in one contract only and simplify the logic, but perhaps it's not necessary. Ideally, the user should be able to attach a script with a deposit (which is a message to the token contract), for example, do nothing, or to place an order immediately; also in the script, the user can indicate when the order is filled/expired/cancelled, return the funds to the user or place another order, etc, etc.
//UPDATE: above comment was written before carefully read the blog post and the code, so it may be wrong. I will update with more info later.
//UPDATE2: so messages will be validated by all registered notifiers (contracts). If failed to pass a validation in one notifier then all changes done in other contracts will need to be rolled back. Interesting. How to do them in parallel?