{
 "description": "Verified Soma programs. Every entry passed `soma check` (and `soma test` / `soma verify` where applicable) on the soma version below, re-run when this index was generated. Fetch `url` for the source. Filter by `domain` or `features` to find a working example of what you are about to write.",
 "soma_version": "3.2.4",
 "count": 15,
 "domains": {
  "escrow_finance": 15
 },
 "features": [
  "agent",
  "cost",
  "fail",
  "guard",
  "http",
  "invariant",
  "lambda",
  "match",
  "multi_cell",
  "native",
  "pipeline",
  "service",
  "skeleton",
  "state_machine",
  "sum_type",
  "think",
  "tools",
  "try"
 ],
 "programs": [
  {
   "id": "escrow_finance/chargeback_window",
   "domain": "escrow_finance",
   "title": "CHARGEBACK WINDOW — disputes die at day 120, reversals happen exactly once",
   "summary": "CHARGEBACK WINDOW — disputes die at day 120, reversals happen exactly once Card networks give cardholders ~120 days to dispute a charge. Two ways processors lose money here: accepting a dispute after the window (the merchant's funds were already swept as final), and reversing the same charge twice when a manual agent and an automated rule both fire. Both are structural below: `finalized` is terminal so a late dispute has no edge to take, and `reversed`/`upheld` are terminal so a second reversal raises. The merchant ledger refuses negative balances.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/chargeback_window.cell",
   "repo_path": "examples/corpus/escrow_finance/chargeback_window.cell",
   "lines": 109,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "Chargeback",
    "ChargebackTests"
   ]
  },
  {
   "id": "escrow_finance/client_money_segregation",
   "domain": "escrow_finance",
   "title": "CLIENT MONEY SEGREGATION — the firm can only ever touch its own excess",
   "summary": "CLIENT MONEY SEGREGATION — the firm can only ever touch its own excess MF Global, October 2011: as the firm's own liquidity died, roughly $1.6B of SEGREGATED customer funds were wired out to cover house obligations. The rule (CFTC 1.20) was clear; the enforcement was a spreadsheet. The structural version: the seg account tracks an `excess` slot — firm money deposited as a buffer — and EVERY house withdrawal draws ONLY on excess, with `excess >= 0` as the invariant. The wire that dips into customer money is a rejected write, even at 2am on the last day. Client claims are themselves a slot that cannot go negative (no over-withdrawal).",
   "url": "https://soma-lang.dev/corpus/escrow_finance/client_money_segregation.cell",
   "repo_path": "examples/corpus/escrow_finance/client_money_segregation.cell",
   "lines": 100,
   "features": [
    "invariant"
   ],
   "cells": [
    "SegAccount",
    "SegTests"
   ]
  },
  {
   "id": "escrow_finance/crowdfund_all_or_nothing",
   "domain": "escrow_finance",
   "title": "ALL-OR-NOTHING CROWDFUNDING — miss the goal, every backer gets refunded",
   "summary": "ALL-OR-NOTHING CROWDFUNDING — miss the goal, every backer gets refunded The all-or-nothing pledge model only works if \"nothing\" is enforced. Platforms have been burned both ways: creators paid out on campaigns that quietly missed their goal, and failed campaigns where refunds ran twice (or never). Here the payout edge exists ONLY from `succeeded`, a campaign can reach `succeeded` only via close_campaign checking pledged >= goal, and the failed branch must drain the pledge pool to zero through refunds — the pool slot refuses negative writes, so a double refund of the same backer raises in memory.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/crowdfund_all_or_nothing.cell",
   "repo_path": "examples/corpus/escrow_finance/crowdfund_all_or_nothing.cell",
   "lines": 120,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "Crowdfund",
    "CrowdfundTests"
   ]
  },
  {
   "id": "escrow_finance/dividend_pool",
   "domain": "escrow_finance",
   "title": "DIVIDEND DISTRIBUTION — payments can never exceed the declared pool",
   "summary": "DIVIDEND DISTRIBUTION — payments can never exceed the declared pool When a board declares a dividend, that number is legally binding — and transfer agents have paid out MORE than the declaration through duplicate shareholder records or a re-run batch job (the same disease as the 2021 \"accidental\" duplicate ACH dividend runs brokers had to claw back). Structure: the declared pool is a slot every payment decrements, with `pool >= 0` as the invariant — the payment that would overspend the declaration is a rejected write. A shareholder can be paid once per declaration, and a closed distribution is terminal.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/dividend_pool.cell",
   "repo_path": "examples/corpus/escrow_finance/dividend_pool.cell",
   "lines": 96,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "Dividend",
    "DividendTests"
   ]
  },
  {
   "id": "escrow_finance/dvp_settlement",
   "domain": "escrow_finance",
   "title": "DELIVERY-VERSUS-PAYMENT — no securities leave before the cash arrives",
   "summary": "DELIVERY-VERSUS-PAYMENT — no securities leave before the cash arrives On 26 June 1974, Bankhaus Herstatt was shut down by regulators AFTER its counterparties had irrevocably paid the Deutschmark leg of their FX trades but BEFORE Herstatt paid out the dollar leg. The money was simply gone — \"Herstatt risk\" got its name and CLS Bank got founded. The cure is delivery-versus-payment: the two legs are ONE state machine, and the deliver edge exists only after cash is confirmed. A trade abandoned after cash arrives must pass through `refunded` — cash can never be stranded — and `soma verify` proves every path ends settled or made-whole.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/dvp_settlement.cell",
   "repo_path": "examples/corpus/escrow_finance/dvp_settlement.cell",
   "lines": 111,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "DvP",
    "DvPTests"
   ]
  },
  {
   "id": "escrow_finance/invoice_factoring",
   "domain": "escrow_finance",
   "title": "INVOICE FACTORING — no advance on unverified paper, no double-selling",
   "summary": "INVOICE FACTORING — no advance on unverified paper, no double-selling Greensill Capital collapsed in 2021 holding billions in \"invoices\" that were never verified — some for trade that hadn't happened, some financed twice through different vehicles. The two frauds are structural here: an invoice can only be SOLD from the verified state (the issued -> sold edge does not exist), and sold has no edge back to itself or to verified, so the same invoice cannot be advanced twice. The advance ledger caps the cash at 90% of face value and refuses negative writes.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/invoice_factoring.cell",
   "repo_path": "examples/corpus/escrow_finance/invoice_factoring.cell",
   "lines": 108,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "Factoring",
    "FactoringTests"
   ]
  },
  {
   "id": "escrow_finance/letter_of_credit",
   "domain": "escrow_finance",
   "title": "LETTER OF CREDIT — the bank pays against verified documents, never trust",
   "summary": "LETTER OF CREDIT — the bank pays against verified documents, never trust A documentary letter of credit (UCP 600) exists because exporter and importer don't trust each other across an ocean: the bank promises to pay the seller, but ONLY against documents proving shipment. The classic loss is paying on presented-but-unexamined documents — the Salomon-era trade-finance frauds ran exactly this gap, with bills of lading for cargo that never sailed. Here `honored` is reachable only through `docs_verified`; presenting is not verifying; partial drawings draw down a credit slot that refuses to go below zero, so the beneficiary can never draw more than the credit line. Expired credits are terminal.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/letter_of_credit.cell",
   "repo_path": "examples/corpus/escrow_finance/letter_of_credit.cell",
   "lines": 116,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "LetterOfCredit",
    "LocTests"
   ]
  },
  {
   "id": "escrow_finance/loan_amortization",
   "domain": "escrow_finance",
   "title": "LOAN AMORTIZATION — principal never goes negative, never grows back",
   "summary": "LOAN AMORTIZATION — principal never goes negative, never grows back Two amortization bugs with real victims: servicers who kept drafting payments after payoff (principal goes negative = the borrower is owed money and usually never told), and the pre-2008 \"option ARM\" negative amortization, where a payment smaller than the accrued interest silently GREW the principal until the loan ballooned past the house's value. Here `principal >= 0` is a memory invariant — the overdraft write raises — and a payment must at least cover the month's interest, so the balance is monotonically non-increasing. paid_off is terminal and proven.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/loan_amortization.cell",
   "repo_path": "examples/corpus/escrow_finance/loan_amortization.cell",
   "lines": 100,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "Loan",
    "LoanTests"
   ]
  },
  {
   "id": "escrow_finance/milestone_escrow",
   "domain": "escrow_finance",
   "title": "MILESTONE ESCROW — a contractor is paid per accepted milestone, never ahead",
   "summary": "MILESTONE ESCROW — a contractor is paid per accepted milestone, never ahead Freelance platforms learned this the expensive way: pay a contractor the full project fee up front and disputes become hostage negotiations. The escrow answer is milestones — but then the bug moves: releasing milestone money TWICE, or releasing more than the client funded. Here the funded balance is a slot that releases draw down (`escrowed >= 0`: the over-release is a rejected write), each milestone is released at most once, and a cancelled or completed project is terminal — the leftover balance goes back to the client exactly once.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/milestone_escrow.cell",
   "repo_path": "examples/corpus/escrow_finance/milestone_escrow.cell",
   "lines": 106,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "MilestoneEscrow",
    "MilestoneTests"
   ]
  },
  {
   "id": "escrow_finance/multisig_disburse",
   "domain": "escrow_finance",
   "title": "MULTISIG TREASURY — 2-of-3 distinct approvals, proven before a cent moves",
   "summary": "MULTISIG TREASURY — 2-of-3 distinct approvals, proven before a cent moves In July 2017 the Parity multisig wallet lost $30M because a code path let a single caller re-initialize ownership and drain funds alone — the \"multi\" in multisig was a convention, not a structure. Here the quorum IS the structure: disbursed is reachable ONLY through the quorum state, which requires two approvals from DISTINCT owners (a repeat approval does not advance the machine). `soma verify` proves the only path to disbursed passes through quorum; the vault refuses negative balances.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/multisig_disburse.cell",
   "repo_path": "examples/corpus/escrow_finance/multisig_disburse.cell",
   "lines": 109,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "Multisig",
    "MultisigTests"
   ]
  },
  {
   "id": "escrow_finance/payroll_run",
   "domain": "escrow_finance",
   "title": "PAYROLL RUN — the payslips must sum EXACTLY to the approved total",
   "summary": "PAYROLL RUN — the payslips must sum EXACTLY to the approved total Payroll overpayments are a quiet epidemic: a duplicated payslip or a fat-fingered salary slips into a run, the bank file goes out, and the company spends months clawing money back from employees (legally messy, morale-destroying). The wall here: the approved budget is a slot that each payslip DECREMENTS, with `budget >= 0` as an invariant — a payslip that would overspend the approval RAISES at the write. And the run can only commit when the budget hits exactly zero: paid == approved, proven by arithmetic, not by hope. Committed runs are terminal.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/payroll_run.cell",
   "repo_path": "examples/corpus/escrow_finance/payroll_run.cell",
   "lines": 100,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "Payroll",
    "PayrollTests"
   ]
  },
  {
   "id": "escrow_finance/security_deposit",
   "domain": "escrow_finance",
   "title": "SECURITY DEPOSIT — deductions can never exceed what the tenant paid",
   "summary": "SECURITY DEPOSIT — deductions can never exceed what the tenant paid Every US state's tenancy law has the same clause because the same abuse keeps happening: a landlord itemizes $2,400 of \"damages\" against a $1,500 deposit and bills the tenant for the fantasy difference — or keeps deducting after the deposit was already returned. Here the deposit is a slot that deductions draw down with `deposit >= 0` as the wall: the over-deduction is a REJECTED WRITE. Returning the balance moves the tenancy to a terminal state, so post-return deductions have no edge.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/security_deposit.cell",
   "repo_path": "examples/corpus/escrow_finance/security_deposit.cell",
   "lines": 99,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "DepositAccount",
    "DepositTests"
   ]
  },
  {
   "id": "escrow_finance/two_party_escrow",
   "domain": "escrow_finance",
   "title": "TWO-PARTY ESCROW — funds move only when BOTH sides say so, and never leak",
   "summary": "TWO-PARTY ESCROW — funds move only when BOTH sides say so, and never leak Classified-ad escrow fraud works one way: the \"escrow agent\" releases the buyer's money before the seller delivers, or refunds after releasing — paying the same dollars out twice. The FBI's IC3 logs thousands of these a year. The fix is structural: release/refund are TERMINAL states of one machine (no path back, proven by `soma verify`), release requires both confirmations, and the held ledger refuses negative balances so the same cent cannot leave twice. Conservation (held + paid == funded) is checked on every read.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/two_party_escrow.cell",
   "repo_path": "examples/corpus/escrow_finance/two_party_escrow.cell",
   "lines": 117,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "Escrow",
    "EscrowTests"
   ]
  },
  {
   "id": "escrow_finance/vesting_schedule",
   "domain": "escrow_finance",
   "title": "VESTING SCHEDULE — cliff then linear, and over-vesting is unwritable",
   "summary": "VESTING SCHEDULE — cliff then linear, and over-vesting is unwritable Equity vesting disputes are a startup classic: a payroll script with an off-by-one releases shares before the 12-month cliff, or rounds the linear schedule up until the employee has claimed MORE than the grant. Clawing shares back after the fact means lawyers. Here the award pool is a memory slot that only decrements: `remaining >= 0` makes claiming past the total grant a rejected write, the cliff is enforced in the vested math, and a forfeited grant is a TERMINAL state — verified, no path back.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/vesting_schedule.cell",
   "repo_path": "examples/corpus/escrow_finance/vesting_schedule.cell",
   "lines": 118,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "Vesting",
    "VestingTests"
   ]
  },
  {
   "id": "escrow_finance/wire_dual_control",
   "domain": "escrow_finance",
   "title": "WIRE DUAL CONTROL — the maker can never be the checker",
   "summary": "WIRE DUAL CONTROL — the maker can never be the checker In August 2020 Citibank meant to send $7.8M of interest on a Revlon loan and instead wired the full $893M principal. Three humans approved it — but all three were looking at the same misleading screen, and a court initially let the creditors KEEP it. Dual control only works when the checker is structurally distinct and the amount has a hard ceiling. Here a wire cannot reach `sent` except through `checked` (the drafted -> sent edge does not exist), the maker's own approval is refused, and the per-wire amount slot rejects anything over the desk's $10M limit at the write — the $893M fat-finger dies in memory, not in a code review.",
   "url": "https://soma-lang.dev/corpus/escrow_finance/wire_dual_control.cell",
   "repo_path": "examples/corpus/escrow_finance/wire_dual_control.cell",
   "lines": 98,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "WireDesk",
    "WireTests"
   ]
  }
 ]
}