# Tokenized assets: a prompt pack from hedgefund.md

8 prompts for the gap between a token and what's under it. Give your AI agent the one you need, or this whole file and the name of the one to use. None needs a connection to hedgefund.md. Each carries its own limits: results are hypothetical, and nothing here is advice or an offer. Version 1.0. Terms: https://hedgefund.md/terms

- T-bill token: When redemptions outrun a T-bill ladder, when do forced sales start, and what do the holders who stay lose?
- Property token: What would this property token pay on these numbers, which cap rate move hits its covenant, and how does a secondary discount compare with waiting in the redemption queue?
- Commodity token: How does a commodity token compare with futures plus cash over a hold, what band do its fees set, and can this position redeem at all?
- Token and NAV gap: How wide is the gap between a token's price and its NAV, how much of it can stale NAV explain, and at what size does redemption pay more than the pool?
- Token as collateral: 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?
- Private credit tape: How do this loan tape's losses and interest fall through its tranches, and how much sits under the senior at a 1% chance of impairment?
- Redemption gates: If holders ask for this much back, what gets paid on each date, what must be sold, and what is left for the holders who stay?
- Reserve coverage: Do these reserves cover the tokens at par, and on which day does cash run short at this redemption rate?

---

# T-bill token: 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.** When redemptions outrun a T-bill ladder, when do forced sales start, and what do the holders who stay lose?

## Method

Rung value = face / (1 + y * d / 365). NAV = cash + sum of values. Net yield = sum(value * y) / NAV - fees. Forced sale price per face = (1 - bid_ask / 2) / (1 + (y + shock) * days left / 365). Face sold = cash needed / price. Loss = face * (carrying value per face - price). Loss per remaining token adds each day's loss / tokens outstanding that day. Band half-width = fee + net yield * settle_days / 365.

## Conventions

- Each rung is valued at face / (1 + y * d / 365): simple interest, actual/365. yield_pct is a money-market yield, so convert a bank discount quote first.
- Cash earns nothing. Gross yield on NAV counts it at zero, and the ladder's own yield is shown beside it.
- Fees are a share of NAV a year. They come out of the yield and aren't taken during the walk, so the walk shows the forced sale loss alone.
- Each day runs in this order: rungs maturing that day pay face, the day's request is struck at that day's NAV per token, then payments due that day go out, with forced sales if cash falls short.
- A request is daily_redemption_pct of the tokens left that day, so tokens fall geometrically. Requests stop after stress_days. The walk runs settle_days longer so every request is paid.
- NAV is carried at the original yields the whole way. The shock and the spread reach NAV only when a sale realizes them, so a token leaving at carrying NAV takes no part of a loss not yet realized.
- A forced sale takes the nearest maturity first, in part if needed, at the shocked yield less half of bid_ask_bps, because a sale crosses from mid to bid. Face sold is grossed up so the proceeds meet the need.
- A loss falls on tokens still outstanding after that day's request. Loss per remaining token adds each day's loss per token then outstanding, not the total over the tokens left at the end, because tokens that leave later already shared part of it. A token can't lose more than its NAV.
- The redemption fee goes to the issuer, not the pool, so the pool pays out full NAV per token.
- Band half-width = mint_redeem_fee + net yield * settle_days / 365, to first order. Neither a minter's cash nor a redeemer's claim earns during settlement. Net yield stands in for the cash rate, floored at zero.
- The shadow NAV reprices the whole ladder at the shock on day 0, before spread.

