Seems important to test

(which effectively disables the rate limiter)

Instructions

New Instructions

AddLiquidityMiningRewards

arguments

• reserve: Pubkey
• RewardType: Deposit | Borrow
• token address: Pubkey
• token amount: u64
• duration_in_slots: u64

behavior

• transfer rewards to a token account owned by program

ClaimRewards

arguments

• reserve: Pubkey
• reward_id: u64

Modifying existing instructions

Deposit, Repay, Borrow, WIthdraw, Liquidate now all affect rewards calculations, so reward variables have to be "refreshed" at the start of each instruction now.

I think easiest way is to modify _refresh_reserve_interest to also refresh the rewards

State

RewardInfo

struct ReserveRewardInfo {
  id: u8,
  token_account: Pubkey,
  mint: Pubkey,
  accumulated_reward_rate: Decimal,
  last_updated_slot: u64,
  rewards_attributed: Decimal,
  total_rewards: u64
}

struct ObligationRewardInfo {
  id: u8,
  old_accumulator: Decimal,
  claimed_rewards: Decimal,
  unclaimed_rewards: Decimal
}

Other considerations:

• how to handle cases when the lm reward duration is finished? rewards can't accumulate forever. maybe best to have a cancelRewards function so the owner can withdraw
• should we have a way to permissionlessly crank LM rewards? in case reward refreshing causes compute issues. Compute issues are scary because they can break liquidations.

We want to store LendingMarket/Reserve metadata onchain (instead of serving it from the backend). This metadata can be managed by our current program.

Implementation:

1. Define LendingMarketMetadata, ReserveMetadata accounts in the rust solend sdk. These should have the fields identical to MarketConfig,ReserveConfig in the backend + generous padding in case we need to add new stuff later. You can look at lending_market.rs to see how accounts are packed/unpacked
2. Define instructions to create and update the metadata accounts. Some things to note:

• only the lending market owner should be able to call these instructions
• the LendingMarketMetadata, ReserveMetadata accounts should be pdas with seeds [lending_market.pubkey, "LendingMarketMetaData"], [reserve.pubkey, "ReserveMetaData"] respectively

3. Update cli with support for new instructions
4. Update typescript sdk with support for reading these accounts and calling these instructions.

Testing should include:

• pack/unpack testing for the new accounts and instructions. See #135
• make sure only the owner can call these instructions. See the tests below this line as an example https://github.com/solendprotocol/solana-program-library/pull/142/files#diff-2e89f0d229c84ee459f9360ec24e3b0ef8d7569b2a5866b37be636053fb83e29R208

Description:

Liquidations in Solend V2 have a dynamic bonus, depending on how unhealthy the obligation is. For example, an obligation that is barely eligible for liquidation will have a liquidation bonus of 0%, while a very unhealthy obligation will have a liquidation bonus of 10%.

Implementation Details:

The ReserveConfig will have the following new fields:

/// loan to value ratio at which the obligation gets liquidated for the maximum bonus
pub max_liquidation_threshold: u8,
/// max liquidation bonus. liquidation bonuses will be interpolated to be a value between liquidation bonus
/// and max liquidation bonus
pub max_liquidation_bonus: u8

The Obligation will have the following new fields:

/// ie sum(d.deposited_amount * d.max_liquidation_threshold * d.current_spot_price for d in deposits)
/// used to calculate the liquidation bonus
pub super_unhealthy_borrow_value: Decimal

The liquidation bonus will be calculated as follows (1):

let weight = (borrowed_value - unhealthy_borrowed_value) / (super_unhealthy_borrow_value - unhealthy_borrow_value)
let bonus = liquidation_bonus + weight * (max_liquidation_bonus - liquidation_bonus)
return bonus + reserve.protocol_liquidation_fee

Explanation for protocol_liquidation_fee:
Currently the protocol liquidation fee is calculated as a percentage of the bonus. However, it makes sense for the program to always make money on a liquidation. In cases where the bonuses are set to zero, the program will not make money. Therefore, on a liquidation, the protocol liquidation bonus (ie the protocol_liquidation_fee) is always included.

Extra care is required to make this specific change because the protocol_liquidation_fee is currently typically 30%, so it's important to handle cases of really high protocol bonuses. It would make sense to cap the protocol liquidation fee value during the Reserve::unpack function. Likewise it probably makes sense to have a global bonus max in (1), so things don't accidentally go crazy.

Explanation of invoke below:
https://docs.rs/solana-program/1.13.5/src/solana_program/program.rs.html#30-32

1. kind of annoying if users have to depend on the entire solend program if they want to use our structs. there's a non-zero change for dependency conflict.
2. some people prefer using anchor bindings to make cpi calls.

I had a PR for this but it went stale #98 not too much work to revive it i guess