The Agreement, explained

This chapter describes the Bitcoin Purchase Agreement the way the engine models it. It is not the Agreement itself and it is not a summary of the legal text. Where the code and the program differ, the difference is stated here and the code is what the numbers come from. Every rule carries the date of the ruling that made it, so a reader can trace a number in a Model Card back to a decision.

The vocabulary is the locked one (Marc, 2026-09-02). The paying side of an Agreement is the Buyer; Buyer 0 opened it. The receiving side is the Holder; Holder 0 is always BTC Now. The paying side changes hands by Transfer, the receiving side by Sale. A Partner is anyone paid a cut of BTC Now’s fees. Engine identifiers keep older names (Owner for the Holder, Obligor for the Buyer, non_performance for a stop); they are quoted in code font when the code is being explained and nowhere else.

The parties

Three entities move money in the engine, and every cent between them goes through the ledger (ledger.rs).

A fourth entity, EntityId::Market, is the counterparty to the stop sale. It buys the coin for dollars and the dollars flow out from it. It has no economics of its own.

What the Buyer buys and pays

The Buyer buys one coin at a price fixed on the day the Agreement opens. That price is the strike \(K\), the coin’s dollar cost at origination. The Buyer agrees to pay a Purchase Price equal to the strike times the program multiple, \(m = 1.475\):

\[ P = K \cdot m \]

contract.rs::ContractTerms::terminal computes \(P\) and quantizes it to cents. At the base terms, a $60,000 coin carries a Purchase Price of $88,500.

The Purchase Price is paid in equal monthly payments over the term \(n\), 60 months in the current program. The payment is straight division, not an annuity:

\[ \text{PMT} = \frac{P}{n} = \frac{88{,}500}{60} = 1{,}475 \]

contract.rs::ContractTerms::schedule builds the schedule. Each payment is rounded down to the cent and the final payment absorbs the residual, so the sixty payments sum to the Purchase Price exactly. The remaining schedule after \(t\) payments is what the Buyer still owes in nominal dollars:

\[ R_t = P - \text{PMT} \cdot t \]

The term is a property of today’s offer, not of the Agreement (Marc, 2026-07-29). Nothing in the engine hard-codes 60 months (spec v1.1). The multiple implies a financing rate, the rate at which an ordinary amortizing schedule of $1,475 would repay $60,000: 16.50% nominal per year at the base terms, solved by bisection in contract.rs::ContractTerms::implied_monthly_rate. The engine calls this the implied financing rate and uses it only for display and for the moneyness boundary; no ledger amount depends on it.

The Buyer may pay early or pay extra at any time without a fee. The Buyer never owes anything after a stop. There are no late fees, no returned-payment fees, no termination fees on the Buyer’s side.

The first payment goes to BTC Now

Every Agreement opens with BTC Now as Holder 0, and the first payment flows to BTC Now whole (Marc, 2026-08-31: “BTC Now always first owner”). In the engine this is input #3, origination_payments, default 1: the first \(N\) payments post from the Buyer to BTC Now as TxKind::OriginationFee and never enter the Holder’s stream (engine.rs::run, step 1). They carry no servicing fee because nothing was delivered to a Holder.

At the base terms the first payment is $1,475, which is 1.67% of the Purchase Price (one sixtieth) and 2.46% of the Holder’s capital. The Holder should read it as a day-one cost of the paper.

The Sale of the paper to a Holder

The Holder buys the paper from BTC Now at a purchase price. The default is par: 1.00 times the strike, $60,000 on the base coin (Marc, 2026-07-12; spec v1.4). Input #6b, purchase_pct_of_strike, expresses it as a fraction of the strike so that a paced book of many cohorts scales correctly. The engine posts the purchase from the Holder to BTC Now at the origination month as TxKind::PurchasePrice.

In the engine the Holder pays at origination and payment 1 arrives a month later. In the program BTC Now is Holder 0 first and a Primary Sale follows; the Holder’s economics start at its purchase date. The engine collapses this to one date, which is the conservative reading for the Holder: it pays before the first payment that it does not receive.

After the Sale, payments 2 to 60 are delivered to the Holder. The Holder never receives the coin.

The servicing fee

BTC Now keeps 5% of every dollar delivered to the Holder, deducted at each send (Marc, 2026-08-31: “we retain 5% of each send”). It is uniform and has no exemptions: scheduled payments, early-completion payoffs and stop-sale deliveries all carry it, and the termination send does too (“we get our 5% of that as well”). The Holder receives 95% of each send.

Input #4, servicing_fee_rate, is the flat rate (spec v1.5). It is not derived from the term; the earlier form, a rate per year times the term in years, died with the September program. A 60-month term at the old 1% per year happened to give the same 5%, so the base case did not move; every other term now pays the same flat rate.

