# Credit System

Collateralized vault credit lets a user deposit a supported crypto asset, pledge it as collateral, borrow USD-denominated credit against it, and deploy that credit directly into approved vaults.

The key idea is that borrowed credit stays inside the protocol. It does not become free wallet balance. It cannot be withdrawn, transferred, used as perp margin, or routed into bots. The only destination is an approved vault.

In practice, the flow is:

1. User deposits a supported asset, such as an LP token.
2. User pledges some or all of that asset as collateral.
3. User borrows USD-denominated credit against the pledged collateral.
4. The borrowed credit is deployed into an approved vault.
5. The vault shares minted from that borrowed credit are marked as credit-funded shares.
6. When those shares are withdrawn, proceeds repay the linked debt first.

This is not cross-margin. Each collateral asset has its own position, its own debt, and its own liquidation path.

### Why It Works This Way

The design is built around three protocol goals:

| Goal                           | Meaning                                                                                                                                                        |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Keep borrowed credit contained | Borrowed credit can only enter approved vaults, so it cannot leak into wallet balance, margin, transfers, or bots.                                             |
| Track what backs debt          | The protocol always knows which collateral asset backs which debt and which vault shares were minted from that debt.                                           |
| Recover debt in layers         | If a position becomes unsafe, the protocol has a defined path: repayment, collateral conversion, vault-share recovery, Insurance Fund treatment, and bad debt. |

For users, it behaves like a vault-only credit line. The protocol tracks which collateral backs each debt position and which vault shares came from borrowed credit, so repayment and recovery can follow a clear path.

### Core Concepts

#### Custody Balance

A custody balance is the user's protocol balance of a supported crypto asset.

For example, if a user deposits 100 LP tokens, their custody balance for that LP token becomes 100.

Pledging collateral does not remove the tokens from custody balance. It locks them as collateral.

Available custody balance is:

`available custody = total custody balance - pledged collateral`

Only available custody can be withdrawn. Pledged collateral stays locked until it is released, converted, or otherwise resolved by the credit protocol.

#### Collateral Position

A credit position is one wallet/account's collateralized debt position for one collateral asset.

For example:

| Wallet/account |        Collateral asset | Pledged collateral | USD debt |
| -------------- | ----------------------: | -----------------: | -------: |
| Alice          | LP\_SUNDAE\_USDCx\_USDM |                100 |    1,000 |

If Alice also pledges ADA, that is a separate position. ADA collateral does not back the LP-token debt, and LP-token collateral does not back the ADA debt.

#### Credit-Funded Shares

When borrowed credit enters a vault, the resulting vault shares are recorded as credit-funded shares.

They are still vault shares owned by the user, but they are linked to the debt:

| Vault share type     | Funded by         | Withdrawal behavior       |
| -------------------- | ----------------- | ------------------------- |
| Free shares          | User-supplied USD | Standard vault withdrawal |
| Credit-funded shares | Borrowed credit   | Repay linked debt first   |

Credit-funded shares do not increase borrow capacity. They can be used to repay debt if needed, but they are not collateral.

### The Basic Lifecycle

#### 1. Deposit A Supported Asset

The user deposits a supported asset, such as an LP token.

The protocol records the asset as custody balance. This does not affect the user's free USD balance.

Example:

| Field              | Before | After |
| ------------------ | -----: | ----: |
| LP custody balance |      0 |   100 |
| Free USD balance   |    500 |   500 |
| Pledged collateral |      0 |     0 |
| USD debt           |      0 |     0 |

#### 2. Pledge Collateral

The user pledges some of the custody asset.

Pledging locks the asset as collateral. It does not spend it, transfer it, or sell it.

Example:

| Field                 | Before | After |
| --------------------- | -----: | ----: |
| LP custody balance    |    100 |   100 |
| Pledged LP collateral |      0 |    80 |
| Available LP custody  |    100 |    20 |
| USD debt              |      0 |     0 |

