Technical documentation
Everything on this site is a rendering of a small number of primary sources: one manifest format, one canonical signing string, one resolution algorithm, one signed registry. This page is the index for people who want the sources themselves — plus a reference implementation you can run against your own books.
Reference settlement implementation — omla-settle
A single-file, dependency-free Python implementation of quarterly settlement: point it at a folder of manifests and a usage file, and it produces the exact per-wallet payment sheet — the same largest-remainder, integer-cents arithmetic as the browser resolver, cross-checked against it. Built to be copied into your stack and adapted (it is deliberately boring Python; an LLM can rewire its inputs to your billing system in one sitting — the math functions are marked normative, everything around them is yours to change).
├── omla_settle.py — the whole implementation: load, resolve, render
├── test_omla_settle.py — stdlib unit tests incl. the site's worked example, to the cent
├── samples/ — four demo manifests + a filled-in usage.json to copy from
├── tools/parity_check.mjs — replays the same inputs through the browser resolver.js in node
└── README.md — quickstart, input format, and LLM-adaptation notes
# one quarter, start to finish
python3 omla_settle.py --manifests samples/manifests --usage samples/usage.json --out out/
# → out/settlement-sheet.json (machine-readable, resolver-identical)
# → out/SETTLEMENT.md (the sheet a human signs off on)
# → out/payments.csv (wallet, cents, pointers — feed it to accounting)The folder ships with the OMLA platform repository (publication to the OMLA GitHub is pending alongside the license going operative — ask us for a copy meanwhile). Signature verification of input manifests is optional at run time (pure-Python core; enable it with PyNaCl installed) — verify before you pay, with the browser verifier if nothing else.
Parity contract & canonical JSON
Every implementation of the resolver — the browser/node JavaScript, the Python package, and omla_settle.py above — must produce byte-identical canonical output for identical input. The rules that make that possible:
- No floats, ever. Shares are exact rationals (BigInt /
fractions.Fraction); money is integer cents; declared shares are integer basis points. - Canonical JSON: sorted ASCII keys at every level, compact separators, integers only — byte-identical between JS and Python's
json.dumps(sort_keys=True, separators=(",", ":")). - Largest-remainder rounding with pinned tie-breaks: wallet address ascending for payment lines, model id ascending for attribution.
- Pinned constants: attribution units 10⁸, dust floor 0.1%, payout floor $0.10, lineage depth cap 32, royalty 3000 bp.
Anyone can therefore reproduce — and dispute — any settlement figure from public inputs. Disagreement between two conforming implementations is a bug by definition, not a negotiation.
Integration quickstart
Using the browser/node resolver directly in your own tooling:
// node — resolver.js is a plain UMD module, no dependencies
const R = require('./resolver.js'); // window.OMLAResolver in a browser
const vectors = R.flatten(manifests); // per-model payment vectors
const sheet = R.resolve({
usage: [{ model_id: '…', weight: '60000' }], // generations × declared stack weight
vectors,
total_cents: 300000, // 30% of the greater of revenue/run cost
period: '2026-Q3'
});
// sheet.lines → [{wallet, percent, amount_cents, pointers, via_models}]The full input semantics (stacks, weights, the two-question owe test) are on the commercial guide; the algorithm itself on the resolver page.