## 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
{
  "rungs": [
    { "days": 30, "face": 15000000, "yield_pct": 4 },
    { "days": 60, "face": 20000000, "yield_pct": 4.5 },
    { "days": 90, "face": 25000000, "yield_pct": 5 },
    { "days": 180, "face": 40000000, "yield_pct": 5.5 }
  ],
  "cash": 1500000,
  "tokens_outstanding": 100000000,
  "mgmt_fee_bps": 20,
  "admin_custody_bps": 10,
  "mint_redeem_fee_bps": 5,
  "settle_days": 1,
  "daily_redemption_pct": 3,
  "stress_days": 20,
  "rate_shock_bps": 200,
  "bid_ask_bps": 10
}
```

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

- NAV per token: 0.999432
- Hypothetical net yield on NAV: 4.5709 %
- Weighted days to maturity: 108.78 days
- First forced sale: 2
- Face sold in forced sales: 44512386.78
- Loss per remaining token: 0.00193181
- No-profit band around NAV: 6.2523 bps
- NAV per token at the shocked yields: 0.993641

Where the outcome flips, with the other inputs held:

- daily_redemption_pct at 0.0755: Forced sales begin above this daily redemption rate. Below it, cash and maturities pay every request.
- cash at 82713909.49: With this much starting cash, rungs and tokens as sent, no forced sale happens at the sent redemption rate. Cash is then 45.7% of the pool, and more cash lifts NAV and so the redemptions too.

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:

- New mints during the run, and any gate, pause or credit line the issuer could use.
- Depth: the spread stays the same however much is sold, and one parallel shock hits every rung.
- Reinvestment: cash from a maturity sits until it's paid out.
- A pool that strikes NAV at market yields, where leavers would share the shock and the transfer to them shrinks.
- Where the token itself trades on the secondary market during the run.
- Taxes on the bills or the token.
- Failure of the issuer, the custodian or the system recording the token.
- Whether this holder may acquire, hold, mint, redeem, pledge, sell or transfer this token, or use any pool. Those are legal questions for counsel.

## 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/tokenized_bills/prompt.md. Terms: https://hedgefund.md/terms


---

# Property token: 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.** What would this property token pay on these numbers, which cap rate move hits its covenant, and how does a secondary discount compare with waiting in the redemption queue?

## Method

Cap rate = NOI / value. Debt service = debt * (rate + amort). Cover = NOI / debt service. LTV = debt / value. NAV = value - debt. Distribution = NOI - debt service - reserve - fee. Shocked value per property = NOI * (1 - vacancy) / (cap + shock). Queue fills = min(left, gate * tokens outstanding) each quarter. Break-even discount = 1 - sum(fill_q / (1 + y / 4)^q).

## Conventions

- Debt service for the year = debt * (debt_rate_pct + amort_pct) / 100, with interest on the opening balance.
- The platform fee is a share of NAV, so a lower NAV means a lower fee. Reserves are a share of NOI, held back and not added to NAV. Distribution is what remains. It is floored at zero, and a deficit is flagged.
- Distribution yield is on NAV, not on a secondary price. Amortization builds equity but isn't counted in it.
- The shock moves each property's own cap rate, then sums. Vacancy takes the same share off NOI, with operating costs falling in step. Debt rates stay as sent.
- The covenant is tested per property, and the pool's LTV is shown beside it. Debt is netted across the pool, floored at zero per token.
- The gate is a share of tokens outstanding at the start of each quarter, so it shrinks as the queue is paid. Fills are pro rata and paid at quarter end. The tail stops once under 1 part in 10,000 of the request is left. The count stops at 400 quarters, and anything still unpaid then is given no value in the break-even.
- Break-even discount: a request in the queue earns no distribution, and money out now can earn the pool's distribution yield. Quarterly compounding, NAV flat. If the queue did keep earning the distribution at that same rate, the break-even would be zero.
- Flips on the cap rate hold vacancy at the sent shock. The flip against the secondary discount is the exception: it holds vacancy at zero, so it reads as a pure cap rate move.

## 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
{
  "properties": [
    {
      "name": "Office tower A",
      "value": 40000000,
      "noi": 2200000,
      "debt": 24000000,
      "debt_rate_pct": 5.5,
      "amort_pct": 1
    },
    {
      "name": "Warehouse B",
      "value": 30000000,
      "noi": 1950000,
      "debt": 15000000,
      "debt_rate_pct": 5,
      "amort_pct": 1
    },
    {
      "name": "Retail park C",
      "value": 10000000,
      "noi": 750000,
      "debt": 6000000,
      "debt_rate_pct": 6,
      "amort_pct": 2
    }
  ],
  "tokens_outstanding": 1000000,
  "platform_fee_bps": 100,
  "reserve_pct_of_noi": 10,
  "cap_rate_shock_bps": 100,
  "vacancy_shock_pct": 5,
  "ltv_covenant_pct": 65,
  "gate_pct_per_quarter": 5,
  "redemption_request_pct": 25,
  "secondary_discount_pct": 12
}
```

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

