-
-
Notifications
You must be signed in to change notification settings - Fork 99
Bankruptcy #362
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
Bankruptcy #362
Conversation
* Remove silly hybrid withdraw/borrow and deposit/repay hybrid functions which serve no purpose except to act as a tremendous footgun * WIP removing the flipping logic from liquidation * Resolve liquidation logic without balance-flipping functions * Fix fuzz fix rust test suite
# Conflicts: # programs/marginfi/src/instructions/marginfi_account/liquidate.rs # programs/marginfi/src/instructions/marginfi_group/handle_bankruptcy.rs # programs/marginfi/src/state/marginfi_group.rs # programs/marginfi/src/utils.rs # type-crate/src/types/bank.rs
@jgur-psyops let's merge this one? |
Not a fan of adding another arbitrary validation function |
Not a fan of adding |
I expect it to look better once this TODO is addressed. But I would do it in a separate PR to only focus on this.
Yeah, so basically it is the main change to bankruptcy. It is what will allow us to deal with super-bankruptcies, which are currently non-solvable. Although, I see your point about the risk of accidentally putting a |
From the meeting earlier it sounds like we're adding a much bigger solution for a problem that we're unlikely to have in the future that is very specifically for dealing with Arena banks that are in a weird state. Would it not be possible to add something that is self contained to specifically arena banks and doesn't expose the other banks to these changes. Agreed that, yes in the long term, users shouldn't be able to get into a state where they can't even get into the state in the first place. And we should be able to handle bankruptcies. Though I don't know what kind of priority this direction is for the product where banks are potentially ending up like this. |
// TODO remove redundant checks for these elsewhere in the program (they are nested many laters deep | ||
// in various value delta functions) | ||
/// Validate the bank's state does not forbid the execution of an instruction | ||
pub fn validate_bank_state(bank: &Bank, kind: InstructionKind) -> MarginfiResult { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this different from assert_operational_mode
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the high level idea is to enforce which states a bank is allowed to be in when an instruction is run? Since this wasn't really enforced before, except implicitly by assert_operational_mode
?
Maybe it's a nit pick but I wonder if the positive is easier to understand
bank.load().allowed_states([PAUSED, REDUCE])
and we can put that in the constraints above the bank's account in a given instruction context.
Nothing left to say on this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Bankruptcy handling: logic, tests, and docs
What this does
Implements full bankruptcy flow for users and banks, including super-bankruptcy handling (clamps loss and kills the bank when bad debt exceeds assets). Introduces a dedicated error code to reflect this terminal state.
Adds a user & bank bankruptcy guide (how it triggers, discharge order, and outcomes): BANKRUPTCY.md.
Hardens instruction paths with additional bank state validation (e.g., during borrow) to prevent actions on paused/reduced/killed banks.
Notable changes
New/updated program errors
BankKilledByBankruptcy (code 6082).
Quick lookup: BankKilledByBankruptcy.
Instruction changes
handle_bankruptcy logic (bank-level settlement, socialized losses, kill path on super-bankruptcy).
borrow as well as the other ixes (deposit repay, withdraw) now validates that the bank is not in a paused or reduced state.
New spec: tests/zb01_bankruptcy.spec.ts (see Files changed).
Fuzz harness updates and additional logging/assertions to surface unexpected liquidation errors.
How it works (short)
Liquidation exhausts remaining assets of the insolvent user.
handle_bankruptcy settles bad debt:
Use insurance if sufficient.
Otherwise, socialize via asset-share value reduction.
If still insufficient (super-bankruptcy), kill the bank (asset share value to zero; bank permanently disabled).
Test plan
Unit/integration tests in zb01_bankruptcy.spec.ts cover user bankruptcy, bank bankruptcy, and super-bankruptcy kill path.
Fuzz tests updated to assert allowed error surface and reject unexpected outcomes; reproducible logs added for triage.