The stop waterfall

A stop is the Buyer ceasing payments. It is the one exit where the engine touches the market: the coin is sold for dollars, and the dollars are divided between the Buyer and the Holder by a fixed rule. This chapter derives that rule from the code, prices the sale on the path, walks the three regimes the rule produces, and reproduces the test that pins every cent.

The rule is the September program’s, ruled by Marc on 2026-08-22 (the refund formula, the Stop Date) and 2026-09-03 (the surplus to the Holder, delivery in dollars), and applied in spec v1.5 §3.3. The code is engine.rs::stop_sale; everything below is read off it.

The five quantities

Every stop is described by five dollar amounts, all cent-quantized Decimal (money.rs::cents).

At the base terms \(P = 88{,}500\) and every payment is $1,475, so after \(k\) payments \(A = 1{,}475k\) and \(R = 88{,}500 - 1{,}475k\). Payment 1 went to BTC Now and was never delivered to the Holder, but it is in \(A\): the refund base is what the Buyer paid, not what the Holder received. The spec flags this as a term-sheet question that is modelled but not yet decided (v1.5 change 8).

The missed date

The engine runs each month in a fixed order (engine.rs::run): scheduled payments first, then pending walks, then early completions, then hazard draws. That order fixes the missed payment date \(D\), the age at which the Buyer did not pay.

A hazard draw at age \(t\) happens in step (4), after payment \(t\) has already been made in step (1). The payment that will be missed is the next one, so \(D = t + 1\). The code passes m + 1 to stop_sale for every draw, naive or rational, including a rational-mode draw redirected onto an underwater Agreement.

A conviction walk is armed at the payment date on which the streak breaches (step 2b) and executes at the next payment date (step 2a), where the pending walk consumes the date without a payment. The walk is the missed payment, so \(D = t\), the age at which it executes.

A rational-boundary walk is decided at the top of step (1), before the payment, when the coin sits below the frontier for that date, and executes in the same month’s step (2a). Again \(D = t\).

A draw cannot fire on the final payment date (t < term_months), but a walk can consume it (t <= term_months). To let a stop at age \(\text{term}\) settle inside the ledger, engine.rs::SimConfig::horizon simulates \(\lfloor \text{lag}/30.4375 \rfloor + 1\) months past the last cohort’s term (engine.rs::settlement_tail_months): one month at the program’s 18 days (v1.5 change 4), three at the 90-day stress (2026-09-05, the audit’s finding 6).

The Stop Date and the sale

A payment up to 15 days late carries nothing. Day 16 after \(D\) is the Stop Date (R-1035, Marc 2026-08-22): the Agreement ends and the sale for dollars begins. The sale follows within two business days (R-1037, Marc 2026-08-22). The engine models the sale at \(D + \text{lag}\) calendar days, where lag is input #24 stop_sale_lag_days, default 18: day 16 plus two business days. The input is validated to 0–90 days (engine.rs::validate).

The lockouts that follow a stop (six months, reinstated 2026-09-03) are outside the engine.

Pricing the sale on the path

The path holds one mark per month, \(S_0, S_1, \dots\). The sale happens between marks, so engine.rs::stop_sale interpolates. With the month of 30.4375 days (365.25 ÷ 12),

\[ \text{pos} = D + \frac{\text{lag}}{30.4375}, \qquad k = \lfloor \text{pos} \rfloor, \qquad f = \text{pos} - k, \]

\[ S = \exp\big((1-f)\ln S_k + f \ln S_{k+1}\big) = S_k^{,1-f}, S_{k+1}^{,f}. \]

Log-linear interpolation is the geometric mean weighted by the fraction of the month elapsed. It is the same convention the custom path mode uses between its anchors (paths.rs::custom), so a custom path and a sale on it agree. Both \(k\) and \(k+1\) are clamped to the last mark of the path as a guard, but the horizon carries the settlement tail, so the mark past the sale date always exists and no sale prices at a clipped mark (finding_6_a_90_day_lag_settles_inside_the_ledger checks lags 0, 18, 30, 30.4375 and 90 at the final defaultable age).