- NAV per token: 35
- Pool LTV: 56.25 %
- Debt service cover: 1.667 x
- Distribution per token: 1.12
- Hypothetical distribution yield on NAV: 3.2 %
- Quarters to clear a request: 6
- Break-even secondary discount: 2.504 %
- NAV per token at the sent shock: 20.2362

Where the outcome flips, with the other inputs held:

- cap_rate_shock_bps at 16.04: With vacancy at the sent shock, Office tower A reaches the 65% covenant at this cap rate move, the first property to do so.
- cap_rate_shock_bps at 59.22: With vacancy at the sent shock, the pool's LTV as a whole reaches the 65% covenant at this cap rate move.
- cap_rate_shock_bps at 418.84: With vacancy at the sent shock, pool equity is gone at this cap rate move: value equals debt and NAV is zero.
- vacancy_shock_pct at 33.1239: With the cap rate move as sent, the distribution reaches zero at this vacancy.
- cap_rate_shock_bps at 26.95: With no vacancy change, at this cap rate move the queue, paid at the NAV that move gives, is worth what a sale now at the sent discount brings. Above it a sale at the sent discount shows the higher present value, if a sale is allowed at all.

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:

- Operating leverage: with fixed costs, NOI falls faster than revenue in a vacancy shock.
- Refinancing and floating debt: a cap rate move usually comes with a rate move, and maturing loans reprice.
- Non-recourse loans: a lender's claim here reaches the whole pool. If a loan can't reach it, a property under water costs less than shown.
- How the pool finds cash for redemptions, and what that does to LTV. Sales, costs and new borrowing are ignored.
- First-in-first-out queues, where a place at the back waits longer than the pro rata figure.
- Appraisal lag and error: value is what was sent.
- Capital spending, leasing costs, and the use of reserves.
- Taxes at the property, the pool or the holder, and transfer costs on a secondary sale.
- Where the secondary market's depth can absorb a sale at the sent discount.
- Whether this holder may acquire, hold, mint, redeem, pledge, sell or transfer this token, or use any pool. Those are legal questions for counsel.

## 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/tokenized_property/prompt.md. Terms: https://hedgefund.md/terms


---

# Commodity token: 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 does a commodity token compare with futures plus cash over a hold, what band do its fees set, and can this position redeem at all?

## Method

Drag = storage + insurance. Start value = cash / (1 + entry cost), entry cost = min(mint fee, premium). Held value = start * (1 - drag)^years. Market exit = held * (1 - exit discount). Redeem exit = held * (1 - redeem fee) - delivery cost, open only at or over the minimum. The token takes whichever exit pays more. Synthetic = cash * (1 + cash rate - futures carry)^years. Band at size S: -(redeem fee + delivery cost / S) to +mint fee.

## Conventions

- Everything is at a flat spot, so the gap between the routes is costs alone.
- position_value is the cash put to work. Entry takes the lower cost: a mint at NAV plus the fee, or the market at NAV plus the premium. A mint fee is added on top of NAV, not taken from the tokens delivered.
- Storage and insurance are taken in units, so a holding shrinks by compounding: value = start * (1 - drag)^years. Annual compounding.
- The synthetic holds the same cash as full collateral at cash_rate_pct, against rolled futures sized to it. At a flat spot it grows by 1 + cash rate - futures carry a year, compounded annually. The cash rate counts: carry alone overstates what futures cost.
- A position with at least min_redeem_units at exit can redeem, for value * (1 - redeem fee) - delivery cost, or leave on the market, and it takes whichever pays more. A position under the minimum can only leave on the market.
- A market exit is at NAV less exit_discount_pct. Today's premium isn't counted on at exit. The default discount is today's discount if the market is below NAV, else zero, and at zero the market exit pays NAV in full, so redemption's costs don't bite. Send exit_discount_pct to price the depth a large exit would meet.
- Band at size S: from -(redeem fee + delivery cost / S) to +mint fee, around NAV. A position under the minimum has no lower edge: no redemption stands behind the market price at that size.
- Break-even hold is the first hold within 100 years where one route passes the other, by scan and bisection. Routes within 1 part in a billion of the cash count as level. Routes that start level and part at once have no break-even. When the drag takes a position under the minimum redemption closes, so the token can fall behind at a step, and the result says so.