The user can still withdraw the unpledged 20 LP tokens. The pledged 80 are locked behind the credit position.

#### 3. Borrow Into A Vault

The user borrows USD-denominated credit against the pledged collateral.

That borrowed credit is deployed directly into an approved vault. It never touches free balance.

Example:

| Field             | Before |                    After |
| ----------------- | -----: | -----------------------: |
| Free USD balance  |    500 |                      500 |
| USD debt          |      0 |                    1,000 |
| Vault liquidity   | 10,000 |                   11,000 |
| User vault shares |      0 | New credit-funded shares |

The protocol records a credit-funded lot for the vault. That lot stores:

| Field            | Meaning                                               |
| ---------------- | ----------------------------------------------------- |
| Collateral asset | The asset whose credit position funded the borrow     |
| Vault ID         | The vault that received the borrowed credit           |
| Shares           | The vault shares minted from the borrow               |
| Funded USD       | The remaining borrowed basis attached to those shares |

#### 4. Vault Operates Normally

The vault can trade, earn yield, take losses, and move in share price as usual.

Credit does not change vault NAV math. It only changes how the user's shares are classified and how withdrawal proceeds flow.

#### 5. Withdraw Vault Shares

At withdrawal request time, the protocol records which type of shares the user is withdrawing:

| Source               | Meaning                                                  |
| -------------------- | -------------------------------------------------------- |
| Free shares          | Shares funded by user-supplied USD                       |
| Credit-funded shares | Shares funded by borrowed credit                         |
| Withdraw all         | The protocol derives both free and credit-funded sources |

This split is locked into the withdrawal record. It becomes the source of truth for cancellation and execution.

At execution time, the vault's final share price is used. For credit-funded shares:

`gross proceeds = credit-funded shares burned * final share price`

Then proceeds follow this repayment order:

1. Repay linked USD debt.
2. Pay leader fee only from surplus/profit.
3. Send remaining surplus to the user's free USD balance.

The user does not receive credit-funded withdrawal proceeds until the linked debt has been paid down first.

### Borrow Capacity Math

Each collateral asset has its own risk parameters.

| Parameter                    | Meaning                                                        |
| ---------------------------- | -------------------------------------------------------------- |
| Asset precision              | Maximum accepted decimal places for that asset                 |
| Max debt ratio               | Maximum borrow limit as a percentage of collateral value       |
| Intervention debt ratio      | Debt ratio where the position becomes liquidation-eligible     |
| Conversion discount          | Discount used when collateral is converted to repay debt       |
| Insurance Fund sale discount | Discount used when Insurance Fund collateral inventory is sold |

These parameters create a buffer between initial borrowing, intervention, and liquidation recovery.

| Layer                   | Purpose                                                                                      |
| ----------------------- | -------------------------------------------------------------------------------------------- |
| Max debt ratio          | Keeps new borrowing conservative                                                             |
| Intervention debt ratio | Defines when a position becomes unsafe enough for liquidation actions                        |
| Conversion discount     | Makes collateral conversion attractive enough for a payer while still reducing borrower debt |

The max debt ratio must be lower than the intervention ratio, otherwise a brand-new borrow could immediately become liquidation-eligible. The max debt ratio also needs to leave room for the conversion discount. If collateral can be converted at a 10% discount, then only 90% of its marked value is available during conversion. The initial borrow limit should sit below that discounted recovery value.

For a position:

`collateral value USD = pledged collateral amount * collateral price USD`

`debt ratio = USD debt / collateral value USD`

`max USD debt = collateral value USD * max debt ratio`

A borrow is allowed only if:

`post-borrow USD debt <= max USD debt`

A collateral release is allowed only if:

`remaining USD debt <= post-release collateral value USD * max debt ratio`

#### Example

Assume:

| Input                   |     Value |
| ----------------------- | --------: |
| Pledged LP tokens       |       100 |
| LP token price          |    20 USD |
| Collateral value        | 2,000 USD |
| Max debt ratio          |       50% |
| Intervention debt ratio |       75% |