fees.rs::FeeState::split takes a delivery and returns the Holder’s net and the fee, summing exactly to the delivery. The fee posting on each delivery is the difference between the rounded cumulative fee before and after (convention C2), so any single posting may differ from 5% of that delivery by a cent, but the lifetime fee on an Agreement is exact to the cent. At the base terms nothing rounds: 5% of $1,475 is $73.75 and the Holder’s net payment is $1,401.25.

On a completed Agreement the lifetime fee is \(0.05 \cdot (P - N \cdot \text{PMT})\), which is $4,351.25 at the base terms, because the first payment is never delivered and carries no fee. The invariant suite tests this identity at terms of 36, 48, 60, 84 and 120 months (invariants.rs::fee_identity_exact_to_the_cent).

The fee is the only thing BTC Now takes from the paper after the first payment. There is no dial that gives BTC Now a share of a stop sale, and the invariant suite asserts that BTC Now’s total take equals its origination fees plus its flow fees.

The stop

A stop is the Buyer ceasing to pay. It is the Buyer’s only exit other than completing, and it is the exit a Holder prices.

The Stop Date

A payment up to 15 days late carries nothing: no fee, no penalty, no consequence. Day 16 after the missed due date is the Stop Date (Marc, 2026-08-22: “stop is 15 days later and we stop on day 16 as always”; atom R-1035). A returned payment counts as no payment. The Buyer may also elect to stop in the app on any day, and that day is the Stop Date.

On the Stop Date the Agreement ends. The Buyer owes nothing further and can pay nothing further.

The engine works at monthly resolution and does not model the 15 days as a separate event. It records the missed payment date \(D\) and treats day 16 after it as the Stop Date. \(D\) is \(t+1\) for a stop drawn at payment age \(t\) (payments run first, so payment \(t\) was made) and \(t\) for a conviction walk or a rational-boundary walk, where the walk is the missed payment. The Agreement’s exit month is \(D\).

The sale for dollars

Within two business days of the Stop Date the coin is sold for dollars at market through the normal venue, in a recorded sale, costs on the Company, with the record kept (Marc, 2026-08-22, approving the drafted mechanics; atom R-1037). The sale exists to fix one number, the proceeds \(V\), against which the refund is computed. It is a recorded sale rather than an index read because Marc chose it: “official sale, to record the proceeds” (2026-08-22).

