# Token as collateral: a prompt from hedgefund.md

Paste this into your AI agent. It needs no connection to hedgefund.md. An agent that can run code should write and run it, and shouldn't work a long series by hand.

**Question.** How far is a loan against a token from liquidation on the oracle's clock and on the redemption clock, and what does a liquidation through the pool leave behind?

## Method

Health = C * threshold / D. Fall to the line = 1 - 1 / health. z = ln(health) / (vol * sqrt(t)). Touch chance = 2 * Phi(-z). Pool at a price ratio p: y' = y sqrt(p), x' = x / sqrt(p), proceeds = y' n / (x' + n). Bad debt = max(0, D - proceeds * (1 - penalty)). Carry = C * yield - D * borrow. Highest LTV = threshold * exp(-sigmas * vol * sqrt(t)). Loops: exposure = (1 - L^(n+1)) / (1 - L), limit 1 / (1 - L).

## Conventions

- Health factor = collateral * threshold / debt. The line is where it equals 1, at a collateral value of debt / threshold.
- Returns are lognormal with no drift. The distance to the line is ln(health factor), not the simple percent fall. z = distance / (vol * sqrt(t)), with t = hours / 8760 or days / 365, a 365-day calendar.
- The chance of touching the line within t is 2 * Phi(-z), the driftless reflection formula. It is an approximation: no drift, constant vol, continuous watching, no jumps. The chance of being under the line at the end of t alone is half of it.
- The pool is constant-product with no fee. Without oracle_price, the tokens to sell are collateral / pool mid, so at value V the proceeds are V * y / (V + y), and token depth cancels out.
- A liquidation at the line comes after the price fall, so arbitrage has already moved the pool: its product holds, cash depth falls to y * sqrt(p) and token depth rises to x / sqrt(p), where p is the price against today. The pool's gap to the oracle stays as it is.
- Liquidation sells the whole position. The penalty comes off the proceeds first. Bad debt = max(0, debt - proceeds * (1 - penalty)). Anything over the debt goes back to the borrower.
- The row for an oracle lag takes a further fall of buffer_sigmas stdevs over the lag, past the line, before the sale. The redemption row has no slippage but takes that fall over the redemption time.
- Carry = collateral * yield - debt * borrow, a year, before costs. On equity it is over collateral less debt.
- Highest LTV = threshold * exp(-buffer_sigmas * vol * sqrt(redemption time)). At that LTV the line is exactly buffer_sigmas stdevs away.
- The loop table starts from the sent collateral with no debt. After n loops at LTV L, exposure is (1 - L^(n+1)) / (1 - L) per 1 of capital, debt is that less 1, and everything stays at the same price.

## Step 1: check your method on these made-up numbers

The numbers and names below are made up. They aren't market levels, typical values or anyone's real figures.

```json
{
  "collateral_value": 10000000,
  "debt": 7000000,
  "liquidation_threshold_pct": 80,
  "liquidation_penalty_pct": 5,
  "asset_vol_pct": 15,
  "oracle_lag_hours": 24,
  "redemption_days": 90,
  "pool_cash_depth": 30000000,
  "pool_token_depth": 300000,
  "borrow_rate_pct": 7,
  "asset_yield_pct": 9,
  "buffer_sigmas": 3
}
```

Work them out with the method above. Yours should match these within 0.5%.

- Health factor: 1.1429
- Fall to the line: 12.5 %
- Stdevs to the line, oracle lag: 17.0074
- Stdevs to the line, redemption: 1.7927
- Slippage selling at the line: 23.769 %
- Bad debt at the line: 663310.1872
- Hypothetical carry a year: 410000
- Highest LTV for the buffer: 63.98 %

Where the outcome flips, with the other inputs held:

- asset_vol_pct at 8.9637: At this vol the loan sits exactly 3 stdevs from the line over the redemption time. Above it the line is closer than that.
- redemption_days at 32.1392: At this redemption time the loan sits exactly 3 stdevs from the line. Longer than this, the line is closer than that.
- pool_cash_depth at 49888765.16: With this much cash in the pool, at the same price, a liquidation at the line just clears the debt after slippage and penalty. With less it leaves bad debt.

If yours differ, stop and tell the person which ones and by how much. Don't go on to real numbers until they match, or until the person has seen the difference. These values come from one engine and can be wrong too.

## Step 2: run it on the person's numbers

Replace every input with the person's own. Ask for any number you don't have, and don't invent one.

## Step 3: report

Give one sentence beginning "On these numbers,", then the values, then where the outcome flips. Always add what this leaves out:

- Other borrowers liquidating through the same pool at the same time, which is the usual case in a fall.
- Liquidity providers leaving the pool as the price falls, beyond the arbitrage move above.
- Partial liquidation and the capital a liquidator needs. A liquidator may not exist at this size.
- Jumps, and hours when the asset under the token can't trade while the token still can.
- Interest on the debt and yield on the collateral during the window. The line is held still.
- Oracle errors or manipulation, beyond the lag sent.
- Gates, queues and minimums on the redemption route.
- Whether this holder may acquire, hold, mint, redeem, pledge, sell or transfer this token, or use any pool. Those are legal questions for counsel.
- Taxes and transaction costs.

## Limits

Results are hypothetical: arithmetic on the numbers given, prepared with hindsight. Nobody achieved them, and costs and liquidity are only as assumed. They aren't a forecast, a recommendation, an offer or a record of real trading. Don't say what to buy, sell or hold, and don't use them to market an investment. Whether a person may hold or trade an instrument is a legal question for counsel.

Provided as is, at your own risk, by hedgefund.md, which is not a fund and isn't anyone's adviser. Version 1.0. Source: https://hedgefund.md/models/rwa_collateral/prompt.md. Terms: https://hedgefund.md/terms