Then:

`max debt = 2,000 * 0.50 = 1,000 USD`

The user can borrow up to 1,000 USD-denominated credit against this position.

Intervention begins when:

`debt > collateral value * intervention debt ratio`

In this example:

`intervention threshold = 2,000 * 0.75 = 1,500 USD`

Since the max borrow is 1,000 USD, the position starts safely below the intervention threshold. If the LP token price falls later, collateral value falls and the same debt can become liquidation-eligible.

#### Price Drop Example

The user borrowed 1,000 USD against 100 LP tokens.

| LP price | Collateral value | Debt ratio | Status                     |
| -------: | ---------------: | ---------: | -------------------------- |
|   20 USD |        2,000 USD |        50% | Active                     |
|   15 USD |        1,500 USD |     66.67% | Active but no new headroom |
|   13 USD |        1,300 USD |     76.92% | Intervention               |

Once intervention starts, the position cannot borrow more or release collateral until it is repaired.

### What Counts As Liquidation

Liquidation is not a single instant event like a perp liquidation. It is a staged recovery process.

The stages are:

1. Active
2. Intervention
3. Collateral conversion
4. Vault-share recovery
5. Insurance Fund no-vault recovery
6. Bad debt

The protocol moves through these stages only when needed.

### Stage 1: Active

A position is active when it is within allowed collateralization limits.

The user can:

| Action                     | Allowed?                      |
| -------------------------- | ----------------------------- |
| Pledge more collateral     | Yes                           |
| Repay debt                 | Yes                           |
| Borrow more USD            | Yes, if still within max debt |
| Release collateral         | Yes, if still within max debt |
| Withdraw unpledged custody | Yes                           |

### Stage 2: Intervention

Intervention begins when the debt ratio crosses the liquidation trigger:

`USD debt > collateral value USD * intervention debt ratio`

In intervention:

| Action                                        | Allowed? |
| --------------------------------------------- | -------- |
| Borrow more USD                               | No       |
| Release collateral                            | No       |
| Pledge more collateral                        | Yes      |
| Repay debt                                    | Yes      |
| Collateral price recovery can repair position | Yes      |
| Payer-funded collateral conversion            | Yes      |

Intervention does not automatically spend the Insurance Fund. It is a risk state: borrowing and collateral release are blocked, while repayment and recovery paths remain open.

The position can return to active if the debt ratio becomes healthy again:

`USD debt <= collateral value USD * max debt ratio`

That can happen through debt repayment, additional collateral, or collateral price recovery.

### Stage 3: Collateral Conversion

Collateral conversion is the first active liquidation mechanism.

A payer spends USD to buy collateral from an unhealthy position at a discount. The payment reduces the borrower's debt.

The payer can be another eligible wallet/account. The borrower does not need to approve the conversion once the position is liquidation-eligible.

Conversion price:

`conversion price = collateral price * (1 - conversion discount)`

Example:

| Input               |  Value |
| ------------------- | -----: |
| Collateral price    | 20 USD |
| Conversion discount |    10% |
| Conversion price    | 18 USD |

If the payer converts 10 LP tokens:

`payment = 10 * 18 = 180 USD`

The protocol applies:

| Party           | Effect                                                      |
| --------------- | ----------------------------------------------------------- |
| Payer           | Pays 180 USD, receives 10 LP tokens                         |
| Borrower        | Loses 10 pledged LP tokens, debt decreases by up to 180 USD |
| Credit facility | Receives debt repayment                                     |

If conversion proceeds exceed remaining debt because of rounding, the precision surplus goes to the borrower as free USD.

### Stage 4: Vault-Share Recovery

If pledged collateral cannot repair the debt because it is exhausted or too small to convert, the protocol can recover through the user's credit-funded vault shares.

This is important: credit-funded shares are not collateral for borrow capacity, but they are part of the debt recovery path.

