Frequently Asked Questions

Non-commercial use: Free and unrestricted — research, personal projects, internal R&D, academic work.

Commercial use: Once per exact calendar quarter (YYYY-Q1 through YYYY-Q4), self-assess 30% of the greater of attributable revenue or total model run cost, resolve it, and pay each wallet directly within 60 days after quarter end. Nothing is submitted to OMLA.

Who pays: The party operating or selling access to the OMLA-licensed model. End users do not pay separately if the service already pays the royalty.

Where it goes: Distribution is recursive through each model's published split. Most of the money flows to the original creators. A fine-tune retains at most 5% — the rest flows upstream through the lineage.

What OMLA does: Serves the signed registry — nothing else. No reporting, no statements, no payer accounts, no records of usage, payers, or payments.

Short version: open-model creators kept finding their work inside somebody else's product and getting exactly zero dollars for it. We watched it happen to friends. So we built a registry that says exactly who should be paid and an open algorithm that computes how much — so commercial users can pay creators directly, all the way up the chain.

Longer version: OMLA offers free non-commercial access and one 30% greater-of rule for commercial use. Under License v2.0, every model publishes a signed manifest — lineage, split, and public payment pointers — and royalties resolve recursively through it, so the original creators receive most of the money no matter how many derivatives sit in between.

The Open Model Licensing Association is an open initiative organizing as a Washington nonprofit (501(c)(3) status not yet filed). It provides a royalty-based license for AI models — free for personal and research use, 30% royalty for commercial use — and maintains the public registry that direct settlement runs on: signed manifests, signed snapshots, and the published resolver algorithm. OMLA never holds or moves funds, and it keeps no records of usage, payers, or payments — because it never receives them.

Open access, not OSI open-source, because royalties are required for commercial use. The model weights can be freely used, modified, and redistributed for non-commercial purposes. Commercial use requires the 30% royalty payment to creators.

An OMLA wallet address is a globally unique payee identifier encoded in Bech32m format (the same encoding used by Bitcoin SegWit v1). It starts with the prefix omla1 followed by 38–58 lowercase alphanumeric characters. It names who is owed; the payment pointers attached to it say where to send the money.

Example: omla1pvc9275lcn5suv6c0k3v0mq3xedcpfw25ng83r

The address encodes 20 random bytes with a Bech32m checksum; it is a stable routing identifier, not a model UUID or an account holding value. Resolver output is keyed by wallet address, so the same wallet appearing in many models' splits still gets one line on a payout sheet.

Each wallet carries one to eight public payment pointers. The supported rails are: Lightning (a Lightning address or BOLT12 offer — the recommended default), Bitcoin on-chain, Ethereum (ETH or ERC-20 tokens such as USDC), Solana, a Stripe Payment Link, a PayPal.Me link, or an invoice URL — your own invoicing page or a mailto: address, which covers every private fiat arrangement.

These are the payee's own destinations; OMLA operates none of them. The commercial user pays over whichever published pointer works for both parties — settlement is direct between payer and payee.

Yes — pointers are public registry data. Everything in a manifest, pointers included, is world-readable and ships in every snapshot. That is what lets any payer pay you without asking anyone's permission. Publish only destinations you are comfortable with the whole internet seeing: payment links, Lightning addresses, crypto addresses, or an invoicing URL — never raw bank account details.

Use an invoice-url pointer: a link to your own invoicing page (or a mailto: address) where payers can request an invoice and settle over whatever private rail you arrange with them — bank transfer included. The private details never enter the registry; only the URL does. Licensees must use one of your published pointers if they are able to transact with it; OMLA does not mediate, escrow, hold, route, or enforce any payment.

Commercial use is any use for monetary gain or advantage, including:

• Hosted APIs or products that charge for access
• Internal operations that yield material business benefit
• Selling or monetizing outputs generated by the model
• Advertising-supported services
• Fundraising or sponsorships
• Using the model to enhance the value of another product or service (e.g., a tour company using AI for narration)

Not commercial use: academic research, personal projects, internal R&D, development of future OMLA-licensed models.