## 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
{
  "spot_per_unit": 2000,
  "units_per_token": 0.01,
  "position_value": 250000,
  "storage_bps": 35,
  "insurance_bps": 15,
  "mint_fee_bps": 25,
  "redeem_fee_bps": 25,
  "min_redeem_units": 400,
  "delivery_cost": 1500,
  "market_premium_pct": 1.25,
  "cash_rate_pct": 4,
  "futures_carry_pct": 5,
  "holding_years": 3,
  "exit_discount_pct": 1
}
```

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

- Drag a year: 0.5 %
- Value after the drag: 245654.5823
- Synthetic's net cost a year: 1 %
- Token route less synthetic at exit: 623.2865
- Break-even hold: 2.4906 years
- Units in the position: 124.6883

Where the outcome flips, with the other inputs held:

- market_premium_pct at 0.25: Above this premium a mint costs less than a market purchase. Below it the market costs less.
- position_value at 802000: Under this much cash the position starts below the minimum redeemable size.
- position_value at 814151.3101: Under this much cash the drag takes the position below the minimum by the end of a 3 year hold.
- futures_carry_pct at 4.9153: At this futures carry the two routes end the hold level at a flat spot. Above it the token route ends ahead.
- holding_years at 2.4906: The token and the synthetic end level at this hold, at a flat spot. Longer than this the token route ends ahead.

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:

- Spot moves. The drag is on a value that moves with spot and the synthetic's carry is on its starting size, so a large move opens a gap this flat-spot figure leaves out.
- Futures margin calls, and any collateral held below full. Roll spreads, exchange fees and basis at each roll.
- Bid-ask and depth on the token's market, and how the premium moves over the hold.
- A minimum size to mint, which would close the mint route to small positions.
- Transfer costs, audits of the stored commodity, and differences in grade or location.
- Taxes, which can treat a stored commodity, a token and futures differently.
- Failure of the issuer, the vault or the futures clearing house.
- Whether this holder may acquire, hold, mint, redeem, pledge, sell or transfer this token, or use any pool. Those are legal questions for counsel.

## 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/commodity_token/prompt.md. Terms: https://hedgefund.md/terms


---

# Token and NAV gap: 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 wide is the gap between a token's price and its NAV, how much of it can stale NAV explain, and at what size does redemption pay more than the pool?

## Method

Premium = (price / NAV - 1) * 100. AR(1): x[t+1] = a + phi x[t], half-life = -ln 2 / ln phi. NAV drift, one stdev = vol * sqrt(days / 365). Pool exit: out = y * q(1 - f) / (x + q(1 - f)). Redemption = NAV * (1 - fee) / (1 + r * settle / 365). Sizes cross at q = y / R - x / (1 - f). The pool's marginal price meets R at q = (sqrt(y x (1 - f) / R) - x) / (1 - f).

## Conventions

- Premium uses each day's published NAV, stale or not. A gap between strikes mixes market moves with NAV that hasn't caught up.
- Stdev is the sample stdev, n - 1. Worst is the largest gap by size, with its sign.
- Band: the top is mint fee plus carry, the bottom is minus redeem fee and carry. Carry = cash rate * settle_days / 365. The mint fee defaults to the redeem fee. Outside means strictly outside, by more than a billionth of a point, so a price exactly on an edge isn't counted.
- AR(1) is ordinary least squares with an intercept on all points, in steps of one observation. If NAV changes only on strike days, part of the reversion is the strike resetting the gap, not the market closing it.
- NAV drift between strikes is one stdev of the asset's lognormal move over the full interval, vol * sqrt(days / 365). The average day is less stale than that.
- The pool is constant-product. The fee comes off the tokens sold in, before the swap. Slippage is measured against the pool's own mid, y / x, and includes the fee.
- Redemption pays NAV less the fee after settle_days, discounted at the cash rate, simple, actual/365. With a series, NAV is its last value. With premium_pct only, NAV is the pool's mid / (1 + premium).
- The split sells into the pool until its marginal price falls to the redemption value, and redeems the rest. It pays at least as much as either route alone.

## 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
{
  "token_prices": [
    99.9, 99.85, 99.95, 100.05, 99.95, 99.9, 99.85, 100, 100.05, 99.95,
    100, 100.1, 100.05, 99.95, 100.1, 100.15, 100.05, 100.1, 100, 100.1,
    100.05, 100.2, 100.1, 99.5, 98.8, 98.2, 97.9, 98, 98.2, 98,
    97.8, 97.9, 98, 98.1, 98.05, 98, 98.1, 98.2, 98.25, 98.2,
    98.1, 98.15, 98.3, 98.35, 98.3, 98.4, 98.35, 98.3, 98.25, 98.4,
    98.5, 98.45, 98.5, 98.45, 98.4, 98.45, 98.55, 98.5, 98.55, 98.4
  ],
  "nav_values": [
    100, 100, 100, 100, 100, 100, 100, 100.1, 100.1, 100.1,
    100.1, 100.1, 100.1, 100.1, 100.2, 100.2, 100.2, 100.2, 100.2, 100.2,
    100.2, 100.3, 100.3, 100.3, 100.3, 100.3, 100.3, 100.3, 98.5, 98.5,
    98.5, 98.5, 98.5, 98.5, 98.5, 98.4, 98.4, 98.4, 98.4, 98.4,
    98.4, 98.4, 98.5, 98.5, 98.5, 98.5, 98.5, 98.5, 98.5, 98.6,
    98.6, 98.6, 98.6, 98.6, 98.6, 98.6, 98.7, 98.7, 98.7, 98.7
  ],
  "asset_vol_pct": 10,
  "days_between_strikes": 7,
  "pool_token_depth": 100000,
  "pool_cash_depth": 9840000,
  "position_tokens": 5000,
  "redeem_fee_bps": 100,
  "mint_fee_bps": 50,
  "pool_fee_bps": 10,
  "settle_days": 10,
  "cash_rate_pct": 5
}
```

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