Vault-share recovery follows the standard vault lifecycle:

1. Select credit-funded lots in a fixed vault order.
2. Estimate how many shares are needed using current vault share price.
3. Queue forced vault withdrawals.
4. Wait for the vault lockup.
5. Execute through the standard withdrawal path.
6. Use final proceeds to repay debt first.

Recovery does not skip lockup. It does not skip vault liquidity checks. It does not bypass the vault liquidity cascade.

If the vault has open positions and not enough free cash, the vault withdrawal cascade runs first. The final withdrawal payout uses the post-cascade share price, so the recovering shares bear the cost of forced liquidity just like ordinary vault withdrawals.

### Stage 5: No-Vault Debt Recovery

Sometimes the last credit-funded shares are burned and debt still remains.

At that point, the protocol checks whether any pledged collateral is still convertible. If so, automatic Insurance Fund conversion can run inside that same vault withdrawal execution.

This is narrow by design.

Automatic Insurance Fund conversion:

| Rule                                         | Meaning                                                       |
| -------------------------------------------- | ------------------------------------------------------------- |
| Only during no-vault-debt recovery           | The Insurance Fund is not a general liquidation backstop      |
| Uses the same conversion discount            | Same conversion price as payer-funded conversion              |
| Converts only what is needed when possible   | If enough collateral remains, it clears the debt              |
| Can convert all remaining collateral         | If collateral is insufficient, it converts what remains       |
| May make Insurance Fund USD balance negative | The IF absorbs treatment while receiving collateral inventory |

After conversion, the Insurance Fund owns the converted collateral inventory. That inventory can later be sold to users at the configured Insurance Fund sale discount.

### Stage 6: Bad Debt

Bad debt is recorded only when all recovery sources are gone.

Bad debt means:

`USD debt > 0`

and

`no convertible collateral proceeds remain`

and

`no recoverable credit-funded vault shares remain`

Bad debt does not disappear. It remains visible on the user's wallet/account and can be repaid later.

While bad debt is positive, the user is blocked from opening new credit.

When the user repays bad debt, the repayment reimburses Insurance Fund treatment rather than the secured credit facility.

### Vault Withdrawal Waterfall

A vault withdrawal can include free shares, credit-funded shares, or both.

#### Free Shares

Free shares behave like standard vault shares.

`free gross USD = free shares * final share price`

If the vault has leader fees:

`free leader fee = profit on free shares * leader fee rate`

`free user USD = free gross USD - free leader fee`

#### Credit-Funded Shares

Credit-funded shares go through the repayment order first.

`credit gross USD = credit-funded shares * final share price`

`debt repaid = min(credit gross USD, linked USD debt)`

`surplus = credit gross USD - debt repaid`

Leader fee is capped by surplus:

`credit leader fee = min(profit fee, surplus)`

`credit user USD = surplus - credit leader fee`

If the credit-funded withdrawal is not enough to repay debt, the user receives no USD from that credit-funded portion.

#### Example: Profitable Credit-Funded Withdrawal

Assume:

| Input                          |     Value |
| ------------------------------ | --------: |
| Credit-funded shares withdrawn |       100 |
| Final share price              |    12 USD |
| Gross proceeds                 | 1,200 USD |
| Linked debt                    | 1,000 USD |
| Surplus before fee             |   200 USD |

The first 1,000 USD flows back to repay the debt.

The remaining 200 USD is surplus. If leader fee is 10% of profit and profit fee calculates to 20 USD, then:

| Recipient        |    Amount |
| ---------------- | --------: |
| Debt repayment   | 1,000 USD |
| Vault leader fee |    20 USD |
| User free USD    |   180 USD |

#### Example: Loss-Making Credit-Funded Withdrawal

Assume:

| Input                          |     Value |
| ------------------------------ | --------: |
| Credit-funded shares withdrawn |       100 |
| Final share price              |     8 USD |
| Gross proceeds                 |   800 USD |
| Linked debt                    | 1,000 USD |

