Allocation Market — the vault-capacity epoch, read by the engine #

Companion to architecture.md (the Allocation Layer in the Level-3 DAG), state-layers.md (§12, the epoch state machine), flows.md (Flow 8), event-catalog.md (§6.16–§6.17, the epoch log and the allocation stream) and matching-engine.md (§6, sleeve ceilings).

This document is DOWNSTREAM of five private authority notes — the objective note, the futarchy note, the tokenomics draft, the simulation note and the product thesis (gitignored, kept verbatim, never edited here — CLAUDE.md core law 7). Every rule below cites the note and section it restates, term by term; where a note leaves a value or a rule open, this document pins a FIELD of the epoch document, names its owner, and — since CLAUDE.md law 7(c) as — the CONFIG DEFAULT the first document carries, which the owner replaces from the next epoch (the values: futarchy-system.md §9, the system view of this layer under law 8). §15 records the rulings and the defaults by date, quoting their authors. the economics review (CLAUDE.md §2–4) holds this document to the notes and the spec-sync review holds it to its siblings.

• §1 Scope and the three vectors
• §2 Symbol table, note-scoped
• §3 The epoch document
• §4 Actors, pools, participants and stakes
• §5 The epoch log and the allocation stream
• §6 The epoch state machine
• §7 The raw allocation and the constraint-adjustment map Γ_C
• §8 The ceiling route
• §8b The capital views
• §9 The evaluation data D_T
• §10 The estimator Θ and the settlement objective
• §11 The optimizer, its certificate and its fallback
• §12 Payouts, the tax, the cap and conservation
• §13 The determinism bridge
• §14 Refusals and verification taps
• §15 Rulings, defaults and open values

1. Scope and the three vectors #

The vault supplies deployable capacity V to N − 1 bookmakers and one cash reserve. Once per epoch, a pari-mutuel market forecasts the allocation a precommitted optimizer will select after an evaluation window; the market's closing pool shares — adjusted to the declared caps — become the bookmakers' credit ceilings for the window's runs; after the window the optimizer settles the pools (the futarchy note, "Overview"). Three distinct vectors (the futarchy note, "Overview": "The proposed allocation, the implemented allocation and the settlement assessment serve different purposes"):

flowchart TB
  S["stakes"] --> WM["w^M<br/>raw market allocation"]
  WM -->|"individual, growth, leverage and group caps, the cash minimum"| WI["w^I<br/>implemented allocation"]
  WI --> CEIL["sleeve ceilings"]
  CEIL --> RUNS["the window's runs"]
  RUNS --> SER["the balance series at the snapshot interval<br/>derived from the runs"]
  SER --> EST["the estimator"]
  EST --> WS["ŵ*<br/>settlement allocation"]
  WS --> P["payouts"]
  WM -.->|"settlement prices on the RAW share"| P
  S -.->|"how long each stake stayed unchanged"| Y["participation yield"]

flowchart TB
  S["stakes"] --> WM["w^M<br/>raw market allocation"]
  WM -->|"individual, growth, leverage and group caps, the cash minimum"| WI["w^I<br/>implemented allocation"]
  WI --> CEIL["sleeve ceilings"]
  CEIL --> RUNS["the window's runs"]
  RUNS --> SER["the balance series at the snapshot interval<br/>derived from the runs"]
  SER --> EST["the estimator"]
  EST --> WS["ŵ*<br/>settlement allocation"]
  WS --> P["payouts"]
  WM -.->|"settlement prices on the RAW share"| P
  S -.->|"how long each stake stayed unchanged"| Y["participation yield"]

In scope: the vault market in USD-equivalent (the economist, 6 Oct: "Current vision is that Futarchy 1.0. operates with USD-equivalent only" — §15 D5), its epoch document, its records, its folds, its arithmetic, its identities.

Out of scope, and fenced off deliberately: the HOUSE / POL layer — its three pots, Q = aU + bC + dE, the surplus split and the treasury bonus have no engine object (core law 4; the draft itself: "the USDC sportsbetting vault remains separate and unchanged"); its "Outside the scope of this design" list is adopted whole — Burning repurchased HOUSE; HOUSE as gas or a chain security budget; Token-gated sportsbetting access; NAV redemption of POL for HOUSE; Settling allocation markets on HOUSE price; Retail leverage secured by HOUSE or a required HOUSE perpetual market; Combining LP deposits, lender principal, credit inventory and reward reserves. The vault-capacity market specified here is the futarchy note's ONE pari-mutuel market. The product thesis's per-strategy YES / NO proposal markets — the 70 / 30 split to correct predictors, the burned challenger HOUSE — are not implemented here. "Per-strategy proposal markets versus one pari-mutuel allocation market" is on core law 7's list of disagreements between the notes; under law 7(c) as amended the CONFIG DEFAULT of the shape is the ONE pari-mutuel market this document specifies (futarchy-system.md §9 C1 names both positions and why the default follows the futarchy note). The CEO's 6 Oct comment ruled out burns ("We don't do burns - this is the previous doc iterations"); it did not speak to the market shape, so §15 question 3 (the live note's question 19) still asks for the shape in writing — a ruling record replaces the default from the next epoch. The simulation note is informational: nothing in this repository reproduces it (random draws are banned in transformer code). The ONE value flow across these lines is the sanctioned one — "The USDC vault's futarchy tax τ can contribute to available protocol surplus after its obligations" — recorded here as §12's tax_recipient — of the three amounts B15 publishes for that account only tax_amount is that inflow; rounding_charge and cap_residue land with tax_recipient and count toward no surplus until a ruling (CONFIG, futarchy-system.md §9 C48 (b)). That available surplus, the credit-inventory pot bought with S_credit and the reward reserve are strictly distinct accounts, and the surplus is gated behind the vault's obligations and required reserves — so naming the account the tax goes to is not the engine's to infer from "protocol owned liquidity in a protocol owned vault": it is one CEO-owned field and the engine records the address it is given (§15 question 4); by R18 that field names the POV account, and the note's obligations gate and its surplus split apply to that account outside the engine (futarchy-system.md §9 R18).

Three other flows cross the participant/protocol line and are named here rather than left implicit. The ROUNDING CHARGE of §12 — the economist's own rule, his words quoted in §15. The protocol's own SEED in every pool, which has to be an ordinary stake for the pool to be funded, so the protocol is paid by and pays into the market like any staker (§15 question 2). And the payout cap's RESIDUE, which no note contains at all: it is the engine's proposal, its default is v1 — no cap at all — and §15 question 5 asked whether it should exist — CLOSED, no cap (§12; futarchy-system.md §9 R12).

Three accounts, and the engine holds none of them (§15 D3). The GRID discussion paper names all three — a working draft, not an authority note and not a ruling record, cited throughout this document only to corroborate what a note or a recorded ruling already carries, and closing no question; §15 states that standing in full. The underwriting vault supplies the deployable capacity V this market allocates. The prediction stake vault holds the stake pool R on the partner chain and pays the settlement out of it — a different account from the one being allocated, which is why V and R are separate fields and never net against each other. The protocol-owned vault "receives specified protocol income and pays explicitly budgeted incentives or limited loss coverage" — whether this market's tax is among that income is NOT something the paper says, and §15 question 4 still asks it. The engine records each stake as a fact citing its chain entry, computes the three vectors and the payout table, and publishes them as records anyone re-derives from the same log (§13).

A note on words: the authority notes say BOOKMAKER and the business paper says DESK or SUPPLIER DESK for the same party — the entity that quotes under a funded account. This document keeps "bookmaker", the notes' term, and "pool" for its outcome in this market.

2. Symbol table, note-scoped #

The notes overload several symbols. This document names each by its note; a letter is context-scoped where it is shared, its row naming the sections it holds in.

3. The epoch document #

One document, hashed, closed, total. Every value or rule the notes call precommitted — "fixed before the market opens", "fixed before betting begins", "published before commitments open", "must specify in advance" (the objective note, "Estimation and settlement": six items; the futarchy note, "Important Design Choices": twelve; the tokenomics draft, "Before commitments open") — is a field of one canonical byte document, encoded exactly as every record is (event-catalog §3: deterministic CBOR, integer map keys ascending, no floats, no bignum tags). Its hash is the epoch's identity:

epoch_id = BLAKE3(canonical_bytes(document)) — the run manifest's precedent (run_id = the hash of the frozen manifest, state-layers §11).

The decoder is CLOSED — an unknown field id refuses the document — and TOTAL — a missing field refuses it; no default is ever decoded in (core law 7(b): "never a code constant, never a decoder default"). A RULE field is a rule identity: {name: text, version: text, hash: 32 bytes}. Two hashes, stated apart (futarchy-system.md §2): a BLOCK's hash is the BLAKE3 over its chain element's rows (1)–(5) — inputs, outputs, config fields, params, rules — plus its declared rule text (the name and version of row (0) are labels outside the hash); a RULE FIELD's hash is the BLAKE3 over that rule's own declared text (a rule spanning several blocks — the estimator (42) for one, the arithmetic rule (32) — carries that same hash in each of its elements), carried with its own version inside the element's rules row (the name and this coverage — futarchy-system.md §2) — the engine implements exactly the versions it declares and refuses any other (event-catalog §7 rule 2's posture). The document is stored content- addressed beside the epoch log, as gate-details documents are (model-plugin-layer §10); the log's first record names its hash (§5). After that record nothing in the document changes: a second epoch_opened naming a different hash, is corrupted history — refused at the edge, a typed halt in the fold (§14).

