OMLA Documentation

Overview

OMLA keeps models freely usable for personal/research work and requires a 30% share (the greater of attributable revenue or run cost) for commercial use. Models are registered with a single payout address (OMLA wallet) so funds cascade automatically through the lineage.

Getting started

1. Read the License (v8-10-2025).
2. Compute the SHA-256 hash of your model weights: sha256sum your-model.bin
3. Generate an Ed25519 keypair (use the registration form or tweetnacl).
4. Register your model to obtain an OMLA wallet address and declare lineage.
5. Add OMLA-ID: omla1… to your model card/README and email verify@omla-ai.org.
6. For commercial use: send 30% of the applicable basis to the model's wallet quarterly.

API Overview

The OMLA API is powered by Supabase PostgREST — all CRUD operations are auto-generated from the PostgreSQL schema. The base URL is https://YOUR_PROJECT.supabase.co/rest/v1/ (set in assets/js/config.js). Authentication uses Supabase JWT tokens.

Public Endpoints (No Auth)

Authenticated Endpoints (Creator)

Authenticated Endpoints (Commercial User)

Database Schema

10 tables in Supabase PostgreSQL (Tokyo region). All tables have Row Level Security (RLS) enabled.

Relationship types (lineage_edges.relationship)

Allowed values: fine-tune, merge, distill, quantize, derivative.

Payment rail types (wallets.rail)

Allowed values: stripe, paypal, lightning, ach, sepa, wise, other.

Wallet Protocol

The OMLA wallet protocol defines how payments are received, split, and routed through the lineage DAG.

Address Resolution Flow

Client sends:  omla1qq0emf5v...
       ↓
Registry lookup: /rest/v1/wallets?address=eq.omla1qq0emf5v...
       ↓
Returns: { model_id, rail: "stripe", rail_identifier: "acct_xxx" }
       ↓
Split resolution: SELECT * FROM resolve_splits(model_id)
       ↓
Returns: [
  { wallet: "omla1...", rail: "stripe",    percentage: 40.00 },
  { wallet: "omla1...", rail: "paypal",    percentage: 35.00 },
  { wallet: "omla1...", rail: "lightning", percentage: 25.00 }
]
       ↓
Payment engine: route $amount × percentage to each wallet via its rail

Quarterly Payout Batch

Runs on the first business day of each quarter:

1. Query all usage_reports where quarter = current_quarter and status = 'submitted'
2. For each report, verify royalty_amount = max(revenue × 0.30, run_cost × 0.30)
3. Call resolve_splits(model_id) for each model in report
4. Aggregate: net all payments to each unique wallet across all reports
5. Filter: drop wallets where total < $0.10 (carry forward)
6. Execute payments, select least-cost rail per wallet
7. Update usage_reports.status = 'paid' and compliance_state = 'COMPLIANT'

Ed25519 Identity

Each model creator generates an Ed25519 keypair for cryptographic identity. The keypair anchors model ownership and authorizes future updates.

Keypair Components

JavaScript (tweetnacl)

import nacl from 'tweetnacl';
import { encodeBase64 } from 'tweetnacl-util';

const kp = nacl.sign.keyPair();
const publicKey = encodeBase64(kp.publicKey);  // Store in registry
const secretKey = encodeBase64(kp.secretKey);  // Creator keeps this

Signing a Registration Payload

const message = JSON.stringify({ name, model_hash, pubkey, timestamp });
const messageBytes = new TextEncoder().encode(message);
const signature = nacl.sign.detached(messageBytes, decodeBase64(secretKey));
const signatureBase64 = encodeBase64(signature);

Bech32m Address Format

OMLA wallet addresses use Bech32m encoding (BIP-350), the same format as Bitcoin SegWit v1 addresses.

JavaScript (bech32 library)

import { bech32m } from 'bech32';

// Generate from model UUID bytes
const words = bech32m.toWords(modelUuidBytes);
const address = bech32m.encode('omla', words, 90);

// Decode
const { prefix, words: w } = bech32m.decode(address, 90);
const uuidBytes = bech32m.fromWords(w);

Split Resolution Algorithm

The split resolution algorithm traverses the lineage DAG recursively and produces a flat terminal split table — one row per creator wallet with their final percentage of any payment.

PostgreSQL Function

SELECT * FROM resolve_splits('your-model-uuid-here'::uuid);
-- Returns: { wallet_address, wallet_rail, percentage }

Pseudocode

function resolve_splits(model_id, weight = 1.0):
  terminal_splits = {}

  for each upstream in model.lineage_edges:
    if upstream.parent is OMLA-registered:
      child_splits = resolve_splits(
        upstream.parent_id,
        weight × upstream.contribution_weight
      )
      merge_additive(terminal_splits, child_splits)

  for each split in model.contribution_splits:
    terminal_splits[split.wallet] += weight × (split.percentage / 100)

  return terminal_splits

Complexity: O(V + E) where V = models in lineage, E = edges. Practical depth: 2–5 levels.

Implementation: Recursive CTE in PostgreSQL (WITH RECURSIVE). Called via Supabase RPC endpoint.

Compliance States

Every model and commercial user entity in the registry has a compliance state. Transitions are automatic based on report submissions, payment verifications, and missed deadlines.

Blacklists are published quarterly at /api/blacklist.json (signed JSON).

Publish a model

The Publish page guides you through a 6-step registration: model identity, Ed25519 keypair, lineage declaration, wallet setup, contribution splits, and signing.

Example model JSON (generated by the form)

{
  "name": "ExampleLM-7B",
  "domain": "NLP",
  "description": "A 7B parameter language model.",
  "model_hash": "e3b0c44298fc1c149afbf4c8996fb924...",
  "ed25519_pubkey": "base64-encoded-32-bytes",
  "license_version": "v8-10-2025",
  "wallet": {
    "address": "omla1qq0emf5v8xgs5gwtk4gec7fy5k7spvg...",
    "rail": "stripe",
    "rail_identifier": "acct_xxx"
  },
  "lineage": [
    { "parent_wallet": "omla1...", "relationship": "fine-tune", "contribution_weight": 0.40 }
  ],
  "contribution_splits": [
    { "recipient": "Alice", "wallet": "omla1...", "percentage": 70 },
    { "recipient": "Bob",   "wallet": "omla1...", "percentage": 30 }
  ],
  "registration_signature": "base64-encoded-64-bytes"
}

Royalties & payments

Commercial users pay the greater of 30% of attributable revenue or 30% of total model run cost. Payments are due quarterly. Minimum per-wallet payout: $0.10 USD.

• Attributable revenue: Revenue directly tied to using the model (subscriptions, API fees, output sales)
• Run cost: Compute, storage, bandwidth, hardware depreciation, direct IT support
• Pipelines: For multi-model systems, split royalties by declared contribution percentages
• Fees: Routing/conversion fees deductible up to 10% of the royalty

Derivatives & attribution

Declare upstream models and contribution weights when registering. A weight of 0.40 means 40% of payments received by your model cascade upstream to that parent.

Security & verification

• Ownership verification: Ed25519 signature on registration; add OMLA-ID: omla1… to model card and email verify@omla-ai.org
• Weight integrity: SHA-256 hash of model weights anchors the specific file version
• RLS policies: Unauthenticated users can only read models/registry; writes require auth
• Audit log: Append-only log of all mutations with before/after state
• API keys: Commercial user keys hashed with bcrypt; never stored plaintext
• No PII: Only email and wallet addresses stored beyond model metadata

Integration

The Svelte SPA (coming soon) provides the full authenticated interface. For now:

• Query the public registry via Supabase PostgREST (anon key required)
• Call resolve_splits(model_id) to get terminal payment splits
• Attach your model JSON to repos and model cards for tooling to consume
• For manual registration: email verify@omla-ai.org with your registration JSON

Glossary