From untrusted GPU proposals to measured contributions.
Bounded proposals · isolated evaluation · reviewed release boundary
Cacheon measures untrusted GPU optimization proposals as attributable contributions and defines a separate review and release path for Cacheon Engine. SGLang owns the serving control plane; Cacheon's contribution boundary is the inference data plane. The current revision does not claim a completed production Engine release.
Why miners participate
Cacheon rewards independently reproduced performance improvements, not uploads or self-reported benchmarks. If settlement crowns a proposal for a published target, it records the corresponding reward claim in the same transaction. The validator later combines eligible claims into a weight vector and publishes it on-chain; realized token emission still depends on the wider Bittensor network.
See the reward lifecycle in plain English →
At the highest level, Cacheon has two systems: the chain-independent product and the market that improves it. Operationally, the market side separates the subnet control plane from the hostile-code referee, giving readers three cooperating surfaces with different trust boundaries.
Integration review: how a reproduced crown becomes ordinary reviewed source, and how model bytes are provisioned. The referee
Isolated, evidence-producing evaluation of one marginal target delta against a validator-owned incumbent stack. The subnet
Finalized proposal ordering, attribution, economic settlement, and weight publication. It is not part of the serving product.
One idea, four objects
The system keeps four objects deliberately separate:
A miner submits a proposal for one registered target delta. The referee may establish a crown after two independent passing qualifications. Cacheon maintainers may then turn the proposal into an integrated contribution after security, provenance, compatibility, and maintenance review. Work that does not fit a registered target is not a valid proposal; widening the catalog is a reviewed validator-side change.
Why the architecture is composable
Every candidate runs as a complete isolated engine, but it is rewarded only for the smallest validator-controlled delta it contributes. Authoritative qualification uses:
- B — the exact incumbent evaluation stack;
- C — the same stack with one registered target replaced;
- B′ — an incumbent bookend, conditional for a hot-swappable v7 candidate and mandatory for a non-swappable v8 candidate;
- A — a separate eager, untimed sampled-audit role when registered; and
- T — a candidate-free pristine reference that grades sealed trajectories after candidate destruction.
The current speed subpolicy is selected from the candidate's manifest features: v7 uses the standing resident pair and takes B′ only when B/C cannot decide; v8 launches separate baseline and candidate engines and always takes B′. C′/B″ survive only in historical v2–v5 evidence. Primary and reproduction attempts also exchange incumbent and candidate physical-lane roles. A persistent hot-swap screen may route candidates before this schedule, but its measurements cannot qualify or settle a contribution.
This separates the execution unit (a complete disposable engine) from the economic unit (one singleton target or atomic target). A new optimization can build on previous wins without repackaging or copying them.
Follow a proposal through the system →
Choose your path
| Goal | Start here |
|---|---|
| Write a Triton, CuTeDSL, or Python reference kernel | Miner guide |
| Validate the repository locally without a GPU | Local quickstart |
| Deploy intake, an arena provider, and qualification workers | Validator guide |
| Integrate a reproduced crown into reviewed source | Cacheon Engine |
| Audit trust boundaries and failure behavior | Security model |
| Check what is implemented, measured, and still unproven | State of record |
Evidence is scoped, not blended
Every performance or authority claim is scoped to the exact runtime, hardware, arena, stack, identities, and procedure that produced it. Diagnostic measurements cannot authorize a crown; crown evidence cannot authorize reviewed source; and release verification cannot retroactively validate qualification. The state of record identifies which evidence products have actually been retained for each boundary.
Note — Source of executable truth This Cacheon repository owns both executable contracts and this documentation. Content-addressed production evidence and immutable publications live in separate operator-owned stores. When prose and code disagree, the code, schemas, and tests in the same revision take precedence.