Rationals in the document take the ONE wire form of §5 — {0: sign, 1: num, 2: den} with sign the unsigned integer 0 (non-negative) or 1 (negative), num and den big-endian byte-string magnitudes with no leading zero byte, zero spelled as the EMPTY num with sign 0 (a negative zero, a leading zero byte, a sign other than 0 or 1, den of zero, or a pair not in lowest terms refuses) — and in this document every magnitude fits 64 bits (a longer one refuses; the allocation stream's rationals, §5, may exceed it). Every nested map carries integer keys like the document itself: a rule identity is {0: name, 1: version, 2: hash}, a pool entry {0: index, 1: name, 2: sleeve_id} (sleeve_id null for cash), a chain element rows 0–5 as futarchy-system.md §2 numbers them, a rules-row entry {0: field_id, 1: name, 2: version, 3: hash}, and a params map keys, by document field id, the SYMBOL (text) in the block's declared text that the field binds — never a copy of the field's value, whose one home is the snapshot (futarchy-system.md §2; at the first epoch every block's params row is empty); every nested map is CLOSED the same way (an unknown key refused by id at its level). A chain account id (participants 23, seeder 26, tax_recipient 29) is a BYTE STRING — the partner chain's raw account bytes, no text spelling, so one account has one spelling (futarchy-system.md §11 W4). The document's byte length is capped at the run manifest's 1 MiB (MAX_DOCUMENT_BYTES — a parser-hardening cap of model-plugin-layer §16's class, not a value of the layer; futarchy-system.md §11 W6) and its nesting at the codec's depth. The DECODER enforces the table's TYPE column — the integer widths, the 32-byte hashes, the array lengths (caps and seed_units one entry per pool), the rational form and the field-49 key set — and check every INEQUALITY, the table's own (λ ≥ 0, ρ ∈ (0, 1], min_stake_units ≥ 1, seed_units[i] ≥ 1, shrink_stiffness > 0 — λ and the stiffness on v1/v2 documents, the v3 inequalities in "The v3 document") included, so shape and content refuse apart. Every array whose meaning is a SET — participants, a chain element's inputs, outputs, config and rules — is strictly ascending and distinct (byte order for accounts, record-name order for inputs and outputs, field-id order for config and rules), so one set has one spelling; pools, caps, seed_units and the chain are ORDERED by meaning (pool index; execution order). The rule-identity fields of the table (1, 6, 17, 19, 22, 27, 32, 35–38, 40–47, and 65–66 on a v2 or v3 document, 42 not on v3) are NOT keys of the document map: each lives in the rules row of exactly one chain element (futarchy-system.md §2) — except the spanning rules (32, 42, 17, 43, 6, 47, 36 and 37 — the check list below), which carry one hash in each element that declares them; under caps_rule v2 the spans read from futarchy-system.md §4's v2 rows — caps_rule (6) in B0 v2, B3 v2 and B11 v2; previous_allocation_rule (47) — its v2 text, naming both predecessor cases (a v1 predecessor's capped_share, a v2 predecessor's allocation/v2 V_i / V_prev) — in B0 v2 and B3 v2 under v2 (B11 v2 reads no w^prev); arithmetic_rule (32) in B2, B3 v2, B4 v2, B6b, B8 v3, B9 v2, B10 v2, B11 v2, B12 v2, B13 v2, B14 v2, B14b and B15 v2 (thirteen); missing_row_rule (17) and returns_rule (43) in B6 ALONE under v2 (B9 v2, B10 v2 and B12 v2 read the series, and the estimator's v2 text carries the missing-snapshot reading — C42's v2 clause, C56; under v1 B6, B9, B10 and B12); the estimator (42) in B9 v2, B10 v2 and B12 v2, the fallback rule (36) in B12 v2 and B13 v2 and the rounding rule (37) in B14 v2 and B15 v2, as under v1; 65 by B6b and 66 by B14b alone (each declared in its block's declaration as data, task 143 steps 3c and 3i) — pinned by the v2 chain's declaration (chain::declared_chain_v2, eighteen elements, task 143 step 3j-1; the totality gate tests/futarchy_chain_v2.rs); under caps_rule v3 the spans read from futarchy-system.md §4's v3 rows — caps_rule (6) in B0 v3, B3 v3 and B11 v3; previous_allocation_rule (47) in B0 v3 and B3 v3; arithmetic_rule (32) in B2, B3 v3, B4 v2, B6b v2, B8 v4, B11 v3, B12 v3, B13 v3, B14 v3, B14b v2 and B15 v3 (eleven); missing_row_rule (17) and returns_rule (43) in B6 alone; the fallback rule (36) in B12 v3 and B13 v3; the rounding rule (37) in B14 v3 and B15 v3; 65 by B6b v2 and 66 by B14b v2; the estimator (42) named by no element and outside the v3 totality set — pinned by the v3 chain's declaration (declared_chain_v3(), sixteen elements); under caps_rule v4 the spans read from futarchy-system.md §4's v4 rows — caps_rule (6) in B0 v4, B3 v4 and B11 v4; previous_allocation_rule (47) in B0 v4 and B3 v4; arithmetic_rule (32) in B2, B3 v4, B4 v3, B5 v5, B7 v6, B6b v3, B8 v4, B11 v4, B12 v3, B13 v3, B14 v4, B14b v3 and B15 v4 (thirteen — B5 v5 floors exact rationals onto the allocation grid and B7 v6 re-holds its usable line); missing_row_rule (17) and returns_rule (43) in B6 v3 alone; the fallback rule (36) in B12 v3 and B13 v3; the rounding rule (37) in B14 v4 and B15 v4; 65 by B6b v3, 66 by B14b v3 and window_rule (40) v5 by B7 v6; the estimator (42) named by no element — pinned by the v4 chain's declaration (declared_chain_v4(), sixteen elements); fields 80 and 81 are document keys, not chain rows — and the decoder's TOTALITY over them is the check that every such id is named by at least one element, a non-spanning id by exactly one. The decoder is total over the document's VALUE keys per payout_cap_rule's version — field 49 present if and only if that rule is v2 — and refuses the retired id 20 as unknown. Money is an integer count of money_unit; capacity is integer mills (the engine's own unit, matching-engine §1). The scenario's run report prints each cycle's document under these field names as cycles[].configuration (futarchy-system.md §7 "The run report").

The v2 document (its fields and checks BUILT, task 143 — futarchy::document::CapsRuleFields; B3 v2, B4 v2, B6b, B8 v3, B9 v2, B10 v2, B11 v2, B12 v2 and B14b built as functions — task 143 steps 3b–3i — and the v2 chain BUILT as data, task 143 step 3j-1: chain::declared_chain_v2 names B0 v2, B1, B2, B3 v2, B4 v2, B5 v2, B6, B7, B6b, B8 v3, B9 v2, B10 v2, B11 v2, B12 v2, B13 v2, B14 v2, B14b and B15 v2, a v2 document passes B0 under it, and chain::declared_chain_for is the one dispatch on the version; the composition's v2 branch folds a v2 epoch through epoch_settled, task 143 step 3j-2). A document whose caps_rule (6) is version 2 carries the value keys 57–64 and names the rule identities 65 and 66 in its chain, pins stake_mobility (56) to moves (the note: stakes may be added and reallocated, never withdrawn — none and withdrawals are refused on it, futarchy-system.md §9 C12), and refuses 5, 9, 14 and 55 as unknown keys; its checks: 0 ≤ cash_min < 1, 0 < cap_single ≤ 1, cap_groups sizes distinct ascending ≥ 2 with each cap in (0, 1], leverage_max > 0, allocation_precision ≥ 1, own_capital one entry per pool with cash 0, window_blocks a multiple of snapshot_blocks (SnapshotGrid), vault_capacity_mills a multiple of allocation_precision (PrecisionGrid — so the floored capacities ⌊D w_i⌋ V / D are whole mills and §7's one rounding stays one; futarchy-system.md §9 C63); the v1 checks below that name caps, liquidity_buffer_min, winsor_q95 or bookmaker_cap_max are v1's; a document whose caps_rule is version 1 decodes as before (its byte form unchanged); every chain element naming caps_rule carries the same version, else the decoder refuses (CapsRuleVersionDisagrees), and a version that is neither 1 nor 2 is refused, never read as v1; a chain element's params key of the other version's set is unknown too (W5). On a v2 document the transition check is the link and the successor slot alone — there is no caps field to hold equal, Γ_C v2 forms G_i from the predecessor's recorded share inside B3 (futarchy-system.md §4 B0, B3). The ranges of fields 59–62 are DOMAIN checks of the engine (CONFIG C70 — the note states values, R29–R32, no ranges): c_c < 1 because at c_c = 1 every allocation but the all-cash point is refused and the market has nothing to allocate; the rest the unit interval and positivity. The rule version selects the known-key set — the precedent of field 49 under payout_cap_rule v2 (futarchy-system.md §9 C-table; the economist's note of 19 October 2026 is the source of every v2 value).

The v3 document (the Note on Futarchy as rewritten — futarchy-system.md §9 R53; its chain declared_chain_v3(), futarchy-system.md §4). A document whose caps_rule (6) is version 3 carries v2's value keys 57–64 and the eight keys 70–77, names the rule identities of the v3 chain, and refuses 10, 13, 15 and 16 as unknown keys — the four scoring fields the note retires (the one λ, cash's one return, the shrinkage prior and its stiffness) — beside 5, 9, 14 and 55; the key count is 45, 46 with payout_cap_vmax (49) under payout_cap_rule v2, one key more, 46 or 47, with the optional retail_fee_rule (79, risk-engine.md §7) — v2's keys less 10, 13, 15, 16, plus 70–77, feed_rules (78) and margin_trigger (67) and liquidation_trigger (68), which its risk chain (declared_risk_chain_v3(), futarchy-system.md §6: R7 v2, R0 v1, R1 v2, R2 v2, R5 v1, R6 v1, R6b v1), naming R7 first and R5, R6 and R6b after the admission blocks, requires by the key-set rule below, so the allocation-side keys alone count 42, 43 with field 49. Its checks are v2's, less the two that name a retired field (λ ≥ 0, shrink_stiffness > 0), plus λ_d ≥ 0, λ_w ≥ 0, r_c ≥ 0, 1 ≤ h_w ≤ K with K = window_blocks / snapshot_blocks (WeeklyHorizon — the weekly sample is never empty), 1 ≤ p ≤ 18 (CashReturnPrecision — a and 10^p inside the 64-bit magnitudes of the document's rationals, §5), each cash pin's lowest-terms denominator dividing 10^p, and THE BRACKET CHECK (CONFIG, futarchy-system.md §9 C94): for the pin R = a / 10^p at d days — d = 1 for 74, h_w for 75, K for 76 (one snapshot is one calendar day, C96) — and r_c = u / v in lowest terms, (10^p + a)^365 · v^d ≤ (v + u)^d · 10^{365p} < (10^p + a + 1)^365 · v^d, the truncation's two inequalities a / 10^p ≤ (1 + r_c)^{d/365} − 1 < (a + 1) / 10^p raised to the 365th power; it forms no irrational and accepts exactly one a per pin (CashReturnBracket(h) otherwise), and every integer it forms is held to CASH_BRACKET_BITS_MAX = 65 536 bits (2^16), a code constant of the serialization class beside RATIONAL_BITS_CEILING (futarchy-system.md §11 W11), a wider one refusing the document. The cap covers p ≤ 18, d ≤ 366 and any rate within the 64-bit magnitudes: every integer the check forms, accepted pin or not, is below 2^47 149 — (v + u)^d · 10^{365p} below 2^{366 · 65 + 365 · 60} (with u + v < 2^65, 10^18 < 2^60), and (10^p + a + 1)^365 · v^d below 2^{365 · 65 + 366 · 64} (with 10^p + a + 1 < 2^65, v < 2^64) — and the fixture's integers are 14 558, 14 604 and 14 781 bits. Every chain element naming caps_rule carries version 3 (CapsRuleVersionDisagrees otherwise); a version other than 1, 2, 3 or 4 is refused, never read as an earlier one; a v1 or v2 document carrying any of 70–77 is refused as an unknown key.

The v4 document (overlapping epochs — futarchy-system.md §4 "The v4 chain", §9 C110; its chain declared_chain_v4()). A document whose caps_rule (6) is version 4 carries the v3 document's keys and checks unchanged plus carry_scoring_rule (80) and carry_budget_rule (81), both required (CarryRulesMissing), each pair naming a declared version of its rule (CarryScoringRule, CarryBudgetRule); the key count is the v3 count plus two — 47, 48 with payout_cap_vmax (49) under payout_cap_rule v2, one key more with the optional retail_fee_rule (79), 48 or 49; a v1, v2 or v3 document carrying 80 or 81 is refused as an unknown key. Its successor check is B0 v4's overlap admission (the document checks below), and every chain element naming caps_rule carries version 4 (CapsRuleVersionDisagrees otherwise).

The v5 document (the credit economics — futarchy-system.md §4 "The v5 chain", §9 C134–C138; its chain declared_chain_v5(), its risk chain declared_risk_chain_v4()). A document whose caps_rule (6) is version 5 carries the v4 document's keys and checks unchanged plus the eight credit fields 82–89, every one required (CreditFieldsMissing): the three profit shares 82–84 rationals within [0, 1] summing to exactly 1 (ProfitSharesNotOne), grid_fee_fixed (85) and pov_reserve (88) capacity mills, grid_fee_share (86) and liquidation_fee (87) rationals within [0, 1], profit_attribution_rule (89) a rule identity naming a declared version (ProfitAttributionRule); the key count is the v4 count plus eight — 55, 56 with payout_cap_vmax (49) under payout_cap_rule v2, one key more with the optional retail_fee_rule (79), 56 or 57; a v1–v4 document carrying any of 82–89 is refused as an unknown key, and a v5 document lacking one CreditFieldsMissing. Its successor checks are B0 v4's overlap admission unchanged (a v5 successor opens while its predecessor is still live, so no closing balance of the predecessor exists at admission — THE CUSHION CARRY of C138 is RC1's read at the successor's own settlement, risk-engine.md §6, never a document refusal), and every chain element naming caps_rule carries version 5 (CapsRuleVersionDisagrees otherwise). A v4 document decodes and runs unchanged under its own chain; the v5 chain's rows (futarchy-system.md §4 "The v5 chain") are the v4 chain's with B0, B3, B11 and B15 re-declared at their next versions and the allocation stream's v5 layout (§5).

Document checks (before stakes open; a failure refuses the document, §14): pools[0].index = 1 with sleeve_id null and caps[0] = 1 (w̄_1 = 1); 0 < w̄_i ≤ 1; Σ_i w̄_i ≥ 1 (true by w̄_1 = 1 — "the feasibility condition is automatically satisfied because w̄_1 = 1" (the 2 October text, cash Q/A) — checked, never assumed); the caps are caps_rule v1's OUTPUT, checked EQUAL (the equality reading — CONFIG, futarchy-system.md §9 C20: the 2 October text's ("Objective and constraints") "w̄_i = C_i(·) … fully specified before the market opens" over the objective note's constraint 2 as a bare inequality, so that the rule's hash determines the caps field): for each bookmaker pool with a previous allocation w̄_i = min(bookmaker_cap_max, n · w^I_{i,prev}) (55; constraint 2 under the per-bookmaker ceiling) and for each without one w̄_i = ε₀ (the bootstrap — ε₀ applies ONLY where there is no previous allocation, the objective note's own placement; a previous implemented share is never 0, since every R_i > 0 and Γ_C leaves every pool positive, so no floor is needed on the first form, and a RECORDED previous share that is not positive — exactly 0, or a negative one Γ_C cannot produce, were one ever recorded — counts as NO previous allocation, so the bootstrap ε₀ applies and no bookmaker is locked out by a required cap of 0 — C20); ridge_epsilon > 0; shrink_stiffness > 0; alpha ∈ (0, 1); open_height < close_height; window_blocks ≥ 1; min_distinct_matches ≥ 1 (MatchFloorZero, futarchy-system.md §9 C6 — a floor of 0 would settle a window with no evidence); vault_capacity_mills ≥ 1 (Range(3) — B8 divides by V); field 51 equals the recomputed system hash; Σ_i w̄_i computed exactly over a common denominator in a 128-bit accumulator, a sum that does not fit being a typed refusal and never a wrapped value; the transition's product n · w^I_{i,prev} reduced to lowest terms over 128-bit intermediates and compared by cross-multiplication in 128 bits, a reduced magnitude above 64 bits being the typed refusal TransitionOverflow, never a wrapped value — the predecessor's capped_share reaching the check keyed by sleeve_id (the bookmaker's identity across epochs; cash by its null), a magnitude over 64 bits refused at that input; every rule-identity field named by exactly one chain element, except the spanning rules — arithmetic_rule (32) in B2, B3, B4, B8–B15, estimator_rule (42) in B9, B10, B12 (v1/v2; named by no v3 element), and missing_row_rule (17) and returns_rule (43) in B6, B9, B10 and B12 under v1 (B6 records the row; B9, B10 and B12 form R_it and write the zero when they form the matrix; under v2 B6 alone — §3), and caps_rule (6) and previous_allocation_rule (47) in B0 and B11 (B0 checks the caps and reads w^prev; B11 shares the caps rule's no-previous-allocation test over the same recorded capped_share — the ε₀ floor itself is C28, in B11's own text) — under v2 6 in B0, B3 v2 and B11 v2 and 47 in B0 and B3 v2 (B11 v2 reads no w^prev, §3) — each and fallback_rule (36) in B12 and B13 (B12 writes the fallback's w^M; B13's tax is decided by the rule's version — v2 taxed, with a producer; v1 untaxed, declared), and rounding_rule (37) in B14 and B15 (B14 floors each payout under it; B15's charge bound is v1's) — with ONE hash in every element that carries it (futarchy-system.md §2, §9 C23); the chain is a DAG over the root streams and names only rule identities the engine implements, one element per block of futarchy-system.md §4 (and risk_chain one per existing block of risk-engine.md §3); fields 67 and 68 present exactly when the risk chain names R5, R6 or R9, 69 when it names R4, 78 when it names R7, 79 only when it names R2 v2 (optional), 80 and 81 exactly when caps_rule is v4 (required there), with t_m ≤ t_l and field 78 shaped as its row states (risk-engine.md §7's key-set rule; a document not naming R7 keeps its bytes); liquidity_buffer_min = 0 under gamma_c_rule v1 (a buffer above 0 is refused HERE, at the document, not after the close — §7); for a non-genesis document whose caps_rule is 1, 2 or 3 open_height ≥ the predecessor's TERMINAL height — its epoch_settled, or its epoch_aborted after an allocation — and, after an aborted successor, ≥ that abort row's height too; close_height > open_height; the registry refusing a successor while the predecessor is still live (PredecessorLive) — the CEO's ruling that cycles do not overlap on a v1, v2 or v3 chain (futarchy-system.md §3, §9 R19, C7), replacing the abutting equality close_height = close_height(predecessor) + window_blocks(predecessor), retired before any epoch ran — and for a caps_rule v4 document B0 v4's OVERLAP ADMISSION in its place (futarchy-system.md §3, §4 "The v4 chain"; CONFIG C110): admitted while the predecessor is still live once its allocation record is recorded, open_height ≥ that record's height (OpenBeforeAllocation), close_height ≥ the predecessor's deadline close_height(predecessor) + window_blocks(predecessor) (CloseBeforeDeadline), a v1–v3 predecessor admitting a v4 successor under R19 alone, and a v4 predecessor's slot reading live to every claimant but a v4 claimant its overlap arm admits, until its capital is released (§8b), so a v1–v3 successor of it is refused PredecessorLive until that release — the predecessor being the epoch registry's latest epoch with an allocation record and no successor registered yet (read: an OPEN successor leaves the predecessor the answer with its slot Taken; an ALLOCATED successor becomes the answer; futarchy-system.md §3) — a registered successor that ABORTED before reaching allocation (an unseeded or unfunded pool, or no votes, at its close) frees the slot, so the lineage never loses its admissible predecessor; a predecessor's own later abort (too few matches, an unjudged run) does not unmake the allocation it implemented, and its successor's caps stand on the recorded capped_share; a GENESIS document (field 39 the anchor) is admitted only when the registry holds no epoch THAT COUNTS FOR ADMISSION — a second lineage cannot open beside a live one; an epoch that aborted before reaching allocation, genesis or successor, is recorded but does not count, and the replacement genesis opens at or after its abort height (CONFIG C51, futarchy-system.md §3, §9 — the registry: futarchy::registry, the loader's admit run before check_transition, the answer rebuilt from the stored epochs alone as of the opening); a REPLACEMENT successor (the slot freed by a pre-allocation abort) needs open_height ≥ the aborted successor's abort height (and, as for any successor, ≥ the predecessor's terminal height under R19) and close_height > open_height (futarchy-system.md §3); 0 ≤ liquidity_buffer_min ≤ 1 (above 1 the feasible set is empty); v_max ≥ 1 when payout_cap_rule is v2, and absent under v1 (the decoder's two typed refusals PayoutCapVmaxPresentUnderV1 and PayoutCapVmaxMissingUnderV2; and, since the version is read from the chain, PayoutCapRuleUnnamed when no element names field 27 and PayoutCapRuleVersionUnknown for a version that is neither 1 nor 2 — never read as v1); pool_tax ∈ [0, 1); 0 < bookmaker_cap_max ≤ 1; the table's own inequalities — λ ≥ 0, ρ ∈ (0, 1], min_stake_units ≥ 1, n > 0 (a zero or negative multiplier would make every grown cap 0, which 0 < w̄_i refuses), ε₀ ∈ (0, 1] (a new bookmaker's cap IS ε₀, so it must be a cap), winsor_q95 ≥ 0 (a level on the POSITIVE returns, the objective note's "Returns") — performed by check with the rest; 128 ≤ rational_bits_max ≤ MAX_RATIONAL_BITS − 128 (RATIONAL_BITS_CEILING, 8 064) and the pool count at most MAX_POOLS (256 — the two hardening caps of futarchy-system.md §11 W8–W9, the floor their companion); every seed_units[i] ≥ min_stake_units (so ≥ 1); seeder ∈ participants; under the document-check version futarchy-system.md §9 C92 declares, seeder ≠ tax_recipient and tax_recipient ∉ participants (PovListed, futarchy-system.md §9 C92) (from the first epoch whose rule chain declares it, every epoch before it carrying no such check unchanged); tax_recipient present (the decoder's totality — a missing key refuses); the sleeve ids distinct and none 0 (0 is the envelope's system sleeve, event-catalog §4); every rule identity one the engine implements — at this phase the set the futarchy crate DECLARES (futarchy-system.md §4 B0–B15, §6 R0–R2, R2 v2 and R7 v1, v2 with producers, R7's the scheduler's feed fold since gate G8, risk-engine.md §9), the declared set being the implemented set until a fold block exists. Group rows Aw ≤ b (the objective note, constraint 3) are not a field under caps_rule v1 (a document carrying them was refused for want of a NUMBER); cap_groups (61) carries them on a v2 document — Γ_C's behaviour under them is declared (futarchy-system.md §9 R11), gamma_c_rule v2 carries it when a row is given (§15 D7). They are expected — the objective note's own constraint 3 offers group caps through Aw ≤ b, and its constraint 5 puts "compliance, solvency, and risk limits" there too, so the refusal is this document waiting for a rule it knows is coming rather than a claim that none is needed.

4. Actors, pools, participants and stakes #

• Pools. Outcome i = 1 is CASH — "Reserve outcome 1 for cash and interpret N as the total number of allocation outcomes: cash plus N − 1 actual bookmakers" (the 2 October text, cash Q/A); its implemented share w^I_1 V "stays in reserve" (the 2 October text, cash Q/A); its bettors "forecast the optimal cash weight and receive pari-mutuel payouts; their stakes do not earn μ₁ directly". Outcomes 2..N are bookmakers, each the owner of ONE SleeveId (stream-core's SleeveId(u32)) under which it quotes in every run of the window — the engine's bookmaker identity across runs.
• Participants (the 2 October text's "Active LPs", staking "based on their forecasts of ŵ*_T"): the chain accounts in participants. A stake from any other account is refused at the edge (§5).
• Stakes. r_ij is participant j's NET POSITION on pool i — the sum of that participant's stake rows on the pool net of that participant's withdrawals from it — an integer of money_unit; R_i = Σ_j r_ij, R = Σ_i R_i (the futarchy note, "Pool balances and market allocation" — its S = Σ_i S_i). Every stake ROW is at least min_stake_units, and a withdrawal must leave the net position either 0 or at least min_stake_units (so the minimum binds positions, not only rows). Every stake is a RECORDED FACT — the chain transaction that moved the asset into the chain's vault, its block height, the participant, the pool, the amount. The engine keeps no balance: "if you mean here by prediction pool, then this is where we have an onchain vault in our blockchain to hold funds of our predictors" (the CEO, §15 D3) — the PREDICTION STAKE VAULT of §1, which the GRID discussion paper separates from the underwriting vault this market allocates.
• Seeds, and why an unseeded pool aborts. The seeder's stake of at least seed_units[i] on every pool is the 2 October text's ("Initial stakes and allocation") "real initial stakes r_i1 > 0 … positive initial stakes ensure that every pool is funded and settlement odds are defined"; it is an ordinary stake record (it pays out like any other); the 19 October note keeps the requirement as "Stakes cannot be withdrawn. Reallocation must preserve a positive total stake in every outcome" ("Opening and initial stakes", R36). The 2 October text also states the standing requirement "The protocol should require R_i > 0 ∀i until settlement" — and the arithmetic needs it: v_i = ŵ*_i / w^M_i divides by R_i. The engine cannot create a stake, so it cannot repair an unseeded pool: at the close, a pool with R_i = 0 aborts the epoch and every net position is returned in full (§6). That refusal is the document's own seed_units/seeder fields doing their work; whether an epoch should instead proceed on the funded pools alone is the CEO's and the economist's call (§15 question 8), and until they say so the abort is the CONFIG default (futarchy-system.md §9 C8 — the live note's question 15, this document's question 8).
• Order and close. The epoch log's order IS the SEQUENCER's acceptance order — "this is FIFO in terms of accepted stake in our sequencer" (the CEO, §15 D12); the book closes at close_height M — "if the cut off window for a prediction market is N time, then we cut off at block M that correlates to N time"; the engine reads FINAL blocks only — "Celestia DA is only the finality layer for our chain to settle its rollup blocks". A stake at a height ≥ M is refused at the edge; a recorded one halts.
• Withdrawal exists only under stake_mobility (56) withdrawals: 0 ≤ x_i ≤ r_ij, R_i − x_i > 0, and the net position left is 0 or at least min_stake_units (the 2 October text, "Changing bets and withdrawal" — "the protocol should require R_i > 0 ∀i until settlement"), as a stake_withdrawn record citing the chain's refund entry; "does not allow withdrawals after close" (the 2 October text, "Collateral and Accounting") — a withdrawal at height ≥ M is refused. RULED by the CEO, 2026-10-13: "A person can rebalance their votes, but pulling out is generally prohibited" — a MOVE between pools is allowed, an exit is not. The move is the note's pure reallocation: x leaves the source pool i under the bounds above (0 ≤ x ≤ r_ij, R_i − x > 0, the position left 0 or at least min_stake_units) and the same x enters the target pool k under the stake rules above — read (CONFIG): as a stake ROW, x ≥ min_stake_units, onto a pool that already has its first row (a move never seeds a pool), and the seeder's position on a pool never falls below seed_units[i] (v1; RETIRED on a v2 document — futarchy-system.md §9 C12, R36: initial stakes follow the same rules as later stakes) by a move or a withdrawal (the seed is the pool's floor; its hook the 2 October text's design choice ("Important Design Choices") "minimum seed balances and treatment of empty pools", a choice the 19 October note decides against a floor ("Opening and initial stakes", R36) — that text bounds a withdrawal by 0 ≤ x ≤ r_ij and R_i − x > 0 and its pure reallocation ("Changing bets and withdrawal") adds no other bound, so both readings are STRICTER than the note, and under the floor the seeds are not "freely reallocatable", leaving the note's consistency assumption 6 on "negligible relative to equilibrium market depth") — so r_ij' = r_ij − x, r_kj' = r_kj + x, R_i' = R_i − x, R_k' = R_k + x and R' = R; the raw shares move by x/R from i to k and w^I = Γ_C(w^M') is re-applied after the move (§7). It is ONE stake_moved record {participant, from_pool, to_pool, amount, tx_id, height} folded atomically, paid at settlement as the positions it left — r_ij − x on i, r_kj + x on k (§12). "Generally prohibited" is read with no exception (CONFIG): an exit before the close is refused outright. The row and the three-way stake_mobility field (56; 30 retired) have a producer (futarchy-system.md §5, §9 C12 and R16); the refund and payout order is each position's FIRST row of any kind — a position born by a move takes the move's offset, a position drained to 0 keeps its first offset.

5. The epoch log and the allocation stream #

Two streams, two writers (one writer per stream — the stream law).

The epoch log (ROOT, one per epoch, fsync-before-ack, event-catalog §5): its one writer is the epoch gateway, an impure edge component (⚠ in the DAG) that (a) records the operator's two actions and (b) tails the partner chain's FINAL blocks for stakes into the vault — a partner feed, so it owes data-conformance (both tiers) and the security review when a parser exists. Its records (grouped by kind, not by append order — a run_included row can only follow the close, as its own column says):

The stake_moved row follows the CEO's ruling that votes move but never leave (§4; futarchy-system.md §9 R16).

Refused at the edge — never appended — and a typed halt if ever recorded (§14): a stake from an unlisted participant or on an unlisted pool, below the minimum, at height ≥ M, below open_height, ahead of the latest recorded final block, repeating a tx_id, or a non-seed first row on a pool; a withdrawal under a stake_mobility other than withdrawals, beyond the position, zeroing the pool, leaving dust, or taking the seeder's position below its seed; a move under none, from an unlisted participant, below open_height, at height ≥ M or ahead of the latest final block, repeating a tx_id, onto the same pool, on an unlisted pool, beyond the position, zeroing the source pool, leaving dust, below the minimum, onto a pool before its first row, or taking the seeder's position below its seed; a run_included whose manifest fails §8's check.

The chain reader's four feed rules (the partner-feed obligations D12 brings with it — "an external feed with its own conformance checks and a finality rule"): (1) FINALITY — only blocks the chain reports final are read, so a re-org below the finality depth cannot change what is already recorded; a chain that reports a different hash for an already-recorded height is a feed violation and halts the epoch (§14), never a rewrite — history only grows (the stream law). (2) CONTIGUITY — heights are consecutive with no gap, so "every final block" is checkable from the log itself rather than trusted; a gap refuses at the edge, and a reader that cannot reach a height does not append past it. (3) ONE READER — the gateway is the log's only writer, so a stake reaches the log once. The finality depth and the chain's own conformance checks are the feed's, named in the epoch document's chain_feed_rule, whose declared text fixes the depth; data-conformance (both tiers) and the security review gate the reader when a parser exists. The FOURTH rule : a block's block_final row precedes the stake, withdrawal, move and top-up rows of that block (risk-engine.md §8) — a stake at a height above the latest recorded final height, or below open_height, is refused — and a tx_id appears at most once in an epoch's log (a replayed row is refused, never counted twice).

The allocation stream (DERIVED, recomputable, written by the allocation fold — one fold per epoch, consuming the epoch log and, after inclusion, each included run's sealed lifecycle, market-event and settlement streams and its manifest):

Rationals on the wire are {0: sign, 1: num, 2: den} — sign the unsigned integer 0 (non-negative) or 1 (negative), num and den big-endian byte-string magnitudes with no leading zero byte, zero spelled as the EMPTY num with sign 0, den ≥ 1, the pair in lowest terms — one encoding per value, as event-catalog §3 rule 5 requires (that section's "no bignums" names the CBOR bignum tags 2 and 3; a declared byte-string field carrying an arbitrary-precision integer is not a tag, and byte strings are among its allowed types). The same form carries the document's rationals (§3, where every magnitude fits 64 bits); on the STREAM the magnitudes of estimate and settlement may exceed 64 bits (the optimizer's outputs), and every quantity that is not a rational is an integer. Schema ids: the six epoch-log records and document_checked, book_closed, raw_share, capped_share, allocation, epoch_aborted, return_observed (1_000_042) (B6) and the seventh epoch-log record stake_moved (1_000_043), and window_closed (1_000_044) (B7) and utilization (1_000_045) (B8) and winsorized (1_000_046) (B9 — v1/v2 only) and estimate (1_000_047) (B10 — v1/v2 only) and feasible_set (1_000_048) (B11) and settlement (1_000_049) (B12's record with its first declared consumer, the certificate's verifier) and pool_liability (1_000_050) (B13) and stake_payout (1_000_051) (B14 — its first producer extending the reserved region to ..=1_000_052) and epoch_settled (1_000_052) (B15 — the v1 region's last id) (1_000_030..=1_000_052 the v1 region; capped_share/v2 1_000_055 and allocation/v2 1_000_056 MINTED by B3 v2 and B4 v2 (task 143 step 3b), balance_series/v1 1_000_053 by B6b (step 3c), utilization/v2 1_000_057 by B8 v3 (step 3d), winsorized/v2 1_000_058 by B9 v2 (step 3e), feasible_set/v2 1_000_059 by B11 v2 (step 3g), settlement/v2 1_000_060 by B12 v2 (step 3h) and participation_yield/v1 1_000_054 by B14b (step 3i) — the extension complete, C61; run_included/v2 1_000_068 past the risk engine's 1_000_061..=1_000_067 (B5 v3; those seven minted by their first producers, risk-engine.md §11); the v3 layout's records balance_series/v2 1_000_069 (B6b v2) and settlement/v3 1_000_070 (B12 v3), each by its first producer, and epoch_aborted/v2 1_000_072 (B1 v2 and B7 v5, the v3 chain's one abort record; 1_000_071 unminted); event-catalog §6.16–§6.17, §7 rule 4 — an id mints with the first producer or the first declared consumer); every record of the v1 chain is minted.

The v2 records and their offsets (the ids of capped_share/v2, allocation/v2, balance_series/v1, participation_yield/v1, utilization/v2, winsorized/v2, feasible_set/v2 and settlement/v2 MINTED, task 143 steps 3b–3i, their offsets with the v2 chain — B12 v2 stamps settlement/v2 at window_seq + 6 already and B14b stamps its rows from the first_seq the composition supplies — futarchy-system.md §4 B6b, B14b, §9 C61): balance_series/v1 (1_000_053) after window_closed; participation_yield/v1 (1_000_054) after the last stake_payout and before epoch_settled; capped_share/v2, allocation/v2, utilization/v2, winsorized/v2, feasible_set/v2, settlement/v2 (1_000_055–1_000_060) in their blocks' places. The settling layout from window_closed at window_seq becomes: balance_series at +1, utilization +2, winsorized +3, estimate +4, feasible_set +5, settlement +6, pool_liability +7, the m payouts at +8 + ℓ, the Y yield rows at +8 + m + j, epoch_settled at +8 + m + Y (BUILT: these are chain::Layout::V2's fields — the layout table, the one home of the offsets, which the composition hands every block it stamps and the registry's walker reads, task 143 steps 3j-1 and 3j-2 — and the composition stamps these places on a v2 epoch, B14b's first row at the layout's yield_first(m); the v1 offsets of this section and of futarchy-system.md §9 C49–C50 are Layout::V1's).

The v3 records and their offsets (futarchy-system.md §4 B6b, B12; event-catalog §6.17): balance_series/v2 (1_000_069) and settlement/v3 (1_000_070), and epoch_aborted/v2 1_000_072 (B1 v2 and B7 v5, the v3 chain's one abort record; 1_000_071 unminted); winsorized and estimate are written by no v3 block. The settling layout from window_closed at window_seq on a v3 epoch (chain::Layout::V3): balance_series/v2 at +1, utilization/v2 +2, feasible_set/v2 +3, settlement/v3 +4, pool_liability +5, the m payouts at +6 + ℓ, the Y yield rows at +6 + m + j, epoch_settled at +6 + m + Y. On a caps_rule v5 epoch (chain::Layout::V5) the layout is the v3 layout through the yield rows, then the credit-economics chain's 6n rows BLOCK-MAJOR — every bookmaker pool's desk_period_result (RC1), then every pool's liquidation_fee (RC2), profit_split (RC3), loss_waterfall (RC4), grid_fee (RC5), desk_account (RC6), the pools ascending inside each block, n the document's bookmaker pools — at +6 + m + Y + r (r = 0 … 6n − 1), and epoch_settled at +6 + m + Y + 6n (futarchy-system.md §4 "The v5 chain", B15 v5; event-catalog §6.17). Under a document whose risk chain names R5–R6b (the v3 document's) the desk records stand among B6's rows in the one total order, so every later record's offset — return_observed row k, window_closed's window_seq and every window-derived offset above — is its layout offset shifted by the desk records before it, the composition's layout assigning it, the window-derived records keeping their relative order (risk-engine.md §11).

6. The epoch state machine #

State is the fold of the two streams above (state-layers, the state law); every transition names its record.

stateDiagram-v2
    [*] --> Declared: epoch_opened / document_checked
    Declared --> Declared: block_final
    Declared --> Open: stake_recorded
    Open --> Open: stake_recorded / stake_withdrawn / stake_moved / block_final
    Declared --> Aborted: epoch_aborted
    Open --> Aborted: epoch_aborted
    Open --> Closed: book_closed
    Closed --> Implemented: raw_share / capped_share / allocation
    Implemented --> Implemented: run_included / run_verdict / return_observed / block_final / desk_topup / margin_called / margin_cleared / liquidated / defaulted
    Implemented --> Observed: window_closed
    Implemented --> Aborted: epoch_aborted
    Observed --> Settled: balance_series / utilization / [winsorized / estimate — v1/v2] / feasible_set / settlement / pool_liability / stake_payout / participation_yield / epoch_settled
    Settled --> [*]
    Aborted --> [*]

stateDiagram-v2
    [*] --> Declared: epoch_opened / document_checked
    Declared --> Declared: block_final
    Declared --> Open: stake_recorded
    Open --> Open: stake_recorded / stake_withdrawn / stake_moved / block_final
    Declared --> Aborted: epoch_aborted
    Open --> Aborted: epoch_aborted
    Open --> Closed: book_closed
    Closed --> Implemented: raw_share / capped_share / allocation
    Implemented --> Implemented: run_included / run_verdict / return_observed / block_final / desk_topup / margin_called / margin_cleared / liquidated / defaulted
    Implemented --> Observed: window_closed
    Implemented --> Aborted: epoch_aborted
    Observed --> Settled: balance_series / utilization / [winsorized / estimate — v1/v2] / feasible_set / settlement / pool_liability / stake_payout / participation_yield / epoch_settled
    Settled --> [*]
    Aborted --> [*]

Every arrow names the records that cause it, and the conditions are these. epoch_opened carries the document's hash and its system hash, the document having passed §3's checks, which the fold re-runs as document_checked (futarchy-system.md §4 B0). block_final repeats through the window's deadline and grace, the heights contiguous from open_height. stake_withdrawn appears only under stake_mobility withdrawals, stake_moved under moves or withdrawals, both within §4's bounds. The book CLOSES on the first block_final at or above M with every pool seeded and positive and at least one vote; if any pool is unseeded (no row at all) or short of seed_units[i] (the seeder's first row below it), epoch_aborted{pool_unseeded} is emitted instead, naming the LOWEST-INDEX failing pool, and epoch_aborted{pool_unfunded} for a seeded pool at R_i = 0 there (a defensive arm — the seed is at least min_stake_units ≥ 1 and a withdrawal or move that would zero a pool halts, so no legal log reaches it), and epoch_aborted{no_votes} when every position above zero is the seeder's (R20; C8's state reading, CONFIG — a seeder's top-up is not a vote, a voter who fully withdrew holds none); every net position returned in full in the order of its first row of any kind; a first row that is NOT the seeder's is not an abort but corrupted history — the edge refuses it (event-catalog §6.16) and the fold halts on a recorded one (§14). raw_share, capped_share and allocation compute w^M, w^I and the capacities V_i (§7), which the window's run manifests then cite (§8). desk_topup is admitted in Implemented at heights at or above M (risk-engine.md §4). run_included and run_verdict repeat once per run (under window_rule v4 a recovered run has two run_verdict rows, failed then the rebuilt record's verified), and return_observed once per Verified verdict in verdict order, until the window's deadline (§9); at the close instant — the first final at or above the deadline by whose height every included run has its verdict row (futarchy-system.md §9 C37; under window_rule v4 its Verified row, a Failed row keeping the window pending until the rebuilt record's Verified row — futarchy-system.md §9 C99), and no later than the grace end — window_closed is appended, or epoch_aborted{too_few_matches} when fewer than min_distinct_matches distinct matches were observed (retired from the first epoch whose rule chain declares the replacing B7 version, once that version is declared with the economist's sparse-evidence rule — futarchy-system.md §9 R52, C6, C8; every epoch before it aborts as written — under B7 v4 and v5 (B7 v5 the v3 chain's) a window below min_distinct_matches closes with the count reported and B12 v3 settles on the fallback (futarchy-system.md §9 C93); the abort clause is B7 v2/v3's), or epoch_aborted{run_unjudged} when an included run still has no run_verdict row at the grace end (decided at the first final above it — futarchy-system.md §9 C37), or, under window_rule v4, epoch_aborted{run_unrecovered} when an included run's latest verdict row there is failed (futarchy-system.md §9 C99). The settling step appends, under a v2 document, balance_series (B6b — in the v2 chain (chain::declared_chain_v2, task 143 step 3j-1) and folded by the composition's v2 branch (fold_to_settlement, task 143 step 3j-2)), utilization, winsorized, estimate, feasible_set, then settlement (the optimizer's output or the fallback, §11), pool_liability, one stake_payout per net position, under a v2 document the participation_yield rows (B14b — task 143 step 3i, in the v2 chain (chain::declared_chain_v2, task 143 step 3j-1) and folded by the composition's v2 branch (fold_to_settlement, task 143 step 3j-2)), then epoch_settled. Under a v3 document the settling step appends balance_series/v2, utilization, feasible_set, settlement/v3, pool_liability, the payouts, the participation_yield rows, then epoch_settled — no winsorized, no estimate (§5's v3 layout).

A second epoch_opened, or any refusal of §14 found in the log, is corrupted history: a typed halt, never a guess (a stake row carries no epoch field — the log it sits in IS its epoch, so "citing another epoch" is not a case). A log that has not reached the close is not corrupted history: the fold yields document_checked alone — a Declared or Open epoch at that offset (state-layers §12).

7. The raw allocation and the constraint-adjustment map #

The raw market allocation (the futarchy note, "Pool balances and market allocation"):

w^M_i = R_i / R, an exact rational never materialized rounded; Σ_i w^M_i = 1; w^M need not satisfy the caps.

Γ_C — the implemented allocation (the futarchy note, "Constraint adjustment" and "Implemented allocation redistribution procedure"), gamma_c_rule v2 and caps_rule v2, BUILT as gamma_c_v2 (task 143 step 3b), in the v2 chain (chain::declared_chain_v2, task 143 step 3j-1; folded in the first segment on the document's version): the note's procedure as written, in exact rationals, over w = w^M(t_2). (gamma_c_rule v1 — the proportional capping over the pinned box caps of the 2 October text, the v1 chain's version — had no group, leverage or cash-minimum step; a document with b̲ > 0 was refused under it.)

1. Individual limits. For every bookmaker pool b_i = min(c_1, G_i, L E_i / V), with G_i = g w^prev_i if w^prev_i > 0, else max(e, u^prev_i / V) (w^prev the predecessor's IMPLEMENTED w^I, previous_allocation_rule — its recorded capped_share for a v1 predecessor, whose u^prev_i is its utilization row's u_i · V_prev, C71; for a v2 predecessor allocation/v2's V_i / V_prev in lowest terms, 0 for every bookmaker under outcome = fallback (read by the registry's walker, task 143 step 3j-1; the v1 share pre-floor, the v2 share the floored one — futarchy-system.md §9 C73); u^prev_i the predecessor's peak used capital in MILLS, futarchy-system.md §9 C55 — 0 at a genesis or for a pool new to the document, so such a pool's cap is e); E_i = own_capital_i (58), V = vault_capacity_mills (3), L = leverage_max (62), c_1 = cap_single (60), g = growth_multiplier (7), e = bootstrap_cap (8). Every weight above b_i is reduced to b_i; the released allocation is pooled and redistributed by step 3 among the remaining eligible pools and cash.
2. Group limits (cap_groups 61). A list of protected groups, initially empty. Sort the bookmaker weights descending, ties by document index ascending (the note's "published index"); check the largest two, three and five (a size above the bookmaker count skipped), in that order. For the first group A above its cap, H_A = Σ_{i∈A} w_i, reduce w_i' = w_i c_|A| / H_A for i ∈ A; add A to the protected list; redistribute H_A − c_|A| outside A by step 3. Re-sort and repeat until every checked sum satisfies its cap — the note: "These checks cover every group of those sizes"; a protected group cannot become violated again.
3. Proportional redistribution. Fix reference weights q_i = the recipient weights at the START of this redistribution, unchanged until it completes (the note: "Keep these reference weights unchanged until that redistribution is complete"). Eligible recipients have q_i > 0 and are cash or a bookmaker with remaining individual capacity, the releasing group excluded — and, CONFIG C72 (the engine's reading, not the note's text), the members of a protected group already at its cap excluded from the start: the note stops them at the first repetition with nothing moved, so the weights are the same and one unit fewer is spent. Increase eligible weights in proportion to q_i until the released amount is exhausted, an individual limit binds (that recipient stops), or a protected group reaches its cap (its eligible members stop); apply simultaneous limits together; redistribute the remainder among the rest; cash has no upper cap; with no eligible positive-weight recipient the remainder goes to cash.
4. The cash minimum (cash_min 59). If w_0 < c_c after steps 1–3 (w_0 the note's cash index — this document's pool 1): w_i' = w_i (1 − c_c)/(1 − w_0) for every bookmaker and w_0' = c_c; no redistribution follows.
5. Precision and verification — B4, capacity_rounding_rule v2, below: the floor to D units, then the verification of the floored allocation, the all-cash fallback on a failure or on step_budget (33) exhaustion — Γ_C counts its passes against the same field the optimizer counts its pivots against (the field's row, §3) — CONFIG C72: step 1 one unit, each group pass that moves weight one, each redistribution repetition one; the check that finds no violated group and no remainder is not a pass; exhaustion fires when a pass is needed and none remains (the step_budget + 1-th pass, C47 (g)'s convention), and when any step's rationals leave rational_bits_max (34) — the bounds' own formation, the cash minimum and the remainder-to-cash step included; the note's computational budget covers both, so an overrun is the all-cash allocation, never a halt on an otherwise valid input, the record's weights and bounds as they stand when the overrun is found (a bound not yet formed 0); the exhausted capped_share/v2 carries the weights at the stop beside exhausted — off the simplex, honest data B4 ignores (the simplex tap of §14 applies to a record without the flag); exhausting it IS the all-cash allocation — the note's rule, with no derived pass count in front of it.

The ex-ante procedure carries no utilisation cap: the note's Overview lists "Utilisation" among the constraints as "Proposed; not yet specified or added". The passes are finite — each group pass protects a new group among the finitely many subsets of sizes 2, 3 and 5 (a protected pair does not stop another pair from violating after a redistribution, so the count is not N + 3), each individual pass caps a new pool — and the budget, not a derived count, is what the engine enforces: its exhaustion is the all-cash allocation, the backstop the note asks for ("a deterministic operation or iteration budget").

The note's example, re-derived. w^M = (0.50, 0.30, 0.20) on three bookmakers with c_1 = 0.40 and no other limit binding, w_0 = 0, c_c = 0: step 1 caps the first bookmaker at 0.40 and releases 0.10; step 3's reference weights are (0.30, 0.20) (cash at 0 is not eligible), so the release spreads 3 : 2 — 0.30 + 0.06 = 0.36, 0.20 + 0.04 = 0.24; no group cap is listed; w^I = (0.40, 0.36, 0.24), the note's result ("Constraints on implementation (allowed allocations)" — the note's illustration uses a 40 % limit, not its parameter c_1 = 1/10, R30). The 2 October example (0.60, 0.25, 0.15) under caps (0.40, 0.50, 0.50) → (0.40, 0.375, 0.225) (the 2 October text, "Constraint adjustment of the market allocation") is step 1 with that text's per-pool caps in place of the uniform c_1 (0.375 and 0.225 stay below 0.40, so c_1 = 0.40 gives the same result) and the same step 3 with cash at 0 (in this document's indexing cash is pool 1; the examples' pools are bookmakers).

Integer capacities — one rounding, then verification (capacity_rounding_rule v2; v1 was the floor alone). The economist's own line (§15) fixes it: one rounding, with the leftover to cash; the note's D step is the same floor — "round each final BM weight down and assign the remainder to cash" — with D = allocation_precision (63), default vault_capacity_mills: units_i = ⌊w_i D⌋ (w the adjusted weights after the cash minimum — the note's w^I_i = ⌊D w_i⌋ / D is V_i / V) and V_i = units_i · V / D for every bookmaker (D divides V, PrecisionGrid), the D = V default the floor to mills below. So every pool is floored and ALL the leftover goes to cash:

V_i = ⌊w_i · V⌋ for every i, then V_1 := V_1 + (V − Σ_i ⌊w_i V⌋) — the D = V case over the adjusted weights w (v1 wrote w^I for the capped share it floored; under v2 w^I is the floored V_i / V).

Cash absorbs the whole remainder, which it always can: its cap is w̄_1 = 1, so V_1 ≤ V is never violated. Hence Σ_i V_i = V exactly, every V_i ≤ ⌊w̄_i V⌋, and the rule needs no tie order at all — two observers cannot disagree about which pool received a spare mill. Instance: V = 1 000 000 on the example above gives (400 000, 375 000, 225 000) exactly (the example's capped pool 1 is a bookmaker; its spare-mill case is not stated on that vector, where cash is not pool 1). On the §12 instance, whose pool 1 IS cash — w^I = (3/5, 1/4, 3/20) — V = 1 000 000 gives (600 000, 250 000, 150 000) and V = 1 000 001 floors to the same three with the one spare mill to cash: (600 001, 250 000, 150 000), every V_i ≤ ⌊w̄_i V⌋ holding since cash's cap is 1. The PAYOUT rounding of §12 is a different rule with a different owner — do not read one for the other.

Verification after the floor (the futarchy note, "Final cash minimum and precision": "Verify non-negativity, the total allocation, the cash minimum, all individual limits and the largest two, three and five sums before implementation"): B4 re-checks the floored V_i / V against every limit of Γ_C; on a failure, or when Γ_C's budget was exhausted (its passes against step_budget or a step past rational_bits_max, C72), the implemented allocation is the all-cash (V, 0, …, 0) and allocation/v2 records outcome = fallback (computed otherwise) — the note's "If the precommitted computational budget is exhausted or final verification fails for otherwise valid inputs, use the all-cash allocation". (An earlier draft of this paragraph sent the spare mill "to pool 2 by remainder"; that was the largest-remainder rule, not this one; the rule's own sentence and its first instance stand.)

8. The ceiling route #

A bookmaker's capacity becomes its risk ceiling — nothing else moves:

• For every pool i ≥ 2, V_i is the sleeve's ceiling_mills in every run manifest of the window under the one-live-run chain, and under the shared-line chain (futarchy-system.md §4 B5 v3) the bound of every run's ceiling_mills ≤ V_i, the run's sublimit of the line (matching-engine §6: "sleeve ceilings are run-manifest parameters … the manifest is a declared determinism root"). Cash's V_1 "stays in reserve" (the 2 October text, cash Q/A) (futarchy note) — no sleeve, no manifest entry.

• The run manifest cites the allocation: the frozen field allocation_ref = {epoch_id, allocation_offset} (the offset of the allocation record in the epoch's allocation stream) as run-manifest field 14, a closed nested map {0: epoch_id (32 bytes), 1: allocation_offset}, OMIT-AT-DEFAULT under model-plugin- layer §12 (absent = the run cites no allocation; every earlier manifest keeps its bytes and its run_id; a present field is one byte form, a malformed nested map refused by ManifestError::AllocationRefWire). The predicate the runtime checks is a SUBSET rule, not an equality — a pool need not quote in every run, and a pool whose V_i = 0 quotes in none (a zero ceiling is already refused by the manifest's own validation, so such a pool simply does not appear, and a manifest naming no sleeve refuses to start — ManifestError::NoBookmakers, the manifest's own validation; §9 then counts the absent pool as a missing row, and §15 question 11 asks what that does to its next cap):

  every sleeve the manifest names is a bookmaker pool of the cited document, and carries exactly that pool's V_i as its ceiling_mills; a pool the manifest omits quotes nowhere in that run.

  That equality is the one-live-run chain's (B5 v1). B5 v2 was the v2 chain's ceiling route until B5 v3 replaced it in place (no live epoch existed, task 147 T4's single declared version); a caps_rule v2 document naming B5 v2, B6 v1 or B7 v2 is refused (ChainMismatch, field 50) — no epoch opens under a rule the engine no longer runs; only caps_rule v1 documents keep the equality, CeilingMismatch and C31's one live run. Under the shared-line chain the predicate is the LINE predicate (futarchy-system.md §4 B5 v3; §9 C31, C89):

  every sleeve the manifest names is a bookmaker pool of the cited document and carries a ceiling_mills ≤ V_i, the run's sublimit; the run's run_included/v2 row carries the same sublimits; at that row the sublimits of the sleeve's live runs (record order) plus this run's sum to at most V_i; a pool the manifest omits quotes nowhere in that run.

  Under the v3 chain B5 v4 reads the line with VERIFIED liveness and adds the PENDING REFUSAL (futarchy-system.md §4 B5, §9 C100): a run's sublimits stay in the live sum until its run_verdict{verified} row and never leave it at a failed one, and a run_included naming a sleeve whose pool has an included run whose latest verdict row BEFORE this row is failed is refused at the START (SleevePending, after LineExceeded) and, recorded, halts B7 v5 (SleevePendingInclusion) until that run's verified row — between the two rows the pool's loss on that match is unknown to the fold, so no new risk is admitted against it.

  Two consequences worth stating. A sleeve the document does not name can never quote in a run of the window, so every sleeve a run of the window needs must be a pool — including the house-model sleeve a house-line board requires at HEAD; listing the pools is therefore a decision about which sleeves may run at all, and it is the CEO's field (§3). And the cited record must be the epoch's own current allocation: a manifest citing a settled or superseded epoch's record satisfies the ceiling equality (or the line) but funds nothing this epoch granted, so the gateway refuses a run_included whose allocation_ref is not this epoch's record, and the runtime refuses the manifest (ManifestError::Inclusion(InclusionError::CeilingRoute( CeilingRouteError)) — the check is futarchy::check_allocation_ref, the layer's own home of its predicate, with the refusals ForeignEpoch, ForeignOffset, SleeveNotAPool, CeilingMismatch (the one-live-run chain) and LineExceeded (the shared-line chain; a ceiling_mills > V_i is LineExceeded with live_sum 0), in that order, while RowVersion (defensive: the derivation's walker halts InclusionRowVersion first) and SublimitsDisagree are Inclusion::admit's, ahead of check_allocation_ref, so the shared-line START refuses, after Run and AllocationRef, RowVersion, SublimitsDisagree, then the route, in that order; AllocationForeign (the record names another epoch) and AllocationShape (its capacities do not count the document's pools) — both checked first, ahead of ForeignEpoch; the runtime depends on futarchy — acyclic, the layer depends on stream-core alone). The predicate gains two clauses, each under its own document condition — the leverage tap under a document carrying fields 58 and 62, the exposure rows under one naming R4; under one naming R9 the edge computes the loss band from its replica of the desk fold and R6 re-derives it at the inclusion row (risk-engine.md §3, §4, §7). The START of an allocation-citing run takes its INCLUSION as a TYPED INPUT DERIVED FROM THE EPOCH LOG (futarchy-system.md §4 B5; state-layers §11): Inclusion::from_epoch(inputs, log, run_id) is the one constructor — the real fold B0–B4 over the sealed log yields the document's checks and the allocation record (the fold's own, at the stream layout's offset — never a handed-in record), B5's fold half fold_through_inclusions(epoch_id, close_height, log) — reading the WHOLE sealed log from the closing block_final to its end, a log short of the close yielding no inclusions — yields the run's recorded run_included row with its log offset; the derivation's own refusals are InclusionBuildError::{Document, Fold(Halt), NotClosed, RowMissing, Layout} (§14); nothing in an Inclusion is a free value. The operator's edge builds it — the two binaries under --epoch <dir> and --epoch-store <dir>, named together, read the epoch store on disk (futarchy-system.md §11 W10) and the pure loader futarchy::inclusion_from_store derives it (the registry rebuilt as of the opening and admit before the fold; futarchy-system.md §10) — and hands it to Scheduler::new_included(manifest, &inclusion, …) (the host's Driver::new_included); Scheduler::new refuses an allocation-citing manifest (InclusionMissing) and new_included a manifest citing nothing (InclusionUncited), after the manifest's own validation (so a bad ceiling is BadCeiling, never a gate refusal). The gate Inclusion::admit then checks that the inclusion was derived for THIS run (the row's run_id = the manifest's run id — Run; the fold already holds run_id = manifest_hash), that the row's allocation_ref is the manifest's (AllocationRef) and the SUBSET rule (CeilingRoute(…)), and records the row's offset in every derived stream's lineage (event-catalog §4, included_at). The trust boundary (CONFIG C30 — §9 C30, register row 33, carried by B5's declared rule identity so a change is a new system hash): the runtime never holds a log handle (a log read inside the runtime would be hidden state, CLAUDE.md law 2 — the Inclusion is its one typed input); the edge is trusted for the LOG's BYTES — exactly as it is for the root logs it hands a run and for the stored epochs the registry is rebuilt from (law 8(d)) — and for nothing else: a forged inclusion needs a forged log that re-folds to the forged record through every block hash and stake row, the same forgery as a forged root log. The fold proves the rest after the fact: B7 halts the window on a sealed run without its row. A run manifest WITHOUT allocation_ref is outside every window and draws no vault capacity — it starts through Scheduler::new at its own ceilings (the demo and replay path; the deployment rule below). CONFIG C31 (§9 C31, register row 34 — the economist's finding, a funds-risk question to the user). The two readings of V_i: this design's first bullet above ("V_i is the sleeve's ceiling_mills in every run manifest of the window") makes V_i the ceiling of EACH run, so k runs of overlapping matches could together reserve k·V_i and the vault's reservable exposure could exceed V; the notes read V_i as ONE total per bookmaker — the futarchy note ("Governance problem", "Market mechanics"): "If the vault has V units of deployable capacity, bookmaker i receives V_i = w_i V", boxed as V_i = w^I_i(t₁) V; the product thesis ("One vault, revocable ceilings"): "Approved ceiling: the maximum shared liability an underwriter may reserve" and "The same dollar can never secure two simultaneous worst-case losses". Law 7(c) takes the default closest to the notes, so the default is the per-bookmaker reading — and, until the user rules on HOW the total is shared across simultaneous runs (ceiling_mills ≤ V_i with the gateway bounding the sum over a sleeve's live runs, or one run at a time), the rule under which both readings coincide: a sleeve has at most ONE live included run per window — the gateway refuses a run_included for a run naming a sleeve that already has an included run without a run_verdict row, and B7 halts on a recorded violation (B6 reads each run's sleeve ids). The manifest rule stays exactly V_i and B5's code is unchanged; B5's declared text names C31. RULED 2026-10-21 (futarchy-system.md §9 R38, the CEO): the credit line is one shared limit across all of a bookmaker's markets from the first pilot, the one-live-run rule a temporary safeguard superseded by R38 from the first epoch whose rule chain declares the shared-line B5 version, the chain every caps_rule v2 document gets; B5 v2 was the v2 chain's ceiling route until B5 v3 replaced it in place (no live epoch existed, task 147 T4's single declared version); a caps_rule v2 document naming B5 v2, B6 v1 or B7 v2 is refused (ChainMismatch, field 50) — no epoch opens under a rule the engine no longer runs; only caps_rule v1 documents keep the equality, CeilingMismatch and C31's one live run, the manifest rule and B5's code as written. Under the shared-line chain the manifest rule is ceiling_mills ≤ V_i with the line predicate above, the gateway bounding the sum over a sleeve's live runs — the first of the two ways named above, the engine's default mechanism (futarchy-system.md §9 C31, C89). The fixture's E3 rows come in two shapes under a v1 document (futarchy-system.md §7 E3): futarchy_epoch_log (B5's gate) keeps the two inclusions at heights 12 and 13 — a recorded C31 violation B7 will halt on; B6's gate sequences them through futarchy_epoch_log_with at 12 and 14 with the first run's run_verdict at 13 between them and the second's at 15; and in five under a v2 document ((a)–(e), futarchy-system.md §7 E3). The deployment rule, part of C30: a deployment holding an epoch serves vault-funded sleeves only through new_included — a run started through Scheduler::new draws no vault capacity and is outside every window.

• A ceiling change is a quoting restriction only. A sleeve's quote headroom is ceiling − Σ_open max(posted, 0) − Σ reservation − max(−realized, 0) across every book it rests in (matching-engine §6; R1 v2 since gate G1 (risk-engine.md §9), v1 before it ceiling − Σ posted − Σ reservation), and a batch that does not fit is truncated by matching-engine §4's step-3 greedy shrink or, when nothing fits, refused with its §8 quote_rejected{capacity} row. That is the whole reach of a ceiling: it bounds NEW quoting — in the exchange's own collateral view and in the market-making layer's worst-case pre-check, which reads the same ceiling before a batch is sent. It never touches a pot (pot = 1000 mills × open interest at every offset, matching-engine §6), an accepted claim or a staged payout. And a ceiling cannot change WITHIN a window at all: one allocation record pins one V_i per pool and every manifest of the window carries it, so the earliest run that can quote under a different ceiling is the first run of the NEXT epoch's window. Inside a run nothing can change it either — the manifest is frozen and its hash is the run's id (state-layers §11, "the run is its manifest + root logs"). A cut is thus always an event between epochs, and it reaches no market that is already open.

• The product thesis's "approved ceiling / quote reservation / drawn capital" are, in this engine, ceiling_mills, the resting-quote reservation and max(posted, 0) of matching-engine §6; its priority rule for scarce free USDC and its capital rent have no engine object here (the vault's free cash is the chain's).

8b. The capital views #

The LPV capital committed to a cycle is locked before its voting opens and until its obligations settle (futarchy-system.md §9 R44, amended by R47); the engine shows that commitment as five quantities DERIVED from the epoch log — a pure read, a fold appending nothing, exposed by d2-cycle report (futarchy-system.md §11 W15) and, when they exist, by the payout publisher or the gateway (futarchy-system.md §7 E5; CONFIG C101):

• committed = vault_capacity_mills (3) — the published budget, pinned before the first stake (§3) and immutable after epoch_opened (law 8(b)); no record of the epoch log changes it; that a withdrawal during voting cannot shrink the funds behind it is the vault side's lock (R44, R47).
• allocated_i = V_i, per bookmaker pool i ≥ 2, from the allocation record (§7).
• reserved_i = the sublimits of the pool's sleeve still live at the log's end under the chain's liveness — on the v3 chain until each run's verified row (§8, B5 v4): the line reserved by running or unverified matches; on the v4 chain the epoch's CARRIED lines included, each locked until its release (its Verified row or its carry_settled/v1 row, futarchy-system.md §4 "The v4 chain"; CONFIG C111). The capital a run USED is B6's drawn_i and capital_i, per run, after its verdict (§9), not a view.
• unreserved_i = V_i − reserved_i — available to the cycle, never to withdrawals: an unused part of the commitment is not withdrawable. On the v4 chain, under either carry_budget_rule version of the holding epoch, unreserved_i is the desk's ROOM: min(usable_i(h), ⌊L·E_i⌋) less its live sublimits, its own locked carried lines and its own consumed amounts — at least 0 by B5 v5's desk bound (futarchy-system.md §4 "The v4 chain"; §9 C125); V_i − reserved_i and usable_i(h) − reserved_i overstate it (after G-O4's OUTSIDE release B's room is 10 000, not 10 020).
• released ⇔ epoch_settled is in the log, on a v1, v2 or v3 chain. At a close every included run of such a chain is verified, so every reserved_i is 0 there. On such a chain, after an abort released is false and reserved_i lists the lines of the runs without a verified row; the vault side releases them on the chain's settlement of those matches, outside the epoch log — an abort record alone releases nothing still securing claims (R44). After an abort the commitment not securing claims is the vault side's to release at the abort record (the reading of PV-06's 'alone cannot release capital still securing claims' and 'Release only after the applicable obligations are cleared': what secures no claim carries no obligation at the abort record; CONFIG C101, the economist's release conditions to replace). There released is the settled path's flag; after an abort the engine exposes committed − Σ reserved_i as the part securing nothing.
• On the v4 chain released is ONE flag, the CAPITAL RELEASE: the epoch's terminal row (epoch_settled or epoch_aborted) in the log and no carried line of it locked (CONFIG C119), true after an abort too once no line of it is locked; the held slot, the settled store entry and its completeness read the same flag. ONE COVERING RULE (futarchy-system.md §4 "The v4 chain"), governing only committed(h), withdrawable and the released part, never the flag: every locked carried line is covered by exactly one epoch, its accepting epoch until that epoch's deadline; the covering moves at each window start and never between them — at the window start close_height of j's successor (D(j) itself under the abutting default, later when the successor opens past D(j)) every locked carried line whose coverer is at or past its own deadline passes to the covering of j's successor when it pins carry_budget_rule v1 (INSIDE), whole lines in lineage then inclusion order while its covered sum stays at most its V, the excess keeping its coverer and eligible again at the next window start; under an OUTSIDE successor nothing passes, each line keeps its coverer and the successor holds, and at the release the released amount (line − consumed) moves into the then-running epoch's commitment (the holding epoch, whose window had started at or before the release and that allocated — futarchy-system.md §9 C117) and leaves the coverer's — except a line released in an INSIDE then-running epoch's turn that the epoch does not cover (an excess line, one that found no room at the window start into that turn, or one released in the turn's gap before that window start), or released in the turn's gap before the then-running epoch's window start, in the turn of an epoch aborted before its allocation, or at a height in no opened epoch's turn (under an OUTSIDE then-running epoch every release in its turn at or after its window start enters its R(h)), whose released amount joins no running pot and is withdrawable from its coverer's terminal row (futarchy-system.md §9 C106, C124). An epoch's committed(h) is, until its terminal row, its own V (plus R(h) under OUTSIDE) less the carried lines that passed from its covering to another's; after its terminal row, only the carried lines it still covers. Its RELEASED PART at its terminal row is its figure just before that row less the carried lines it still covers, and a later release adds nothing to it: the released amount is the covering or holding successor's, the consumed amount the vault side's loss, so no dollar is both withdrawable and committed, nor committed twice (R44). The release of a carried line that never reaches Verified is a recorded edge row: it leaves reserved_i at its carry_settled/v1 row in the accepting epoch's root log (futarchy-system.md §7 E8; CONFIG C113). The settled store entry is written at the later of the capital release and the first final above the grace end (C37) (futarchy-system.md §11 W10; at the abort row for a v4 epoch that aborts before its allocation, no line held), the flag released at the capital release, and no withdrawal is paid from a locked line.

withdrawable is the VAULT's number, owned by the vault side: deposits less committed less every other encumbrance — on the v4 chain, under both carry_budget_rule versions, less the sum of committed(h) over EVERY epoch whose figure is above 0 (every epoch until its terminal row, and after it while it covers a locked line, whatever its released flag) by the covering rule above, so each locked carried line is subtracted once, inside its one covering epoch's figure, and an earlier epoch's non-covering part is withdrawable from its terminal row (futarchy-system.md §9 C125); a figure read from partial inputs, a capital view whose successors stops before the latest epoch summed, keeps every line whose passing it cannot read, so a sum of such figures, none read past the epochs summed, gives a withdrawable at or below this one, never above it (futarchy-system.md §7, C125). The engine holds no deposits and exposes no such field; it supplies committed. The handoff order on released is the vault side's — return credit, distribute bookmaker PnL, process withdrawals from released capital, allocate what remains (the R47 row's reading) — and in the engine it is the records' own: the runs' verdicts and return_observed rows, epoch_settled, then the next document's allocation — on a v1, v2 or v3 chain; on the v4 chain the next document's allocation may precede epoch_settled, its pot formed gross of the carry (CONFIG C116), and the handoff order runs per release on the capital release. Cash has no sleeve and no line, so no view row. The word is "reserved", never "deployed": the line a running match holds is reserved; what it draws is measured per run.

9. The evaluation data #

"During the evaluation period the protocol observes a precommitted data set D_T = (R_1, …, R_T), where R_t is the vector of bookmaker returns observed at time t" (the objective note, "Estimation and settlement" — the note's R_t there is a RETURN vector, not this document's stake pool R; §2). Here D_T comes from the engine's own streams — never from a bookmaker's report (the 2 October text's "bookmakers share performance results with the vault" is read as the vault OBSERVING results — the 19 October note: "The protocol records their performance" (Overview); self-reporting would be a mock and the cheapest estimator attack).

One observation per run (delta_rule 22 v1 — "Δ = one run", §15 D2: the economist, match first, a time interval later; the 19 October note's Δ is a DIFFERENT symbol, the snapshot interval snapshot_blocks (57), R34 — the per-run observation is the record the series of this section is derived from, and keeps its own name). The order — stakes, then the close, then the evidence — is the futarchy note's own cycle (Overview: publish the rules, collect predictions, set credit limits, observe trading, assess and settle): stake in pools, compute the raw w^M(t_2), implement w^I, THEN observe D_T. It needs no rule of its own here, because §8 already enforces it structurally: a window's run cites an allocation record, and no such record exists until the book has closed (§6).

One observation per included run at its run-sealed offset — a term this document coins for the run's FINAL offset: the sealed end of its settlement stream, after the last settlement_complete, every market settled or voided and every pot drained to exactly zero (matching-engine §6's pot identity). One per run, not the product thesis's between-match "flat-book checkpoint". Mid-run has no price (state-layers §7's in-flight carve-out: between a settlement group's first row and its barrier the folds are legitimately mid-transaction).

The run must have reached Verified, not merely Completed (state-layers §11): a Completed run still becomes Failed if the determinism harness re-runs it and a stream hash differs, and an observation already folded into return_observed could not be withdrawn without rewriting history. So the fold waits for the harness's verdict, and a run that never reaches Verified never contributes. Under window_rule v4 (B7 v5, the v3 chain's) a failed verdict is a recovery incident, never an exclusion: the run's record is rebuilt — the same manifest re-folded over the same root logs — and the rebuilt record's verified row, a second run_verdict for the run, is its one observation; until that row the window waits, and at the grace end without it the epoch aborts run_unrecovered (futarchy-system.md §9 C99).

The window, and why the operator does not choose it (window_rule v2 — a FIXED span of heights; the team, 7 Oct 2026, in the sync's notes: "a 30-day credit allocation span for specific game categories" — the per-category half superseded by the economist's one clock (futarchy-system.md §9 R4); the economist (futarchy-system.md §9 R4, R5), asked how long the period is and whether every title shares one, answered that the length is a parameter to change and the clock one; asked which matches count, every match). The objective note lists "the return data included in D_T" FIRST among the six things "the protocol must specify" before betting, so a window the operator picks run by run after stakes are in would not be precommitted at all — it would let whoever appends run_included select the evidence that settles the market. The rule therefore leaves no selection, and the length is a document value:

The window is [M, M + window_blocks); its DEADLINE is M + window_blocks (field 52). D_T is the runs whose own frozen manifest cites THIS epoch's allocation record and whose run_included row carries a height below the deadline, taken in the order those rows appear in the epoch log, each observed once at its run-sealed offset once its run_verdict{verified} row is in the epoch log (§5 — the harness's verdict, recorded); under window_rule v2 and v3 a run whose row says failed contributes nothing and is listed failed, and under v4 it keeps the window pending until the rebuilt record's verified row (futarchy-system.md §9 C99). The window closes on the first block_final at or above the deadline once every such run has its verdict row (under v4 its verified row) — at h*, the smallest final height at or above the deadline at which every included run has a verdict row of height ≤ h* (the HEIGHT reading, CONFIG C37 — a verdict row is stamped with the latest final height) — and no later than the first block_final at or above deadline + verification_grace_blocks (field 53) — an included run still without one of height ≤ that final's there ABORTS the epoch (run_unjudged, the first such run in inclusion order named, the abort decided only once a final above that one is in the log — C37 — every net position refunded; under v4 a run whose latest row there is failed aborts the same way as run_unrecovered), so that withholding a verdict can never select the evidence (futarchy-system.md §4 B7, §9 C25). A run citing this allocation cannot START before its run_included row exists (futarchy-system.md §4 B5), so every run that could produce evidence is in the log, and a row at or after the deadline is refused. If D_T holds fewer than min_distinct_matches distinct match ids, the epoch aborts there and every net position is refunded in full (B7 v2 and v3); under B7 v4 and v5 (B7 v5 the v3 chain's), the window closes with the count reported and B12 v3 settles on the fallback (futarchy-system.md §9 C93).

One window for every title ("One clock"). The order is the LOG's, not the order the runs happened to seal: the log's order is the one recorded fact two observers both hold, and the determinism bridge (§13) has nothing else to stand on. The economist confirmed the live note's proposal "every match settled inside the period, in the order settled, nobody chooses afterwards"; the engine's reading of "settled inside the period" is "opened under this allocation before the deadline, its settlement observed at its run-sealed offset" — a run settles on its own replay clock, not the chain's, so this is the one reading two observers can take from the log; the reading is named in the register (futarchy-system.md §9 C4) for his objection. The blocks that compute this are futarchy-system.md §4 B6–B7.

A window always closes. The deadline arrives with the chain's blocks, the grace bounds a run the harness never judges, and below the match floor the epoch aborts rather than waits — the design's earlier hole (v1 had no answer for a window that never filled; §15 question 10) is closed by construction, with the abort as the default for the live note's question 22 (futarchy-system.md §9 C8) — on the v3 chain the window below the floor settles on the stake-split fallback, taxed (C93).

Membership is thus a property of the run's own recorded manifest and of a height the chain assigned, not of an operator's choice: run_included RECORDS that a qualifying run exists (and carries its manifest hash so the citation is checkable, and the height at which it was recorded), it does not admit one. A sealed run citing this allocation record that is absent from the log is corrupted history — the same posture as any other missing record (§14) — and a run_included for a run whose manifest cites another record is refused at the edge. What the operator does choose is which runs to CREATE, which is the operational act of serving matches; every created run that cites the allocation and is included before the deadline is in. K = |D_T|. A run included at or after the deadline belongs to no window of this epoch.

Per included run, per bookmaker pool i ≥ 2 (returns_rule v1 — the per-run quantities; utilization_rule v2 aggregates capital_i over the window as the peak, below; SleeveId = the pool's sleeve; folds of the run's lifecycle, market-event and settlement streams through the collateral fold of matching-engine §6; the denominator, the per-market sign rule, the per-run peak and the sampling instant are the engine's readings recorded as CONFIG — futarchy-system.md §9 C35; v1 observes neither own available capital nor a mark-to-market PnL, both named by the objective note's "Data" and neither an engine object this phase):

The sign rule: a market's posted may be negative (realized profit on closes, matching-engine §6); capital counts max(posted, 0) per market.

The balance series — the note's snapshots, derived from the runs (B6b, series_rule v1, BUILT as fold_balance_series — task 143 step 3c — in the v2 chain (chain::declared_chain_v2, task 143 step 3j-1) and folded by the composition's v2 branch (fold_to_settlement, task 143 step 3j-2); the futarchy note, "Performance collection", "Balances and utilisation", "Interval returns"; the user's ruling of 2026-10-20: the per-run streams stay the record). The note records, "for each BM i and snapshot k", the free own capital F^own, the unused credit F^credit, the capital reserved for open orders U^orders and committed to open positions U^positions, at snapshots every Δ from t_2. The engine forms them from the per-run rows above and the document:

The GRID: snapshots at M + k · snapshot_blocks (57) for k = 0 … window_blocks / snapshot_blocks (window_blocks a multiple of snapshot_blocks — B0's SnapshotGrid check); interval 1 is [M, M + Δ] (a verdict stamped at M, the closing final's own height, is legal upstream) and interval k ≥ 2 is (M + (k − 1) Δ, M + k Δ], so a run's interval is max(1, ⌈(h − M) / Δ⌉) for a verdict height h up to the deadline; the closing snapshot is at the DEADLINE, and a run whose run_verdict height lies in (deadline, h*] (inside the grace) belongs to the LAST interval K; a height below M or above h* is corrupted history, a typed halt (futarchy-system.md §9 C59). A run belongs to the interval containing its run_verdict height — it is observed once, at its end (C52). The opening snapshot k = 0 is recorded with B_{i,0}, F^own = own_capital_i, F^credit = V_i and U^peak, η, R^bal pinned at 0 — recorded values, not observations: B9 v2, B10 and B12 read the snapshots k ≥ 1 (C59).

Per bookmaker pool i ≥ 2 and interval k: U^peak_{i,k} = the maximum over the interval's runs of the run's capital_i (the peak of posted plus reservation — the note's U^orders + U^positions), 0 with no run — a per-interval PEAK, not the note's instantaneous stock, because the record carries one peak per run and a run's clock is its own (C52 names the gap); under the shared line, where a pool's runs overlap, the maximum is a DEPARTURE from the note's formula (law 7(a)): the note DEFINES U_{i,k} = U^orders + U^positions ("Count each funded amount once", "Balances and utilisation"), and the maximum over runs is CONFIG only because no cross-run instant exists; it understates u_{i,T} — own capital 0 and no P&L in the interval, B = 100 000: 60 000 + 40 000 drawn at once reads U^peak 60 000, η 0.6, e^util 2/3 with ρ = 9/10; with own capital 20 000, 60 000/120 000 = 1/2 and e^util 5/9 — which at THIS settlement tightens w̄^util = e^util · w^I_i with e^util_{i,T} = max_{k∈K_T} η_{i,k}/ρ and η_{i,k} as below (B11 v2, §10), which can lower ŵ*_i where the bound binds, moving settlement payout from the desk's backers to the other pools' stakers (zero-sum before the tax, no LP effect), penalising exactly the concurrency R38 enables, and next epoch changes Γ_C's bootstrap only where w^prev = 0 (C71's case split, after a fallback), where it lowers G_i; the alternative, Σ of the runs' peaks, overstates and loosens the settlement cap; the economist's question stands (futarchy-system.md §9 C89, register row 92); B_{i,k} = own_capital_i + V_i + Σ pnl_i over the runs attributed to intervals 1 … k (B_{i,0} = own_capital_i + V_i — realized results accrue to the desk's own capital first: losses by C26's order, gains by C69's reading; profit distributions are between epochs, C68); F_{i,k} = B_{i,k} − U^peak_{i,k}, split into F^own and F^credit below; η_{i,k} = min(U^peak_{i,k} / B_{i,k}, 1) (C58 — a peak above the balance, a realized loss netted into capacity, counts as full use); R^bal_{i,k} = B_{i,k} / B_{i,k−1} − 1. The split of the free balance (C69, a reading: credit is drawn first, own capital is the cushion that absorbs losses first — C26): F^own_{i,k} = max(min(own_capital_i + Σ pnl_i, F_{i,k}), 0), F^credit_{i,k} = max(F_{i,k}, 0) − F^own_{i,k}, both non-negative, their sum max(F, 0); the identity F^own + F^credit + U^peak = B holds whenever U^peak ≤ B, and above it η = 1 (C58). Losses past own capital lower B into the credit; POV's reserves ahead of LPV (C26) are not modelled in the series until a risk-chain block lands (C68's scope; C69). Every amount of the series is in capacity mills — own_capital (58) is pinned in mills for that reason.

An interval with no run of pool i is OBSERVED: U = 0, B unchanged, R^bal = 0, in the joint vector and in the pool's own series — the note's "Use the same observation times for all BMs" — so a surviving pool's T_i is the interval count; a wiped-out pool's T_i is its last snapshot k (its later snapshots MISSING, C42's count). A pool with B_{i,0} = 0 (own capital 0 and no credit) writes NO row; its readers take η = 0, R^bal = 0, e^util = 0 — observed zeros, T_i = K, a mean of 0 (C56). Observed zeros are the engine's answer to the note's "missing observations" question (C65): a run spanning several intervals shows U = 0 and R^bal = 0 until its verdict interval, where its whole result lands — the mean and the CVaR see that shape. A run's result is realized at its verdict, so no unrealised position is carried at a snapshot (the note's entry-price valuation question, C67). The only evidence floor is min_distinct_matches (21); the note's minimum trading evidence — distinct trades and markets per bookmaker — has no rule yet (C66, open). A desk whose B_{i,k} ≤ 0 at k ≥ 1 ends its series there — R^bal_k = B_k / B_{k−1} − 1 (at most −1), η_k = 1, later snapshots MISSING for it (C56). Cash's column — cash_return (13) in every interval, never winsorized (C40) — is the READERS' (B9 v2, B10; on v3 the pins 74–76, B12 v3's), never a row of the series. No flow enters a window but the trading result, net of trading fees (futarchy-system.md §9 C29): deposits, withdrawals, credit-limit changes and profit distributions are between epochs — WHILE no risk-chain block exists (risk-engine.md §4: a margin top-up or a liquidation would be an intra-window flow); the note's flow-adjustment question needs no engine rule under a document naming no desk-period block (C68, C82) — the top-up desk_topup is that block's flow and series_rule v2 adds it to B (risk-engine.md §4, C82).

The balance_series record carries, per pool in document order and per snapshot k = 0 … K, B, U^peak, F^own, F^credit, η, R^bal as exact rationals, the decoder holding η ∈ [0, 1], U^peak ≥ 0, F^own ≥ 0, F^credit ≥ 0 and the opening row's zeros, and no sign bound on B or R^bal (event-catalog §6.17; C59). B8 v3, B9 v2, B10 and B12 read this series in place of the per-run rows; the per-run rows remain the record the series is derived from and re-derived against.

The three return series — daily, rolling weekly, monthly (the futarchy note as rewritten, "Daily, rolling weekly and monthly returns"; B6b v2, series_rule v2, the v3 chain — futarchy-system.md §4 B6b). "The three series" are the daily (h = 1), rolling weekly (h = h_w) and monthly return series of that section, term by term:

R^{bal,h}_{i,k} = B_{i,k} / B_{i,k−h} − 1 for h ∈ {1, h_w} and k = h … K, and R^month_i = B_{i,K} / B_{i,0} − 1 — the note's h ∈ {1, 7}, k = h, …, n_T and B_{i,n_T} / B_{i,0} − 1, with h_w = weekly_horizon_snapshots (73) = 7 and n_T = K (one snapshot is one calendar day — CONFIG, futarchy-system.md §9 C96). Every ratio is taken on the SCORING balance B̃ = max(B, 0) — a departure from the note named under 7(a), CONFIG C95: the note's R^{bal,h}_{i,k} = B_{i,k} / B_{i,k−h} − 1 asks only the opening condition B_{i,k−h} > 0, so a negative closing balance gives a return below −1, while B̃ floors the return at −1 at the wipe-out row, because the lenders' loss on a pool is bounded by the credit extended — the deficit beyond the balance is the desk's own and the risk engine's. Apart from the floor, B̃ is 0 at every snapshot after the pool's wipe-out row and a ratio whose opening is 0 is 0 (the open-question defaults, 7(c), CONFIG C95, under the note's open "treatment of zero opening balances, missing observations and insufficient valid windows"); the monthly ratio opens on B_{i,0} > 0 (a pool with a zero opening has no series, C56).

The balance_series/v2 record carries v1's rows — R^bal on B̃, which differs from v1's raw ratio only at the wipe-out row, floored there at −1 — plus, per row, weekly_return PRESENT iff k ≥ h_w, and per pool with a series one monthly_return. The series still ends at the wipe-out row (C56) and its readers fill what follows: a daily return 0 after the wipe-out row, a weekly window that opens before the wipe-out and closes at or after it −1, one that opens after it 0, the monthly return −1. Cash is no row: its three returns are the document's pins 74–76, the note's fixed-rate rule R^h_{0,k} = (1 + r_c)^{h/365} − 1 and R^month_{0,T} = (1 + r_c)^{n_T/365} − 1 truncated at p decimals (C94). The eligible windows are K_T^(h) = {h … K} for both horizons — the note's "With complete valid records, K_T^(h) = {h, …, n_T}" read as the engine's CONFIG (C95): records are complete by construction, a run-less interval observed at 0, a wipe-out handled by B̃ and never by excluding a window. The series scored stays C57's total-balance R^bal (futarchy-system.md §9 R52 (i), R53).

Missing rows (missing_row_rule v1 — the ZERO in the joint vector CONFIRMED by the economist, 2026-10-12: "Count return as zero."; the exclusion from the pool's OWN series CONFIG — futarchy-system.md §9 C42): a pool whose sleeve is absent from the run's manifest, or whose capital_i = 0, has no return there — it enters that run's JOINT loss vector as 0 and is EXCLUDED from its own series; T_i counts the runs where pool i was observed. The ZERO convention is not cosmetic — a zero return in the joint vector moves the tail and so ŵ* — and it is now his, so §15 question 14 is closed. A desk that placed orders with no fills in that run has a return of 0 there and its open orders still count toward u_{i,T} (his same comment; the utilization rule above). Cash: R_1t = cash_return in every run (the futarchy note's μ₁).

Utilization (utilization_rule v2 — the economist's own words, futarchy-system.md §9 R1, R3). The 2 October text ("How do we estimate the objective when some bookmakers underutilize their allocated weights?") fixed what u_{i,T} MEASURES — "bookmaker i's utilized credit during the evaluation period, expressed as a fraction of vault capacity". The economist fixed the two things the note left open. What counts as utilized: on the simulation's "credit is drawn only on filled bets, never on open quotes" — "I believe the effective credit is drawn both on filled bets and opened orders."; on a desk with no bets in a match — "If BM placed orders there with no fills, it counts as utilization though return is 0." How it aggregates: "The peak over the whole period initially." — "Later on, it will be time-weighted probably." So:

u_{i,T} = max over the runs of D_T (the window's included runs with a Verified verdict, C38) of capital_i / V — the peak over the period of drawn PLUS reserved, capital_i being each run's peak of Σ_markets max(posted_m, 0) + reservation (the table above).

The posted D9 default ("drawn credit, never reservations", with the mean of per-run peaks as v1's aggregation) is REPLACED by this ruling record before any epoch ran under it; its rationale — that open orders would raise u at no cost — is recorded in the register row so the economist weighs it knowingly. "The peak over the whole period" across CONCURRENT runs would need a cross-run clock the engine does not have (each run's replay_ts is its own, core law 2); the maximum over runs of each run's peak is the reading the recorded streams define, named as CONFIG in futarchy-system.md §9 C5 — and exact as an aggregation under C31's one-live-run rule (superseded by R38 from the first epoch whose rule chain declares the shared-line B5 version, the chain every caps_rule v2 document gets; only caps_rule v1 documents keep C31's one live run): a pool's runs in D_T hold disjoint inclusion-to-verdict spans in record order, so no instant carries one pool's capital from two runs, each run's peak being C35's boundary-sampled peak; a sum across concurrent runs is not what a pool can show — and the time-weighted measure he expects later is a v3 under the chain's heights. Under the shared line a pool's runs overlap: the sublimits of its live runs sum to at most V_i at every inclusion row, so the termwise bound holds without a cross-run instant, while the maximum over runs no longer equals the pool's concurrent use — it understates it, a departure from the note's U^orders + U^positions ("Count each funded amount once") taken as CONFIG only because no cross-run instant exists; at this settlement it tightens the utilisation cap (e^util_{i,T} = max_{k∈K_T} η_{i,k}/ρ with η_{i,k} = min(U^peak_{i,k}/B_{i,k}, 1), B11 v2, §10), which can lower ŵ*_i where the bound binds, moving payout from the desk's backers to the other pools' stakers (zero-sum before the tax, no LP effect), next epoch it lowers Γ_C's bootstrap G_i only where w^prev = 0 (Σ of the runs' peaks would overstate and loosen the settlement cap), and the economist's question stands (CONFIG C89, futarchy-system.md §9). What his words leave unnamed is CONFIG C39 (futarchy-system.md §9): on a tie the peak run named is the first in D_T order; a pool no run of D_T observed records NONE (for B11, u = 0); u is recorded as measured even above 1 — never clamped, never a halt — because under the v1 headroom, before G1, a run's C35 capital_i could exceed its ceiling: the engine's headroom SUMMED signed posted over the sleeve's OPEN markets (matching-engine §6 "realized profit expands capacity"; a settled market's position is dropped, so only an open one counts) while capital_i counts max(posted_m, 0) per market (C35), so profit realized by closing in an unsettled market funded posting beyond the line in another open market of the same run and showed u above the desk's own w^I_i — since G1 the headroom clips posted at zero per market and charges the realized loss (R1 v2, risk-engine.md §3), so a close's profit funds nothing beyond the line; the nearest alternative reading is min(capital_i, V_i) / V. The cap is cap^util_i = u_{i,T}/ρ under utilization_rule v2; v3's e^util is §10's. The block is futarchy-system.md §4 B8.

10. The estimator and the settlement objective #

The objective of record on the v3 chain (objective_rule v2, B12 v3; the futarchy note as rewritten, "Objective", "Daily and rolling weekly CVaR", "Estimated objective"; futarchy-system.md §9 R53):

Q̂_T(w) = R^month_{V,T}(w) − λ_d CVaR^(1)_{α,T}(w) − λ_w CVaR^(7)_{α,T}(w) − ε‖w‖²,

term by term the note's. R^month_{V,T}(w) = wᵀR^month_T is the monthly portfolio return, R^month_T the pools' unfiltered monthly returns with cash's cash_return_monthly (§9). CVaR^(h)_{α,T}(w) is the empirical CVaR of the JOINT portfolio losses L^(h)_k(w) = −(w_0 R^h_{0,k} + Σ_i w_i R^{bal,h}_{i,k}) over k ∈ K_T^(h) — the note's w_0 this document's pool 1, cash's column its pinned horizon return in every row — "Compute CVaR from these joint portfolio losses, rather than summing individual BM CVaRs"; the daily term (h = 1) has K windows, the weekly term (h = h_w) K − h_w + 1, both at the one α. λ_d, λ_w ≥ 0 are the two weights, and ε > 0 the ridge over all N weights, cash (pool 1) included (‖w‖² = Σ_{i=1}^{N} w_i² — the note's Σ_{i=0}^{N} over its N bookmakers plus cash). Each CVaR is the sample CVaR min_ζ [ζ + (1/((1 − α) K_t)) Σ_k max(0, L^(k)_t(w) − ζ)], which IS the note's "average of the worst 100(1−α)% of observed portfolio losses" with its fractional tail — re-derived on the note's example: 30 observations at α = 19/20 give the weight 1/((1/20) · 30) = 2/3; the function falls while two or more losses exceed ζ (slope at most 1 − 2 · 2/3 < 0) and rises while one does (1 − 2/3 > 0), so its minimum sits at ζ = L_(2), the second-worst loss, and is worth L_(2) + (2/3)(L_(1) − L_(2)) = (L_(1) + ½ L_(2)) / 1.5 — the worst loss plus half the second-worst, divided by 1.5. Nothing is estimated — "No return expectation is estimated and no synthetic monthly paths are generated"; "no bootstrap or simulated monthly paths are used for this objective" — and all three series stay unfiltered: winsorisation is the note's future step ("Winsorisation (future step)"), with no field and no block on the v3 chain. λ_d, λ_w, r_c, α, ε and the measurement rules are pinned in the document before the book opens ("Keep the objective, λ_d, λ_w, r_c, α, ε and all measurement rules fixed as published before t_1").

The bullets below, "The objective of record" and the shrinkage instance are the v1/v2 chains' (objective_rule v1, estimator_rule v1/v2).

"It applies a precommitted estimator θ̂_T = Θ(D_T) and computes Q̂_T(w) = Q(w; θ̂_T)" (the objective note). Θ is the note's "Suggested construction of θ", term by term — the content of estimator_rule v1, and of v2 where a bullet says so (estimator_rule_v2, futarchy-system.md §4 B9 v2):

• Winsorize positives (B9 v2, BUILT as fold_winsorized_v2 — task 143 step 3e — in the v2 chain (chain::declared_chain_v2, task 143 step 3j-1) and folded by the composition's v2 branch (fold_to_settlement, task 143 step 3j-2); the futarchy note, "Return filtering and evidence"): per bookmaker pool q95_i = the 95th percentile of ITS strictly positive interval returns R^bal_{i,k} by NEAREST RANK — the ⌈0.95 n⌉-th smallest of the n positive values, 0 when n = 0 (futarchy-system.md §9 C53: the note names no interpolation); R^w_{i,k} = min(R^bal_{i,k}, q95_i) over the pool's FULL series — "Positive returns above the threshold are capped; zero and negative returns remain unchanged … do not pool returns across BMs"; "Retain the raw observations alongside the winsorised returns" — the record carries both hashes (C41: the winsorized matrix under fh:winsorized-matrix/v1, the raw under fh:raw-series-matrix/v1), K and the thresholds, not T_i; the joint matrices are K × N over the intervals k = 1 … K with a 0 where a pool has no recorded row (a pool with no series; a wiped-out pool's later snapshots — C42's joint-vector rule through C56). Cash's column cash_return verbatim, never winsorized (C40); a surviving pool's T_i the interval count, a wiped-out pool's its last snapshot k, a pool with no series K observed zeros (§9: a no-run interval is observed at 0; futarchy-system.md §9 C56). The 2 October reading — one pinned level winsor_q95 (14) over per-run returns — is v1, retired with its field.
• Shrunken means (the objective note; the two notes DISAGREE here — below; B10 v2 BUILT as fold_estimate_v2 over the series, task 143 step 3f, in the v2 chain (chain::declared_chain_v2, task 143 step 3j-1) and folded by the composition's v2 branch (fold_to_settlement, task 143 step 3j-2) — T_i per C56, the mean over the first T_i rows of the pool's column of the recomputed winsorized matrix). μ̂_i = δ_i R̄_i + (1 − δ_i) μ₀, δ_i = T_i / (T_i + shrink_stiffness), R̄_i the mean of pool i's T_i winsorized interval returns — the OBSERVED entries of the matrix, the mask read from the rows (an observed return of exactly 0 counts, a MISSING row does not (v1; under v2 only a wiped-out pool's later snapshots are missing, a no-run interval's 0 counts — C56) — futarchy-system.md §9 C42; both are 0 in the matrix); a pool observed in no run has (v1; under v2 T_i ≥ 1, futarchy-system.md §9 C56) T_i = 0, δ_i = 0 and μ̂_i = μ₀ — the formula with the R̄_i term at weight 0 (CONFIG, futarchy-system.md §9 C43; B10); every sum, mean, δ and μ̂ is held to rational_bits_max (§13) — one past it makes the estimate record's EXHAUSTED outcome, which B12 reads as a budget exhaustion and settles on w^M (§11's fallback; CONFIG C44); μ̂_1 = cash_return.
• Joint-tail CVaR. The K joint same-Δ vectors R^(k),w (missing rows 0, cash cash_return); portfolio loss L^(k)(w) = −wᵀR^(k),w; CVaR_α(L(w)) = min_ζ [ζ + (1/((1 − α)K)) Σ_k max(0, L^(k)(w) − ζ)] (Rockafellar–Uryasev — "the expected loss conditional on being in the worst (1 − α) tail", rendered on the sample as the note's "joint-tail CVaR on portfolio losses").

Where the two notes disagree on the estimator (law 7's disagreement sentence; futarchy-system.md §9 C18, C57). The futarchy note of 19 October names "the precommitted bootstrap estimator Θ(D_T)" and specifies no resampling scheme, sample count or seed; its deterministic reading is the EMPIRICAL distribution of D_T, and the sample CVaR over the matrix (above) IS that plug-in. The one departure is the MEAN: the objective note shrinks it toward μ₀ with the stiffness, the futarchy note's plug-in does not. Default under 7(c): the shrinkage is kept (the plug-in is a new estimator_rule version, not a stiffness value — shrink_stiffness > 0 is the document check's; C18), both positions recorded, a ruling or a specified bootstrap replaces it from the next epoch. The SCORED return is R^bal, the total-balance return the note defines — its Overview says "expected return on utilised capital", the objective note's R_it = pnl_i / capital_i (returns_rule v1, §9) IS a return on utilised capital, and the note itself marks "whether scoring uses this total-balance return or return on utilised capital" as "a choice to resolve before settlement rules are finalised" (C57, both positions named). RULED 2026-10-21 (futarchy-system.md §9 R39, the CEO): the scored basis becomes the net return attributable to the LP credit allocated for the window, unused allocation included; C57 is superseded by R39 from the first epoch whose rule chain declares the LP-return series_rule version, declared once the economist's attribution conventions are pinned, and every epoch before it carries C57's R^bal unchanged. R39 takes neither of the note's two positions: it keeps the unused allocation in the denominator (as R^bal does) and removes the bookmaker's own capital (which R^bal's B_{i,k} contains); the Overview's "expected return on utilised capital" becomes the diagnostic the CEO keeps; the note's Q(w) wording is the economist's to reconcile with his attribution conventions. Closed by R53: the note as rewritten estimates nothing — the v3 chain has no estimator block; the objective note's shrinkage is that note's own text, no longer a default on the v3 chain.

The objective of record (the v1/v2 chains') — the content of objective_rule v1 (§15 D1 — the economist: "Option (a) … is the most currently correct"; the 19 October note writes the same form, Q(w;θ) = E_θ[R_V(w)] − λ CVaR_{α,θ}[−R_V(w)] − ε‖w‖², over N + 1 weights with cash at its index 0 — this document's pool 1):

Q_obj(w) = μ̂ᵀw − λ · CVaR_α(L(w)) − ε ‖w‖².

The 2 October text's Q_mv = wᵀμ − λwᵀΣw is that text's ("Objective and constraints") "for mean-variance utility" example and is NOT computed here.

The feasible set at settlement (the futarchy note, "Constraints on implementation" and "Utilisation-supported caps"; the objective note's constraint 7), feasible_set v2, BUILT as fold_feasible_set_v2 (task 143 step 3g), in the v2 chain (chain::declared_chain_v2, task 143 step 3j-1) and folded by the composition's v2 branch (fold_to_settlement, task 143 step 3j-2):

F_T^util = { w : Σ_i w_i = 1; w_i ≥ 0; w_1 ≥ c_c (the note's w_0, this document's pool 1) (cash's lower row); w_i ≤ b_i for every bookmaker (the individual bound min(c_1, G_i, L E_i / V)of §7, READ fromcapped_share/v2, which records b_i per pool); w_i ≤ e^util_i · w^I_i for every bookmaker with e^util_i < 1 (the utilisation bound); Σ_{i∈S} w_i ≤ c_|S| for every S of a listed size (the group caps, §11) },

with e^util_i = max_{k∈K_T} η_{i,k} / ρ from the balance series (B8 v3, utilization_rule v3, BUILT as fold_utilization_v2, task 143 step 3d, in the v2 chain (chain::declared_chain_v2, task 143 step 3j-1) and folded by the composition's v2 branch (fold_to_settlement, task 143 step 3j-2) — the note: "If e^util_{i,T} < 1, impose this additional upper bound … If e^util_{i,T} ≥ 1, impose no additional utilisation bound"; K_T includes the opening snapshot at M — its η the recorded 0, C59, so the max is unchanged by it — and the closing one at the deadline); cash is exempt from the utilisation caps and the group caps. The 2 October reading — cap^util_i = u_{i,T} / ρ as an absolute share with an ε₀ floor for a pool with no previous allocation — is v2 of the rule, superseded (futarchy-system.md §9 C5, C28, C39). "All original implementation constraints continue to apply": the growth, bootstrap and leverage limits are inside b_i. w^I_i is allocation/v2's V_i / V; a fallback epoch's bookmaker by the verification follows the same rule (its own capital may open a series, so e^util_i may reach 1); on an EXHAUSTED capped_share/v2 (a bound not yet formed recorded 0) the allocation is all-cash (B4 v2) and EVERY bookmaker's upper is 0 — the feasible set is the all-cash point, cash (1, c_c) and the groups unchanged — while the settlement is the raw stake split: B12 v2 reads capped_share/v2's exhausted FIRST, before feasible_set/v2, and when set writes ŵ* := w^M taxed under fallback_rule v2 with exhausted code 2 caps, never optimising over the all-cash set, so every pool's v_i is 1 before the tax — CONFIG, futarchy-system.md §9 C72 and C22 (the economist's answer for the optimiser's budget, R13, applied to Γ_C's; the question goes to the economist; the engine's budget convention: the note's b_i lies past rational_bits_max for at least one pool; a per-pool reading would make settlement depend on document order, since the overrun zeroes the pools after it; a typed halt would freeze the epoch on honest data, C44's principle); the record feasible_set/v2 carries the group caps of the sizes ≤ N alone — the note's "skip a group size greater than N" ("Group limits", the redistribution procedure), and under "Constraints on implementation" item 2 the caps range over S ⊆ {1,…,N}, so a size above N binds nothing — every bound and every group cap held to rational_bits_max (34).

What F_T^util does NOT contain. The objective note's C_t also carries "all precommitted solvency and risk rules hold" and, in constraint 5, "compliance, solvency, and risk limits as precommitted rows of Aw ≤ b or solvency predicates". Of those, v2 represents the group caps (the note's c_|S|) and nothing else — no further predicate has a number or an owner (§15 question 9).

F_T^util is never empty, and the witness is the all-cash point: w = e_1 has w_1 = 1 ≥ c_c (for every c_c ≤ 1; the document check's c_c < 1 is the domain check above, not what the witness needs) with every bookmaker weight 0, below every individual, utilisation and group cap — the 2 October text: "cash retains w̄_1 = 1, so the feasible set remains nonempty even when all bookmaker utilization caps are zero". This is also why an all-cash settlement is a legitimate outcome, not a failure — the 2 October text again: "(1, 0, …, 0) [is] a feasible optimizer choice when holding only cash maximizes Q, even if the bookmakers have spare capacity". Under v2 the witness stands on the current note: "If every e^util ≥ 1, then F_T^util = F_T", the utilisation caps only lower the bookmakers' uppers (cash is exempt), and with c_c < 1 (the document check) the all-cash point meets cash's lower row, so it lies in F_T and in every F_T^util.

The note's utilization example, re-derived. A bookmaker allocated 20 %, utilizing 10 %, with ρ = 0.90: cap^util = 0.10 / 0.90 = 1/9 = 0.1111…; "strong performance on the utilized 10 % can therefore justify at most an 11.11 % credit limit. The additional 1.11 % is the headroom implied by the target utilization ratio."

A shrinkage instance. T_i = 3, shrink_stiffness = 1, R̄_i = 4/100, μ₀ = 0: δ_i = 3/4, μ̂_i = 3/4 · 4/100 = 3/100.

11. The optimizer, its certificate and its fallback #

ŵ*_T = argmax_{w ∈ F_T^util} Q̂_T(w) (both notes).

Shape, stated exactly. In w alone the objective is strictly concave but PIECEWISE quadratic: the sample CVaR is piecewise linear in w (the objective note's own words — "sample CVaR is piecewise linear, so ties are possible"), and the ridge supplies the strict curvature ("−ε‖w‖² is strictly curved, so the sum is strictly concave and has exactly one maximizer"). Lifting the CVaR with ζ and z_k ≥ 0, z_k ≥ L^(k)(w) − ζ turns it into one quadratic program — maximize μ̂ᵀw − λζ − (λ/((1 − α)K)) Σ_k z_k − ε‖w‖² over the polytope of (w, ζ, z), a quadratic objective under linear constraints, linear in (ζ, z) and strictly concave in w. So: a QP in the lifted variables, strictly concave and piecewise quadratic in w. (Our own decision-tree note calls it "a linear program in exact rationals"; that line is wrong and §15 question 15 carries the correction — a linear program has no strictly curved term, and the ridge is exactly what makes the maximizer unique.)

On the v3 chain (B12 v3) the objective is rᵀw − λ_d CVaR_α(L_d(w)) − λ_w CVaR_α(L_w(w)) − ε‖w‖² (§10): still strictly concave and piecewise quadratic in w, now with TWO piecewise-linear terms. Each term lifts with its own ζ_t and z_t,k ≥ 0, z_t,k ≥ L^(k)_t(w) − ζ_t, so the lifted problem stays one QP — maximize rᵀw − Σ_t (λ_t ζ_t + c_t Σ_k z_t,k) − ε‖w‖², linear in (ζ_d, z_d, ζ_w, z_w) and strictly concave in w — with one maximizer in w (the ridge) and each ζ_t recorded as the path reached it.

The maximizer in w is unique and rational. ζ need NOT be: the optimal ζ is generically a whole interval when the tail breakpoints are degenerate. It is RECORDED all the same — the certificate's stationarity conditions are over (w, ζ, z) and cannot be re-checked without it — but as the value the pivot path reached, not as a unique optimum, which is why the certificate below is identified by that path rather than claimed unique. z_k is not recorded: it is max(0, L^(k)(ŵ*) − ζ) from what is.

Method (optimizer_rule v1, with arithmetic_rule = exact rationals, §15 D6): an active-set method on the KKT system of the lifted problem in exact rational arithmetic — every intermediate a fraction of integers, no float anywhere (core law 2) — started at a DECLARED basis, since a start the implementer picked would make the recorded certificate's bytes depend on that choice rather than on the inputs:

v1's initial basis is the ALL-CASH vertex — w = e_1 (feasible on every document, §10), ζ = min_k L^(k)(e_1), z = 0.

From there, with pivot_rule = the lowest-index entering and leaving variable, which makes the pivot PATH a pure function of the inputs. Finiteness is not assumed: lowest-index selection is Bland's anti-cycling rule for the simplex method on a linear program, and this is an active-set method on a quadratic one, where it is not a cycling guarantee — so step_budget bounds the path and the fallback covers its exhaustion. Every rational the solver forms (the HELD SET, futarchy-system.md §9 C47 (i)) is bounded by rational_bits_max bits on its numerator and denominator. "Given the same inputs, independent observers should obtain the same ŵ*_T" (both notes) — here a MUST: the same inputs give the same bytes.

The group caps in the active set (optimizer_rule v2, BUILT with B12 v2 — fold_settlement_v2, task 143 step 3h; futarchy-system.md §9 C60). A cap c_k on every subset of size k is the constraint "the k largest weights sum to at most c_k" — one convex, piecewise-linear constraint on w, exact (for every S of size k, Σ_{i∈S} w_i ≤ the top-k sum). The solver treats it over w alone, with no auxiliary variable: at the current point the binding candidate of size k is the row Σ_{i∈S*} w_i ≤ c_k over the current top-k set S*; the ratio test along a direction tracks the sum of the k largest as a piecewise-linear function of the step, its breakpoints where two coordinates tie, exact in rationals. THE WALK, stated exactly: after the base candidates, the breakpoints t_ij = (w_i − w_j)/(p_j − p_i) > 0 for the bookmaker pairs i < j with p_i ≠ p_j, sorted ascending, equal ones merged; the segments [t_a, t_b) walked ascending while t_a < 1; on each the top-k set S_seg is the order by the value w_i + t_a p_i at the segment's start, then the LARGER rate p_i, then the lowest position — the order on the open segment, so a pair tied at the start with different rates is ordered by its rates and only identical lines tie through to the index (counterexample to "ties by index", size 2 over the full vector, cash first: w = (1/2; 1/4, 1/8, 1/8), p = (0; 0, −1/2, 1/2), c_2 = 3/8 — at t = 0 f_2 = 3/8 = c_2, desks 2 and 3 tie at 1/8, the larger rate puts desk 3 in, S = {1, 3}, rate 1/2, gap 0, t* = 0: the row {1, 3} enters; by index the set would be {1, 2} with rate −1/2 and never block); the first segment whose set's rate is > 0 and whose t* = t_a + (c_k − f_k(t_a)) / rate lies before t_b (f_k reaches c_k inside the segment) blocks at t* with (k, S_seg), provided t* < 1, t* = 0 a legal degenerate pivot; a size's walk ends at the first segment whose t* falls before its end t_b (whether or not t* < 1), or at its last segment — no later segment of that size is formed; every listed size is walked regardless of an earlier size's t*; a rate ≤ 0 never blocks, so a row in the working set (its own rate 0) never re-enters while another set of its size may; a ray never meets a group row (w is fixed); every rational the walk forms is held in futarchy-system.md §9 C47 (i)'s pinned order; a group row in the working set is recorded in the certificate by its size and its members, so the verifier re-checks it without enumerating subsets, and the stationarity gains one multiplier κ_g ≥ 0 per active group row. The working set may hold SEVERAL rows of one size (at a tie on the k-th weight the optimum needs them); the entering order at the least t is every C46 index before every group row, then the lowest size, the size's blocking row the top-k set of the OPEN segment that starts at t* (a cap met exactly at a breakpoint enters the next segment's set at gap 0); the (size, members) order remains the order of E's rows and of leaving; the active group rows are E's LAST rows, ascending by (size, members), each the indicator of its set with right-hand side c_k and multiplier y = +κ_g; leaving, the lowest base index with a negative multiplier first, else the lowest (size, members) group row; the anti-cycling backstop is C47's budget (C60). The group rows are kept beside the C46 enumeration as the index class (size, members) — recorded in settlement/v2's key 7, never an integer of the enumeration; the entering and leaving rules, E's order and the held set of C47 are re-pinned for the new rows ((b), (c), (f), (i)); with no group listed the method is v1's to the byte. The VERIFIER (verify_settlement_v2) re-checks without enumerating subsets: the group rows' identities, every listed cap by sorting (the sum of the k largest bookmaker weights ≤ c_k), per group row its size listed, its members a top-k set at ŵ* (defence in depth — a set summing to c_k under a cap on the k largest is one), Σ_S ŵ* = c_k exactly, κ_g ≥ 0, the stationarity μ̂_i − 2εŵ*_i = ν − κ_lower,i + κ_upper,i + Σ_{g∋i} κ_g − Σ_k κ_d,k R^w[k][i], and the probes within every listed cap (C45) — sufficient, since the cap of size k is the convex hull of the top-set indicators. The alternative — a lift with one threshold variable and N slacks per size, linear in N — is exact too but puts variables with no curvature and no unique optimum into the EQP, which the pinned conventions do not cover; it is not taken. settlement/v2 carries the group rows of the active set; feasible_set/v2 carries the listed sizes and caps, and B12 v2 holds the record's caps to the epoch's pinned list (the document's cap_groups restricted to the bookmaker count, in document order — FeasibleSetDisagrees("groups"), the verifier's Shape("feasible_set groups")).

The method, stated exactly (the conventions beyond am's text are futarchy-system.md §9 C47). The lifted variables x = (w, ζ, z); the WORKING SET W ⊂ the C46 indices, the simplex equality always imposed; Z = {k : z_k ≥ 0 ∈ W}, T = {k : tail_k ∈ W}. Two invariants hold from the start and through every add and drop: Z ∪ T = [K] — every z_k is pinned (0 on Z, L^(k)(w) − ζ on T \ Z, L^(k)(w) = ζ on T ∩ Z) — and W's rows are linearly independent (a blocking constraint has a strictly positive rate along the step, so it is independent of W). The START is the declared point w = e_cash (this document's e_1), ζ = L^(0)(e_cash) (= min_k L^(k)(e_cash): cash's column is cash_return in every row, futarchy-system.md §9 C40), z = 0, with the basis every bookmaker lower bound, every z_k ≥ 0 and tail_0 (C47 (a)) — a vertex. Each ITERATION is one of three cases (a STEP is a PIVOT — an iteration that moves, adds or drops; the terminating optimality check is none; Exhausted::Steps at the step_budget + 1-th pivot — C47 (g)): T ∩ Z = ∅ with s = c|T| − λ ≠ 0 — a RAY in ζ with w fixed, rising to min_{k∈T} L^(k)(w) (that z_k ≥ 0 enters) or falling to max_{k∉T} L^(k)(w) (that tail enters), the lowest k attaining (C47 (d)); T ∩ Z = ∅ with s = 0 — ζ held, the EQP in w with a = μ̂ + c Σ_{k∈T} r_k; T ∩ Z ≠ ∅ — k₀ = min(T ∩ Z) (C47 (e)), ζ = L^(k₀)(w) and the EQP in w: maximize aᵀw − ε‖w‖² on E w = e with a = μ̂ + λ r_{k₀} + c Σ_{k∈T\Z} (r_k − r_{k₀}) (the lift with ζ and z substituted — exact, since the eliminations are equalities of W) and E's rows the simplex, the active bounds, the loss equalities (r_k − r_{k₀})ᵀw = 0 for the other k ∈ T ∩ Z, in C47 (f)'s order; the solution w_new = (a − Eᵀy)/(2ε), (E Eᵀ) y = E a − 2ε e, by exact elimination (C47 (h)). With p = w_new − w = 0 the MULTIPLIERS follow by row kind — the simplex row's y is ν, a lower row's −κ_lower,i, an upper row's +κ_upper,i, a loss row's −κ_d,k; κ_d,k = c on T \ Z, 0 off T, κ_d,k₀ = λ − c|T \ Z| − Σ_{others} κ_d,k (from ∂ζ), κ_z,k = c − κ_d,k on Z (from ∂z_k) — every inequality multiplier ≥ 0 is OPTIMAL (the certificate (w, ζ, W ascending, the multipliers, steps_used, bits_max_used)), else the LOWEST C46 index with a negative multiplier leaves (C47 (c)). With p ≠ 0 the RATIO TEST over the inactive inequalities whose rate is strictly positive (t_j = −g_j/g_j') gives t = min(1, min_j t_j); the move is taken and, when t < 1, the LOWEST C46 index attaining t enters — t = 0 a legal degenerate pivot, a constraint reached exactly at t = 1 not added (C47 (b)). EVERY rational the solver forms — the result of every add, sub, mul, div and negation on its path, formed only through the budget's own arithmetic (the HELD SET of C47 (i), the code's by construction, with the ORDER of formation pinned there — every sum a left fold in ascending index, a zero factor forming no product, a's terms in the stated order, the full Gram, the rates for every run, the losses advanced by t·dL — because lowest-terms widths depend on it) — is held to rational_bits_max the moment it is formed; bits_max_used is the widest; the derived constants 1 − α, (1 − α)K, c and 2ε are the path's first rationals, formed through the same budget after the exhausted-estimate arm (an exhaustion there the bits fallback) — a value compared but not formed (the ray's blocker, the inputs) is not held, nor is the halts' arithmetic before the budget exists (the raw share's sum behind RawShareDisagrees("sum"), a shape check on an input); one past the budget, or the step_budget + 1-th pivot, is the fallback — "the certificate holds" meaning the pinned path's own terminating check, and a pivot taken only after its rationals are held, so a bits exhaustion within a pivot pre-empts the steps one. The fold does not verify its own record (the verifier below is the independent tap); the chain-level tap settlement_reproduces re-folds and compares canonical bytes (§14).

The terms lift (optimizer_rule v3, pivot_rule v3, B12 v3; futarchy-system.md §9 C46 and C47 as superseded on v3). The lift generalises to a list of CVaR terms t, in order daily d then weekly w, each with its loss-row matrix L_t (§2; rows its eligible windows K_T^(h_t), columns the document's pools, cash first — cash's column its pinned horizon return, a pool's its horizon return on B̃, 0 where it has no row), its weight λ_t, its row count K_t (K_d = K, K_w = K − h_w + 1) and its tail weight c_t = λ_t / ((1 − α) K_t); the linear term r = (cash_return_monthly, monthly_return_i …), r_i = 0 for a pool with no series (opening balance 0), takes μ̂'s place. The variables are (w, ζ_d, z_d, ζ_w, z_w). The ENUMERATION v3 is [0, N) lower, [N, 2N) upper, then per term in order [o_t, o_t + K_t) its z ≥ 0 rows and [o_t + K_t, o_t + 2K_t) its tail rows, o_d = 2N, o_w = 2N + 2K_d — with one term exactly the enumeration above. Per term the sets Z_t, T_t, the invariant Z_t ∪ T_t = [K_t] and the three cases hold as above with c_t, λ_t and s_t = c_t|T_t| − λ_t. Each ITERATION: the lowest-index term in the Ray case (T_t ∩ Z_t = ∅, s_t ≠ 0) moves its ζ_t alone along its ray to its blocker, w and the other term fixed; when no term is in the Ray case, the EQP in w with each ζ_t pinned (k₀_t = min(T_t ∩ Z_t), ζ_t = L^(k₀_t)_t(w)) or held, a = r + Σ_t a_t with each term's a_t as the one-term case writes it (c_t Σ_{k∈T_t} r_{t,k} held, λ_t r_{t,k₀_t} + c_t Σ_{k∈T_t \ Z_t} (r_{t,k} − r_{t,k₀_t}) pinned) and every pinned term's loss equalities among E's rows. The PIVOT RULE v3: among the candidates the lowest term first, then the lowest index. The start is the one-term start per term — w = e_cash, each ζ_t = L^(0)_t(e_cash) (cash's column constant in each matrix), z = 0, the basis every bookmaker lower bound, every z_t,k ≥ 0 and each term's tail_0. With one term the path, the pivots, the certificate and the bytes are v1/v2's.

Certificate. The settlement record carries the active set (as indices of the constraint enumeration, futarchy-system.md §9 C46) and the KKT multipliers κ_j (§2 — never the estimate's μ̂); anyone re-checks, in exact arithmetic and in the order the futarchy-system.md §4 B12 row fixes (the order decides which refusal a record with several defects is named by): the matrix REBUILT from the window's rows through B9's builder and its hash held to winsorized's and estimate's (C41 — never read from a record); the shapes (K = 0 refused); the fallback's rules through exhaustion_of (w^M verbatim, Σ w = 1 re-checked); the estimate's rows; the certificate's shapes (one multiplier per index, the indices ascending and distinct); the budgets — steps_used ≤ step_budget, bits_max_used ≤ rational_bits_max, every RECORDED rational within the budget; the verifier's own intermediates are not bounded, since a tap writes no record; primal feasibility (the simplex, the bounds, z_k := max(0, L^(k)(w) − ζ) reconstructed); dual feasibility (κ_j ≥ 0) and complementary slackness (every active g_j = 0 exactly); stationarity (the gradient of the Lagrangian f − Σ_j κ_j g_j − ν h — f the lifted objective μ̂ᵀw − λζ − λ/((1 − α)K) Σ_k z_k − ε Σ_i w_i², h(w) = Σ_i w_i − 1 the simplex equality (never h*, the close height) — zero in w, ζ, z — ∂w_i: μ̂_i − 2εw_i = ν − κ_lower,i + κ_upper,i − Σ_k κ_d,k R^w[k][i], ν DERIVED at the cash coordinate and every other coordinate held to it, never recorded; ∂ζ: λ = Σ_k κ_d,k; ∂z_k: λ/((1 − α)K) = κ_z,k + κ_d,k); then the strict uniqueness identity over the probe set of futarchy-system.md §9 C45 (defence in depth: the KKT conditions are sufficient for the concave lift over a polyhedron, so a verified record IS the maximizer and a probe fails only against a non-maximizer). The verifier proves the VALIDITY of an optimized record; a fallback against a healthy estimate it can only hold to ŵ* = w^M — a forged one is refused only by re-running B12 and comparing bytes, the solver's gate. The verifier (futarchy::verify_settlement) precedes the solver, so the tap exists independently of the optimizer. The certificate is not claimed to be the UNIQUE one — at a degenerate optimum several active sets certify the same ŵ* — only to be A valid certificate, and to be the one the pinned pivot path produces: the path is a function of the inputs, so the recorded bytes are too, and that is what byte identity needs. A record whose certificate fails to verify is corrupted history (§14), and the check is a tap that never calls the optimizer ("a genuinely independent check means not calling the function under test", CLAUDE.md §2–4 item 3).

On v3 (settlement/v3; the v3 verifier fold::certificate_v3, the tap settlement_reproduces_v3) the record carries zetas — one ζ_t per term, daily then weekly — in place of the one zeta, and the KKT rows are per term: f = rᵀw − Σ_t (λ_t ζ_t + c_t Σ_k z_t,k) − ε Σ_i w_i²; ∂w_i: r_i − 2εw_i = ν − κ_lower,i + κ_upper,i + Σ_{g∋i} κ_g − Σ_t Σ_k κ_tail,t,k L_t[k][i]; per term ∂ζ_t: λ_t = Σ_k κ_tail,t,k, and ∂z_t,k: c_t = κ_z,t,k + κ_tail,t,k with c_t = λ_t / ((1 − α) K_t). The verifier's order is v2's with the two matrices and r re-derived from balance_series/v2 through the one builder the fold shares (no hash, futarchy-system.md §9 C97), and the sparse rule first among the fallback's rules (below).

Tie-break. The ridge makes the maximizer unique; tie_break_rule is the note's "backstop for exact numerical ties" and selects the lowest-index vertex among exactly equal objective values — reachable only if ε were 0, which the document refuses.

Fallback (fallback_rule v2 — the default, v1 a declared version; §15 D6 — the economist: "we need a fallback"): if either budget is exhausted before the certificate holds — and an estimate carrying exhausted (B10's budget overrun, futarchy-system.md §9 C44) is such an exhaustion: the optimizer does not run and the record says fallback: true with bits — ŵ* := w^M. Under v2 an exhausted capped_share/v2 (Γ_C's budget, futarchy-system.md §9 C72) is the third: B12 v2 reads it FIRST, after the raw share's shape and before feasible_set/v2 — nothing of the feasible set is read — and writes the same fallback with caps, never optimising over B11 v2's all-cash set; CAPS PRECEDENCE: with the estimate exhausted too the code is caps; the verifier refuses an optimised, bits or steps record under an exhausted capped_share/v2 and a caps record against a healthy one (BUILT, task 143 step 3h; futarchy-system.md §9 C44, C72). On the LIVE path that caps fallback is never reached — CONFIG (futarchy-system.md §9 C72, task 143 step 3j-2): an exhausted capped_share/v2 makes the allocation all-cash (the note's "use the all-cash allocation"), every bookmaker's ceiling 0, which a manifest refuses, and a manifest naming no sleeve refuses to start (§8), so no run is included, min_distinct_matches cannot be 0 (futarchy-system.md §9 C6) and B7 aborts too_few_matches, refunding every stake whole and untaxed (C22: an abort is no settlement) — B7 v2 and v3's ending; on the v3 chain that window closes with no match and SETTLES on the sparse fallback, taxed (futarchy-system.md §9 C93 before C72's arm); B12 v2's caps arm holds the block contract on a constructed input no live epoch reaches; moot while pool_tax = 0 (C16). Then every v_i = ŵ*_i / w^M_i = 1, w^I stands as implemented, and the record says fallback: true with the budget that ran out. The TAX on that path is B13's arithmetic, so B13 declares fallback_rule too (a spanning rule, B12's text) and builds v2 alone — a document pinning v1 is refused typed (FallbackRuleUnbuilt), never priced untaxed by a block that did not build it. Σ ŵ*_i = 1 and ŵ* = w^M ∈ W, so conservation holds; the one thing ŵ* = w^M need not satisfy is a CAP — w^M ∉ F is exactly the case Γ_C exists for — which is why §14's cap check is scoped to the optimizer's output and not the fallback's.

The fallback on the v3 chain (fallback_rule v3: "on budget exhaustion, on Γ_C v2's exhausted budget, or on a sparse window (fewer distinct matches than the floor, B7 v4) ŵ* := w^M exactly, the pool tax still applied"; futarchy-system.md §9 C93, R54). After the input shape checks B12 v2 runs before its caps fallback, B12 v3 reads the SPARSE condition first — window_closed's distinct-match count below min_distinct_matches — and writes ŵ* := w^M with exhausted = sparse (code 3, settlement/v3 only), no arithmetic formed and nothing further read; then caps (C72), then the derived constants' bits, then the solver's steps and bits. B13 v3 prices the sparse fallback like every fallback, v_i = 1, the tax levied: every v_i = 1, so below the floor no prediction gains or loses beyond the tax; scoring sparse evidence is the economist's rule. This is the user's edge default standing in for the economist's sparse-evidence rule (R52 (ii)): below the floor the window settles on the stake split less the tax, at or above it the objective scores; his rule replaces it from the first epoch whose rule chain declares the block carrying it.

Two things about the fallback are departures from the futarchy note, and both are recorded rather than smoothed over. First, the note boxes ŵ*_T ∈ F, and w^M is precisely the object the same note says may violate the caps — so on the fallback path settlement is priced by a vector outside the feasible set. Nothing a bookmaker RECEIVES leaves F: the implemented allocation is still w^I = Γ_C(w^M) and capacity was granted at the close. What leaves F is the pricing vector, and with every v_i = 1 that pricing returns each net position — less the declared pool tax under v2 — rather than redistributing it. The economist asked for a fallback ("we need a fallback"); this is the cheapest one in evidence terms, and it is his to replace.

Second, the tax on the fallback path (§15 question 6). The posted default worded it "stakes are returned" — fallback_rule v1: every staker receives r_ij back whole, no tax, no residue, no charge. The DEFAULT is v2: the tax is levied on the fallback path exactly as on the optimizer's — Π_ij = ⌊r_ij (1 − τ_pool)⌋, T_tax = τ_pool R, the rounding charge as §12 — because the 2 October text ("Taxation and fees?") STATES the rule, and the 19 October note keeps it ("The fee rate is τ, fixed before the futarchy market opens", "Participants and stakes") ("Fees must be declared before the market opens … the rule must apply independently of the final allocation"), and a stated rule is 7(a)'s, not an open value; v1 stays a declared version the economist may pick, and the two are indistinguishable while pool_tax = 0 (futarchy-system.md §9 C16, C22).

12. Payouts, the tax, the cap and conservation #

On the RAW share (the futarchy note, "Settlement" and "Outcome payouts"): "settlement odds use the raw pool share w^M_i = R_i / R, not the constraint-adjusted implementation weight w^I_i" —

v_i = ŵ*_i / w^M_i; pool liability P_i = ŵ*_i R; Π_ij = r_ij · ŵ*_i / w^M_i before fees; Σ_i P_i = R ("Pool accounting").

The tax (the 2 October text, "Taxation and fees?"; the 19 October note, "Participants and stakes": "The fee rate is τ, fixed before the futarchy market opens", and "Pool accounting": τ = 0): T_tax = τ_pool R, R_net = (1 − τ_pool) R, P_i = (1 − τ_pool) ŵ*_i R, Π_ij = r_ij (1 − τ_pool) ŵ*_i / w^M_i; "aggregate payouts equal (1 − τ)R, while τR is transferred to the protocol treasury or another predeclared recipient" — tax_recipient, the account the CEO names there (§1; §15 question 4 — D4 rules out a burn and does not pick the account). "Bettors' aggregate P&L before any other fees is −τR." B13 writes v_i, v'_i, P_i, T_tax and the residue as EXACT rationals — nothing is rounded there (§13: one rounding per quantity): B14 floors each payout, and B15 floors the tax and the residue ONCE, their dropped fractions joining the one rounding charge (futarchy-system.md §9 C48 (b): tax_amount = ⌊τ_pool R⌋).

The payout cap, and the one place it strains the note (§15 question 5 — D8 records only the 1-cent minimum stake and the seed, and names no options). The cap v'_i = min(v_i, v_max) bounds the dust-leverage hole: a one-unit stake on a near-empty pool whose ŵ*_i is large would otherwise pay ŵ*_i R / R_i without bound, and the utilization cap bounds every bookmaker pool but not cash, which the futarchy note exempts while making an all-cash allocation feasible. The amount the cap diverts is NOT dust when it binds: on a pool holding a small share of R against a large ŵ*_i, a cap of 3 can send tens of percent of the whole pool to the recipient in one epoch.

So the cap is specified here and has no producer. No note contains a payout-multiple cap; its residue moves participants' money to a protocol account in an amount that depends on ŵ*, which is exactly what the futarchy note's fee rule forbids — "the rule must apply independently of the final allocation". The engine therefore does not build the diversion ahead of its owner's answer, and it does not fake the absence with a big number either: payout_cap_rule v1 is NO CAP — v'_i = v_i everywhere, no v_max field in the document, cap_residue = 0 in every epoch, pinned as a tap (§14). v2 is the cap, with v_max present and the residue to tax_recipient; §15 question 5 asked whether it should exist at all — CLOSED (no cap, futarchy-system.md §9 R12). The alternative that needs no cap is the one the dust-leverage finding itself suggests: the minimum stake plus a seed per pool large enough that no pool can be dusted — stated in full here rather than by an option letter, since D8 lists none. Under v2 the pool's liability is (1 − τ_pool) R_i v'_i and the RESIDUE (1 − τ_pool) Σ_i R_i (v_i − v'_i) goes to tax_recipient.

That residue's MAGNITUDE depends on ŵ* — and the 2 October text's fee rule ("Taxation and fees?") says "Fees must be declared before the market opens. They may be deducted from the common pool or from settlement payouts, but the rule must apply independently of the final allocation." The cap's RULE is declared before the market opens and is independent of the allocation; the AMOUNT it diverts is not. So either the cap is not a fee in the note's sense (a bound on a pool's payout multiple, outside the note's fee machinery), or it is a fee the note's sentence forbids. The engine took no side: v_max is a field, payout_cap_vmax, and §15 carried the question to the economist in his own terms, with the alternative that needs no cap — the minimum stake and a seed per pool large enough that no pool can be dusted (the alternative stated in full above, since D8 lists no options); he CLOSED it with no cap (§15 question 5), so v2 stays a declared version nobody builds and B13 refuses a document pinning it (PayoutCapUnbuilt). The cap is a RULE VERSION, never a number: payout_cap_vmax is present only under v2, and v1 — the default — has no field to set.

Integer rounding — the economist's rule (rounding_rule v1). He proposed it himself, on the sub-unit-payout thread (the recorded comment): "What if we effectively pay (suggested payout // minimum unit of accounting)? The remainder is therefore an additional protocol charge." So each participant is paid the FLOOR of their exact share in money_unit,

Π_ij = ⌊ r_ij (1 − τ_pool) v'_i ⌋,

and the dropped fractions are summed into one declared ROUNDING CHARGE to tax_recipient. Conservation is then exact by construction, with no tie-break anywhere:

Σ_ij Π_ij + ⌊T_tax⌋ + ⌊cap_residue⌋ + rounding_charge = R — exactly, in money_unit; Σ_j PnL_j = −⌊T_tax⌋ − ⌊cap_residue⌋ − rounding_charge (the floors B15's, C48 (b)).

The charge is bounded by one unit per payout row — the tax's and the residue's own dropped fractions included (futarchy-system.md §9 C48 (b); under payout_cap_rule v1 the residue is 0, so the bound is m, the payout rows; a fractional residue, which no existing version produces, would allow one unit more), so equality with the row count is reachable and "fewer than the stake records" is not promised — and it is dust at any serious stake size — and min_stake_units is what keeps it dust RELATIVE to the stakes: at the 1 cent minimum (§15 D8) a participant can lose at most one cent of a payout to it. The rule has two properties the alternative lacks: it needs no tie order at all, so two observers cannot disagree about who got the spare unit, and it never pays anyone MORE than their exact share.

B14 (futarchy::fold_stake_payouts) pays B1's positions — the list close_book returns at the close, every net position above zero in the order of each position's first row of any kind (§6; a position born by a move at the move's offset, one grown by a later move or drained to 0 and re-credited in its slot) — one stake_payout each, the amount formed as ⌊r_ij P_i / R_i⌋ from B13's EXACT liability (= ⌊r_ij (1 − τ_pool) v'_i⌋ term by term, since P_i = (1 − τ_pool) R_i v'_i; v'_i is not read, τ_pool only to re-hold the stored record's net identity Σ_i P_i = (1 − τ_pool) R beside its conservation, so a record whose tax was folded into the pools never pays; the split of Σ_i P_i across the pools is the settlement's — an observer that reads a STORED pool_liability re-derives it through B13 first — re-running B13 and comparing bytes, futarchy-system.md §10's byte-identity tap —), the ℓ-th record stamped (h*, window_seq + 7 + ℓ) after pool_liability's + 6 (futarchy-system.md §9 C49). The seeder's seeds (C11) and a moved position at its destination (C12) are paid like every row; B14 writes no charge — the dropped fractions, below one unit per position in all, are B15's.

B15 (futarchy::fold_epoch_settled) writes the epoch's settlement record — tax_amount = ⌊T_tax⌋ and cap_residue = ⌊cap_residue⌋, the first and only rounding of each (futarchy-system.md §9 C48 (b)), payouts_total the sum of B14's floors, and rounding_charge = R − payouts_total − tax_amount − cap_residue, so the identity above holds exactly in money_unit by construction (the four amounts re-add to R). What B15 HOLDS, before it floors: the stored liabilities' signs, conservation and net identity (the home shared with B14) and T_tax = τ_pool R against the document's rate — which, with conservation and the net identity, holds iff cap_residue = 0 —, the payouts per pool against P_i (the whole within Σ_i P_i follows), rounding_rule v1 (the bound below is v1's), and the charge's RANGE: at most one unit per payout row (rounding_charge ≤ m) — a charge above m means a payout below its floor, corrupted history (§14). The bound's detection power is a recorded limitation: a shortfall of at most m units in all, or a payout list padded with zero payouts, passes, since B15 receives no positions by its declaration — the composition runs B14 for real, and a STORED payout list is accepted only when B14's re-fold over B1's positions and the stored pool_liability reproduces its bytes (payouts_reproduce, the chain-level tap of futarchy-system.md §10, named here and in §14 as the condition that makes the limitation safe; with the composition). The three amounts go to tax_recipient; the record carries no account — the document's field is read by whoever publishes them (futarchy-system.md §9 C50), stamped (h*, window_seq + 7 + m) after the m payouts.

The alternative, pinnable under the same field as v2, is the engine's largest-remainder rule (normalize_exact's — model-plugin-layer §6: floor, then the spare units to the largest fractional remainders, ties by LOWER index; here the lower index is the earlier position in B1's first-row order). It keeps every unit with the participants instead of the protocol, at the cost of a tie order that decides who receives a spare unit. Example of the difference — three 1-unit stakes against a pool liability of 2 units: v1 pays 0, 0, 0 and charges 2 to the protocol; v2 pays 1, 1, 0 by position order. The economist's v1 is the version with a producer.

A consistency check against the business paper's instance. The GRID discussion paper works the market through once in round numbers, with pool_tax at zero — its "With prediction fees omitted" — and it is consistent with §7 and §12 term by term. A $100 000 underwriting vault with a SEPARATE $10 000 prediction pot; closing stakes of 20 % on cash, 40 % on desk A and 40 % on desk B; no limit binding, so w^I = w^M and the ceilings are $20 000 held as cash, $40 000 and $40 000 (§7). The assessment returns ŵ* = (0.20, 0.50, 0.30) in that same cash-first order, so the pools take ŵ*_i R = $2 000, $5 000 and $3 000, summing to R (§12), and v_i = ŵ*_i / w^M_i is 1.00, 1.25 and 0.75 — a $100 stake returns $125 on A and $75 on B, which is what the paper states. It is a check, not a confirmation: the paper is downstream of the same notes and defers its mechanics to the economist's and our own inserts. Both of its cautions travel with it — "These transfers neither create vault trading profit nor establish an underwriting APR", and "The assumed assessment illustrates settlement accounting, not a simulation result."

Worked instance (money_unit = cent, total pool R = 100 000, τ_pool = 1/50, payout_cap_rule v1; the instance was first worked under v2 with v_max = 3, never reached, and every number below is the same — pools cash / A / B): pool totals (R_1, R_2, R_3) = (60 000, 25 000, 15 000) — every pool SEEDED first (the futarchy note's r_i1 > 0; a non-seed first row is corrupted history, §6): cash holds the seeder's 1 000 and one 59 000 stake, A the seeder's 1 000 then 19 000 and 5 000, B the seeder's 1 000 then 14 000 (re-split from an earlier 20 000 / 15 000 split, which broke the seed-first rule; the totals and everything derived from them are unchanged — futarchy-system.md §7's E2 log carries exactly these rows) → w^M = (0.60, 0.25, 0.15) (the note's vector; w̄ = (1, 0.50, 0.50) — for this example bookmaker_cap_max = 1/2 and a non-genesis epoch with n · w^I_{prev} ≥ 1/2 for A and B, so the caps pass §3's checks — keeps w^M ∈ F, so w^I = w^M and V = 1 000 000 mills gives V_i = (600 000, 250 000, 150 000) — A's and B's sleeves quote under 250 000 and 150 000 mills, 600 000 stays in reserve). Settlement returns ŵ* = (0.30, 0.40, 0.30): v = (0.5, 1.6, 2.0), none above v_max; T_tax = 2 000; pool liabilities (1 − 1/50)·(30 000, 40 000, 30 000) = (29 400, 39 200, 29 400); 29 400 + 39 200 + 29 400 + 2 000 = 100 000 ✓. Pool A holds three positions, 1 000 / 19 000 / 5 000: their exact shares of 39 200 (1.568 per staked cent) are 1 568, 29 792 and 7 840, all whole, so the floor costs nothing — P&L +568, +10 792 and +2 840. Cash's two rows take 29 400 · 1/60 = 490 and 29 400 · 59/60 = 28 910, and B's two rows (1.96 per cent) 1 960 and 27 440 — every share whole, so the rounding charge is 0 on this instance and the parts sum to R with nothing left over.

Split that cash stake instead into 29 999 and 29 001 (the pool still totals 60 000 with the 1 000 seed, so nothing above changes). The pool's unit payout is 29 400 / 60 000 = 0.49 per staked cent, so the three exact shares are 490, 14 699.51 and 14 210.49; the floors pay 490, 14 699 and 14 210 — 29 399 in all — and the one remaining cent is the rounding charge to tax_recipient. 29 399 + 39 200 + 29 400 + 2 000 + 1 = 100 000 ✓. In the fallback on the UNSPLIT book (ŵ* := w^M): v = (1, 1, 1); under fallback_rule v2 (the default) each position — every stake row here is a position of its own, there being no withdrawal — is paid ⌊r_ij · 49/50⌋ — 980 and 57 820 on cash, 980, 18 620 and 4 900 on A, 980 and 13 720 on B — and T_tax = 2 000, so 98 000 + 2 000 = 100 000 ✓ with no cap residue and no rounding charge (every share whole); under v1 every stake would be returned whole and the tax not levied (§11).

The participation yield (the futarchy note, "Participation yield"; B14b, participation_yield_rule v1 — BUILT as futarchy::fold_participation_yield with its record and declaration, task 143 step 3i, in the v2 chain (chain::declared_chain_v2, task 143 step 3j-1) and folded by the composition's v2 branch (fold_to_settlement, task 143 step 3j-2)) — paid beside the payouts from a budget outside the pool: a substake is a portion of a participant's stake in a pool with the height it was last placed. The ledger is built per (participant, pool) from the epoch log's stake rows in offset order up to the first block_final at or above M (the slice B1 reads): stake_recorded at height d opens a substake; stake_moved closes substakes of the SOURCE pool NEWEST first — newest is the LARGEST HEIGHT (the note's timestamp), ties by the largest log offset, since admission holds a row's height only at or below the latest final and a later offset may carry a lower height; the tie by the largest offset is a determinism rule with no effect on H or any halt, since equal heights carry equal weights (futarchy-system.md §9 C54 — the note: "If only part of a stake is moved, reset the timestamp only for that part", which part unnamed; newest first keeps the most duration for the mover, where the alternatives are oldest first, FIFO, under which the mover keeps less duration — the move gate's p1 holds 38 500 against 38 800 — and pro-rata, neutral between portions) — a partial close shrinking that substake, and opens one in the destination at the move's height; a move whose source pool is its destination is refused (YieldDisagrees("pool"), a defensive re-hold — B1 refuses it first as MoveSamePool); C54 is read as the ONE closing rule, so stake_withdrawn closes newest first the same way — a dead arm under v2, which refuses withdrawals (C12), kept as a total rule; amounts and heights freeze at M, and the open substakes per (participant, pool) equal B1's position exactly (corrupted history otherwise). H_j = Σ_i Σ_d s^(d)_{ij} (M − d) / (M − open_height) (field 48 — no stake row precedes it, the chain reader records from it, so no weight exceeds 1); Y_j = ⌊y H_j / Σ_m H_m⌋ in money_unit, y = participation_reward_units (64, default 0 — the yield is off until a value is set, C64); the floor is participation_yield_rule (66)'s own, separate from rounding_rule (37): the remainder y − Σ_j Y_j is UNPAID — never a charge to tax_recipient — derivable, as B15's charge is, and an integer below the number of participants with H_j > 0 (each floor loses less than one unit; NOT bounded by the row count — with y = 1 and two equal weights every Y_j = 0, no row, remainder 1); with y = 0 or Σ_m H_m = 0 no row is written — after every halt, so corrupted history is named under the default too (the rounding, C64). THE SEEDER is a participant AS THE NOTE STATES (C64): "Index the M futarchists by j = 1, …, M" ("Participants and stakes"), "The first futarchist, indexed by j = 1, supplies a positive initial stake to every outcome" and "Initial stakes follow the same rules as later stakes" ("Opening and initial stakes"), and Σ_{m=1}^{M} H_m includes j = 1 (the note's M there the futarchist count, §2) — so its seeds are ordinary stake rows held from their height and C11 pays it like every row, its substakes count in H and its row is written when positive — allocation-side accounting, not the vote of C8 / R20; once y > 0 its duration dilutes every other row. The inclusion is a property of rule 66's identity (a rule version, not a config field): excluding the seeder would depart from the note and could come only from a dated ruling record (law 7(c)), never by swapping a value. "Participation yield is independent of betting gains and losses, so a losing position remains eligible. It accrues only during [t_1, t_2)". The yield is not part of the closing pool (the note's S, this document's R); its funding is outside the engine — the payout publisher (futarchy-system.md §7 E5) reads the rows as it reads the payouts. One participation_yield {participant, amount} per participant with Y_j > 0, in the order of each participant's first appearance in B1's position list (a participant whose earliest pool was drained appears where its first surviving position does), before epoch_settled.

13. The determinism bridge #

The notes say independent observers "should" obtain the same ŵ*_T; here that should is a MUST (core law 2; CLAUDE.md law 7(d)):

• Arithmetic. Stake sums, capacities and payouts are integers; w^M, B13's v_i, P_i, T_tax and residue, w^I, R_it, μ̂, the CVaR auxiliaries, ŵ* and the certificate are exact rationals (§15 D6) — fractions of arbitrary-precision integers bounded by rational_bits_max, reduced to lowest terms at every step so the representation is canonical. No float, no RNG, no wall clock, no unordered iteration anywhere in the fold (clippy.toml enforces the bans mechanically); the only time in the layer is the chain's block height and the runs' replay_ts.
• One rounding per quantity, at the declared place: the capacities V_i in mills (§7, every pool floored, the whole leftover to cash), the payouts in money_unit (§12, floored with the dropped fractions charged) and the tax and the cap's residue in money_unit at B15 (floored, the fractions in the same charge — futarchy-system.md §9 C48 (b)); B13's liabilities are exact and rounded nowhere. Never a rounded intermediate, and never one rule read for the other.
• A fixed iteration budget (step_budget, rational_bits_max) and a declared fallback — no tolerance-terminated loop, no "close enough".
• A certificate anyone re-checks (§11) in the same arithmetic — the independent recompute the determinism harness runs on every other stream.
• Byte identity. Two folds over the same epoch log and the same sealed run streams produce the same allocation stream, byte for byte; the determinism harness (architecture.md) re-runs the allocation fold from the epoch log and the included runs' root logs as it re-runs every run from its roots.

14. Refusals and verification taps #

Refused at the edge / halting if recorded (event-catalog §4's posture — a fold never guesses on corrupted history):

Taps — the notes' identities as tests that can fail, each computing its expected value independently of the code it checks:

• Σ_i w^I_i = 1, and w^I inside the simplex and the box caps — Γ_C's own target set, not F_T^util, whose buffer and utilization caps bind only at settlement; Γ_C(w) = w whenever w already satisfies the box caps; at most N passes (§7; the futarchy note's example reproduced).
• Σ_i V_i = V; V_i ≤ ⌊w̄_i V⌋ (§7).
• Σ_i w̄_i ≥ 1 CHECKED on every document (never assumed).
• Σ_i ŵ*_i = 1 and, outside the fallback, ŵ* ∈ F_T^util with the KKT certificate holding (§11); in the fallback ŵ* = w^M exactly.
• Under payout_cap_rule v1, cap_residue = 0 in every epoch — the no-cap version is pinned, not assumed.
• Σ_i P_i = (1 − τ_pool) R before any cap; Σ_ij Π_ij + ⌊T_tax⌋ + ⌊cap_residue⌋ + rounding_charge = R as integers (§12); Σ_j PnL_j = −⌊T_tax⌋ − ⌊cap_residue⌋ − rounding_charge (the floors B15's, futarchy-system.md §9 C48 (b)); the rounding charge is at most one unit per payout row.
• The note's own PRE-FEE identity, as its own case: with τ_pool = 0, a non-binding v_max and every share whole, Σ_j PnL_j = 0 exactly ("Zero-sum accounting") — the taxed form above must not be the only pin.
• The ridge's uniqueness, as a check and not an assumption: Q̂_T(ŵ*) > Q̂_T(w) STRICTLY, for every w of a declared finite probe set of feasible points (the vertices of F_T^util the certificate's active set touches, and the all-cash point), evaluated in exact arithmetic without calling the optimizer; ε = 0 stays refused at the document, where the objective note rests the single maximizer on ε > 0.
• The utilization caps bind at SETTLEMENT ONLY: Γ_C's target set is the simplex and the box caps, and contains no cap^util — "At settlement, the original feasible set is intersected with the realized utilization constraints" (futarchy note). Operationally: two different u_{i,T} profiles over the same stakes must yield byte-identical w^I, and every bookmaker pool must satisfy ŵ*_i ≤ u_{i,T}/ρ.
• A withdrawal obeys 0 ≤ x_i ≤ r_ij, R_i − x_i > 0, and r_ij − x_i is 0 or at least min_stake_units (§4).
• Cash keeps w̄_1 = 1; the growth and utilization caps bind i ≥ 2 only; u_{i,T} = 0 gives cap^util_i = 0 unless the bootstrap applies (§10).
• F_T^util ≠ ∅ on every document.
• The utilization example 0.10 / 0.90 = 1/9 and the shrinkage instance (v1/v2) (§10) re-derived by hand in the test, never by calling Θ.

The v2 taps and refusals (B3 v2's and B4 v2's pinned by tests/futarchy_gamma_c_v2.rs, B6b's series identity by tests/futarchy_balance_series.rs; the chain-level taps — settlement_reproduces_v2, payouts_reproduce — on the composed v2 stream by tests/futarchy_compose_v2.rs, task 143 step 3j-2): w^I ∈ F_T — cash ≥ c_c, every bookmaker ≤ b_i, every top-two, top-three and top-five sum within its cap (B4's verification); Γ_C(w) = w for w ∈ F_T ON THE D-GRID (off the grid the floor moves it); Σ_i w_i = 1 on a capped_share/v2 without exhausted (an exhausted record is off the simplex by its unassigned release, C72); the all-cash fallback whenever the verification fails or the budget is exhausted (B4's CapacityExceeds arms — a floor past u64 — are unreachable on a checked document, whose V fits); at settlement ŵ*_i ≤ e^util_i w^I_i for every non-cash pool with e^util_i < 1, no bound at or above 1, cash exempt, a pool with e^util_i = 0 capped at 0 with no bootstrap at settlement (the note, "Utilisation-supported caps"); on every stake_moved 0 ≤ x ≤ s_ij and S_i − x > 0 (the note, "Reallocation"); F^own + F^credit + U^peak = B at every snapshot with U^peak ≤ B, and η = 1 above it; Σ_j Y_j ≤ y with the remainder below the number of participants with H_j > 0; the document refusals SnapshotGrid, PrecisionGrid, the cap_groups shape, the cash_min range, the own_capital length, a stake_mobility other than moves, and the keys 5, 9, 14 and 55 on a v2 document (BUILT, task 143). The composition's boundary for a v2 document is B0: under the v1 chain it is refused at the chain equality (ChainLength) before any block runs; under the assembled v2 chain (declared_chain_v2(), task 143 step 3j-1) it passes B0 and the first segment dispatches on the version — B3 v2 and B4 v2 write capped_share/v2 and allocation/v2; the composition's v2 branch after the window (B6b, B8 v3 … B15 v2, task 143 step 3j-2) folds it through epoch_settled in §5's v2 layout, B13 over settlement/v2 through records::SettledWeights; B3 v1, B9 v1 and B11 v1 — and B10 v1 and B12 v1 through the matrix B9 recomputes for them — carry the defensive halt CapsRuleUnbuilt (the PayoutCapUnbuilt shape).

The v3 taps (B0 v3, B6b v2, B12 v3, B13 v3; futarchy-system.md §7, §10): the three fixture cash pins accepted by the bracket and each pin one unit of 10^{−12} above or below refused; weekly_return present exactly at k ≥ h_w and every return on B̃; the note's 30-observation tail (L_(1) + ½ L_(2)) / 1.5 re-derived by hand against the objective's CVaR, never by calling it; Σ_i ŵ*_i = 1 and the KKT rows per term on every optimized record; a window below the floor settling with exhausted = sparse, every v_i = 1, the tax levied and B15's identity holding; settlement_reproduces_v3 true on the stored stream and false on one mutation; with one term the v1 and v2 records byte for byte; the bit bound — the fixture document passing it at p = 12, K = 30 and a document at p = 18, K = 31 passing it too (at the fixture's rate its largest bracket integer is 22 064 bits); the ridge resolved on the v3 fixture — one maximizer, ε halved or doubled moving no coordinate of ŵ* by more than 1/100, and ε‖ŵ*‖² below one thousandth of |ŵ*ᵀr| + λ_d |CVaR^(1)| + λ_w |CVaR^(7)| at the optimum (futarchy-system.md §9 C98; ε the CONFIG value, both fractions test acceptance thresholds, ours (engine), not epoch inputs — the note's "test that the optimiser can resolve the ridge term while its contribution remains small").

15. Rulings, defaults and open values #

Law 7's record for this layer. A RULING is a dated line quoting its author — law 7's ruling record, (c): the user's words, or the economist's or the CEO's own words from an authority note or its HackMD comments, admitted by the user's answer 7 of that day ("Correct"), effective from the next epoch; a DEFAULT is the CONFIG value or rule the first epoch document carries unless its owner changes it — posted in the HackMD decision-tree note — the user, 6 Oct 2026: "add proposed solutions to remaining decisions super DRY and concise and 100 % aligned with our core engine principles" — and in the team's Defaults Register (HackMD KQvluWaOQruNsbSuvEOTug), with every VALUE listed in futarchy-system.md §9; an OPEN VALUE is a field no default can supply (an account, a chain). The rulings and defaults are recorded in futarchy-system.md §9 (its R and C tables) and summarised below.

A sixth source, and what it is not. The GRID discussion paper — "Full House: a verifiable underwriting exchange for esports", a working draft by the user, the economist and the CEO prepared for an external partner, kept beside the authority notes and gitignored like them — is cited in §1, §12 and below. §1 carries the same standing note at its first citation, so a reader meets it before any use. It is NOT an authority note and NOT a ruling record. Its own text says the features it describes "are proposed capabilities", marks blocks as "material to complete before external circulation", and closes "Detailed mechanics still await the named owners' specifications". So it is cited here only as CORROBORATION of something a note or a recorded ruling already carries, never as the authority for a rule, and no question below is narrowed or closed by it. It does usefully name the three accounts this market touches (§1) and work the market through once in round numbers (§12).

It also records who owes what. Its engine package is assigned to us — "the relationship between prediction close, evaluation start/end and credit activation, plus deterministic calculation, rounding and failure handling", and separately the state-transition diagram, the credit and collateral invariants, sequencing, feed-failure suspension, finality and recovery. This document is the first of those two; the second lives across the sibling specs. Its economics package is the economist's — "the definitive objective, net-return definition, evidence estimator, sample window, caps and redistribution policy" and the "treatment of non-participating desks" — which is where questions 1, 12 and 14 and D7's redistribution rule are owed. It also names the manipulation question 5 exists for: "a small prediction stake can redirect a much larger credit allocation".

Rulings (the decision-tree note's comment threads):

• D1 — the economist, 5 Oct 2026, choosing between the two candidate objectives: "Option (a) … is the most currently correct. The one in [the other source] was an early example / filler." (the bracket replaces a private document's name) → Q_obj is the objective of record (§10).
• D3 — the CEO, 5 Oct 2026: "this is where we have an onchain vault in our blockchain to hold funds of our predictors." → facts-only custody (§1, §4).
• D4 — the CEO, 5 Oct 2026: "We don't do burns - this is the previous doc iterations. As we need to funnel productive assets to other means. E.g. protocol owned liquidity in a protocol owned vault" → RULED: no burn anywhere in this layer. NOT ruled by it, and asked in questions 3 and 4 below: the market SHAPE (the comment does not mention proposal markets or the 70 / 30 split), and which protocol account tax_recipient names. The vault's tax is routed into "available protocol surplus after its obligations", which is a different account from the protocol-owned vault that buys credit inventory, and the engine infers neither.
• D5 — the economist, 5 Oct 2026: "HOUSE will be introduce later. Current vision is that Futarchy 1.0. operates with USD-equivalent only." → USD-equivalent stakes and payouts (§1, §3).
• D8 — the CEO, 5 Oct 2026: "From a product pov, having normal fiat denominators for minimum staking makes most product sense. I.e. 1 cent." → min_stake_units = 1 cent USD-equivalent, pending the economist on the economic minimum.
• The payout rounding — the economist, 4 Oct 2026, on the sub-unit-payout thread: "What if we effectively pay (suggested payout // minimum unit of accounting)? The remainder is therefore an additional protocol charge." → rounding_rule v1: each payout floored to the money unit, the dropped fractions one declared charge to tax_recipient (§12).
• D12 — the CEO, 5 Oct 2026: "this is FIFO in terms of accepted stake in our sequencer. And if the cut off window for a prediction market is N time, then we cut off at block M that correlates to N time. Celestia DA is only the finality layer for our chain to settle its rollup blocks" → the order and the close of §4–§5.
• The economist, 2 Oct 2026 (the panel note's threads), asked to confirm that Δ is one match: "At the beginning when the number of book-makers is low and markets are thin, it is better to use /delta as one match. However, when there are several competitive book-makers or the market is very liquid, it is better to use /delta as a fixed interval of time." → Δ = one run first, a time interval later; asked whether D_T is derived from the engine's own settlement records: "Correct."; q95 at portfolio level and the allocation weight as the next run's frozen-manifest ceiling are his unquoted answers in the same threads.
• D6 — the economist, 2 Oct 2026, on the arithmetic thread: "Yes. Agree, that we need a fallback when computation goes over meaningful limits." → the optimizer carries a declared fallback rather than failing (§11; the posted D6 default fixes its content).
• The economist, 2 Oct 2026 (the same threads), asked to confirm that all arithmetic is exact: "It sounds right to me. The leftover could go to the cash." → the capacity rounding of §7: an exact argmax rounded once, the leftover to cash and not by remainder.
• D9 — the posted default records one thing and this document claims no more of it: utilization is DRAWN credit, never reservations — REPLACED by the economist's own words (§9; futarchy-system.md §9 R1, R3: drawn plus reserved, the peak over the period).
• The user, 5 Oct 2026: "whatever is their vision, our job is to make it hold our principles, and make it bullet proof"; the user's defaults ruling (quoted at the head of §15).
• The economist, 2026-10-12, on the live note's comment threads — futarchy-system.md §9 R1–R7 carry his words — → window_rule v2 and utilization_rule v2 (§9), missing_row_rule v1's zero and previous_allocation_rule v1's w^I confirmed, the credit-economics rates CONFIG fields; questions 1, 7, 12 and 14 below are CLOSED by these.
• 2026-10-12, the CEO, on the live note's question 21 (retail leverage): "We will deal with it later once we have the risk engine" → out of scope.
• 2026-10-13, the user, asked whether a market may straddle an epoch boundary keeping the values it opened under: "No preference on the sentences" → the default stands (CLAUDE.md law 8(b); the register's row 1).
• 2026-10-21/23 — the Note on Futarchy rewritten (futarchy-system.md §9 R53, the economist, 2026-10-21: the objective Q̂_T with λ_d = λ_w = 0.1, r_c = 0.035, "No return expectation is estimated", winsorisation a future step); the user's sparse-evidence edge default (R54, 2026-10-23: "can we use some sort of edge settings until we wait for Oleh do decide?" — below the floor the window settles on the stake-split fallback less the tax); the defaults C93–C98 (register rows 96–101) → the v3 document and chain (§3, §5, §9–§11, §14).
• 2026-10-23 — the CEO's PV-04 and PV-06 (futarchy-system.md §9 R42, R44, R47) carried into the v3 chain as the defaults C99–C101 (register rows 102–104): B1 v2, B5 v4 and B7 v5 in the v3 chain, epoch_aborted/v2, the capital views (§5, §6, §8, §8b, §9, §14).

Every comment quoted above was read from the decision-tree note's own comment threads on the dates given; the narrative records carry each body verbatim with its author and timestamp, so this document is not the only copy of the authority for the choices it records.

Defaults. The status column uses four words. RULED: a ruling record fixes it (the row names the futarchy-system.md §9 R row). CONFIRMED: a default this document took that its owner's quoted answer later matched. CONFIG: a default under law 7(c), its owner free to change it from the next epoch — the D rows are the decision-tree note's posted "Defaults" table, the — rows this document's own defaults, each with a register row in the Defaults Register. OPEN: a value no default supplies.

Questions this document puts to them, each in their own terms (those since answered are marked CLOSED with the quote, or DEFAULTED with the CONFIG row):

1. (CLOSED as to the aggregation — the economist, 2026-10-12: "The peak over the whole period initially."; the per-run reading stands as CONFIG C35.) To the economist — how a run's capital is measured, and how it averages over the window. As asked: per run the engine took the PEAK of posted plus reserved collateral as capital and the peak of drawn credit as utilization, and the MEAN of per-run peaks over the window; the rivals named were the window peak, the dollar-second share and the median. As answered (futarchy-system.md §9 R1, R3): utilization is drawn PLUS reserved and the window PEAK — utilization_rule v2 (§9); the per-run capital definition stands as the engine's reading (futarchy-system.md §9 C35 — the denominator, the sign rule, the per-run peak and the sampling instant; C5 is the window's aggregation).
2. To both — the protocol's own seed is a position in the market. A seed has to be an ordinary stake for the pool to be funded, so the seeder — the protocol — collects that pool's pari-mutuel payout and bears its loss. That is value moving between the protocol and the market in both directions, beside the tax, and the notes do not discuss it. The engine pays the seeder's row like any other — it has to, or Σ_i P_i = (1 − τ) R fails — so the question is what happens to that payout AFTER it is paid: back to the protocol, or rolled into the next epoch's seed? (Giving it to the pool's other stakers instead would change the note's settlement identity, not a parameter, so it is not on this list.)
3. To both — the market shape, to confirm in writing. For the vault-capacity layer, is it one pari-mutuel allocation market per epoch, and are the product thesis's per-strategy YES / NO proposal markets (the 70 / 30 split to correct predictors, the locked HOUSE burned) superseded for this layer — or do they remain a separate mechanism we must still model? The CEO's comment ruled out burns (§15 D4); it did not speak to the shape, and the two notes disagree, so nothing here takes a side (§1).
4. (CLOSED as to the account — the CEO, 2026-10-13: "POV makes most sense"; the rate is theirs to set, pool_tax = 0 meanwhile.) To the CEO — which account the pool tax goes to. Does τ_pool · R land in the protocol-owned vault directly, or in available protocol surplus after the vault's obligations and required reserves, as the tokenomics draft words it — and are those the same account or different ones? The engine records one address and models neither gate (§12).
5. (CLOSED — the economist, 2026-10-13: "I dont think we should cap pool's payout mutliple".) To the economist — the payout cap against your own fee rule. The 2 October text ("Taxation and fees?") says a fee's rule must apply independently of the final allocation. A cap on a pool's payout multiple diverts an amount that depends on ŵ*, and when it binds that amount is large, not dust. Is the cap outside the fee rule (a bound, not a fee), or should there be no cap — the minimum stake and a seed per pool large enough that no pool can be dusted? Until you answer, the default is v1: no cap (§12).
6. (CLOSED — the economist, 2026-10-13: "the fee is charged anyways"; v2 confirmed.) To the economist — the tax when the optimizer falls back. If the step budget runs out and settlement pays ŵ* := w^M, the posted default returned the stakes untaxed (v1); the engine produces v2, the tax levied, because your own fee rule — "the rule must apply independently of the final allocation" — is a stated rule. Say so if you want v1; the difference is τ_pool R (§11).
7. (CLOSED — the economist, 2026-10-12: "What it had.") To the economist — which previous allocation the transition rule means. In w̄_i ≤ n · w^prev_i, is w^prev the predecessor epoch's IMPLEMENTED allocation w^I (what the bookmaker actually had) or its SETTLEMENT allocation ŵ* (what the optimizer judged optimal)? They differ materially; the engine reads w^I unless you say otherwise (§3).
8. (CLOSED as to a cycle nobody votes in — the CEO, 2026-10-13: "a state like "cancelled"", epoch_aborted{no_votes}; the per-pool R_i = 0 case stays the CONFIG abort.) To both — the treatment of empty pools. At the close, does an epoch with any pool at R_i = 0 abort and refund every net position in full, or proceed on the funded pools with the unseeded pool out of the simplex and out of the window's returns? The arithmetic needs R_i > 0, so the engine refuses rather than invent; the rule is yours (§4, §6).
9. (The economist asked back (futarchy-system.md §9 R15) which caps are meant — the credit split; Γ_C under a group row is declared pro rata, so only the number is open.) To the economist — solvency and compliance predicates. Are there rules beyond the box caps that must enter F_T for the first epochs, and what rule identity declares them? v1 represents none: F_T^util is the simplex, the box caps, the liquidity buffer and the utilization caps, and group rows are refused pending D7 (§10).
10. (DEFAULTED by window_rule v2 — the deadline always arrives; below the match floor the epoch aborts and refunds, CONFIG C8 — the owners' to replace.) To both — what ends an epoch whose window never fills. If the runs never reach runs_n with min_distinct_matches, nothing in v1 closes the epoch: no settlement, no abort, stakes locked. A deadline height that aborts and refunds in full (a new field), settlement on the runs observed so far, or locked until the runs exist? (§9.)
11. To both — a bookmaker whose capacity rounds to zero. A bookmaker with a previous allocation whose integer capacity rounds to 0 mills, or which quotes in no run of the window, records NONE (u = 0 for B11, C39) and therefore a settlement cap of 0 — permanently, since the ε₀ floor is written for a bookmaker with NO previous allocation. Does ε₀ apply to it too, or does a zero-capacity pool keep its previous cap? (§7, §10.)
12. (CLOSED — the economist, 2026-10-12: "Every match."; the fixed span of v2 replaces the count.) To the economist — confirm the window rule, since it is your field and the note's first precommitment. v1 takes every run whose own manifest cites the epoch's allocation record, in the log's order, to the first prefix meeting runs_n and min_distinct_matches. It is the one new default with no alternative proposed, because any other reading we could see lets someone choose the evidence after stakes are in. Confirm it or name the rule you want (§9).
13. (CLOSED — the economist, 2026-10-13: "Scale down pro rata"; the bookmakers scale down to make room for the cash minimum; b̲ = 0 stays until a number is given.) To the economist — Γ_C under a liquidity buffer. Γ_C caps weights downward; the buffer w_1 ≥ b̲ is a LOWER bound, which capping cannot reach. A document with b̲ > 0 is therefore refused until you declare what Γ_C does under it — do bookmaker weights scale down pro rata to make room, or does the buffer bind at settlement only, as the utilization caps do? (§7, §10.)
14. (CLOSED — the economist, 2026-10-12: "Count return as zero."; the own-series exclusion stays CONFIG, futarchy-system.md §9 C42, register row 45) To the economist — what a missing row contributes to the tail. A bookmaker absent from a run, or with zero capital there, has no return. v1 puts 0 in that run's joint loss vector and drops the row from the bookmaker's own series. Zero is not neutral: it moves the CVaR tail and therefore ŵ*. Zero, the row dropped from the vector, or μ₀ in its place? (§9.)
15. To both — a correction to our own decision-tree note. Its D1 engine line calls the objective "a linear program in exact rationals". With the ridge −ε‖w‖² it is a quadratic program, strictly concave in w; the ridge is what makes the maximizer unique, so the classification matters and the line is ours to fix, not yours.

Owner values and their CONFIG defaults — written into the first epoch document. The owner column of §3's field table is the record; this list is read off it, so a field appears here under exactly the owner it has there. Every field below EXCEPT the accounts and the chain carries a CONFIG default with a value (futarchy-system.md §9's C-table and the Defaults Register) — the owner replaces it from the next epoch, and the engine no longer waits for a value to be written before the first document can exist.

• The economist: caps and caps_rule, growth_multiplier n, bootstrap_cap ε₀, liquidity_buffer_min b̲, lambda λ, alpha α, ridge_epsilon ε, cash_return μ₁, winsor_q95, shrink_prior_mu0 μ₀, shrink_stiffness, missing_row_rule, utilization_rho ρ, utilization_rule, payout_cap_rule and its v_max under v2, pool_tax τ_pool, window_rule, previous_allocation_rule, fallback_rule, rounding_rule — each with a default (futarchy-system.md §9 C2–C3, C15–C22).
• The CEO: chain_feed_rule, money_unit, pools, participants, min_stake_units, seed_units, seeder, tax_recipient, stake_mobility, open_height, close_height — the accounts, the chain and the heights OPEN (no default can supply them); the rest defaulted (C9–C12, C24).
• Jointly: vault_capacity_mills V (OPEN), window_blocks (C4), min_distinct_matches (C6), delta_rule.
• The engine's, confirmed by the economist: step_budget, rational_bits_max, verification_grace_blocks, and the rule identities the engine implements — arithmetic_rule, pivot_rule, capacity_rounding_rule, tie_break_rule, objective_rule, estimator_rule, returns_rule, gamma_c_rule, optimizer_rule — and the chain that names them (C23, C25).
• Derived, so nobody writes it: previous_epoch_id — the predecessor's hash, which the engine fills from the epoch it follows (the genesis anchor for the first); system_hash, which the loader re-derives.

The 19 October note's values and the v2 defaults (futarchy-system.md §9 R24–R37, C52–C69): the note states λ, α, ρ, g, e, c_c, c_1, c_2, c_3, c_5, L, τ and Δ, each now a ruling record replacing or confirming its row above (D2's "Δ = one run" is the per-run observation, R34's Δ the snapshot interval; D7's "group rows refused" and D10's ε₀ floor at settlement are superseded by R31 and R28; questions 11 and 13 are closed by them). The engine's v2 defaults, each CONFIG with its source: allocation_precision = V (C63), participation_reward_units = 0 (C64), the per-interval peak (C52), the nearest-rank percentile (C53), newest-first moves (C54), u^prev in mills (C55), the zero and wiped-out balances (C56), the scored return (C57), η clamped (C58), the last interval (C59), the group rows in the solver (C60), the id region (C61), own capital pinned at open and locked (C62 — the one funds-risk question), observed zeros (C65), the evidence floor (C66), realized at the verdict (C67), no intra-window flow while no risk block exists (C68), credit drawn first (C69).

A field with a DEFAULT above still needs its value written into the document; the default says what the first document carries, not that the field may be omitted — the decoder is total (§3). Code of this layer waits on the user's word, not on a value: under law 7(c) as amended the defaults are the first document's values until a ruling record replaces them (futarchy-system.md §10 names the gates the first code must pass).