You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 12, 2023. It is now read-only.
After a discussion with @bonomat and @thomaseizinger I gave "who should come up with the price" for collaborative close some more thought, in context of adding an automated sell at limit for the taker. I see automated sell at limit as additional (small) feature on our roadmap for the next milestone, or as separate milestone afterwards.
I regard automated sell at limit and automated buy at limit as different, independent features. I think we should prioritize automated sell at limit over automated buy at limit because it is the more critical one in terms of monitoring over time.
We currently don't have multiple maker, there is no orderbook to record limit orders, i.e. we don't really have a marketplace. We could theoretically "trust" the maker and record a limit order with the maker, but I think that would be step in the wrong direction.
Thus, I think our current approach of proposing a price by the taker makes sense.
Given that we add automated sell at limit this flow makes sense:
Taker opens a position
Taker adds a sell limit to the position that is stored in the taker database. (i.e. only the taker knows about this limit - no trust involved)
All taker limits are monitored within the taker daemon
If the price reaches a sell limit (if it increases to the limit for long, or decreases for short) the taker will propose to settle to the maker with the limit price.
If the maker refuses we will force-close, i.e. stop rolling over and use the set oracle attestion to close. I think this makes sense if we assume that the price does not go nuts after we hit the limit. Under normal circumstances there is no reason for the maker not to accept, so the force close scenario should be regarded as the exception of the case.
Currently there is no partial order filling, so I'd say we don't have to discuss stop orders in this scenario. Orders will always be filled completely.
Once we have multiple makers and some form of orderbook we can change this to let the taker create the order in a decentralized orderbook. In the best case we can make whole positions tradeable. I think this should be possible to achieve if all three parties (the taker that wants to sell the position, the taker that is willing to "take it over" and the maker that the position was opened again) collaborate.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
After a discussion with @bonomat and @thomaseizinger I gave "who should come up with the price" for collaborative close some more thought, in context of adding an
automated sell at limit
for the taker. I seeautomated sell at limit
as additional (small) feature on our roadmap for the next milestone, or as separate milestone afterwards.I regard
automated sell at limit
andautomated buy at limit
as different, independent features. I think we should prioritizeautomated sell at limit
overautomated buy at limit
because it is the more critical one in terms of monitoring over time.We currently don't have multiple maker, there is no orderbook to record limit orders, i.e. we don't really have a marketplace. We could theoretically "trust" the maker and record a limit order with the maker, but I think that would be step in the wrong direction.
Thus, I think our current approach of proposing a price by the taker makes sense.
Given that we add
automated sell at limit
this flow makes sense:If the maker refuses we will force-close, i.e. stop rolling over and use the set oracle attestion to close. I think this makes sense if we assume that the price does not go nuts after we hit the limit. Under normal circumstances there is no reason for the maker not to accept, so the force close scenario should be regarded as the exception of the case.
Currently there is no partial order filling, so I'd say we don't have to discuss stop orders in this scenario. Orders will always be filled completely.
Once we have multiple makers and some form of orderbook we can change this to let the taker create the order in a decentralized orderbook. In the best case we can make whole positions tradeable. I think this should be possible to achieve if all three parties (the taker that wants to sell the position, the taker that is willing to "take it over" and the maker that the position was opened again) collaborate.
Beta Was this translation helpful? Give feedback.
All reactions