The royalty is the greater of:

1. 30% of attributable revenue — revenue directly attributable to the model (sales, subscriptions, API calls, output sales)
2. 30% of total model run cost — the accounting cost to operate the model (pro-rated compute, storage, bandwidth, hardware depreciation, direct IT support)

Once per exact calendar quarter (YYYY-Q1 through YYYY-Q4), compute both figures and use the larger. Pay within 60 days after quarter end. Your ledger and sheets stay with you: nothing is reported or submitted to OMLA, and OMLA does not want it. An honest zero base can owe $0.

If you run several models, meter each one consistently (compute cost, tokens, or explicit revenue attribution) and the resolver spreads your obligation across them by those weights. Free and non-OMLA components reduce the royalty base proportionally.

Four steps once per calendar quarter: meter locally, calculate the greater-of obligation, resolve it with an exact YYYY-Q[1-4] quarter against a verified signed snapshot, and pay each wallet directly within 60 days after quarter end.

Where supported, use the optional memo OMLA:<model-id-prefix>:<quarter>. Keep the sheet locally. Nothing is reported or submitted to OMLA, and OMLA does not want it. A snapshot no more than 90 days old at calendar-quarter end provides the safe harbor; lines under $0.10 are non-payable dust.

If you monetize outputs substantially generated by the model (sell images, sell text, etc.), that constitutes Commercial Use of the model and triggers the 30% royalty. The license does not apply to or transfer to the outputs themselves — only to the use of the model to generate them.

Enforcement belongs to creators, not OMLA. The license runs between the model's creators — including upstream creators, who are express third-party beneficiaries of their resolved shares — and the commercial user. Creators can require a user's self-assessment records on reasonable notice and pursue ordinary contract remedies if the numbers don't hold up.

OMLA no longer tracks payment compliance and keeps no payment records to check against. What OMLA can do is registry integrity: a registration that turns out to be fraudulent, or subject to a legal or DMCA action, can be revoked or delisted after review. Anyone may still raise a registry-content complaint through the contact page.

Every model publishes a split in its manifest: the share it retains, and the share that flows to each lineage parent — integer basis points summing to exactly 100%. Distribution walks that graph. When you owe a royalty on a model, its retained share goes to its payees, and each upstream share flows to the parent, which splits it again by its own published manifest — and so on, until every fraction lands on a wallet.

Worked through a chain: C is a quantize of B (retains 2%), and B is a fine-tune of the original A (retains 5%). $100 of royalty on C resolves to $2.00 for C, $4.90 for B (5% of the $98.00 that flowed up), and $93.10 for A. The resolver does this flattening for you — deterministically, in integer math, with a depth cap of 32 and cycle defense — so a payout sheet is one function call, not a research project.

Because most of the value in a fine-tune is the base model. A fine-tune adjusts a sliver of what the original training run built, so the license caps what a derivative can retain: 5% for a fine-tune, 2% for a quantize, 10% for a distillation or merge. The rest of the royalty flows upstream to the people who did the bulk of the work.

The cap also closes a loophole: without it, a derivative could declare most of the split for itself and starve the chain above it. And it works in your favor the moment anyone builds on you — a commercial fine-tune of your model sends at least 95% of its royalties upstream to your model, where your own split applies. Small percentages of real usage across a whole ecosystem beat 100% of nothing.

A model with no lineage — an original — retains 100%. A derivative's retained share is capped by its relationship to its parents:

• Fine-tune — retains at most 5%
• Quantize — retains at most 2%
• Distill — retains at most 10%
• Merge — retains at most 10%

A model with several relationship types is capped by the largest applicable cap. Every declared lineage edge must carry an upstream share of at least 0.01%, and retained plus upstream shares must sum to exactly 100% — registration fails closed otherwise.

Check the OMLA registry at omla-ai.org/registry. Search by model name or look up by SHA-256 weight hash. Registered models have:

