Publish Your Model

Ed25519 is a fast, modern digital-signature scheme. It produces very small keys (32-byte public, 64-byte secret) and very short signatures (64 bytes). The browser generates your keypair locally; nothing is sent over the network.

Three places the keypair matters:

1. Registration signature. You'll sign the final manifest — identity, weight hash, License acceptance, split, payees, and pointers — so anyone can verify the record was created by you.
2. Signed manifest updates. Changing your pointers or split later means signing a manifest-update message with this same key — no signature, no change.
3. Proof of key control. A challenge signature proves control of the registered key. It does not by itself prove authorship, rights, lineage, or control of a payment destination.

Safe storage: keep two offline copies of the encrypted bundle, separate from its passphrase. Never commit either to git or send either through chat or email. OMLA never receives the secret and cannot recover the bundle or passphrase; email alone is not cryptographic recovery.

Each relationship carries a retention cap from License v2.0 §3 — the most your model may keep of anything that arrives at it:

• Fine-tune — retain at most 5%. The base did most of the heavy lifting; you shaped the behavior.
• Quantization — retain at most 2%. You changed the efficiency profile, not the capabilities.
• Distillation — retain at most 10%. A new artifact, trained on the parent's outputs.
• Merge — retain at most 10%, with the upstream share divided across the merged parents.
• Training from scratch. Leave the lineage section empty. This is original work — your model retains 100%.

With multiple parents of mixed relationships, the highest cap among your edges applies. The split is recursive: what you send upstream is divided again by each parent's own published split, so most of the money reaches the original creators.

Non-OMLA bases (like Meta Llama, Stable Diffusion) can't receive royalties through OMLA — but you should still declare them in your model card for transparency. A future field will capture these as informational external lineage.

• Lightning address or BOLT12 offer (recommended) — instant, near-zero fees, works like email. Get one from any Lightning wallet or service.
• BTC / ETH / SOL addresses — plain on-chain destinations. On Ethereum, the same address receives USDC and other ERC-20 stablecoins.
• Stripe Payment Link / PayPal.Me — hosted fiat links; the payer opens the link and pays card-to-you or account-to-account.
• Invoice URL or mailto — your own invoicing page or billing address. Put private fiat rails (bank transfers, invoicing services) behind it.

The omla1… address itself never moves money — it's the stable identifier your pointers hang off, and it stays the same when you rotate pointers later with a signed manifest update from your dashboard.

Payee shares divide this model's retained slice — solo creators use one payee at 100%; teams, funders, or charities each get their own payee and the shares must total 100%.

Because most of a derivative's value comes from the models it builds on. License v2.0 §3 caps what each relationship may retain (fine-tune 5%, quantization 2%, distillation and merge 10%), and the rest flows upstream — where each parent's own published split divides it again, all the way to the original creators.

Worked example: $100 arrives at a fine-tune retaining 5%. Its payees share $5; $95 flows to the base model and is divided by the base's own split. Original models retain 100% of whatever reaches them.

Each upstream parent must get at least 0.01%. The live preview below runs the real resolver on your draft manifest so you can see the final per-wallet outcome before you sign it.

You're signing the canonical v5 registration message: model name, account id, algorithm, public key set, SHA-256 weight hash, exact License version and artifact digest, timestamp, and the SHA-256 hash of your canonical manifest — so the split, payees, and pointers you reviewed are exactly what gets published under your signature.

On submit (live mode):

1. The browser POSTs the v5 signed request to the register-model Edge Function with your user JWT.
2. The function verifies the signature, re-derives the manifest hash server-side, and rejects on any mismatch.
3. Database triggers validate no lineage cycles, the retention cap, exact 100% totals for both split and payee shares, pointer formats, and unique key fingerprint.
4. Registry status starts as ACTIVE and the model enters the next signed snapshot.
5. The success result shows the model UUID, manifest hash, and registry-page link.

In preview mode, submit downloads an unsigned draft for manual review. It is not a verified registration because v5 binds a live account id and exact License artifact.