The two ends of the lag are worth naming. Lag 0 sells at the missed date’s own mark, \(S = S_D\). Lag 30.4375 sells exactly one month later, \(S = S_{D+1}\). The default 18 days sits at \(f = 18/30.4375 = 0.5914\) of the way between them. The test stop_sale_regime_one_exact_cents in tests/invariants.rs checks all three on a path that falls between the marks; the table in the walk-through below prints the values.

At monthly resolution this is a small refinement: the difference between an 18-day and a 30-day sale is a fraction of one month’s price move. It is modelled because the ruling names a day count, and because on a path that is falling through the missed month the sale is priced on the way down rather than at the top of it.

The proceeds

The sale price is reduced by the static haircut, input #15, and the market-sale cost, input #16:

\[ V = \operatorname{cents}\big(S \cdot e^{-\text{haircut}} \cdot (1 - \text{sale cost})\big). \]

The program haircut is 0 (Marc, 2026-07-12: a one-coin sale has no market impact, and stops never synchronize because payment dates differ by Buyer). The sale cost is 25 bp, so at the base terms \(V = 0.9975,S\). The haircut slider and the tornado’s 50% stress remain for a reader who wants an execution discount. \(V\) is stored on the Agreement as stop_proceeds_usd; it is the one number the auditor, the Holder and the Buyer’s statement share.

The refund and the delivery

The R-1033 rule (Marc, 2026-08-22, reporting counsel’s approval) reads: if the Buyer’s payments plus the sale proceeds come to the Purchase Price or less, the Buyer gets nothing back; if they come to more, the Buyer is refunded the excess, never more than he paid in. In engine.rs::stop_sale:

\[ \text{refund} = \min\big(A,\ \max(0,\ V + A - P)\big), \qquad \text{delivered} = V - \text{refund}. \]

Since \(R = P - A\), the middle term is \(V - R\): the refund is the proceeds above the remaining schedule, floored at zero and capped at what the Buyer paid. Read from the Holder’s side, the same two lines say: the Holder is paid the remaining schedule first, the Buyer is refunded up to what he paid, and whatever is left after both is the Holder’s. The refund is paid in dollars. A stopped Buyer never receives coin (v1.5 change 1).

The code guards both amounts with debug_assert!(delivered >= Decimal::ZERO && refund >= Decimal::ZERO), and both hold algebraically: the refund is at most \(V - R \le V\) when it is positive, and zero otherwise.

The fee on the delivery

The delivery is one more send to the Holder, so it carries the flat 5% servicing fee like every other delivered dollar (Marc, 2026-08-31: 5% of each send, termination sends included). engine.rs::stop_sale passes delivered through fees.rs::FeeState::split, which uses the cumulative-rounding convention: the fee posting is \(\operatorname{round}(0.05 \times \text{cum after}) - \operatorname{round}(0.05 \times \text{cum before})\), so the Agreement’s lifetime fee is exact to the cent even when a single posting wobbles by one. The Holder receives \(\text{delivered} - \text{fee}\).

The fee is BTC Now’s only take from a stop. There is no share of the surplus and no dial that could create one; the invariant test stop_sale_waterfall_identities_across_regimes asserts that BTC Now’s total take equals origination fees plus flow fees on a book where surpluses occur. That is the part of the July founder invariant that survived (spec v1.5 change 6).

Shortfall and surplus

Two per-Agreement fields describe how far the sale landed from the schedule and from the price:

\[ \text{shortfall} = \max(0,\ R - V), \qquad \text{surplus} = \max(0,\ V - P). \]

The shortfall is the Holder’s loss against the remaining schedule on that Agreement, in dollars, before the fee; it is zero once the sale covers the schedule. The surplus is the delivery above the remaining schedule, the part of the proceeds that exceeds the whole Purchase Price after the Buyer has been made whole. Both are stop_surplus_usd and shortfall_usd on the Agreement row, and both sum to book totals (total_shortfall_usd, stop_surplus_usd in outputs.rs). They cannot both be positive: a surplus needs \(V > P \ge R\).