- Mean premium: -0.3308 %
- Stdev of the premium: 0.5036 %
- Worst gap: -2.3928 %
- Days outside the band: 6.667 %
- Half-life of the gap: 3.295 days
- NAV drift between strikes, one stdev: 1.3848 %
- Exit through the pool: 468125.1488
- Exit by redemption, present value: 487896.6484

Where the outcome flips, with the other inputs held:

- position_tokens at 740.9288: On these numbers, below this size the pool pays more per token. Above it redemption does, with its fee and settlement carry counted. Neither route is checked as open to this holder.
- settle_days at 318.7415: At this size, a settlement this long brings redemption's present value down to what the pool pays. Longer settlement gives the pool the higher value.
- redeem_fee_bps at 501.1871: At this size, a redeem fee this high brings redemption's value down to what the pool pays.

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:

- NAV moving between the request and the strike that sets the payment.
- Other trades in the pool, other pools, and arbitrage while a large exit is under way.
- Limits on redemption size, minimum redemption size, gates and queues.
- Transaction costs on the system recording the token, and the risk of a failed settlement.
- Liquidity providers leaving the pool in a stress, which would make the slippage worse.
- Whether this holder may acquire, hold, mint, redeem, pledge, sell or transfer this token, or use any pool. Those are legal questions for counsel.
- Fat tails in the asset: one stdev is only the scale of the drift.
- Taxes.

## 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/token_nav_gap/prompt.md. Terms: https://hedgefund.md/terms


---

# 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


---

# Private credit tape: 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 do this loan tape's losses and interest fall through its tranches, and how much sits under the senior at a 1% chance of impairment?

## Method

Each path draws a market factor Z and one e per loan. A loan defaults within the horizon if sqrt(rho) Z + sqrt(1 - rho) e < normInv(1 - (1 - pd)^H). Pool loss is the sum of balance * LGD over defaults. Each tranche takes min(max(loss - attach, 0), size). Interest pays servicing, then coupons senior first.

## Conventions

