feat: allow to configure coordinator leverage #2618
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With this patch we introduce a new table: `coordinator_leverages`. It contains two fields: - trader_leverage - coordinator_leverage i.e. we can define a coordinator leverage for each possible trader_leverage. For simplcitiy reasons we only have round numbers in the database and no floating points, hence, when looking up a coordinator leverage for a trader leverage, we need to round. If no match is found, we fall back and take the max allowed leverage of the coordinator. This allows us to not have an entry from 1 - 100 but stop at e.g. 10 with a max coordinator leverage of 10. If a user then goes a 100x, we still pick leverage 10. There is one downside of this patch: The coordinator's reserve now depends on the trader's leverage which we might not want.
luckysori
reviewed
Jun 7, 2024
Comment on lines
+44
to
+45
| tracing::error!("Failed at loading leverage from db. Falling back to 2.0 {err:#}"); | ||
| 2.0 |
There was a problem hiding this comment.
❓I guess we don't need this?
| // TODO(bonomat): we should make this configurable as well. Ideally, we | ||
| // can differentiate between a _leverage_ when opening a position and a | ||
| // _multiplier_ when opening a channel. | ||
| let default_coordinator_leverage = |
There was a problem hiding this comment.
❓Why do we need a default coordinator leverage?
| /// | ||
| /// Unfortunately our version of flutter_rust_bridge does not support hashmaps yet | ||
| pub coordinator_leverages: Vec<CoordinatorLeverage>, | ||
| /// The leverage the coordinator will take if none is provided in `coordinator_leverages` |
There was a problem hiding this comment.
❓Do we really need to cater for this situation by adding a default? If coordinator_leverages is empty I think something went very wrong and we shouldn't allow trading anyway.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With this patch we introduce a new table:
coordinator_leverages.It contains two fields:
i.e. we can define a coordinator leverage for each possible trader_leverage. For simplcitiy reasons we only have round numbers in the database and no floating points, hence, when looking up a coordinator leverage for a trader leverage, we need to round. If no match is found, we fall back and take the max allowed leverage of the coordinator. This allows us to not have an entry from 1 - 100 but stop at e.g. 10 with a max coordinator leverage of 10. If a user then goes a 100x, we still pick leverage 10.
There is one downside of this patch: The coordinator's reserve now depends on the trader's leverage which we might not want.