Topics can now be configured for regression or classification and return either one value or a labeled set. Network inferences use the same labeled structure.
Existing topics migrate as regression, single-output topics under the canonical label y. Their prediction targets, horizons, and core behavior remain unchanged within the new format.
For direct integrators, v0.17 requires changes to emissions queries, transactions, response parsing, and event handling. Integrations must support labeled inputs and outputs even when consuming an existing single-output topic.
Labeled outputs in v10
Before v0.17, every mainnet topic produced a single numeric output. The output schema did not distinguish between task types or support several named values within one network inference.
v0.17 adds labels to the topic output model. A topic defines the labels workers submit against, and network inferences are returned using the same labels.
A single-output regression topic uses the canonical label y. A multi-output topic returns a set of values, with each value attached to the label defined by the topic. This allows integrations to identify output components by name rather than treating them as positions in an unlabeled sequence.
Labels also provide the structure required for classification topics. A topic can define a set of possible outcomes and return one value for each outcome. If the topic requires those values to sum to one, the network inference can be interpreted as a probability distribution.
The probability constraint is optional. Classification outputs do not inherently need to sum to one, and multi-output regression values remain continuous estimates.
Existing topics migrate under y
Existing mainnet topics migrate as regression, single-output topics. Their output is represented under the canonical label y.
The migration preserves each topic’s current prediction target, horizon, and scoring loop. It does not convert existing topics to classification, introduce additional outputs, or change how their underlying predictions should be interpreted.
The compatibility distinction is between topic behavior and integration format. Existing topics retain their core behavior, while their queries, transactions, responses, and events move to the v10 emissions format.
An integration consuming an existing topic should continue to read one prediction value. At the protocol layer, that value now appears within the labeled v10 structure.
This gives existing and future topics a common output model without changing the meaning of current network inferences.
Classification and multi-output topic design
The new schema separates task type from output count.
A topic can use regression or classification. It can also produce one output or multiple labeled outputs. These properties are defined independently in the topic configuration.
A classification topic might define outcomes such as up, neutral, and down. Workers submit values against those labels, and the network returns an accuracy-weighted inference using the same outcome set.
A multi-output regression topic can return several related continuous estimates under one topic. For example, a realized volatility target covering a defined asset basket and shared horizon could assign a separate label to each asset. The resulting network inference would contain one continuous estimate for every required label.
Both formats keep the topic’s target, horizon, labels, and scoring loop within one topic definition. Builders can select an output schema that matches the structure of the prediction problem rather than reducing every target to one scalar.
The upgrade provides the protocol-level format for these topics. Each topic still requires its own target definition, label set, horizon, and scoring configuration.
Direct integrations move to emissions v10
Direct emissions integrations must move from v9 to v10.
The change covers:
- emissions queries
- emissions transactions
- labeled request
- response handling
- emissions event processing.
Integrations should no longer assume that every network inference contains one unlabeled scalar. The parser must identify values using the labels supplied by the topic schema.
This requirement also applies to existing topics. Those topics remain single-output, but their value is represented under y in the updated format.
Integrators working only with existing topics need to support the v10 representation. Integrators planning to consume classification or multi-output topics also need to handle arbitrary topic-defined label sets and multiple values within one network inference.
Systems consuming Allora through a higher-level interface should confirm how that interface represents v0.17 outputs. Systems using emissions queries, transactions, or events directly require a v10 compatibility pass.
Building with the expanded topic schema
v0.17 gives topic designers two additional decisions at the schema level: whether the target uses regression or classification, and whether the network inference contains one value or multiple labeled values.
Classification topics can represent a defined set of outcomes directly. Multi-output topics can keep related estimates within one target, horizon, and scoring loop. Optional normalization allows classification outputs to function as probability distributions when the topic requires it.
Existing topics continue as regression, single-output topics under y. New topics can use the expanded formats where their prediction targets require them.
For direct integrators, v10 provides one labeled representation across these topic formats. Queries, transactions, network inference responses, and events now use that structure throughout the emissions integration surface.
The result is a common output model for existing single-output topics and the classification and multi-output topics introduced with v0.17.
Network outputs are aggregated predictions, not financial advice. No guarantee of accuracy or fitness for any purpose. Consumers bear all trading risk.
.jpg)