The engine sells the coin stop_sale_lag_days after the missed date (input #24, default 18 calendar days: day 16 plus two business days). The sale price is the path’s price at that point, interpolated log-linearly between the monthly marks on either side. The proceeds are

\[ V = S(D + 18/30.4375) \cdot e^{-h} \cdot (1 - c) \]

where \(h\) is the static haircut (input #15, default 0, Marc 2026-07-12: a one-coin sale has no market impact) and \(c\) is the market-sale cost (input #16, default 25 basis points, Marc 2026-07-11). All of this is engine.rs::stop_sale. The cash posts at the first monthly date at or after the sale, ceil(D + stop_sale_lag_days/30.4375). At the default 18-day lag this is the month after the missed date; at zero lag it is the missed month.

One difference to note. The ruling puts the sale’s costs on the Company; the engine takes the 25 basis points out of the proceeds, which lowers \(V\) by $150 on a $60,000 coin. The waterfall determines how that reduction is allocated between the refund and the delivery; each does not necessarily fall by $150. The sale standard itself, the venue, the deadline and the price against the index, is not yet written into the Agreement, and the model assumes a market sale at the path price less 25 basis points.

The waterfall

Let \(A\) be every payment the Buyer made, payment 1 included (engine.rs::Agreement::paid_in), \(P\) the Purchase Price and \(R = P - A\) the remaining schedule. The proceeds pay out by the R-1033 formula (Marc, 2026-08-22, reporting legal’s approval):

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

\[ \text{delivered} = V - \text{refund} \]

The refund goes to the Buyer in dollars. The delivery goes to the Holder, less the 5% fee. Read as a waterfall, the proceeds pay the Holder the remaining schedule first, then refund the Buyer up to what he paid in, and any surplus above the Purchase Price stays with the Holder (Marc, 2026-09-03: after the refund “the rest goes to” the Holder; the ruling of 2026-08-22 had left the upside with the Company, and 2026-09-03 moved it to the Holder). Three regimes follow from the formula:

The Buyer never gets back more than he paid. The Holder never receives less than the proceeds allow and never more than the remaining schedule plus the surplus above the Purchase Price. Nobody owes anybody anything after a stop. engine.rs::stop_sale records shortfall_usd = max(0, R − V), stop_surplus_usd = max(0, V − P), buyer_refund_usd and stop_proceeds_usd on the Agreement, and the invariant suite checks the three regimes against these identities on every stop of a rising path.

Whether payment 1, the one BTC Now kept, sits in the Buyer’s refund base is a term-sheet item that is flagged, not decided. The engine models it as included, reading Marc’s “the maximum he paid” (2026-09-03).

Dollars, never coin

A stopped Buyer receives dollars, never coin. The refund is paid from the proceeds within ten business days with a statement (Marc, 2026-08-22). The Holder’s delivery is also in dollars; there is no in-kind residual term. A Holder who wants the coin buys it with the proceeds on its own account (Marc, 2026-09-03: “they get in dollars but of course they can just back to back it into coin anyways”). The engine posts TxKind::StopSaleDelivery from the market to the Holder and TxKind::StopRefund from the market to the Buyer; a zero refund posts nothing. Any view that reinvests stop proceeds into coin models the Holder’s own behavior, not a term of the Agreement.

This replaced two earlier designs. The July engine sized the sale to the remaining schedule and returned the residual coin to the Buyer (spec v1.2, Marc 2026-07-11). The 2026-08-21 election of dollars or coin at the agreed price was dropped the next day because a payoff available only by quitting reads like a bet on the price. Under the September program the only way to profit from Bitcoin through the Agreement is to complete it.

Early completion

The Buyer may pay the remaining schedule \(R_t\) in cash at any time and take the coin. This is early completion. It is cash only: the coin is never sold to pay for it (spec v1.5, change 3). The Holder receives \(R_t\) less the 5% fee and the Agreement closes.

engine.rs::settle posts the payoff from the Buyer to the Holder as TxKind::MakeWholeDelivery (the identifier is historical) and the fee to BTC Now. It records the Buyer’s coin equity at exit, the spot value of the coin less the payoff, as coin_returned_usd. That figure is the Buyer’s property, not a cash flow, and it appears in the outputs only as a transparency counter.

Relative to full scheduled completion at the base terms, early completion delivers the same total net scheduled cash sooner. It also closes the Agreement, removing any later stop exposure and possible surplus. Its effect on portfolio cash and IRR therefore depends on the alternative path and exit behavior. Run the early-completion propensity (input #12) at zero as a separate sensitivity. In the engine the decision is a monthly draw with probability proportional to how far the coin is above the remaining schedule, \(u_t = \text{propensity} \cdot \max(0, (S_t - R_t)/S_t)\), optionally gated by a take-profit threshold on the Buyer’s all-in cost (input #22). Those are model choices, not terms; see the behavior chapter.

Completion

When the sixtieth payment is made, the Agreement completes and the coin is delivered to the Buyer. The engine marks the Agreement Completed at the payment date that brings payments_made to the term and posts nothing further. Delivery of the coin is outside the ledger: the Holder never held it and the engine never values it. No new hazard draw occurs after payment 60 completes the Agreement. A hazard draw after payment 59 can miss payment 60 and follows the same stop waterfall and sale timing as an earlier stop. A lost-conviction walk armed at payment 59, or a rational-boundary decision at payment 60 itself, can still consume payment 60 unpaid (engine.rs::run, steps 1 and 2a); those are deterministic rules, not draws.

The two lockouts

Two lockouts were reinstated on 2026-09-03 (Marc), after the ruling of 2026-08-10 that struck the July lockout ladder.

1. A person who has not yet signed gets a 60-minute window to accept a price. Letting two such windows lapse locks the person out of the program for seven days. This stops the free look at the price from being farmed.
2. A Buyer who stops, for any reason, is locked out for six months. This makes re-entering at a lower strike a six-month bet with the deposits at stake.

Neither is modelled. The engine has no notion of a person across Agreements and no re-entry; each Agreement is one Buyer, once. The July rescission ladder, escalating lockouts and Application Fee are not part of the modelled program.

No qualification and no sizing

There is no qualification of Buyers and no sizing of an Agreement to the Buyer’s cash flow (Marc, 2026-08-22: “we will NOT check eligibility, we do NOT size”; atoms R-1034 and R-1036). Four checks run before a Sale or a Transfer: identity verification, sanctions screening, a bankruptcy screen on the consumer report, and the one-Bitcoin active cap, under which a Buyer’s active coin across Agreements in force may not exceed one Bitcoin. The cap is the only sizing rule. A credit-score floor was considered on 2026-08-21 and foreclosed the next day.

The engine models none of these. It has no Buyer attributes: no score, no income, no identity, no cap. Every Agreement is one coin, which is why the engine’s book of one-coin Agreements is also a book that respects the cap. The consequence for the Holder is that the stop hazard is a prior on an unscreened population, and the behavior chapter says so.

What the engine does not model

The engine models money. It leaves out the parts of the program that move the coin or move the parties.

• The Dedicated Wallet and custody. Each Agreement’s coin sits in a per-Agreement wallet under a trust structure until completion, and on a stop the trust releases it to the Company for sale. The engine has no wallet; it prices the coin on the path and sells it at a number.
• The Transfer of the paying side. A Buyer may hand the Agreement to another Buyer (Transferor to Transferee) for a $250 transfer fee. The engine has one Buyer per Agreement for its whole life.
• The Sale of the receiving side after the Primary Sale. Secondary Sales between Holders, and the 1% facilitation fee on the value moved (Marc, 2026-08-31), are outside the engine. It models one Holder that buys at origination and holds to the end.
• Referral cuts. A Partner’s cut of the first payment (X1, ruled 50% on 2026-08-31) and of the servicing fee (X2, ruled 0 for now) are splits inside BTC Now’s take. The engine reports BTC Now’s take whole.
• The stop-sale mechanics. Venue, deadline, the record, the refund’s ten-day clock and the refund rail (dollars to the account paid from) are procedure. The engine posts the refund and the delivery at one date.
• The lockouts, above.
• Payment rails and timing inside a month. ACH, the 15 days of grace, returned payments and the reminder ladder collapse into one monthly mark.

One Agreement, three endings

Everything below is at the base terms and was run through the engine at POST /api/forwardflow/simulate with one cohort of one Agreement, zero hazard, and a constructed path (PathMode::Custom). The early completion was forced with the propensity (input #12) at 1.0 and the take-profit gate (input #22) at 0, and the stop with the lost-conviction rule (input #11) at X = 0%, Y = 1, so that each exit lands on the stated month; the dollar figures do not depend on how the exit was forced. A $60,000 coin, 1.475×, 60 payments of $1,475, Purchase Price $88,500, payment 1 to BTC Now, 5% on every delivered dollar, the Holder buys at par ($60,000), the stop sale 18 days after the missed payment, 25 basis points of sale cost, no haircut. The rates of return quoted are irr_nominal_pa from outputs.rs::analyze for that single Agreement on that path; they are not the Model Card’s book figures.

Completion

The Buyer pays $1,475 a month for 60 months and takes the coin.

The Holder’s undiscounted multiple is 1.378×. The engine prints a nominal rate of 13.1% per year (14.0% effective), a weighted average life of 31 months and payback in month 44. That is the paper’s rate with nobody stopping and nobody completing early.

Early completion at month 24

The Buyer makes 24 payments, then, with the coin at $90,000, pays the remaining schedule in cash and takes the coin.

The Holder’s total is the same $82,673.75 as at completion and its multiple is the same 1.378×; only the timing differs, and the engine prints 20.1% nominal (22.0% effective) because the money came back in two years instead of five. The Buyer’s $36,900 never enters the ledger.

A stop after twelve payments, at three prices

The Buyer makes 12 payments and misses the thirteenth. \(A = 17{,}700\), \(R = 70{,}800\), \(P = 88{,}500\). Day 16 is the Stop Date. The coin is sold 18 days after the missed date. Three prices at the sale show the three regimes. The Holder has already received 11 net payments, $15,413.75, and BTC Now has $1,475 plus 11 fees of $73.75.

Three things to read off the table.

At $40,000 the sale does not cover the remaining schedule. The Buyer gets nothing back, the Holder takes the whole $39,900 and still loses $6,681.25 on its $60,000. This is the loss the paper carries, and it is a loss on any stop where the proceeds fall below the capital line described in the risk-desk chapter.

At $75,000 the proceeds clear the remaining schedule by $4,012.50, and exactly that amount goes back to the Buyer. The Holder receives precisely the remaining schedule, $70,800 gross, and its total is the same $82,673.75 it would have received at completion. In regime 2 a stop is a completion that arrived early.

At $100,000 the proceeds exceed the Purchase Price. The Buyer gets back everything he paid, $17,700, and not a dollar more; the Holder receives the remaining schedule plus the $11,250 surplus. This is the ruling of 2026-09-03 in one row: the upside on a stop belongs to the Holder. On Bitcoin’s own history it is the row that moves the replay figures, and the Model Card says to read them with the in-the-money stop rate attached.

In every column BTC Now’s take is its fees only: the first payment, 5% of the delivered payments and 5% of the delivered proceeds. In every column the sale cash posts at month 14, the Agreement’s exit month is 13, and the Buyer receives dollars.

Where each rule comes from

The full sequence of versions, with what each one changed in the numbers, is in Versions and rulings. The formulas above are derived and tested in Contract math and the fee and The stop waterfall.