The full 800 USD flows back to debt repayment.

The user receives 0 USD from that credit-funded portion, and 200 USD of debt remains.

If no other credit-funded shares or convertible collateral remain, that residual can become bad debt.

### Protocol Accounting

The protocol tracks secured debt with a credit facility ledger.

When credit is borrowed:

`credit facility balance decreases`

`borrower credit position debt increases`

`vault liquidity increases`

For active secured debt, the accounting invariant is:

`credit facility balance + secured USD debt = 0`

Example:

| Item                    | Amount |
| ----------------------- | -----: |
| Credit facility balance | -1,000 |
| Borrower secured debt   |  1,000 |
| Sum                     |      0 |

When debt is repaid:

`credit facility balance increases`

`borrower credit position debt decreases`

Bad debt is moved out of the secured credit facility and into Insurance Fund treatment.

### LP Token Support

LP tokens fit naturally into this design because they are collateral assets with protocol-provided USD prices.

For the current version, SundaeSwap USDCx/USDM LP tokens are mapped to a named collateral asset:

`LP_SUNDAE_USDCx_USDM`

The important moving pieces are:

| Piece                   | Purpose                                                                                  |
| ----------------------- | ---------------------------------------------------------------------------------------- |
| Custody asset mapping   | Converts chain-facing token symbols and raw token amounts into protocol custody balances |
| Collateral asset config | Defines precision, max debt ratio, intervention ratio, and liquidation discounts         |
| Collateral price        | Gives the LP token a USD value for borrow capacity and risk checks                       |
| Approved vault list     | Controls where borrowed credit can be deployed                                           |

If any of those are missing, the asset cannot safely support collateralized borrowing.

### Prices And Risk Triggers

Collateral price is what turns a token amount into USD borrowing power.

The protocol rechecks position health when relevant state changes, such as:

| Trigger                              | Effect                                         |
| ------------------------------------ | ---------------------------------------------- |
| Collateral price update              | Rechecks positions using that collateral asset |
| Risk parameter update                | Rechecks affected assets                       |
| Portfolio action                     | Rechecks touched positions                     |
| Collateral conversion                | Rechecks target position                       |
| Vault withdrawal execution or cancel | Rechecks affected credit-funded lots           |

Users do not need to submit a liquidation command. The protocol checks position health.

In the current version, passive vault NAV movement by itself does not trigger liquidation. Vault share value matters when shares are withdrawn or recovered.

### Insurance Fund Inventory

When the Insurance Fund converts collateral, it receives the collateral asset as inventory.

That inventory can later be sold back into the market through the protocol.

Sale price:

`sale price = collateral price * (1 - Insurance Fund sale discount)`

A buyer pays free USD and receives the collateral into custody balance. From there, the buyer can withdraw it or pledge it like any other supported collateral asset.

### FAQ

| Questions                                                     | Answer                                                                              |
| ------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Can I withdraw pledged collateral?                            | No, only unpledged custody is withdrawable.                                         |
| Can I borrow USD and use it elsewhere?                        | No, borrowed credit can only be deployed into approved vaults.                      |
| Do credit-funded shares count as collateral?                  | No, they can be used to repay debt, but they do not increase borrow capacity.       |
| What happens when I withdraw credit-funded shares?            | Proceeds repay debt first; only surplus reaches free USD.                           |
| Can I repair a risky position?                                | Yes, by repaying debt, pledging more collateral, or benefiting from price recovery. |
| Can someone else convert my collateral?                       | Yes, once the position is liquidation-eligible.                                     |
| Does the Insurance Fund immediately bail out risky positions? | No, it only acts automatically in narrow no-vault-debt recovery.                    |
| Does bad debt vanish?                                         | No, it remains repayable and blocks new credit while positive.                      |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.strikefinance.org/perpetuals/vaults/credit-system.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.