• A unique omla1… wallet address with public payment pointers
• An Ed25519 public key proving creator identity (the verifier also accepts hybrid Ed25519 + ML-DSA-65 post-quantum keys)
• A SHA-256 hash anchoring the specific model weights
• A signed manifest — lineage, split, and pointers — with a manifest hash you can recompute
• A registry status: ACTIVE, REVOKED, or DELISTED

You can also add OMLA-ID: omla1… to your model card or README and email verify@omla-ai.org for verification.

Every model in the registry carries one of three statuses:

• ACTIVE — the normal state; the manifest is served and listed
• REVOKED — the registration is under review after a credible integrity challenge; the manifest stays visible with its status so payers can see it, and the state is reversible
• DELISTED — removed from listings after review for fraud, a legal order, or a DMCA action; the manifest remains resolvable so models downstream of it still settle correctly

Status says something about the integrity of the registration — never about anyone's payment history. Transitions are deliberate, reviewed, audit-logged actions, and delisting is reserved for fraud, legal, and DMCA cases. The process, complaint route, and appeal window live on the Registry Integrity page.

No. OMLA keeps no records of usage, payers, or payments — because it never receives them. There is no delinquency clock and no payment blacklist. Whether a given company has paid is something only that company and its payees can know.

Enforcement is the creators' license rights: audit on reasonable notice and ordinary contract remedies. Registry statuses exist to protect the registry itself, not to score payers.

No. You can keep your fine-tune private. The OMLA License only requires royalty payments for commercial use — it does not mandate open-sourcing of derivative weights or code.

Declare your lineage when you register: one edge per parent, each typed as fine-tune, merge, distillation, or quantization. Every edge must carry an upstream share of at least 0.01%, your retained share is capped by the relationship type, and the whole split must sum to exactly 100% in basis points — the wizard enforces the caps live and registration fails closed on any mismatch.

A snapshot is static signed JSON under /registry/v2/: a pinned-key-signed current index, immutable sequence and previous-index links, domain-separated Merkle roots and per-model proofs, plus creator-signed evidence. A key declared only in the index is not enough. Payers keep the verified sequence and Merkle root locally; nothing is sent to OMLA.

If you resolve a calendar quarter against a verified signed snapshot no more than 90 days old at that quarter's end and pay the sheet, your obligation for that quarter is discharged even if a manifest later changes. Pin one snapshot per quarter.

At resolve time, a wallet share below 0.1% is dropped and the remaining lines renormalize. Any line under $0.10 for the calendar quarter is also non-payable. Nothing accrues or carries forward.

omla-resolve/2.0 is the published algorithm that turns a registry snapshot plus your usage into a payout sheet. It flattens each model's recursive split into per-wallet shares, spreads your obligation across models by your metered weights, applies the dust rule, and emits one line per wallet — percentage, amount, and payment pointers. It is deterministic integer math with largest-remainder rounding, a depth cap of 32, and cycle defense: the same inputs produce byte-identical sheets in the Python and JavaScript reference implementations, and published test vectors let anyone verify a reimplementation. Every registry model page runs it in your browser — try the "Resolve $100" demo.

Obligations are denominated in USD. Settle each line over a published pointer at a fair conversion where needed. Amounts under $0.10 per wallet per calendar quarter are non-payable dust.

The browser generates Ed25519 locally and downloads an AES-256-GCM encrypted omla-creator-key-v1 bundle; no full secret appears in the page or clipboard. Registry reads verify a client-pinned Ed25519 key, immutable index links, Merkle proofs, and supported creator evidence. Because the browser pin comes from the same origin, independent first-visit trust still requires an external verifier or witness. Hybrid Ed25519 + ML-DSA-65 remains an advanced API/CLI path until audited browser support ships.

Scenario: You published an original model (no lineage). It retains 100%, split across two team wallets at 70% / 30%. A commercial user self-assesses a $10,000 basis for the quarter — a $3,000 royalty, all attributed to your model.

Result: Wallet one is paid $2,100.00 and wallet two $900.00 — directly, from the payer.

