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

Take rate #83

Closed
wants to merge 9 commits into from
Closed

Take rate #83

wants to merge 9 commits into from

Conversation

nope-finance
Copy link
Member

@nope-finance nope-finance commented Apr 13, 2022

when interest compounds some gets set aside as a protocol claimable fee

additionally there is a crank function which makes it possible to claim the fees (anyone can call but the fees always go to the reserve fee receiver)

@@ -2197,6 +2201,71 @@ fn process_update_reserve_config(
Ok(())
}

#[inline(never)] // avoid stack frame limit
fn process_redeem_fees(program_id: &Pubkey, accounts: &[AccountInfo]) -> ProgramResult {
Copy link

@0xCactus 0xCactus May 17, 2022

Choose a reason for hiding this comment

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

Should we restrict who can execute this function for security as its protocol specific? E.g only allowed by the market owner

Choose a reason for hiding this comment

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

I think it's not needed because the function sends the fees to reserve.config.fee_receiver only, so it doesn't really matter who triggers this instruction.

Copy link
Member Author

Choose a reason for hiding this comment

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

i think we specifically dont want to limit it because want to set up a crank to call it once a day from a non essential address

@@ -381,6 +382,8 @@ pub struct ReserveLiquidity {
pub borrowed_amount_wads: Decimal,
/// Reserve liquidity cumulative borrow rate
pub cumulative_borrow_rate_wads: Decimal,
/// Reserve accumulated protocol fees
pub accumulated_protocol_fees_wads: Decimal,

Choose a reason for hiding this comment

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

can we use same term as above - cumulative_protocol_fees_wad

Copy link
Member Author

Choose a reason for hiding this comment

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

it means something different though

.try_add(Decimal::from(usdc_balance_after - usdc_balance_before))
.unwrap();

assert_eq!(
Copy link
Member Author

Choose a reason for hiding this comment

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

these first 6 assertions are interesting they assert that total supply and exchange rate dont change when claiming fees (which makes sense)

but utilization does (because we take from available liquidity and add to debt. this balances the accounting that occurs over time where borrowers were accumulating more debt than lenders were owed until fees are claimed

@nope-finance nope-finance force-pushed the take_rate branch 2 times, most recently from f97c337 to dd8152e Compare June 6, 2022 08:25
@nope-finance
Copy link
Member Author

#89 implements this instead

@0xripleys 0xripleys deleted the take_rate branch January 25, 2023 10:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants