The ledger that makes multi-listing composable and safe

Every existing venue for human-capital claims is either single-instrument (ISAs, athlete revenue advances) or single-listing(music-catalog auctions on Royalty Exchange). None supports the natural human lifecycle: a founder raises a covenant at age 26, builds a company, IPO’s, eventually takes a direct listing to monetize the trajectory separately, and ten years later a second direct listing because new evidence justifies a different price.

Every one of those events is a new claim on the same underlying — the issuer’s future Total Economic Benefit. Without a ledger the system has three failure modes:

• 1.Over-commitment.The issuer sells 30% of a 100% TEB across listings and can’t live on the remainder. Existing instruments fail silently here — the overhang isn’t visible to the underwriter.
• 2.Impaired prior holders.A new listing with overlapping windows dilutes earlier holders’ claims, but because the claims share an underlying rather than an issuer balance-sheet, dilution doesn’t show up until cash distributes.
• 3.Arithmetic divergence.Without a single source of truth, the underwriter’s model, the issuer’s understanding, and the auditor’s reconstruction can all differ on what the total committed share actually is.

The Obligation Ledger closes all three. Every listing application updates a single per-issuer data structure. Every pricing request reads from that structure. Every cap-check runs against it. If the ledger math is clean, every downstream product composes.

Every token class on Preflop — Covenant Phase 1 dividend stream, Covenant Phase 2 perpetual claim, Direct Listing, a second Direct Listing on the same person, and any future class — is the same three-element tuple on an issuer’s future TEB:

The token claim is a slice of TEB parameterized by those three:

$\alpha_i$is the fraction of the issuer’s TEB the class claims (e.g. 2% for a Direct Listing perpetuity). $s_{\text{rate},\,i}$ is the per-window payout rate. $N_i = 10{,}000$ is the fixed token supply per class. Windows are half-openso back-to-back listings can’t double-count the boundary instant.

Why it matters —The asymmetry of human-capital claims is that they stack on a single denominator. A share of Google and a share of Amazon don’t interact. Two share-of-TEB claims on the same person absolutely do. The tuple abstraction + cap invariant is what makes the stack coherent.

At every moment $t$, the sum of all active claim rates on a single issuer is bounded by a platform-wide constant $C_{\max}$:

The choice of $C_{\max} = 25\%$isn’t arbitrary. It’s calibrated against three ceilings:

• —Living cost. The issuer must retain ≥75% of their TEB to live, pay taxes (federal + state ~35% combined at the relevant income band), save, and invest.
• —Behavioral incentive. Well-studied labor economics shows the effort-elasticity of work declines sharply above ~30% of marginal income taxed or claimed. Below 25%, the incentive to grow TEB (and therefore holder payouts) is preserved.
• —Creditor precedent.US wage-garnishment caps for unsecured debt sit at 25% of disposable income. Preflop’s claim sits inside the same envelope.

$C_{\max}$ is a platform parameter, not a per-issuer parameter — uniformity is a feature, not a limitation. Every issuer operates under the same ceiling, so every listing price is comparable across issuers without a per-issuer leverage correction.

The 25% invariant restricts flow. The natural question is whether it also bounds the aggregate stock of fractional ownership a market can hold. Theorem: it does, with the same constant.

Proof (Fubini). Sum the claim-PV definitions across classes and swap $\sum$ with $\int$ (justified — the integrand is nonnegative):

Bound the inner sum by $C$ pointwise (the hypothesis), pull the constant out, divide by $V_{\text{HC}}(t) > 0$:

Why it matters —Plain English: the 25% pointwise flow-cap automatically bounds the 25% aggregate stock-ownership. The founder always retains $\geq 75\%$ of themselves — mathematically guaranteed, not just policy-constrained. There is no obligation stack that violates this. Full derivation in the human-capital spec.

Numerical cross-check (Maya year 8 with covenant + DL)

Maya carries a covenant $(s_1=3\%, s_2=1\%, T=10)$ and adds a Direct Listing at $e_{\text{dir}} = 3\%$ at year 4. At year 8 the active flow is $3\% + 3\% = 6\% \leq 25\%$ ✓. Aggregate $e_{\text{eff}}$ at year 0 (engine evaluation): covenant ≈ 1.66%, DL = 3.00% (exact for DL window matching V_HC). Total ≈ 4.66% — well under 25%. Both flow and stock invariants hold with significant headroom.

