0xripleys borrow coefficient

[0xripleys]

Summary:
Add a borrow weight to the Reserve

before, borrowed value in usd was calculated by

borrowed_value_usd = sum(b.borrow_amount * b.token_price for b in obligation.borrows)

now, we do:

borrowed_value_usd = sum(b.borrow_weight * b.borrow_amount * b.token_price for b in obligation.borrows)

Borrow weight is always greater than 1.

Purpose: If some reserve R is at 100% util, then any liquidator who liquidates an obligation that's collateralized by R will receive cTokens, which is undesirable. With this change, when reserve util is close to or at 100%, Solend plans to increase the borrow weight. This in turn will cause liquidations to happen, and reserve util will eventually decrease.

Affected instructions

• borrow obligation liquidity: strictly more conservative now
• withdraw obligation collateral / withdraw obligation collateral and redeem reserve liquidity: also more conservative
• liquidate obligation collateral and redeem reserve liquidity: the increase in borrow weight can make certain obligations now unhealthy. Also, the increase in borrow weight causes a bigger liquidation.

Testing

• borrow obligation liquidity: a previously valid borrow is now rejected because of the borrow weight change
• withdraw: a previously valid withdraw is now rejected because of the borrow weight change
• liquidate: a previously healthy obligation is now unhealthy when borrow weight is increased, and can be liquidated

[codecov-commenter]

Codecov Report

Merging #127 (0c34672) into 0xripleys_outflow_limits (ebec41a) will increase coverage by 0.76%.
The diff coverage is 99.81%.

❗ Current head 0c34672 differs from pull request most recent head 68ce780. Consider uploading reports for the commit 68ce780 to get more accurate results

📣 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

@@                     Coverage Diff                      @@
##           0xripleys_outflow_limits     #127      +/-   ##
============================================================
+ Coverage                     80.86%   81.62%   +0.76%     
============================================================
  Files                            42       43       +1     
  Lines                         13373    13896     +523     
============================================================
+ Hits                          10814    11343     +529     
+ Misses                         2559     2553       -6     

Impacted Files	Coverage Δ
token-lending/cli/src/main.rs	0.06% <0.00%> (-0.01%)	⬇️
token-lending/sdk/src/state/obligation.rs	95.05% <ø> (+0.36%)	⬆️
token-lending/program/src/processor.rs	80.48% <100.00%> (+0.14%)	⬆️
token-lending/program/tests/borrow_weight.rs	100.00% <100.00%> (ø)
token-lending/program/tests/helpers/mod.rs	100.00% <100.00%> (ø)
...nding/program/tests/helpers/solend_program_test.rs	96.64% <100.00%> (+<0.01%)	⬆️
token-lending/program/tests/init_reserve.rs	100.00% <100.00%> (ø)
token-lending/sdk/src/instruction.rs	98.21% <100.00%> (+0.01%)	⬆️
token-lending/sdk/src/math/decimal.rs	100.00% <100.00%> (ø)
token-lending/sdk/src/state/reserve.rs	96.19% <100.00%> (+0.49%)	⬆️
... and 2 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[nope-finance]

init reserve/ update reserve config don't accept a borrow_weight_bps value of < 10_000

i still think it would be better to just do 1 + borrow weight so there isn't a need to rely on checks like this. is there a strong reason not to?

also I guess i wonder if this needs to be basis point precision rather than just percent precision

[0xripleys]

i still think it would be better to just do 1 + borrow weight so there isn't a need to rely on checks like this. is there a strong reason not to?

i don't have a strong opinion. i guess as long as we use the borrow_weight() function directly, the dangers are minimized anyways. your call

also I guess i wonder if this needs to be basis point precision rather than just percent precision

hmm i guess not really lol. kinda annoying that Decimal::from_pct accepts a u8, but w/e i guess i could change that