HEDGEFUND.md

Models / Fund terms and risk / redemption_gates

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?

Walks a redemption request through notice, dealing dates and a gate against assets with their own days to cash and haircuts. Shows what is paid, sold and left on each date, and what the holders who stay end up with. All numbers come from the caller. It is arithmetic on a list of assets, not a liquidity opinion or a reading of any fund's terms.

The paste-ready promptmodel.md

On these numbers, a request of 40% clears in 7 dates, by day 210, paying 39,948,896.83, and the holders who stay go from 70% to 100% illiquid, at 98.76 per 100 of carrying value.

Hypothetical, and on made-up numbers until you replace them. Nobody traded this, and nothing here is on offer.

Readings

The numbers, with their units.

Dates to clear

7dates

Day 210.

Paid in all

breach

39,948,897

Short of cash from day 120.

Haircut cost

794,610

Falls on the units left after each sale.

Illiquid share before

70%

days_to_cash over 60.

Illiquid share of what is left

watch

100%

Holders who stay: carrying value per 100

watch

98.76

The first payment is at 100.

Holders who stay: exit value per 100

watch

85.84

What is left, sold at the listed haircuts.

What flips it

The value of one input where the outcome changes, with the others held.

  1. redemption_request_pct

    29.86%now 40

    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.

  2. gate_pct_per_period

    6.8476% of NAVnow 10

    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.

Flags

What went past a line, and what to read before you trust the rest.

  • breach
    On day 120 the gate would allow 7,278,185.90, and assets that can reach cash by then bring 2,754,040.40. short_of_cash
  • watch
    The illiquid share of what is left goes from 70% to 100%. illiquid_share_up
  • watch
    The first payment is at 100 per 100. If everything left went at the listed haircuts, the holders left at the end would get 85.84 per 100. last_one_out
  • watch
    Assets that can reach cash run short at about the same request with or without this gate, near 29.86%. The slower assets don't arrive in time for the gate to matter. gate_adds_little

What this leaves out

What the formula leaves out, by name.

  • 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.
What it took as given (12)

What it took as given to get here.

  • 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.
Paid and left by date
  • Paid
  • Left unpaid
010M20M30M306090120150180210Day
The data

Liquidity profile by bucket

Days to cashBefore: carrying valueBefore: share %Before: cash after haircutAfter: carrying valueAfter: share %
0 to 7 days15,000,0001515,000,00000
8 to 30 days15,000,0001514,850,00000
31 to 90 days00000
91 to 180 days40,000,0004037,600,00029,256,49349.37
181 to 365 days30,000,0003024,000,00030,000,00050.63
Over 365 days00000

Each redemption date

DateDayRequestedGate capHeld by the gateShort of cashPaidCarrying value soldHaircut costHaircut on sales %Left unpaidPaid at, per 100
13040,000,00010,000,00030,000,000010,000,00010,000,0000030,000,000100
26030,000,0009,000,00021,000,00009,000,0009,040,40440,404.040.44692721,000,000100
39020,989,5258,095,96012,893,56508,095,9608,177,73781,777.37112,893,56599.95
412012,879,0947,278,1865,600,9084,524,1452,754,0402,781,85927,818.59110,125,05499.84
515010,121,0327,000,0003,121,0327,000,000000010,121,03299.8
618010,121,0327,000,0003,121,03207,000,0007,446,809446,80963,121,03299.8
72103,098,8976,255,319003,098,8973,296,699197,8026099.09

What was sold

DateDayAssetCarrying value soldCash raisedHaircut %
130Cash5,000,0005,000,0000
130Bill 90d5,000,0005,000,0000
260Bill 90d5,000,0005,000,0000
260Stock basket A4,040,4044,000,0001
390Stock basket A8,177,7378,095,9601
4120Stock basket A2,781,8592,754,0401
6180Loan book B7,446,8097,000,0006
7210Loan book B3,296,6993,098,8976

With this gate and with no gate

ItemWith this gateNo gate
Dates to clear76
Day cleared210180
Haircut cost794,610796,487
Units left at the end: carrying value per 10098.7698.71
Units left at the end: exit value per 10085.8485.79
Request where assets run short, %29.8629.85
Illiquid share of what is left, %100100

Hypothetical, computed from the numbers sent and any stated default, with hindsight. Nobody traded it, and costs and liquidity are only as assumed. Not a forecast, a recommendation, an offer, or a record of real trading. Don't use it to market an investment.

formula 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.

inputs_hash 38dd33e7e76fffa6

Paste it into your agent

No connection needed. This prompt carries the method, the conventions and what this site's engine gives on the made-up numbers, so your agent can check its own work before it touches real ones. Every prompt, with its hash, is listed at /prompts.json. A copy that stays fixed for this version, for a stack to point at: /v/1.0/models/redemption_gates.md.

prompt.md
# Redemption gates: a prompt from hedgefund.mdPaste 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?## MethodOn 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 numbersThe 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.83517196Where 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 numbersReplace every input with the person's own. Ask for any number you don't have, and don't invent one.## Step 3: reportGive 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.## LimitsResults 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

Call it

The same code answers on this page, over HTTP, over MCP and on your own machine, and the same inputs give the same bytes. No key, and nothing is stored. Send positions by POST or run the library, because a URL can land in a server log. model.md holds all of this for your agent.

POST the inputs to /api/v1/redemption_gates.

terminal
curl -s https://hedgefund.md/api/v1/redemption_gates \  -H 'content-type: application/json' \  -d '{"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}' \  | jq '{summary, flags, flips, not_modeled, inputs_hash}'

Inputs

InputTypeRangeRequiredWhat it is
assetsarray1 to 40 itemsyesWhat the fund has, at carrying value.
assets[].namestringyesA label, such as Bill 90d.
assets[].valuenumber0 to 10000000000000yesCarrying value in money.
assets[].days_to_cashwhole number0 to 3650yesDays from starting a sale to having the cash.
assets[].haircut_pctnumber0 to 99yesPercent below carrying value that a sale brings in.
redemption_request_pctnumber0 to 100yesShare of the fund asked for on day 0, in percent.
notice_dayswhole number0 to 730yesDays from the request to the first redemption date.
frequency_dayswhole number1 to 730yesDays between redemption dates.
gate_pct_per_periodnumber0 to 100yesMost that can be paid on one date, in percent of NAV on that date. 100 means no gate.

Hypothetical, and on made-up numbers until you replace them. Nobody traded this, and nothing here is on offer.

1.0Use at your own risk: hedgefund.md is not a fund, not an offer of any security, token or fund interest, and not advice. Results are hypothetical, may be wrong, and are not a record of real trading. Don't use them to market an investment. See the terms.