LoRA Merger
Capability Composition Subnet
Thousands of specialist adapters exist. Nobody knows which combination actually does the job.
This subnet turns that into a measurable question, pays whoever answers it best, and publishes enough for anyone to check the answer without trusting the operator.
same device, same bytes
A recipe names the adapters and how to combine them. The network rebuilds it and measures what comes out.
Nobody is training anything here
The pieces of applied AI are already available: capable open base models, thousands of task-specific LoRA adapters, serving stacks, evaluation harnesses. What is still unsolved is the composition decision — for one real job, which adapters help, which are redundant, which actively conflict, and at what weights.
A miner does not submit a model. They submit a recipe: one JSON document naming adapters from a frozen pool and how to combine them. Every field is a bounded number, a name from that pool, or an enum.
That single constraint is what makes the whole system safe and checkable. Nothing a miner writes is ever executed. The engine reconstructs the recipe into weights deterministically, so two machines running the same image on the same kind of device produce byte-identical bytes — which is the only reason "the champion's package" is a well-defined object at all. The factorising merge methods reproduce across devices only to within arithmetic tolerance, not to the byte; see the limits below.
The search space is large enough to be a real contest. With 26 selectable adapters and seven merge methods, four-adapter combinations alone run to about 62,000 before anyone touches a coefficient, a density, a rank or a per-layer override.
What a miner actually does
Any hardware. A GPU only if you want to evaluate locally before committing. How you search is entirely your own business — the network judges the artifact, never the research that produced it.
Read the contract
The pool, the base model, every bound, every gate and the exact scoring formula are published as one machine-readable document.
Search, privately
Which adapters compose, at what weights, under which merge method. This is the actual work and nothing about it is reported.
Evaluate locally
Reconstruct the artifact and score it against the public instance pack using the same scorer the engine runs.
Commit one digest
Your entire on-chain footprint: a content hash of the recipe plus a pointer to the bytes. The recipe itself lives off-chain.
Wait to be drawn
The queue is ordered by commit block. Nobody chooses who is evaluated next — the chain does, by the order it accepted commitments.
A decisive loss retires the hotkey permanently. The rule is only defensible because failures that indict the engine hold a candidate for a later window instead of spending its shot.
Recipes are public — they must be, or nothing could be verified. So the earliest commitment wins on the reconstructed bytes, and a later copy has to be measurably better, not merely higher.
Almost every submission fails to take the top slot. Everything below it is graded on quality, improvement, proximity and running cost, and paid accordingly.
A validator needs no GPU, and is not a relay
Validators do not reconstruct, serve or score anything. That is a real concentration of trust in one operator, and the answer to it is not a promise — it is that a validator refuses to pay for a number it cannot reproduce itself.
Instance generation is a pure function of a published seed and the scorer is deterministic. So a validator regenerates the exact problems the candidates faced and re-runs the scoring over the operator's own published traces — on a small VPS, with no GPU and no model.
An engine whose scores do not follow from its own traces does not get paid. When a vector cannot be verified, the validator burns rather than passing it along: a stale champion collecting emission because the engine died is worse for the network than nobody collecting it.
Verify the operator's signature against an allow-list the validator controls. Check the vector against the chain it can see. Re-score a closed window from published traces. Burn anything unverifiable.
That the instance draw was bound to the block it claims, and that recent windows all derive from one seed root — so the operator cannot quietly re-roll which problems a candidate faces.
Four parties, one direction of trust
Everything that decides a published number is public and installable by anyone. The engine that runs those rules is the operator's, and nothing public depends on it — a test fails if that ever stops being true.
The recipe contract, the merge engine, the workflows and every rule that turns evidence into a number — aggregation, gates, retention, the comparator, ranking, the weight vector.
The window loop, candidate serving, the artifact cache, the store, the read-only API. None of it changes what a candidate scores.
The hidden seed root and wallet material. Neither is in either repository, and the draw each window is bound to a block hash the operator does not choose.
What the network pays for
The leader takes most of the workflow weight. Everything below it is graded, because a recipe is one shot and paying a near miss the same as a soup of distractors teaches nobody anything.
Only packages clearing every hard gate are graded — this is not a consolation prize for something undeployable. If nobody qualifies, the pool burns rather than becoming a bonus for an uncontested leader.
What is not yet true
A design that published only its favourable properties would be marketing. These are the open questions, stated as they stand.
Does composition beat the best single adapter? On this pool, not yet demonstrated. The references exist precisely so the network can discover the answer is no.
openAn SVD merge is byte-reproducible on a device, not across devices.
linear reproduces exactly on CPU and GPU. Every method ending
_svd does not: LAPACK and cuSOLVER factorise the same matrix
differently, and on a 12288×4096 delta 65% of elements still differ after
bfloat16 rounding — quantisation cannot close it. Scores are unaffected, because a
validator re-scores from published traces and never re-merges. What it costs is
reproducing a published artifact digest, which needs the same class of
device the engine used.
The evaluation corpora are public. The hidden seed protects which items a window draws, not the items themselves — weaker than a generated workflow, and the price of corpora whose difficulty is already measured.
mitigatedAn operator choosing one seed root dishonestly at genesis. Re-rolling between windows is caught and a fabricated block binding is caught. A single bad root chosen before any candidate exists is not — that needs an eventual reveal.
not defendedEfficient multi-adapter serving is a real competitor. Static merging is only worth selling where measured total cost is genuinely better. A routed-adapter reference baseline is planned.
openDeterministic reconstruction across independent machines. Byte-identical, with load order, precision, threading, TF32 and singular-vector signs all pinned.
verifiedWhat a merged package is worth, and when it is worth nothing
A company does not buy "a translation adapter" or "a SQL adapter". It buys a system that finishes a business process. The question is whether that is cheaper to run as one merged model or as several specialists behind a router — and that is an arithmetic question, not a matter of taste.
A routed system spends something on every single request deciding where to send it. If that decision is made by a model, it is tokens; if by a classifier, it is a hop and a service. A merged package answers directly, so the cost is not reduced — it stops existing.
A merged package is a single file under 524 MB that serves on one 24 GB card. No adapter set to keep resident, no swap on a cold skill, no per-skill capacity planning. VRAM stops being a function of how many capabilities you offer.
Regulated buyers approve artifacts, not architectures. One versioned, content-addressed file with a reproducible build is a far shorter conversation than "these seven adapters, this router, and its training set".
A worked example
A support pipeline with five specialist skills, one million requests a month, an LLM router. Illustrative arithmetic on the stated assumptions — not a measurement. Substitute your own numbers; the shape is what matters.
| Per request | Routed | Merged | Difference |
|---|---|---|---|
| Router prompt in | 250 | 0 | −250 |
| Router decision out | 10 | 0 | −10 |
| Task call | same | same | — |
| Network hops | 2 | 1 | −1 |
| Per month, 1M requests | 260M tokens | 0 | 260M fewer |
The router tokens are pure overhead: they buy no answer, only a decision about who should answer. Removing a hop also removes its tail latency, which is usually what a user actually feels.
What we have actually measured
On a 250-item paired benchmark, output tokens tracked merge health closely enough to be a diagnostic in their own right.
| Package | Score | Output tokens | Rows |
|---|---|---|---|
| reading the engine… | |||
Two things are true at once and both matter. A healthy merge was three times cheaper to run than the base model on identical work. And on this pool it also scored lower than the best single adapter — which is exactly the trade the network exists to measure rather than assume. A collapsed merge announces itself in cost before it announces itself in score, which is why token efficiency is a scored term and not a footnote.
Cost is not a marketing claim here. Latency, token efficiency and artifact size are 15% of the quality score, so a package that wins is already a package that is cheap to run.
When merging does not win
Stated plainly, because a buyer will find these out anyway.
Efficient multi-adapter serving is genuinely good. S-LoRA and Punica amortise adapter swapping well. Where your router is a cheap classifier rather than a model, the token argument shrinks to a latency and operations argument.
dependsA specialist can simply be better. If one adapter dominates your traffic, merging trades capability for convenience you may not need. On the current pool no merge has beaten the best single adapter.
not yetMerging can destroy general ability. An over-aggressive merge loses instruction-following before it loses task score. That is why a retention floor of 0.98 on a held-out probe is a hard gate rather than a scored term.
gatedWho this is for
Multi-step agent systems pay routing overhead on every step. Collapsing a fixed skill set into one package removes that per-step cost and one moving part.
One artifact on one card is deployable where a fleet of adapters plus a router is not — and where a fixed footprint is the procurement requirement.
A reproducible, content-addressed artifact with a published evaluation record is an auditable object. The architecture behind it is not.
What the network produces, then, is not a model. It is a continuously re-measured answer to "which composition is worth deploying, and what does it cost to run" — published with the evidence, so a buyer can check it without trusting either the miner or the operator.
Window pipeline
runningPackage under measurement
—Marker shows the strongest permanent reference on that axis.
Hard gates
—Permanent references
re-measured each window| Package | Kind | End-to-end | Retention | Tokens |
|---|
Champion
holding- uid
- —
- held
- —
- margin
- —
- artifact
- —
- recipe
- —
Emission split
gradedChallenger queue
—| Hotkey | Block | State |
|---|
Completion, last 24 windows
Engine log
On chain
—Read from the subnet itself, not from the engine. A miner’s whole on-chain footprint is one commitment; a validator’s is the stake it carries and the block it last wrote weights at. Everything above is the engine’s account of the arena — this is the chain’s, and the two are checkable against each other.
| UID | Hotkey | Role | Stake | Incentive | Dividends | Last write | Submission |
|---|