gnosis / dex-liquidity-provision

GNU Lesser General Public License v3.0
12 stars 9 forks source link

Confusing naming: brackets #253

Closed fedgiac closed 4 years ago

fedgiac commented 4 years ago

The terms "brackets" and "fleet of Safes" are confusing for the user and don't really reflect why they would be needed or which purpose they serve. In particular, it's not immediate that the number of orders placed between lowest and highest limit is the number of brackets.

Let's discuss about possible alternatives. We could also keep the term "bracket", since it's somewhat ubiquitous in this repo, but then we should at least clarify the readme. Related options: --fleetSize --brackets.

Thanks @Rafanator for the feedback.

josojo commented 4 years ago

Here is a list of other names that cross my mind: master_account<>subaccount main_account<>subaccount master_safe<>trade_account master_safe<>bracket_account master_safe<>order_pair_element

bh2smith commented 4 years ago

I would like to point out that we have previously been using the term "Fund Account" for master safe which makes pretty good sense to me. I would like to remind us of this PDF document that was started and abandoned a couple months ago.

LiquidityProvisionDiagram.pdf

As for fleetSize, I would propose numSafes, numBrackets, or numTraders. Obviously, if we are going to eliminate the term "brackets" then numSafes would be my preference. I actually think it could be the best possible avenue, since there is no reason in trying to hide the fact that these "trader accounts" are, indeed, Gnosis Safes.

We had furthermore, been referring to subSafes as "trader accounts". I certainly would not want to call masterSafe the subaccount or anything at all related to sub. That being said, I suspect @josojo's first four suggestions were accidental suggestions for brackets because they seem to be exactly the opposite. Maybe if the term master were replaced everywhere with sub then those suggestions would make sense.

To summarize, here is my attempt at naming suggestions:

Master Safe <--> Fund Account
fleetSize <--> numSafes or numBrackets
brackets <--> this should remain.

My reason for brackets remaining the same is as follows. If traditional finance does not already have a term for this, that is because they don't have this kind of trading mechanism. If this trading mechanism is new, then I think everyone who built it would agree that this is the most natural term.

josojo commented 4 years ago

call masterSafe the subaccount

Sorry, if my post was unclear. I wanted to call the masterSafe, master account and the bracket , subaccount

Rafanator commented 4 years ago

My concern with fleetSize and numSafes is that they are not clearly explaining what determining a fleetSize does to your liquidity provision in terms of order placement.

It is clear that I create some Safes/walllets, but that is well abstracted already in the process, and not so relevant from the market maker's order placement perspective.

What I understand fleetSize is determining is quoting the bids and asks at different price levels. Therefore, I would recommend that we call it numQuotes, Number of Quotes.

With numQuotes, we adhere to a more traditional lingo that market makers would use.

Thoughts?

fedgiac commented 4 years ago

In general I like the idea of sticking to trading lingo. If we go with Rafa's suggestion then we need to change what this number means, since --fleetSize=n is actually equivalent to --numQuotes=n+1 (there are n+1 different prices with n Safes), and it's not possible to have just a single quote with our scripts.

bh2smith commented 4 years ago

I am fine to go with num quotes, although it confuses me because I am never thinking of the prices in the middle of the brackets. I haven't seen any good arguments against numBrackets. Is there any harm in introducing a new term with a new trading strategy? Does such a trading strategy already exist? If so, then I imagine there is no need for discussion.

Rafanator commented 4 years ago

A) I think numBrackets is nice and can work, provided that it can be accompanied by a short 1 sentence description of what it is. Could you please put exactly into words which params of the order placing it takes care of?

B) Bracket strategy does not exist in trading. The term Bracket Orders does exist, which is pretty much setting a limit order for entry price with two limit orders, one higher and one lower, to help limit loss and lock in profit. https://www.interactivebrokers.com/en/index.php?f=583

On Thu, May 14, 2020 at 12:17 PM Benjamin Smith notifications@github.com wrote:

I am fine to go with num quotes, although it confuses me because I am never thinking of the prices in the middle of the brackets. I haven't seen any good arguments against numBrackets. Is there any harm in introducing a new term with a new trading strategy? Does such a trading strategy already exist? If so, then I imagine there is no need for discussion.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gnosis/dex-liquidity-provision/issues/253#issuecomment-628538465, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGKQQVTQOAS6VRM2QKGWYMDRRPAJZANCNFSM4M76H5YA .

-- Rafael Suárez

Rafanator commented 4 years ago

Edit: The term Bracket Orders does exist, which is pretty much setting a limit order for entry price with two additional limit orders, one higher and one lower, to help limit loss and lock in profit. ᐧ

On Thu, May 14, 2020 at 1:59 PM Rafael Suárez rafael.suarez333@gmail.com wrote:

A) I think numBrackets is nice and can work, provided that it can be accompanied by a short 1 sentence description of what it is. Could you please put exactly into words which params of the order placing it takes care of?

B) Bracket strategy does not exist in trading. The term Bracket Orders does exist, which is pretty much setting a limit order for entry price with two limit orders, one higher and one lower, to help limit loss and lock in profit. https://www.interactivebrokers.com/en/index.php?f=583

On Thu, May 14, 2020 at 12:17 PM Benjamin Smith notifications@github.com wrote:

I am fine to go with num quotes, although it confuses me because I am never thinking of the prices in the middle of the brackets. I haven't seen any good arguments against numBrackets. Is there any harm in introducing a new term with a new trading strategy? Does such a trading strategy already exist? If so, then I imagine there is no need for discussion.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gnosis/dex-liquidity-provision/issues/253#issuecomment-628538465, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGKQQVTQOAS6VRM2QKGWYMDRRPAJZANCNFSM4M76H5YA .

-- Rafael Suárez

-- Rafael Suárez

bh2smith commented 4 years ago

The term Bracket Orders does exist, which is pretty much setting a limit order for entry price with two limit orders, one higher and one lower

I feel like this is similar to our "spread orders" (i.e. placing a willingness to sell slightly above market value and a willingness to buy slightly below)

bh2smith commented 4 years ago

@Rafanator, I can tell that you are replying to these via email... not sure if you wanna include the entire thread history in these replies.

Rafanator commented 4 years ago

No, it is easier to understand from the perspective of entering a position. You determine an entry order, that can be a limit or market order, that would be your entry price. Additionally, you put a higher limit sell order to sell that asset at a profit, and a lower priced stop order to sell the asset at a limited loss.

Easier terms to understand: Entry: 100 Take profit order: 150 Stop loss order: 75

Those three would be one bracket order. ᐧ

On Thu, May 14, 2020 at 2:04 PM Benjamin Smith notifications@github.com wrote:

The term Bracket Orders does exist, which is pretty much setting a limit order for entry price with two limit orders, one higher and one lower

I feel like this is similar to our "spread orders" (i.e. placing a willingness to sell slightly above market value and a willingness to buy slightly below)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gnosis/dex-liquidity-provision/issues/253#issuecomment-628588852, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGKQQVQORWDDARFBDVPAPTLRRPM3XANCNFSM4M76H5YA .

-- Rafael Suárez

bh2smith commented 4 years ago

Ok, so then, it seems there is an existing term "Bracket Order" which is closely describing the intention of "brackets" we have here. That is, in our case, the brackets are placing a limit buy-order for the "baseToken" whose limit when the price (relative to the quote Token) is the lower than entry (i.e. the stop-loss) price and a limit sell-order (which is analogous to the "take profit order").

With this in mind it appears the terms are actually aligned.

However, our the trading strategy outlined here is somewhat more sophisticated because there is a "fleet" of non-overlapping bracket orders depicted in ascii art as follows:

--- takeprofit_1
|
** entry_1
|
--- stoploss_1
--- takeprofit_2
|
** Entry_2
|
--- stoploss_2
***** <--------Main Entry Point (valuation of base token at time of deployment)
--- takeprofit_3
|
** Entry_3
|
--- stoploss_3
--- takeprofit_4
|
** Entry_4
|
--- stoploss_4