Every new listing application runs through both algorithms below; the application is accepted only if both return $\text{OK}$. Using two algorithms with different implementations provides a mechanical safeguard against a single bug cascading into a silent over-commitment.

Algorithm 1 · Analytic transition-point scan

The sum-of-active-rates function is a step function: its value only changes at transition points (the $t_{\text{start}}$ and $t_{\text{end}}$ boundaries of every listing). Between transitions the sum is constant. The algorithm:

function capCheck_analytic(existing, proposed):
  boundaries = sort(union(
    { t_start for class in existing ∪ { proposed } },
    { t_end   for class in existing ∪ { proposed } }
  ))
  for τ in boundaries:
    active = { c ∈ existing ∪ { proposed } : c.t_start ≤ τ < c.t_end }
    if sum(c.s_rate for c in active) > C_max:
      return REJECT with violation point τ
  return OK

Correct by construction: every transition point is evaluated. Complexity: $O(n \log n)$ from the sort, linear per transition.

Algorithm 2 · Monthly-bucket scan

Discretize time into monthly buckets over the shared horizon. At every bucket, compute the sum of active rates directly. Accept only if every bucket is under $C_{\max}$. The algorithm:

function capCheck_buckets(existing, proposed, horizon_months = 900):
  for m in 0..horizon_months:
    t = now() + months(m)
    total = sum(c.s_rate for c in existing ∪ { proposed }
                if c.t_start ≤ t < c.t_end)
    if total > C_max:
      return REJECT with violation month m
  return OK

Obviously correct (you evaluate every month). Finite but large (75 years × 12 months ≈ 900 buckets per issuer). Complexity: $O(n \cdot H)$ where $H$ is the horizon bucket count.

Why it matters —Why both: the analytic scan is fast but depends on correct sorting and strict half-open-interval handling; the bucket scan is slow but mechanically transparent. A discrepancy between them at any transition point is a signal that something in the implementation has drifted, and the listing is held until the discrepancy is resolved.

The price of any class is the present value of its slice of future TEB. General form:

In the pure-perpetuity case (Direct Listing, or a post-T Covenant Phase 2), $t_{\text{end}} = \infty$ and $\mathbb{E}[\text{TEB}(\tau)] = \text{TEB}_0 \cdot e^{g(\tau-t)}$. The integral collapses:

That’s the Gordon anchor from Stage 2 of the pricing spec. Every class uses the same machinery. No per-class pricing exception; no special cases.

Each issuer has a single ledger document. Example shape (abbreviated for clarity):

{
  "issuer_id": "priya-chandra",
  "cap_ceiling": 0.25,
  "content_hash": "sha256:8a3c4f21…",
  "obligations": [
    {
      "class_id": "cov_prycA",
      "kind": "covenant",
      "phase_1": { "s_rate": 0.05, "t_start": "2025-06-01", "t_end": "2032-06-01" },
      "phase_2": { "e_rate": 0.02, "t_start": "2032-06-01", "t_end": null },
      "tokens_outstanding": 10000,
      "status": "active"
    },
    {
      "class_id": "dir_prycA",
      "kind": "direct-listing",
      "e_rate": 0.03,
      "t_start": "2028-04-15",
      "t_end": null,
      "tokens_outstanding": 9800,
      "status": "active"
    }
  ],
  "history": [ /* append-only audit log */ ]
}

Three properties the ledger guarantees:

• —Append-only history. Every mutation (new listing accepted, deficiency triggered, delisting recorded) appends a record. Past entries are never rewritten.
• —Content-hash chaining. Every record includes a SHA-256 hash of the prior state. A tamper at any point breaks the chain from that point forward — auditors can detect retroactive edits mechanically.
• —Single source of truth. Pricing, governance, and delisting reviews all read from the ledger. Nothing maintains a parallel obligation list.

The ledger library ships with 75 passing tests covering the full state-space of cap-check behavior. High-level categories:

The full suite lives at lib/obligation-ledger/__tests__/ and runs on every build via Vitest. The same library prices every real listing on the site.

Why it matters —Rigour-per-dollar-of-market-infrastructure is the fair yardstick for a new pricing rail. The ledger is a small piece of code — under 1,000 LOC. 75 tests against 1,000 lines is a ratio you’d expect from an exchange engine, not an early-stage product. It’s there because the invariant is load-bearing: if the ledger is wrong, every price above it is wrong.