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. Right now, you'll sign the final registration payload so anyone can verify the record was created by you.
2. Future updates. To change a wallet, rotate splits, or update metadata, you'll need to sign the change with this secret key. Without it you cannot update your model.
3. Proof of ownership. If someone disputes the registration, you prove you're the creator by signing a challenge with the secret key.

Safe storage: paste the secret key into a password manager (1Password, Bitwarden, etc.) or an encrypted file. Never commit it to git, never post it in Discord/Slack, never email it. OMLA does not store it and cannot recover it if lost — recovery requires the board verifying your identity via email + recomputing the weight hash.

The weight is your honest estimate of how much of this model's value came from the upstream model. Some rules of thumb:

• Fine-tune on a base model. Common: 0.60–0.80 upstream. The base did most of the heavy lifting; you shaped the behavior.
• Quantization / distillation. Very high: 0.90–0.98 upstream. You changed the efficiency profile, not the capabilities.
• Merge of two peer models. Split based on parameter count or evaluation contribution; totals must still be ≤ 1.0.
• Adapter / LoRA layered on a base. Often 0.70–0.90 upstream; your work is the delta.
• Training from scratch. Leave the lineage section empty. This is original work — 100% of the pool stays here.

Weights less than 1.0 leave a remainder, which becomes your "original contribution" portion and is split via Step 5. Weights summing to more than 1.0 will be rejected by the database.

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

The omla1… address is not a payment instrument itself. It's a globally unique identifier that OMLA resolves to whatever real payment method you chose (your Stripe Connect account ID, your PayPal email, your Lightning address, etc.).

Flow, during a quarterly payout:

1. A commercial user's usage report generates $X of royalty owed to models including yours.
2. The quarterly-payout job calls resolve_splits(), which returns a table of (omla1… address, rail, percentage).
3. For each row, the job looks up the rail + rail_identifier and calls the rail's execute().
4. Stripe / PayPal / Lightning actually moves the money; OMLA records the payment.

Your rail_identifier (Stripe acct_…, PayPal email, Lightning address) is private — not shown on your public registry page. You can change it later by signing an update with your Ed25519 secret key.

Which rail should I pick? If you're in the US, Stripe Connect is the easiest and cheapest. If you're international, PayPal is more universal but charges more. If you already have a Lightning wallet, Lightning is nearly free and instant. Multiple wallets per model are supported — you can add more later from your dashboard.

When $100 arrives at your wallet, it's split in two phases:

1. Upstream flow-through. If Step 3 declared a base model with contribution weight 0.40, $40 flows up to the base model (and recursively to its ancestors). You don't control how that $40 is split — that's the base model's own splits table.
2. Local pool (this step). The remaining $60 is yours to divide among the people who built this model. You + collaborators + funding recipients. Those divisions must sum to 100% of the local pool.

Common patterns:

• Solo creator: one row, 100% to your own wallet.
• Co-creators: two or three rows summing to 100%. Disputes go through the complaint system, not a rewrite of this table after the fact (changes need co-signer consent — see the roadmap).
• Grant funder: a percentage earmarked for your grant giver, remainder to yourself.
• Nonprofit donation: a percentage to a charity's OMLA wallet.

Every recipient's wallet here must itself be a valid OMLA address (either an existing one or a freshly-generated one bound to their chosen rail).

You're signing a canonical JSON blob: { name, hash, pubkey, wallet, license }. The signature lives in models.registration_signature and anyone can verify it later against the stored public key. It's the cryptographic proof that the keypair's owner authorised this registration.

On submit (live mode):

1. The browser POSTs to the Supabase REST API with your user JWT.
2. Row-Level Security confirms your signed-in email matches the creator_email you typed in.
3. Database triggers validate: no lineage cycles, weight sums, split totals, Bech32m address format, unique Ed25519 public key.
4. Initial compliance state is seeded as REGISTERED.
5. You're redirected to your model's detail page with the generated UUID and wallet.

In preview mode (no Supabase configured), submit downloads a signed registration JSON for manual email submission to verify@omla-ai.org — useful while the production database is being set up.