OMLA Documentation

Overview

OMLA keeps models freely usable for personal and research work and attaches one obligation to commercial use: once per calendar quarter (YYYY-Q1 through YYYY-Q4), self-assess a 30% royalty on the greater of attributable revenue or run cost and pay the creators directly within 60 days after quarter end. Distribution is recursive through each model's published split. Nothing is reported or submitted to OMLA. The commercial workflow is four steps: local ledger, calculate, resolve, pay.

Getting started — creators

1. Read the License — OMLA Model License & Royalty Terms v2.0 (Direct Settlement).
2. Open the registration wizard. It generates an Ed25519 key in the browser and downloads an AES-256-GCM encrypted omla-creator-key-v1 bundle. Keep two offline backups; the full secret is never displayed, copied, or sent.
3. Declare lineage: each OMLA-registered parent and how you derived from it (fine-tune, merge, distill, quantize).
4. Add payee wallets and public payment pointers — a Lightning address, an on-chain address, a Stripe Payment Link, a PayPal.Me link, or your own invoice URL. Pointers are public.
5. Set the split: what you retain (capped by how you derived — a fine-tune keeps at most 5%) and the share of each upstream parent. Everything sums to 100% and the wizard shows a live "$100 through this model" preview.
6. Sign and submit. The wizard signs the v5 registration message — which pins your manifest hash — and the server verifies every signature before writing anything.

Creator hub for the plain-language version; Technical §9 for the byte-level flow.

Getting started — commercial users

You never need an OMLA account. Once per calendar quarter: keep a local ledger, calculate the 30% greater-of obligation, resolve, and pay each published payee directly within 60 days after quarter end. Nothing is submitted to OMLA.

# 1. Download and verify a signed snapshot against an independently pinned key
curl -O https://omla-ai.org/registry/v2/snapshot.jsonl.gz
curl -O https://omla-ai.org/registry/v2/index.json
# index.json's self-declared pubkey_b64 is informational, not a trust root

# 2. Resolve your usage ledger into a settlement sheet
omla-resolve --ledger usage.csv --snapshot registry/v2/ --total 4200.00 --period 2026-Q3

# 3. Pay each wallet line within 60 days after quarter end.
#    Memo (optional): OMLA:<model-id-prefix>:<quarter>

• Self-assessment. The royalty is 30% of the greater of attributable revenue or run cost for the calendar quarter, computed by you from your own records. Nothing is reported or submitted to OMLA, and OMLA does not want it.
• Safe harbor. Resolving against a signed snapshot ≤ 90 days old at calendar-quarter end discharges the obligation for that quarter, even if a manifest changed after the snapshot.
• Reproducibility. The sheet records the snapshot seq and root hash. Your auditors can rerun the same deterministic algorithm on the same inputs and get the same output, byte for byte.
• Dust floor. Wallet lines under $0.10 per calendar quarter are dropped by the resolver and renormalized — no carry-forward ledger.

Users hub for lanes and worked examples; Technical §12 for the algorithm; resolver integration guide for platform patterns.

Registry data

The registry has two equivalent read surfaces. Prefer the static snapshot files: they are signed, cacheable, and mirror-friendly. The live PostgREST API serves the same tables for interactive queries (anon key in assets/js/config.js).

Signed snapshot files

Live API (public read, no auth beyond the anon key)

Writes (creators — signature-gated Edge Functions)

Database schema

Supabase PostgreSQL (Postgres 17). Every manifest table is world-readable; there are no write policies at all — writes happen only through signature-verifying SECURITY DEFINER functions. All share arithmetic is integer basis points.

Relationship types (lineage_edges.relationship)

Allowed values: fine-tune, merge, distill, quantize. The relationship determines the retention cap (below).

Splits & retention caps

Every model publishes a split in basis points (1 bp = 0.01%): what it retains, and what flows to each lineage parent. Retention is capped by how the model was derived, and the caps are enforced in the wizard, the Edge Function, and the database:

An original model (no lineage) retains exactly 100%. Within the retained share, teams divide among their own wallets with payee_shares (basis points, summing to 10000). Details and invariants: Technical §8.

Payment pointers

Each wallet publishes 1–8 public payment pointers — how payers actually settle. Supported rails: lightning (address or BOLT12 offer — recommended), btc, eth (incl. USDC), sol, stripe-link (Stripe Payment Link), paypal-me, and invoice-url (your own invoicing page or billing email — private fiat rails go here). Every pointer is validated against an anchored regex in the browser, the Edge Function, and the database. The full regex table: Technical §7.

The resolver

omla-resolve/2.0 is the pinned, deterministic algorithm that flattens the lineage graph and turns a usage ledger into a percentage — and optionally integer cents — per wallet. Fixed-point integer math (UNITS = 1e8), largest-remainder rounding, a 0.1% dust floor, a depth cap of 32, and cycle defense. Python and JS implementations ship with shared test vectors and produce byte-identical output.

// In the browser (vendored, no CDN):
const vectors = OMLAResolver.flatten(manifests);
const sheet   = OMLAResolver.resolve({
  usage: [{ model_id, weight }], total_cents, period: '2026-Q3', vectors
});

# Or from the command line:
omla-resolve --ledger usage.csv --snapshot registry/v2/ --total 4200.00 --period 2026-Q3

Full algorithm, constants, and the settlement-sheet format: Technical §12.

Direct settlement

• Rate: once per calendar quarter, 30% of the greater of attributable revenue or attributable run cost, self-assessed by the commercial user (License v2.0 §4).
• Distribution: recursive through each model's published split — the resolver computes it; you pay it.
• Safe harbor: a signed snapshot ≤ 90 days old at calendar-quarter end discharges the obligation for that quarter.
• Floor: wallet lines under $0.10 per calendar quarter are dropped and renormalized.
• Due/memo: pay within 60 days after quarter end; where supported, tag OMLA:<model-id-prefix>:<quarter>.
• Records: keep your usage ledger, resolution sheets, and payment evidence for 7 years (License v2.0 §7). OMLA keeps none of it — it never receives any.

Registry integrity

Every model carries a registry status: ACTIVE (normal), REVOKED (flagged — still resolvable, reason shown), or DELISTED (removed from listings after review — reserved for fraud, impersonation, legal orders, or DMCA outcomes; the manifest remains resolvable for upstream shares). Transitions are reviewer actions with recorded reasons, all audit-logged. OMLA does not track payment compliance — enforcement of payment is the creators' license right. Details: Registry integrity and Technical §14.

Security & verification

• Identity: the normal browser flow is Ed25519 with an encrypted local bundle. The server also accepts hybrid Ed25519 + ML-DSA-65 from advanced API/CLI clients; the browser does not claim hybrid protection. The registry identity is the SHA-256 key fingerprint.
• Manifest integrity: the creator's key signs the manifest hash (registration message v5); the server re-derives and checks it; the signed snapshot chain commits every manifest to a signed root.
• Weight integrity: the SHA-256 hash of the weight files is signed at registration and stored as protected metadata.
• Public read, signed write: anyone can read everything; nothing can be written or changed without a creator-key signature verified server-side.
• Audit log: append-only, SHA-256 hash-chained record of every registry mutation; verify_audit_chain() proves integrity.
• Minimal data: OMLA stores creator emails, public keys, and published manifests — and nothing about payers or payments, because it never receives them.

Glossary