The shortfall is not the Holder’s capital loss. The Holder paid \(P_{\text{buy}}\) (par, $60,000, at the base terms) and has already received net payments; the row’s capital_pnl is net received minus capital deployed and is the number to read for realized loss. The risk desk’s PD, LGD and EAD are built from the shortfall and the remaining schedule at the stop (see The risk desk).

The three regimes

The min and max make the rule piecewise. Ordering \(V\) against \(R\) and \(P\) gives three regimes.

In regime 1 the sale did not cover the schedule; the Buyer’s payments cushion the Holder’s loss and the Buyer gets nothing back. In regime 2 the Holder gets exactly the remaining schedule and every dollar above it goes back to the Buyer, up to what he paid. In regime 3 the Buyer has been refunded in full, so the cap binds, and the Holder keeps the rest: the remaining schedule plus the surplus above the Purchase Price.

The worked examples below are at the base terms after twelve payments: \(A = 17{,}700\), \(R = 70{,}800\), \(P = 88{,}500\). Each was run through the engine on a custom path with the conviction rule set to walk on the first month below the strike (x_underwater: 0.0, y_consecutive: 1, hazard 0, early completion 0, one Agreement, lag 18), and every figure below is what the API returned. The path anchors are (11, 1.0), (12, r) for regime 1 and (11, 1.0), (12, 0.9), (13, r) for regimes 2 and 3; the walk is armed at month 12 and executes at month 13, so \(D = 13\) and the sale prices on the flat segment after month 13.

Regime 1, \(r = 0.7\). The sale prices at $42,000, so \(V = 42{,}000 \times 0.9975 = 41{,}895.00\). Then \(V + A - P = -28{,}905\), the refund is $0, and the whole \(V\) is delivered. Fee $2,094.75, net to the Holder $39,800.25. Shortfall \(70{,}800 - 41{,}895 = 28{,}905.00\). The Holder’s capital_pnl on the row is −$4,786.00: eleven delivered payments net of fee, $15,413.75, plus $39,800.25, less the $60,000 paid at par.

Regime 2, \(r = 1.4\). The sale prices at $84,000, \(V = 83{,}790.00\). \(V + A - P = 12{,}990\), below \(A\), so the refund is $12,990.00 and the delivery is \(83{,}790 - 12{,}990 = 70{,}800.00\), the remaining schedule to the cent. Fee $3,540.00, net $67,260.00. Shortfall 0, surplus 0. The Holder ends the Agreement with what completion would have paid (delivered_gross $87,025.00, the same as a completed row), forty-six months before the last scheduled payment and undiscounted.

Regime 3, \(r = 1.8\). The sale prices at $108,000, \(V = 107{,}730.00\). \(V + A - P = 36{,}930\), above \(A\), so the cap binds: refund $17,700.00, everything the Buyer paid. Delivery \(107{,}730 - 17{,}700 = 90{,}030.00\), which is \(R + 19{,}230\); the surplus is \(V - P = 19{,}230.00\). Fee $4,501.50, net $85,528.50.

All three post at month 14 (\(\operatorname{round}(13 + 18/30.4375) = \operatorname{round}(13.59) = 14\)) with exit month 13.

The same rule in the ruling’s own example, one coin at a Purchase Price of $90,000 with $24,000 paid (Marc, 2026-08-22): proceeds $66,000 refund $0; $80,000 refund $14,000; $90,000 refund $24,000; $110,000 refund $24,000, with $110,000 left on the receiving side (the Company in the ruling’s words; the Holder since the ruling of 2026-09-03).

Posting month and exit month

The stop has two dates in the ledger, and they differ on purpose.

The exit month is \(D\), the missed payment date: a.status = Exited { month: missed, tag }. It is the month the Agreement stopped being paid. The per-Agreement table reports it as exit_month (outputs.rs::agreement_table), and the exposure layer counts the Agreement as active only in the months before it (exposure.rs).