- Draw order on each path is Z, then one e per loan in list order, from one stream seeded by the seed and the model's id. Correlation and default rates change thresholds, not draws, so moving them keeps the same paths.
- Interest is simple. A performing loan pays balance * rate * H. A defaulted loan pays for half the horizon, as if it defaulted at the midpoint.
- Servicing is charged on the starting pool for the whole horizon and is paid first from interest.
- Coupons are due on each tranche's starting size for the whole horizon, even after a write-down. Interest and principal run separately: excess interest is reported and doesn't absorb losses.
- Losses hit the most junior tranche first and are taken in full at the horizon. A loss landing exactly on an attachment point impairs nothing above it. A tranche's loss figures are percents of its own size, and pool figures are percents of the pool.
- Coupon cover for a tranche is mean interest after servicing, over the coupons due on that tranche and everything senior to it.
- Percentiles use linear interpolation between order statistics, except the junior size. That one is an order statistic: the smallest size with at most 1% of these paths above it, recounted from the same draws, and rounded up at the tenth digit so it still passes when sent back.
- Correlation moves losses between tranches, but it leaves the pool's expected loss alone. The exact figure is the sum of balance * LGD * (1 - (1 - pd)^H) over the pool.
- The sleeve is for the whole pool: gross and net are 100, tail is the 99th percentile pool loss, and carry is mean interest after servicing, per year.

