Pooled holdback and the advance

Status: 🔵 Built and tested, never proven. Its risk model is checked three independent ways. No LP has taken an advance, because the deferred path has no persistence layer.

The problem

An LP fronts a purchase on their own credit line. The order is placed, shipped and delivered, and a return window runs before the LP is whole. DeferredState starts at placed with bulkReleasedCents: 0, and stage 1 does not fire until delivery. So through transit (days, sometimes weeks) the LP has financed a purchase and holds nothing.

Why the old design over-reserved

Today each LP's holdback self-insures their own return: 15% of every general-merchandise order. Ten LPs each hold 15% against a return that will hit about one of them. Nobody redid the arithmetic.

Pooled, the reserve only has to cover the aggregate draw, freeing the difference for early release.

This is not borrowing

There is no interest, collateral, liquidation or counterparty. The LP gets their own escrow for their own order, only sooner.

Earlier and smaller. The advance is 50% at placed, and the LP already gets 85% at delivered. The earlier, riskier moment gets the smaller fraction, or something would be priced backwards:

Moment	Today	With the advance
placed	nothing	50%
delivered	85%	tops up to 85%
window closes	15%	15%

Stage 1 tops up to the bulk target instead of paying again. The old guard refused to run twice. The new one bounds the total money, which is strictly safer and lets an advance exist without paying an LP twice.

The number that actually matters is not 50%

The worked case is ten transactions at a 10% return rate. Under independence that is comfortable: P(≥3 returns) = 7.02%. A 50% advance only breaches at six returns, a 0.015% event.

But returns cluster (a holiday season, a bad merchant). With intra-class correlation ρ:

ρ	P(≥6 returns): a 50% advance breaching	99th-percentile returns
0.00	0.015%	4
0.10	0.91%	5
0.20	2.65%	7
0.35	5.22%	9

At ρ = 0.20 a 50% advance breaches roughly one book in forty.

So the load-bearing number is the correlation assumption, and 50% is what falls out of it at ρ = 0.10. The code derives the fraction from that configured assumption and reports both, so a reader can dispute the assumption directly.

Small N is the regime we are in

Ten users is too few for the law of large numbers to help. Variance dominates, so sizing against the average return rate sizes against the number that matters least.

How the fraction is derived

What stays held, plus the reserve, must cover the bad month:

(1 − f)·T + R  ≥  D_tail        ⟹     f  ≤  1 − (D_tail − R) / T

Where T is the book, R the funded reserve, and D_tail the draw at the 99th percentile.

Two properties follow:

• It rises as the reserve grows, so LPs get more money earlier with no hand re-tuning. That is what Morpho yield is for.
• It falls on its own when the book concentrates or the correlation assumption is raised. That makes it safe to show a seller.

The tail draw sums the largest positions, not the average one, because a bad month hits concentrated exposure. Sizing off the mean understates the book that needs it most.

What it costs, said plainly

Pooling means one LP's escrow can temporarily cover another LP's return.

That turns pure escrow into mutualised insurance, a change in kind, so the seller flow shows it at listing instead of in the terms or a tooltip.

Advancing against unsold inventory means eating the loss when a card does not clear. That is a real balance sheet, the cost behind incumbent resellers' 10–25% spreads. Doing it on purpose, priced off our own data, is better than doing it by accident. It is still a choice that needs arguing for.

Underwriting: real interface, illustrative numbers

Every listing carries a merchant, face value, discount and, eventually, a fill rate: a dataset nobody else has for this inventory. A model on it answers "how fast will this sell" and "how much can we advance."

We do not have the volume to underwrite. A handful of listings cannot distinguish "Best Buy at 8% sells in three days" from noise.

So the seam is real, and a fitted model drops in behind it unchanged. The only implementation, IllustrativeUnderwriter, is named so it cannot pass for anything else wherever it appears. Every estimate carries basis: 'illustrative' in the type, so a second consumer cannot show a forecast by accident.

In the seller UI the caveat sits above the numbers, in the warning colour, because a caveat after a figure is read after the figure is believed.

DATA_REQUIRED_TO_FIT lists what a fitted model would need, including the half most often forgotten: listings that never sold. A naive fit drops this right-censored data and makes everything look faster than it is.