The posting month is the first payment date at or after the sale point, \(\lceil D + \text{lag}/30.4375 \rceil\) — the point itself when it is a whole month — always inside the horizon (the settlement tail is sized for it). With the default lag of 18 days the fraction is 0.59, so the cash lands at \(D + 1\); at 45 days at \(D + 2\); at 0 days at \(D\) itself. The sale is priced at the log-linear interpolation of the marks at \(\lfloor \cdot \rfloor\) and \(\lfloor \cdot \rfloor + 1\), and the posting month’s mark is the later of the two, so the cash is never booked before the last observation that priced it (model audit 2026-09-07, R02: booking at the nearest payment date put a 10-day or a 45-day sale’s cash one month before the mark it was priced on, so a price move strictly after the cash date revised realised cash — the audit’s $60,000 path with the following mark halved: $56,857.50 → $45,277.95 at 10 days, → $40,809.67 at 45; tests/model_audit_2026_09_07_r02.rs runs every allowed lag). The engine keeps the cash at monthly resolution because the ledger is monthly; the price is not rounded, only the posting date.

The refund deadline in the program (ten business days after the sale, R-1037) is inside the same month at this resolution, so the refund posts with the delivery.

The ledger postings

engine.rs::stop_sale writes three transfers, all at the posting month, all from the external Market entity, which is the counterparty of the recorded sale (ledger.rs::EntityId):

The ledger drops zero-amount transfers (ledger.rs::Ledger::transfer), so a regime-1 stop writes no StopRefund posting and the test asserts exactly that. Conservation holds by construction: the three amounts sum to \(V\), and \(V\) is what the Market gives up. No posting ever names the coin; the ledger is dollars only, and the coin’s disposal is represented entirely by the Market paying \(V\).

On the Agreement the stop leaves stop_proceeds_usd, buyer_refund_usd, stop_surplus_usd, shortfall_usd, and sets coin_returned_usd to zero. Two book totals accumulate in engine.rs::run: buyer_refunds_usd and stop_surplus_usd. The test stop_sale_waterfall_identities_across_regimes recomputes every row’s refund, shortfall and surplus from \(V\), \(A\) and \(P\), checks that the sum of StopRefund postings equals the book’s refund total, that each row’s delivered_gross equals its scheduled deliveries plus \(V - \text{refund}\), and that all three regimes actually occur on its rising path (500 Agreements on a flat-vol bridge from $60,000 to $240,000, naive draws).

The exact-cents test, walked

stop_sale_regime_one_exact_cents in tests/invariants.rs is one stop with every cent by hand. The configuration: one Agreement at the base terms, a custom path with anchors (5, 1.0), (6, 0.6), hazard 0, early completion 0, the conviction rule on with x_underwater: 0.0 and y_consecutive: 1, lag 18.

1. The path. paths.rs::custom holds $60,000 through month 5, moves to $36,000 at month 6 and stays there. The strike is the month-0 price, $60,000.
2. Months 1 to 6. The Buyer pays $1,475 six times: payment 1 to BTC Now, payments 2 to 6 delivered to the Holder, $7,375.00 gross, $368.75 of fee. \(A = 8{,}850.00\), \(R = 79{,}650.00\).
3. Month 6, step (2b). The rule compares the spot with \((1 - 0) \times 60{,}000\). $36,000 is below it, the streak reaches 1, and a walk is armed for the next payment date. (At months 1 to 5 the spot equalled the strike; the comparison is strict, so the streak stayed at 0.)
4. Month 7, step (1). The pending walk consumes the payment date; nothing is paid. Step (2a) executes the walk with missed = 7, tag ConvictionWalk. \(D = 7\).
5. The sale. \(\text{pos} = 7 + 18/30.4375 = 7.5914\); \(S_7 = S_8 = 36{,}000\), so the interpolation is $36,000 exactly. \(V = 36{,}000 \times 0.9975 = 35{,}910.00\).
6. The waterfall. \(V + A - P = 35{,}910 + 8{,}850 - 88{,}500 = -43{,}740\). Refund $0. Delivered $35,910.00.
7. The fee. Cumulative delivered goes from $7,375.00 to $43,285.00; 5% of those is $368.75 and $2,164.25; the posting is the difference, $1,795.50. Net to the Holder $34,114.50.
8. The record. Shortfall \(79{,}650 - 35{,}910 = 43{,}740.00\). Surplus 0. Posting month \(\operatorname{round}(7.5914) = 8\). Exit month 7. Lifetime fee on the row $2,164.25. No StopRefund posting. Conservation sum $0.00.