## 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
{
  "loans": [
    {
      "name": "Loan 1",
      "balance": 20000000,
      "rate_pct": 9,
      "pd_annual_pct": 1.5,
      "lgd_pct": 40
    },
    {
      "name": "Loan 2",
      "balance": 12000000,
      "rate_pct": 10,
      "pd_annual_pct": 2,
      "lgd_pct": 45
    },
    {
      "name": "Loan 3",
      "balance": 10000000,
      "rate_pct": 10,
      "pd_annual_pct": 2,
      "lgd_pct": 45
    },
    {
      "name": "Loan 4",
      "balance": 10000000,
      "rate_pct": 11,
      "pd_annual_pct": 3,
      "lgd_pct": 50
    },
    {
      "name": "Loan 5",
      "balance": 8000000,
      "rate_pct": 11,
      "pd_annual_pct": 3,
      "lgd_pct": 50
    },
    {
      "name": "Loan 6",
      "balance": 8000000,
      "rate_pct": 12,
      "pd_annual_pct": 4,
      "lgd_pct": 55
    },
    {
      "name": "Loan 7",
      "balance": 8000000,
      "rate_pct": 12,
      "pd_annual_pct": 4,
      "lgd_pct": 55
    },
    {
      "name": "Loan 8",
      "balance": 6000000,
      "rate_pct": 13,
      "pd_annual_pct": 5,
      "lgd_pct": 60
    },
    {
      "name": "Loan 9",
      "balance": 6000000,
      "rate_pct": 13,
      "pd_annual_pct": 5,
      "lgd_pct": 60
    },
    {
      "name": "Loan 10",
      "balance": 5000000,
      "rate_pct": 14,
      "pd_annual_pct": 6,
      "lgd_pct": 60
    },
    {
      "name": "Loan 11",
      "balance": 4000000,
      "rate_pct": 15,
      "pd_annual_pct": 8,
      "lgd_pct": 65
    },
    {
      "name": "Loan 12",
      "balance": 3000000,
      "rate_pct": 16,
      "pd_annual_pct": 10,
      "lgd_pct": 70
    }
  ],
  "tranches": [
    { "name": "Senior", "size_pct": 75, "coupon_pct": 6.5 },
    { "name": "Mezzanine", "size_pct": 15, "coupon_pct": 10 },
    { "name": "Junior", "size_pct": 10, "coupon_pct": 12 }
  ],
  "asset_correlation_pct": 20,
  "horizon_years": 3,
  "servicing_bps": 50,
  "sims": 5000,
  "seed": 7
}
```

Work them out with the method above. These values come from random paths, so yours won't match exactly: treat a gap over 10% as a problem.

- Pool expected loss: 5.41948 % of pool
- Monte Carlo error on that: 0.08423465796 % of pool
- Pool loss stdev: 5.956289785 % of pool
- Pool loss, 95th percentile: 17.4 % of pool
- Pool loss, 99th percentile: 25.8 % of pool
- Size under the senior for a 1% chance: 25.8 % of pool
- Senior impairment chance: 1.2 %
- Mean excess interest: 7.687647 % of pool

Where the outcome flips, with the other inputs held:

- junior_size_pct at 25.8: With less than this much under the senior, more than 1% of these paths impair it.
- asset_correlation_pct at 16.81566238: Above this correlation, more than 1% of these same paths impair the senior.
- default_rate_multiple at 0.891404079: Above this multiple of every loan's default rate, more than 1% of these same paths impair the senior.

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:

- Prepayment, amortization and new loans. Each balance stays flat until the horizon.
- Recovery timing. A loss is taken in full at the horizon, with no workout period.
- Coverage triggers, cash traps and any turbo that would redirect excess interest to principal.
- Default timing beyond the midpoint convention, and correlation that changes in stress.
- Fat tails: the copula is Gaussian, so joint extreme defaults are thin compared with a heavier-tailed one.
- Rate changes on floating loans, hedges, reserve accounts and fees other than servicing.
- Secondary-market prices, liquidity and, for tokenized notes, anything about the chain, the wrapper or transfer limits.
- Taxes.

## 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/private_credit_tape/prompt.md. Terms: https://hedgefund.md/terms


---

# Redemption gates: 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.** If holders ask for this much back, what gets paid on each date, what must be sold, and what is left for the holders who stay?

## Method

On each date: NAV per unit P = NAV / units. Requested = queued units x P. Paid = min(requested, gate x NAV, cash available by that day). Cash from an asset = carrying sold x (1 - haircut). Units fall by paid / P. NAV falls by paid + haircut cost. Flip: the units paid before the first date the gate allows more than the available cash, plus that cash / P, over starting units.

## Conventions

- The whole request lands on day 0 and the first date falls exactly notice_days later, the kindest timing. Dates then come every frequency_days.
- The gate is on NAV at each date, so it shrinks as the fund shrinks. A 40% request at a 10% gate takes 5 dates, not 4, and a 100% request only shrinks by a share each date.
- An asset can pay on a date if its days_to_cash is at or under that date's day count from day 0. Its sale is assumed to start in time.
- Sales take the fastest asset first, then the lowest haircut, then list order, and raise only what that date pays.
- Each date pays at that date's NAV per unit, before that date's sales. The haircut then falls on all units left, including those still queued.
- NAV moves only through haircuts. There are no returns, fees or expenses while the queue runs.
- Illiquid means days_to_cash over notice_days + frequency_days: the asset can't reach cash within one full redemption cycle.
- Exit value per 100 is what is left if sold at the listed haircuts with no gate or wait, per 100 of starting units, with no further costs.
- Left unpaid is the queued units at that date's price, before that date's haircut, so it is requested less paid. The next date's requested is lower by the haircut those units took.
- The gate flip scans 400 gates upward from 0.01, each about 2.3% above the last, and narrows the first short one by bisection. A run of short gates narrower than that step could be missed.
- The sleeve's tail loss is what the units left at the end would lose per 100 at the listed haircuts. On a long walk that can be far above the fund's average loss, because each earlier date paid before its own haircut.
- A queue or a NAV under one billionth of the fund counts as gone. The walk stops at 240 dates.

## 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
{
  "assets": [
    {
      "name": "Cash",
      "value": 5000000,
      "days_to_cash": 0,
      "haircut_pct": 0
    },
    {
      "name": "Bill 90d",
      "value": 10000000,
      "days_to_cash": 2,
      "haircut_pct": 0
    },
    {
      "name": "Stock basket A",
      "value": 15000000,
      "days_to_cash": 10,
      "haircut_pct": 1
    },
    {
      "name": "Loan book B",
      "value": 40000000,
      "days_to_cash": 180,
      "haircut_pct": 6
    },
    {
      "name": "Office tower A tokens",
      "value": 30000000,
      "days_to_cash": 365,
      "haircut_pct": 20
    }
  ],
  "redemption_request_pct": 40,
  "notice_days": 30,
  "frequency_days": 30,
  "gate_pct_per_period": 10
}
```

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

- Dates to clear: 7 dates
- Paid in all: 39948896.83
- Haircut cost: 794610.4356
- Illiquid share before: 70 %
- Illiquid share of what is left: 100 %
- Holders who stay: carrying value per 100: 98.76082123
- Holders who stay: exit value per 100: 85.83517196

Where the outcome flips, with the other inputs held:

- redemption_request_pct at 29.85851082: Up to this request, the request or the gate sets every payment. Above it, on day 120, assets that can reach cash fall short of what the gate would pay. With no gate it happens at about the same request, 29.85%, so the gate adds almost nothing here.
- gate_pct_per_period at 6.847631673: At this request, a gate at or below this level pays every date without running short of assets that can reach cash. Above it, a date runs short.

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:

- The run itself: holders who see the gate and join the queue. The request is one fixed size.
- Market moves while the queue runs.
- Haircuts that grow with the amount sold or the hurry. Each asset has one fixed haircut.
- A pro rata slice of every asset. Sales here take the fastest asset first.
- Swing pricing, exit fees, side pockets, payment in kind and suspension.
- Credit lines and other borrowing against the book.
- The settlement lag after a date, holdbacks and audit reserves.
- Taxes, on the fund or on the holder.

## 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/redemption_gates/prompt.md. Terms: https://hedgefund.md/terms


---

# Reserve coverage: 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.** Do these reserves cover the tokens at par, and on which day does cash run short at this redemption rate?

## Method

Coverage = sum(amount * (1 - haircut)) / tokens. Cumulative redemptions by day t = tokens * (1 - (1 - r)^t), since each day redeems r of what's left. Cash by day t = sum of amount * (1 - haircut) over reserves with days_to_cash <= t. A shortfall is cumulative redemptions above cash on any day. Net income = face * (yield - fee).

## Conventions

- Each day redeems the daily rate of the tokens still outstanding that morning, at par. The redemptions shrink as tokens leave.
- A reserve becomes cash only on its days_to_cash, in full, after its haircut. Unused cash carries forward, so the test compares running totals, not one day's flows.
- A shortfall is a day-end running total of redemptions above the running total of cash. Days are 1 to the horizon.
- Coverage counts every reserve, including any that reach cash after the horizon. The ladder counts only what has reached cash by that day.
- Yield isn't added to the cash ladder. Net income per year is face * (yield - fee), on the reserves as they stand.
- Income over the horizon scales that by the tokens left at the start of each day, over a 365-day year, as if reserves shrink in step with tokens.
- The largest daily rate comes from a bisection between 0 and 100 percent, cut at the tenth digit to a rate that passes when sent back. A shortfall can't get smaller as the rate rises. If no rate up to 100 gives a shortfall, the largest is 100.
- The sleeve is per 100 of tokens. Tail is the haircut loss, liquidity days the last reserve's days to cash, and carry the yearly net income.

## 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
{
  "tokens_outstanding": 100000000,
  "reserves": [
    {
      "name": "Bank cash",
      "amount": 10000000,
      "haircut_pct": 0,
      "days_to_cash": 0
    },
    {
      "name": "Bill 30d",
      "amount": 30000000,
      "haircut_pct": 0.5,
      "days_to_cash": 3
    },
    {
      "name": "Bill 90d",
      "amount": 30000000,
      "haircut_pct": 1,
      "days_to_cash": 5
    },
    {
      "name": "Loan note",
      "amount": 25000000,
      "haircut_pct": 5,
      "days_to_cash": 30
    },
    {
      "name": "Property note",
      "amount": 10000000,
      "haircut_pct": 15,
      "days_to_cash": 120
    }
  ],
  "daily_redemption_pct": 5,
  "horizon_days": 60,
  "reserve_yield_pct": 4,
  "fee_bps": 30
}
```

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

- Coverage after haircuts: 101.8 %
- First shortfall day: 24 day
- Shortfall on that day: 1251097.566
- Largest daily rate with no shortfall: 4.017365659 % a day
- Net income per year: 3885000
- Net income over the horizon: 203069.525

Where the outcome flips, with the other inputs held:

- daily_redemption_pct at 4.017365659: The largest daily rate with no shortfall over 60 days. Just above it, cash first runs short on day 29.

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:

- Haircuts that widen as more is sold, and forced-sale price impact.
- Selling a reserve early for less than the stated haircut, or borrowing against it.
- Any legal claim on the reserves, custody or banking failure, and whether the reserves exist as stated.
- Contract, chain or bridge failures, paused redemptions, gates and redemption fees.
- Weekends and holidays. Every day counts as a settlement day.
- The token's price away from par in a secondary market.
- Taxes.

## 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/reserve_coverage/prompt.md. Terms: https://hedgefund.md/terms