Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix!: allow safe leverage operations during partial oracle outages #1821

Merged
merged 21 commits into from
Feb 15, 2023

Conversation

toteki
Copy link
Member

@toteki toteki commented Feb 14, 2023

Description

This one does a lot of things:

  • Allows account_summary to work during price outages, treating all unknown prices as zero.
    • In such cases, supplied value and other fields will appear lower than it really is, since some assets were skipped
    • Liquidation threshold will be null when it can't be computed, since there's no safe way to do that with missing prices
  • borrow_limit in queries as well as messages is computed using only collateral with known prices
    • If the portion of your collateral with known prices is enough to cover a borrow, then it still works.
    • Same for withdraw and decollateralize
  • MaxWithdraw and MaxBorrow (both queries and messages) now function with missing collateral prices, respecting the borrow limit policy above. The queries return zero on missing borrow prices, or a missing price for the specific token being asked for.
  • liquidation_targets query skips addresses where liquidation threshold cannot be computed, instead of returning an error for the whole query
  • MsgLiquidate will be able to function with some missing prices on the target's borrowed assets, if their other borrows are high enough to still put them above their liquidation threshold

API Breaking:

  • liquidation_threshold field in account_summary field can now be null

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • added appropriate labels to the PR
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

@toteki toteki changed the title fix: allow safe leverage operations during partial oracle outages fix!: allow safe leverage operations during partial oracle outages Feb 14, 2023
x/leverage/keeper/iter.go Outdated Show resolved Hide resolved
@toteki toteki marked this pull request as ready for review February 14, 2023 18:11
@toteki toteki requested review from a team as code owners February 14, 2023 18:11
@codecov-commenter
Copy link

codecov-commenter commented Feb 14, 2023

Codecov Report

Merging #1821 (5e3c211) into main (c500338) will increase coverage by 0.60%.
The diff coverage is 75.84%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1821      +/-   ##
==========================================
+ Coverage   57.53%   58.13%   +0.60%     
==========================================
  Files          79       80       +1     
  Lines        8111     8213     +102     
==========================================
+ Hits         4667     4775     +108     
+ Misses       3104     3097       -7     
- Partials      340      341       +1     
Impacted Files Coverage Δ
x/leverage/keeper/keeper.go 70.05% <56.25%> (+0.77%) ⬆️
x/leverage/keeper/iter.go 66.29% <62.50%> (+0.56%) ⬆️
x/leverage/keeper/borrows.go 77.44% <65.38%> (-0.34%) ⬇️
x/leverage/keeper/collateral.go 69.53% <66.66%> (-0.24%) ⬇️
x/leverage/keeper/limits.go 65.44% <75.00%> (+6.14%) ⬆️
x/leverage/keeper/msg_server.go 79.25% <75.00%> (+0.12%) ⬆️
x/leverage/keeper/oracle.go 67.83% <78.57%> (+3.49%) ⬆️
x/leverage/keeper/grpc_query.go 66.77% <82.85%> (+2.54%) ⬆️
x/leverage/client/tests/tests.go 100.00% <100.00%> (ø)
x/leverage/keeper/errors.go 100.00% <100.00%> (ø)
... and 9 more

Copy link
Member

@robert-zaremba robert-zaremba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this is a right solution.
I'm worried about borrowed value will skip borrowed tokens with unknown oracle prices, treating them as zero value -- this can prevent liquidations, which normally should happen.

Also,

  • proper error checks are missing.
  • let's add a follow up task to test new edge cases
  • document or make a task to solve panic in case of missing collateral price when we try to liquidate a position.
  • probably, this will also block uncollaterize operations. Make sure we can decolaterize asset with "zero" price

x/leverage/keeper/borrows.go Outdated Show resolved Hide resolved
x/leverage/keeper/grpc_query.go Show resolved Hide resolved
x/leverage/keeper/grpc_query.go Show resolved Hide resolved
x/leverage/keeper/iter.go Show resolved Hide resolved
Copy link
Member

@robert-zaremba robert-zaremba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pre-approving to make the planned released sooner.
I've updated the previous review note: #1821 (review)
Let's make sure we add all relevant tasks, and follow ups in the task board.

@toteki
Copy link
Member Author

toteki commented Feb 15, 2023

see , document or make a task to solve panic in case of missing collateral price when we try to liquidate a position.

This is an intended error return - we can't declare a borrower unhealthy (liquidation eligible) without knowing the value of all their collateral.

probably, this will also block uncollaterize operations.

Decollateralize and withdraw both use assertBorrowerHealth, which requires the value of all borrows is known, and that the borrow limit derived from their collateral with known prices (some might be missing) is sufficient to cover the borrows.

I'll check off the other two comments as they are done

@robert-zaremba
Copy link
Member

Decollateralize and withdraw both use assertBorrowerHealth, which requires the value of all borrows is known, and that the borrow limit derived from their collateral with known prices (some might be missing) is sufficient to cover the borrows.