Essentially one puts brackets around a main "target price" (Main Entry) the current valuation. Each of these bracket orders is a different Account ("Gnosis Safe"). Because one generally wants to place a trading strategy of "buy low sell high" the upper half of the brackets are funded only with the quoteToken and the lower half of the brackets are funded only with the "baseToken"

This means that trade will be made according to the buy-low sell-high strategy at several different prices in the spectrum defined by stoploss_4 < takeprofit_1 Note that, if there are active users trading against these orders, the funds in each "bracket" will flow towards the current valuation.

Anyway, this is just my rational for using a term like numBrackets. Would be happy to hear some descent alternate suggestions if this is not going to happen.

A) I think numBrackets is nice and can work, provided that it can be accompanied by a short 1 sentence description of what it is. Could you please put exactly into words which params of the order placing it takes care of?

Glad you like it @Rafanator! Looks like we might land on this after all. Where is is that we might want to include this "one sentence description"? Are there any parts of my longer description here that we could use?

Rafanator commented 4 years ago

Very well elaborated answer. Then yes, I guess it is fine if we use numBrackets, I like it :) ᐧ

On Thu, May 14, 2020 at 2:31 PM Benjamin Smith notifications@github.com wrote:

Ok, so then, it seems there is an existing term "Bracket Order" which is closely describing the intention of "brackets" we have here. That is, in our case, the brackets are placing a limit buy-order for the "baseToken" whose limit when the price (relative to the quote Token) is the lower than entry (i.e. the stop-loss) price and a limit sell-order (which is analogous to the "take profit order").

With this in mind it appears the terms are actually aligned.

However, our the trading strategy outlined here is somewhat more sophisticated because there is a "fleet" of non-overlapping bracket orders depicted in ascii art as follows:

--- takeprofit_1 ** entry_1
--- stoploss_1 --- takeprofit_2 ** Entry_2
--- stoploss_2 ***** <--------Main Entry Point (valuation of base token at time of deployment) --- takeprofit_3 ** Entry_3
--- stoploss_3 --- takeprofit_4 ** Entry_4

--- stoploss_4

Essentially one puts brackets around a main "target price" (Main Entry) the current valuation. Each of these bracket orders is a different Account ("Gnosis Safe"). Because one generally wants to place a trading strategy of "buy low sell high" the upper half of the brackets are funded only with the quoteToken and the lower half of the brackets are funded only with the "baseToken"

This means that trade will be made according to the buy-low sell-high strategy at several different prices in the spectrum defined by stoploss_4 < takeprofit_1 Note that, if there are active users trading against these orders, the funds in each "bracket" will flow towards the current valuation.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gnosis/dex-liquidity-provision/issues/253#issuecomment-628602046, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGKQQVWVT5FBT323INPZDRTRRPQAPANCNFSM4M76H5YA .

-- Rafael Suárez

bh2smith commented 4 years ago

Amazing! This is great. This issue was originally about the term brackets alone but we also mentioned a few others.

Would everyone be ok with masterSafe -> fundAccount or was masterSafe ok in the first place?

Rafanator commented 4 years ago

I am indifferent. Your call.

On Thu 14. May 2020 at 16:07, Benjamin Smith notifications@github.com wrote:

Amazing! This is great. This issue was originally about the term brackets alone but we also mentioned a few others.

Would everyone be ok with masterSafe -> fundAccount or was masterSafe ok in the first place?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gnosis/dex-liquidity-provision/issues/253#issuecomment-628660749, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGKQQVSSSRBMIHXOAMHGE7DRRP3LNANCNFSM4M76H5YA .

-- Rafael Suárez

josojo commented 4 years ago

Each of these bracket orders is a different Account ("Gnosis Safe").

You are even using the word account to describe the brackets. I think that sub_account would be the better fit, but I am okay with sticking to brackets.

Would everyone be ok with masterSafe -> fundAccount or was masterSafe ok in the first place?

The fundAccount needs to be a Safe, so I think that sticking with a name, which contains the word safe is not a bad choice.

but these are just my two cents

bh2smith commented 4 years ago

Cool, I think this discussion has concluded and I will implement these changes ASAP. Lets keep in mind that we may also have to adjust some content in dex-docs.