The test then swaps in the path (5, 1.0), (6, 0.6), (8, 0.5), which keeps falling through the missed month, and runs the same stop at three lags. The marks are \(S_7 = 60{,}000 \sqrt{0.6 \times 0.5} = 32{,}863.35\) and \(S_8 = 30{,}000\).

The test asserts the two ends exactly and that 18 days lands strictly between them. The other rows were produced by the same configuration through the API.

What died with the July rule

Before v1.5 the stop was the sale rule of spec v1.2 (Marc, 2026-07-11), described there under the older word that the vocabulary lock of 2026-09-02 retired; the doc comment on input #15, the haircut, still carries it. Three things about it are gone.

The sale was sized to the remaining schedule. Only enough coin was sold to deliver \(R\); the Holder’s entitlement was capped at the Agreement. Now the whole coin is sold, and the proceeds are divided by the waterfall.

The residual coin went back to the Buyer. Whatever coin was not needed for \(R\) was the Buyer’s property and was returned to him, in coin, at the sale price. Now the Buyer receives a dollar refund by formula, and coin never reaches a stopped Buyer.

The sale was priced at the next month’s mark. Now it is priced at \(D + \text{lag}\) days by interpolation, which at the default lag is 41% of the way back toward the missed date’s mark.

The founder’s July sentence, that the Holder can never keep more than it is owed, described that rule and is superseded for the Holder (spec v1.5 change 6). What was kept is that BTC Now takes fees only.

The Model Card’s reading of the change (v2.0, 3 September 2026) is the practical summary. On a driftless path the two rules deliver almost the same cash, and the zero-drift medians moved by a tenth of a point. The right tails and every historical-replay row moved a lot, because under the September rule a Buyer who stops while the coin is worth more than the Purchase Price hands the surplus to the Holder, and on Bitcoin’s own history that surplus is large.

Why the difference matters to a Holder

Three consequences follow from the rule as coded, and a desk should hold all three at once.

The surplus is the Holder’s. In regime 3 the delivery is \(R + (V - P)\), not \(R\). The July rule capped the Holder at \(R\) on every stop; the September rule caps the Buyer at \(A\) instead. This is the long call at the Purchase Price described in The risk desk: struck at 1.475× entry, exercised only by a Buyer who stops in the money. It is rare by construction (the drawdown multipliers, input #23, halve the hazard in the money when they are on, as they are in the Model Card’s run; see Who stops paying), but when it fires it is worth the whole gap between the coin and the Purchase Price, and the Model Card marks it as the least-evidenced behavior in the model and the one now driving the replay upside.

A stopped Buyer never gets coin. The refund is dollars, whatever the price did. There is no partial lot, no delivery to a wallet, no Buyer-side price exposure after the Stop Date. The engine sets coin_returned_usd to zero on every stop; only early completion leaves coin with a Buyer. The ruling’s reasoning (Marc, 2026-08-22) was that a stop is a refund right with no upside: the only way to profit from Bitcoin under the Agreement is to complete the purchase.

The Holder may buy coin with the dollars. Delivery is in dollars by ruling (Marc, 2026-09-03), with no in-kind residual term. A directional desk that wanted the coin can buy it back with the proceeds on its own account, at its own execution cost. The engine models the dollars; the planned reinvest-into-coin view models the Holder’s own act, not a term of the paper. A stop is still a forced sale for dollars at the bottom of a drawdown, and the Holder’s exposure is to the sale price, not to the coin thereafter, unless it chooses otherwise.

Between the first and the second consequence sits the regime that will occur most often on a falling path, regime 1, where nothing changed in kind from July: the sale fails to cover the schedule, the Holder books the shortfall, and the Buyer’s payments cushion it. What changed there is only the pricing date. The whole loss story of the paper still lives in the first nineteen months of each vintage, where \(R\) sits above the entry price (\(88{,}500 - 1{,}475 \times 19 = 60{,}475\) after payment 19, \(59{,}000\) after payment 20) (The risk desk draws that line).