Publish your model
Publishing means signing a manifest: your identity, your model's lineage, the royalty split you choose (with suggested defaults if you want them), and where commercial users pay you. Work down the eight steps and you end up with one finished omla-manifest.json — you never write JSON by hand. Every step runs in this browser tab: your secret key is generated, encrypted and used locally, your weight file is hashed locally, and nothing is uploaded to OMLA or anyone else at any point.
How the eight steps fit together
Three stages. The first is one-time setup you reuse for every model you ever publish; the second describes this model; the third turns the description into a signed, self-contained file.
Your identity
A signing key (proves manifests are yours) and a wallet address (names you as a payee). Make them once; reuse them for every model.
Your declaration
What the model is, what it was built from, how the royalty splits between you and your parents, and exactly how to pay you.
One signed file
Your key signs the declaration into omla-manifest.json. Ship it next to your weights — it works the moment it exists.
- You need: a browser, and about ten minutes.
- You get: one JSON file — your public licensing terms.
- Uploaded: nothing, ever. There is no OMLA account.
Already have a key and wallet from a previous model? Skip straight to step 3.
1 Generate a signing key
What this makes. An Ed25519 keypair — the same signature scheme SSH and Signal use. The public key becomes your creator identity; the secret key signs your manifests.
Where it lives. In a file you download: omla-creator-key-v1.json. The secret key inside is encrypted with AES-256-GCM under your passphrase (PBKDF2, 600,000 iterations) before it ever touches disk. Keep two offline copies.
One key, many models. You reuse this key for every model you publish, and for future manifest updates — payers recognize you by its fingerprint, not your display name.
If you lose it (or the passphrase): there is no recovery and no reset email, because there is no account. You'd generate a new key and republish; manifests signed with the old key stay valid but can no longer be updated.
An Ed25519 keypair, generated locally and encrypted with a passphrase you choose. The secret key is encrypted before it ever touches disk, and it is never sent anywhere — not to OMLA, not over the network. Losing the passphrase means losing the key; there is no recovery.
2 Generate a wallet address
Not a bank account, not a blockchain. An omla1… address is just a stable identifier (Bech32m-encoded random bytes, like a postcode with a checksum). Money never moves "through" it — it tells a payer which payment pointers are yours.
Pointers do the paying. You attach one or more public pointers to the address: a Lightning address, an on-chain address, a Stripe payment link, PayPal.Me, or an invoicing URL. A payer picks whichever rail they can actually use — attach more than one to make paying you easy.
Public by design. Everything here ships in your public manifest. Never put anything private in a pointer.
Changed banks? Publish an updated manifest with new pointers, signed by the same key. Verification ties pointers to your signature, so nobody else can redirect your payments.
A Bech32m-encoded omla1… address is how the manifest identifies a payee. Generate one, then attach one or more public payment pointers to it — a Lightning address, an on-chain address, a Stripe payment link, a PayPal.Me link, or an invoicing URL. Pointers are public by design: anyone resolving a payment needs to see where it goes.
3 Certify your model
Why this is here. The registry lists models that pay their creators — it must never become a distribution channel for abuse. The four certifications are the floor every listed model stands on.
These are signed statements, not checkboxes. They become the safety_certifications block inside the bytes your key signs. Certifying falsely is a misrepresentation under Terms §6.2, and a certified model that turns out to generate CSAM is reported and delisted under §6.3 — no exceptions, no appeals path.
"Reasonably designed and tested" means good-faith effort proportional to your model: for most models, running it against the obvious abuse prompts and documenting that you did.
Required for every manifest, regardless of what the model does or who it's for. These become the safety_certifications fields in your signed manifest (schema) — not a one-time website formality, but part of the record your key signs. Full legal text: Terms of Service §6.2–6.3.
"safety_certifications": {
"no_harmful_use": false,
"not_for_minors": false,
"no_csam": false,
"safety_tested": false
}4 Describe your model
Model id. A random UUID that stays stable for this model. A new release with different weights is a new manifest — either a fresh id, or the same id republished with a new weight_hash and version bump.
Weight hash. The SHA-256 of your published weight file is how a payer proves the manifest matches the artifact they downloaded — it pins your terms to those exact bytes. Hashing happens in your browser via the File API; a multi-gigabyte file just takes a moment.
Source URL. Point at the canonical home of the weights (Hugging Face repo, release page). Diligence teams follow this link first — a dead or ambiguous source is the fastest way to not get paid.
These fields become the identity half of your manifest. Everything here is public — it is what a commercial user reads to work out that they owe you money.
Hashed in your browser — the file is never uploaded. Large files take a moment.
5 Declare lineage and your split
Basis points. Shares are integers out of 10,000 (100 bp = 1%). No floats ever touch money math.
The split is yours to declare. License §6 publishes suggested retained shares — fine-tune 500 bp (5%), quantization 200 bp (2%), distill or merge 1000 bp (10%) — but they are defaults, not caps. Whatever you sign is what the resolver pays out, and the whole split is public: payers and upstream creators can read exactly what you declared.
OMLA parents. A parent that has its own manifest gets a real upstream share — the royalty flows through it recursively, so original creators get paid even three derivatives down the chain.
Non-OMLA parents. You can (and should) still declare a parent that never adopted OMLA — a base model on any other license. It is recorded in your lineage as external:<source> for honest provenance, but it receives no share: the license is opt-in and makes no claim on models that never joined. If that creator later publishes a manifest, republish yours with them as an OMLA parent so they start getting paid.
Stack weight matters only when several independent models produce one output together (base model + LoRAs). See stacks.
If your model is built from someone else's, say so — the declared lineage is what makes the chain honest. The split is yours to choose: License §6 suggests defaults, this form prefills them, and whatever you sign is what resolvers follow. Parents can be OMLA models (they receive an upstream share) or any other model (recorded as provenance, no share — they never opted in).
No parent declared, so you keep the whole royalty: 10000 bp.
Only matters when several independent models make one output together — see stacks. Leave it at full weight if you are unsure.
6 Say where you get paid
How a payer actually pays you. Once a quarter, their settlement sheet lists your wallet address, the amount, and these pointers. A person or a script then pays each line over whichever rail they can use. That's it — no OMLA in the middle.
Attach more than one rail. A US payer may find Stripe easiest; a payer abroad may prefer Lightning; a corporate accounts team may want an invoicing URL. Every extra standard pointer raises the odds you get paid without anyone emailing you.
About "Other". The standard rails are validated formats every OMLA tool understands. An other pointer is a free-form description — tools can't validate it, payment scripts can't automate it, and a payer who can't figure it out may lawfully be unable to complete that line. It exists for genuine edge cases (e.g. a national bank-transfer scheme), and it belongs alongside a standard pointer, not instead of one.
Your wallet address from step 2, plus at least one public payment pointer. A payer reads these directly out of your manifest — there is no OMLA account in between, so if these are wrong nobody can pay you.
7 Sign it
What exactly gets signed. Your fields are serialized into the canonical OMLA-MANIFEST-v1 string — id, name, source, timestamps, license version, weight hash, lineage, safety certifications, payees with their pointers, and the split — in a fixed order with sorted keys. The signature covers every byte of it.
What that buys you. Nobody can alter a payment pointer, a share, or a certification after the fact: change one byte and verification fails everywhere, offline, with just the manifest and your public key. This is the entire security model — there is no account to hack because there is no account.
Locally, once, wiped. The key bundle is decrypted in memory, used for one signature, and discarded. Nothing here makes a network request — check DevTools if you like.
Load the key bundle you saved in step 1 and unlock it with your passphrase. Signing happens in this tab: the secret key is decrypted in memory, used once, and wiped. It is never sent anywhere.
8 Publish it
The file is the product. A signed manifest sitting next to your weights already binds any commercial user of those weights — the registry only makes it easier to find and harder to tamper with.
The registry today. Submissions are reviewed and added by hand. The automated, signature-gated publish pipeline — validation gates, append-only sequencing, snapshot signing, mirrors — is designed and written up in Registry automation & security.
What to send. The manifest JSON and the public key that signed it. Never your passphrase, never your key bundle — no honest party will ever ask for either, including OMLA. Verification needs only public material.
Your signed manifest is a self-contained document. It is worth something the moment it exists, before OMLA does anything with it — so publish it where your model already lives:
- Put
omla-manifest.jsonnext to your weights — in the Hugging Face repo, the model card, the release page, the git repo. A commercial user who has your model then has your payment terms, with no lookup and no OMLA in the loop. - Link it from your model card, so it is findable by someone doing licensing diligence.
- Send it to the registry — see contact — to be included in the signed public index. The automated publish endpoint is gated until the License is operative (design: registry automation & security), so submissions are added by hand until then.
Send the manifest JSON and the public key you signed it with. Never send your passphrase or your key bundle to anyone, including OMLA — nobody needs it to verify your signature.