For redistribution platforms

Integrate with OMLA

If you host or redistribute third-party AI models, integrating OMLA Direct means two things: read the signed public registry so every model shows its license terms and where the money goes, and ship the open omla-resolve algorithm so commercial users can compute exactly which wallets to pay. There is no usage reporting and nothing to submit — OMLA publishes information, and payers pay creators directly.

Three integration surfaces

  1. Registry lookup. The registry is published as signed static JSON under /registry/v2/ — an index with a sequence number, root hash, and Ed25519 signature, plus one public manifest per model (identity, lineage, split, payees, payment pointers, registry status). Weight-hash lookup gives you upload-time dedup and license auto-population. Mirror it freely; verify the signature.
  2. Ship the Resolver. omla-resolve/2.0 is a deterministic, open-spec algorithm with published test vectors and reference JS/Python libraries. Given usage weights and a snapshot, it returns the payee percentage per wallet — byte-identical for any party who runs it. Render it on model pages, or hand it to your commercial customers for their own self-assessment.
  3. Registration (optional). If creators publish models from your platform, call the register-model API with the version 5 signed manifest — identity, lineage, split with retention caps, payee wallets, and public payment pointers. Signing happens client-side; there are no usage-reporting endpoints anymore, for anyone.

Per-platform friction ranking

Model Marketplaces with Their Own Economy friction 2 · drop-in

Platforms that already have per-model license selectors and SHA-256 dedup on upload. Best surface: registry lookup on upload plus the manifest's "where the money goes" panel on model pages. Everything you need is static signed JSON — no accounts, no callbacks, nothing to report.

Creator-Paid Inference Platforms friction 3 · buy-in needed

Already pays creators a share of inference revenue — the 30% greater-of royalty maps cleanly onto existing economics. Where your platform is the commercial user, you self-assess, resolve against a signed snapshot, and pay each manifest's wallets directly from your own accounts.

Inference Routers / Aggregators friction 3 · buy-in needed

Per-request metering already exists — exactly the usage ledger the resolver consumes. Offer your commercial customers a per-model usage export and bundle omla-resolve so they can compute their own settlement sheets. Your routing fee stays orthogonal to the royalty.

Weight Hosting Platforms friction 4 · leadership buy-in

Primarily a weights host, not an inference host. Best surface: registry lookup at upload, adding omla-2.0 as a license identifier and linking each model's public manifest. Don't expect enforcement; do expect visibility.

Commodity Inference Providers friction 4 · unit-economics problem

Low-margin inference with no creator in the price stack today. The royalty is the monetizing user's obligation, not yours — the light-touch play is surfacing each model's manifest and resolver output so your customers can settle correctly. A platform-wide creator mandate or EU AI Act Article 53 pressure changes the calculus.

Enterprise Cloud Inference friction 3 · worth courting

Catalog-style open-weight inference with enterprise compliance appetite. The pitch writes itself: a deterministic, open algorithm over a hash-anchored snapshot — auditors reproduce the numbers from the customer's own records, no third party in the loop.

Compute IaaS / GPU Rental friction 5 · not a fit

Infrastructure-as-a-service — the customer is the commercial user, not the platform. OMLA talks to their customers directly; mirroring the registry and preinstalling the resolver CLI is a nice-to-have.

Where you land depends on your platform type. If you're unsure which category fits, send us a note and we'll help map it out.

Reference integration snippet — lookup & resolve

Full read path: check whether an uploaded weight file is OMLA-registered, fetch its public manifest, and show who would be paid what. No key, no account — the registry is public, signed, static JSON.

const REGISTRY = 'https://omla-ai.org/registry/v2/';

// 1. Verify the index signature against your independently pinned registry
//    Ed25519 public key. Do not trust pubkey_b64 only because index.json says so.
const index = await fetch(REGISTRY + 'index.json').then(r => r.json());

// 2. On upload: is this weight hash registered?
//    (weight hashes live in each model manifest; snapshot.jsonl.gz has
//    every manifest, one per line — index it however you like)
const manifest = await fetch(REGISTRY + `models/${modelId}.json`).then(r => r.json());
annotateModelPage(manifest); // license 2.0, lineage, split, status, pointers

// 3. Show the money path: "if you owed $100 for this model…"
//    payees.json is the model's precomputed flattened payee vector
//    (or compute it yourself with OMLAResolver.flatten on the manifests).
const payees = await fetch(REGISTRY + `models/${modelId}/payees.json`).then(r => r.json());
const sheet = OMLAResolver.resolve({
  usage: [{ model_id: modelId, weight: 1 }],
  total_cents: 10000,                       // $100.00
  period: '2026-Q3',                        // required with total_cents
  vectors: { [modelId]: payees.vector }
});
// sheet.lines → wallet, percent, amount_cents, payment pointers.
// A commercial user pays those wallets DIRECTLY — nothing is reported
// to OMLA, and OMLA keeps no record of usage, payers, or payments.

Registration API — v5 manifest shape

Only needed if creators publish models from your platform. The normal OMLA browser flow imports an encrypted creator bundle and signs the canonical v5 registration message with Ed25519; it binds the account, license version and digest, weight hash, and manifest hash. Hybrid Ed25519 + ML-DSA-65 remains an advanced API/CLI option until an audited browser implementation ships. There is no usage-reporting endpoint.

await fetch(`${OMLA_FUNCTIONS}/register-model`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json',
             Authorization: `Bearer ${creatorJwt}` },
  body: JSON.stringify({
    name: 'ExampleLM-7B-Instruct',
    sig_algorithm: 'ed25519',               // normal browser flow
    public_key, registration_signature, signed_timestamp,
    account_id, weight_hash,
    license_version: '2.0', license_digest,
    manifest_hash,                    // SHA-256 of the canonical manifest
    lineage: [{ parent_id: BASE_MODEL_ID, relationship: 'fine-tune' }],
    wallets: [{ address: 'omla1…', share_bp: 10000,
                pointers: [{ rail: 'lightning', value: 'creator@ln.example' }] }],
    split: { retain_bp: 500,          // fine-tune cap: at most 5%
             upstream: [{ parent_id: BASE_MODEL_ID, share_bp: 9500 }] }
  })
});
// The registry re-derives the manifest hash server-side and fails closed
// on any mismatch, cap violation, or split that doesn't sum to 100%.

Full field reference, canonical message formats, and the resolver specification live in Technical docs.

How settlement works

Whoever monetizes the model — you, or your customers — follows four steps once per calendar quarter: keep a local usage ledger; calculate 30% of the greater of attributable revenue or run cost; run omla-resolve with a YYYY-Q1 through YYYY-Q4 quarter; and pay each published payee directly within 60 days after quarter end. Most of the money flows to the original creators. Nothing is reported or submitted to OMLA, and OMLA does not want it; OMLA holds no funds, operates no payment rails, and keeps no records of usage, payers, or payments.

Talk to us

Platform-integration questions: hello@omla-ai.org. Engineering detail / API bugs: hello@omla-ai.org.