We should enable a user to decollaterize the asset with zero price.

@mergify mergify bot merged commit 87b9ed4 into main Feb 15, 2023
@mergify mergify bot deleted the adam/availability branch February 15, 2023 22:31
mergify bot pushed a commit that referenced this pull request Feb 15, 2023
…1821)

## Description

This one does a lot of things:
- Allows `account_summary` to work during price outages, treating all unknown prices as zero.
  - In such cases, supplied value and other fields will appear lower than it really is, since some assets were skipped
  - Liquidation threshold will be null when it can't be computed, since there's no safe way to do that with missing prices
- `borrow_limit` in queries as well as messages is computed using only collateral with known prices
  - If the portion of your collateral with known prices is enough to cover a borrow, then it still works.
  - Same for withdraw and decollateralize
- `MaxWithdraw` and `MaxBorrow` (both queries and messages) now function with missing collateral prices, respecting the borrow limit policy above. The queries return zero on missing borrow prices, or a missing price for the specific token being asked for.
- `liquidation_targets` query skips addresses where liquidation threshold cannot be computed, instead of returning an error for the whole query
- `MsgLiquidate` will be able to function with some missing prices on the target's borrowed assets, if their other borrows are  high enough to still put them above their liquidation threshold

API Breaking:
- `liquidation_threshold` field in `account_summary` field can now be null

---

### Author Checklist

_All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues._

I have...

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [x] added `!` to the type prefix if API or client breaking change
- [x] added appropriate labels to the PR
- [x] targeted the correct branch (see [PR Targeting](https://github.com/umee-network/umee/blob/main/CONTRIBUTING.md#pr-targeting))
- [ ] provided a link to the relevant issue or specification
- [x] added a changelog entry to `CHANGELOG.md`
- [x] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [ ] updated the relevant documentation or specification
- [x] reviewed "Files changed" and left comments if necessary
- [ ] confirmed all CI checks have passed

### Reviewers Checklist

_All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items._

I have...

- [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] confirmed all author checklist items have been addressed
- [ ] reviewed state machine logic
- [ ] reviewed API design and naming
- [ ] reviewed documentation is accurate
- [ ] reviewed tests and test coverage
- [ ] manually tested (if applicable)

(cherry picked from commit 87b9ed4)

# Conflicts:
#	proto/umee/leverage/v1/query.proto
#	swagger/swagger.yaml
#	x/leverage/types/query.pb.go
toteki added a commit that referenced this pull request Feb 15, 2023
…ackport #1821) (#1828)

* fix!: allow safe leverage operations during partial oracle outages (#1821)

## Description

This one does a lot of things:
- Allows `account_summary` to work during price outages, treating all unknown prices as zero.
  - In such cases, supplied value and other fields will appear lower than it really is, since some assets were skipped
  - Liquidation threshold will be null when it can't be computed, since there's no safe way to do that with missing prices
- `borrow_limit` in queries as well as messages is computed using only collateral with known prices
  - If the portion of your collateral with known prices is enough to cover a borrow, then it still works.
  - Same for withdraw and decollateralize
- `MaxWithdraw` and `MaxBorrow` (both queries and messages) now function with missing collateral prices, respecting the borrow limit policy above. The queries return zero on missing borrow prices, or a missing price for the specific token being asked for.
- `liquidation_targets` query skips addresses where liquidation threshold cannot be computed, instead of returning an error for the whole query
- `MsgLiquidate` will be able to function with some missing prices on the target's borrowed assets, if their other borrows are  high enough to still put them above their liquidation threshold

API Breaking:
- `liquidation_threshold` field in `account_summary` field can now be null

---

### Author Checklist

_All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues._

I have...

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [x] added `!` to the type prefix if API or client breaking change
- [x] added appropriate labels to the PR
- [x] targeted the correct branch (see [PR Targeting](https://github.com/umee-network/umee/blob/main/CONTRIBUTING.md#pr-targeting))
- [ ] provided a link to the relevant issue or specification
- [x] added a changelog entry to `CHANGELOG.md`
- [x] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [ ] updated the relevant documentation or specification
- [x] reviewed "Files changed" and left comments if necessary
- [ ] confirmed all CI checks have passed

### Reviewers Checklist

_All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items._

I have...

- [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] confirmed all author checklist items have been addressed
- [ ] reviewed state machine logic
- [ ] reviewed API design and naming
- [ ] reviewed documentation is accurate
- [ ] reviewed tests and test coverage
- [ ] manually tested (if applicable)

(cherry picked from commit 87b9ed4)

# Conflicts:
#	proto/umee/leverage/v1/query.proto
#	swagger/swagger.yaml
#	x/leverage/types/query.pb.go

* fix conflict

* fix

---------

Co-authored-by: Adam Moser <63419657+toteki@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants