Get reimbursed for hosting OMLA-licensed models
If you run inference, mirror weights, or otherwise host OMLA-licensed models, creators can opt to redirect a share of their royalty to you — quarterly, weighted by reported inference volume, verified by Ed25519 identity. OMLA itself takes zero; every dollar you receive is one the creator chose to share.
Economic flow
resolve_hoster_fork().Worked example
Assume ExampleLM-7B has hoster_share_pct = 15.0, no upstream lineage, and a single creator. A commercial user runs it in production and owes a $200 royalty for 2026-Q2. Three verified hosters reported inference volume for the quarter:
| Party | Inferences | Volume share | Pool share | Payout |
|---|---|---|---|---|
| Hoster A | 128,345 | 0.310 | 4.65% | $9.30 |
| Hoster B | 213,980 | 0.517 | 7.75% | $15.50 |
| Hoster C | 71,675 | 0.173 | 2.60% | $5.20 |
| Hoster pool total | 414,000 | 1.000 | 15.00% | $30.00 |
| Creator pool (remainder) | — | — | 85.00% | $170.00 |
The creator receives $170 instead of the $200 they would have received without opting into hoster reimbursement. In exchange: three independent hosters were kept economically whole (or closer to it) for serving inference, distribution is wider, and the creator didn't have to self-host.
How a hoster gets paid — end to end
- Generate an Ed25519 keypair. This is your hoster identity, separate from any model creator identity. Keep the secret key in a password manager or HSM.
- Claim attribution. For each model you host,
POST /api/hoster/claimwith an Ed25519 signature over the string"host:<model_id>". See API example. - Get verified. The model's creator counter-signs your claim, or OMLA compliance reviews and approves it. Unverified claims accrue no balance.
- Report volume quarterly.
POST /api/hoster/reportwith a signed payload: inferences count (required), tokens processed and compute hours (optional). Reports are editable until the quarter-close cutoff (default T+30 days). - Check accrued balance.
GET /api/hoster/balance?hoster_claim_id=…returns per-quarter status. - Payout. Payment rails for hosters are not yet live — see the roadmap. When live, you'll register a wallet + rail to receive your accrual.
Payout currency — creator's choice
Every model declares an ordered list of preferred currencies. A hoster (or commercial-user platform) paying a creator walks the list top-to-bottom and pays in the first currency it can natively remit. If none of the creator's preferred currencies match, the hoster falls back to the creator's backup cryptocurrency — declared by the creator at registration, mandatory.
- A backup currency is required and must be a crypto (BTC, LN-SATS, ETH, USDC — enumerated in the currency registry).
- Platforms may charge a declared, publicly-visible conversion fee when they have to convert their native currency into the backup crypto (e.g. Civitai → BTC at 30%). Fees are capped at 50% and must be disclosed before payout — no silent skim.
- If a platform pays a creator in a currency the platform supports natively, the fee is 0 by construction.
| Scenario | Creator prefers | Platform supports | Chosen payout | Conversion fee |
|---|---|---|---|---|
| Best case | BUZZ → USD → BTC* | BUZZ, USD | BUZZ | 0% |
| Fiat match | JPY → USD → BTC* | USD | USD | 0% |
| Backup fallback | BUZZ → BTC* | USD only | BTC | platform's declared USD→BTC fee |
| Platform-native with fee | USD → BTC* | BUZZ only | BTC | BUZZ→BTC fee (e.g. 30%) |
resolve_payout_currency() in migration 010.Rules & caveats
- Opt-in at the creator's discretion. A model with
hoster_share_pct = 0owes hosters nothing. Most models will start at 0 — the creator consciously chooses to share. - Ceiling of 50%. A creator can't give hosters more than half the royalty; at that point other arrangements are more appropriate than OMLA's flow.
- Volume-weighted, not prestige-weighted. The hoster who ran 80% of inferences gets 80% of the hoster pool. If OMLA later detects inflated reports, the complaint workflow can reduce or revoke accruals; see Compliance.
- Changes are signed. A creator updating
hoster_share_pctmust sign the update with their model creator key. No silent changes. - No OMLA take. We don't skim hosters or creators. If the math above looks lopsided to you, that's because we aren't in the middle of it.
Questions: coord@omla-ai.org for hoster onboarding and multi-party coordination, support@omla-ai.org for general help.