Scenario: For calendar quarter 2026-Q3, NovaBase-Instruct is a fine-tune of NovaBase-70B and a user owes a $3,000 royalty on it.

Result: The fine-tune's creator is paid $150.00 (5%); NovaBase-70B's creators are paid $2,850.00 (95%).

Scenario: NovaBase-Instruct-4bit is a quantize of a fine-tune of NovaBase-70B. A user owes $100 on it for calendar quarter 2026-Q3.

Math: The quantizer keeps 2% of $100 = $2.00; the fine-tuner keeps 5% of the $98.00 that flows up = $4.90; the remaining $93.10 reaches NovaBase-70B.

Result: $2.00 / $4.90 / $93.10 — the original creators get 93.1%.

Scenario: A merge retains 10% and splits 60% / 30% upstream. A user owes $1,000 on it for calendar quarter 2026-Q3.

Result: Merge team $100.00; parent one $600.00; parent two $300.00. If a parent were itself a derivative, its share would keep flowing up by that parent's own split.

Scenario: For calendar quarter 2026-Q3, you owe $200, metered 50/50 across NovaBase-Instruct and NovaBase-Instruct-4bit. NovaBase-70B is owed through both paths.

Result: The resolver merges lines by wallet address — one line of $188.10 (94.05%) for NovaBase-70B's wallet, $9.90 for the fine-tuner, $2.00 for the quantizer.

Scenario: A distant upstream wallet resolves to 0.06% of your usage for calendar quarter 2026-Q3.

Result: 0.06% is below the 0.1% dust floor, so the line is dropped at resolve time and the remaining lines renormalize to 100%. Separately, any line under $0.10 is non-payable. Nothing is accrued or carried forward.

Scenario: Bob charges $1 per user per month. In calendar quarter 2026-Q3, each continuously subscribed user produces $3 of attributable revenue.

Result: $3 × 30% = $0.90 per user for 2026-Q3, resolved once and paid within 60 days after quarter end.

Scenario: Hardware depreciation plus direct support totals $200,000 annually, allocated consistently at $50,000 to calendar quarter 2026-Q3; no attributable revenue.

Royalty basis: 2026-Q3 run cost = $50,000.

Result: $50,000 × 30% = $15,000 for 2026-Q3, due within 60 days after quarter end.

Scenario: During calendar quarter 2026-Q3, $0.10/token × 1,000 tokens = $100 attributable model revenue.

Result: 30% × $100 = $30 owed.

Scenario: Jenny pays a site $20/month; the site aggregates its attributable revenue and settles once for calendar quarter 2026-Q3.

Result: Jenny owes $0; the site pays based on its revenue/compute.

Scenario: A $1,000/month GPU rental runs an OMLA model throughout calendar quarter 2026-Q3, for $3,000 quarterly run cost.

Result: 30% × $3,000 = $900 for 2026-Q3, resolved once and due within 60 days after quarter end.

Scenario: During calendar quarter 2026-Q3, Alex buys $50 in credits on SiteY and uses images in paid ads.

Result: SiteY owes 30% of $50 = $15; Alex owes no separate royalty if SiteY pays.

Scenario: A $3,000 obligation for calendar quarter 2026-Q3 spans two OMLA models; the local ledger shows 80% on model one and 20% on model two.

Result: The resolver spreads $2,400 through model one's split and $600 through model two's, then merges lines by wallet. Meter consistently — compute cost, tokens, or explicit revenue attribution — and keep the ledger.

Scenario: In calendar quarter 2026-Q3, a pipeline is 70% free and 30% OMLA. Revenue $1,000 → OMLA base $300 → royalty $90.

Scenario: In calendar quarter 2026-Q3, saved labor = 100 hrs × $50 = $5,000 value; no attributable revenue.

Result: 30% × $5,000 = $1,500 royalty. If truly no cost/value basis (fully depreciated hardware, no support, no value), base may be $0.

Rule: The amount owed is in USD; you settle directly using any pointer the wallet publishes. If one pointer carries high fees, use another of their listed pointers or agree a method with the payee. OMLA charges nothing and operates no rail.