Allora

Service overview

What is Allora?

Allora Network is a decentralized inference network: workers submit predictions on a topic, the chain combines them, and anyone can read the collective result. peaqOS exposes that read as a native adapter — an agent names a topic id and optionally a network, and peaqOS fetches the latest network inference from the public Allora chain LCD, keyless, on testnet and mainnet from the same deployment. An optional free consumer API key adds a second read path for the same topics. Every value comes back as a high-precision decimal string; peaqOS never parses chain numerics to a float, and records the order, run, outcome, and audit trail. The same adapter runs the other direction: a machine can join a topic as an inference worker. peaqOS validates the worker’s allo1… address offline, verifies the operator’s own registration or submission transaction against the chain’s emitted EventWorkerRegistered, persists it as a machine registration record, and re-reads live worker health on demand. Every fee-bearing action stays with the operator’s own keyring — peaqOS holds no keys and signs nothing.

How it works

1. Step 1

   Pick a topic

   Topic ids are per-network and are never portable between chains — testnet 1 and 3 are 10-minute ETH and BTC price topics, mainnet 1 and 2 are 8-hour log returns.

2. Step 2

   Order the read

   Call get-topic-inference with the topic id and an optional network; no credentials are needed for the chain path on either network.

3. Step 3

   Read the answer

   peaqOS returns the combined value as decimal strings with the block height and staleness it was measured at, and stores the run, outcome, and audit trail.

4. Step 4

   Or supply predictions

   To join a topic as a worker, register from your own keyring, hand peaqOS the transaction hash to verify against chain state, and it keeps the registration record and re-reads worker health on request.

Adapter operations

Behind peaqOS — the agent names a topic, peaqOS reads the Allora chain LCD keyless (or the consumer API when a key is present) and records the run. The worker operations read chain state only; peaqOS never signs.

• GETget-topic-inference

  Read a topic’s latest collective inference; returns the labeled combined value, block height, staleness, and — for log-return topics — an interpretation.

• GETget-worker-status

  Derive a worker’s live state on a topic from six read-only chain queries: funded, registered, submitting, stale, eligible, and the height it was all measured at.

• GETverify-registration-proof

  Verify a registration or submission transaction against chain state. Reads the emitted EventWorkerRegistered, so a reputer registration is rejected.

• GETverify-worker-address

  Validate an allo1… worker address offline — bech32 encoding, checksum, and HRP — with no chain call and nothing persisted.

Integration fields

Wire Allora into peaqOS

providerKey

allora

serviceId

allora:{network}:topic-{topicId}

skillKey

allora-topic-inference

serviceType

oracle.prediction

operation

get-topic-inference

networks

testnet + mainnet, served from one deployment

required input

input.topicId

optional input

input.network, input.source (auto|rpc|consumer), input.outlierResistant, input.includeRaw

credential path

providerCredentials.allora.apiKey — optional, consumer path only

output

combinedValue, inferenceBlockHeight, staleness, confidenceInterval, interpretation

worker serviceId

allora:{network}:worker

worker skillKey

allora-worker-participation

worker operations

verify-worker-address, verify-registration-proof, get-worker-status

registration records

GET /api/v1/machines/{machineId}/registrations

payment

not-required — public chain reads are free

operator-paid

worker registration: 50,000,000 uallo protocol fee + gas, paid from the operator’s own wallet

FAQ

Questions agents ask about Allora

• Does it require an API key?+

  No. Reads go to the public Allora chain LCD, which is keyless on testnet and mainnet alike. A free Allora consumer API key is optional — sent as providerCredentials.allora.apiKey it unlocks a second read path, but that API is metered at roughly five requests per fourteen minutes, so the chain path stays the default.

• How does payment work?+

  No peaqOS market payment runs on this service — chain reads cost nothing — and peaqOS still records the order, execution, and audit receipt. Registering a machine as a worker is the one part that costs money, and it is paid by the operator’s own wallet straight to Allora: a 50,000,000 uallo protocol fee plus gas, charged inside the registration message.

• Which topics and networks can a robot read?+

  Both networks from one deployment. Topic ids are per-network and never portable between chains — testnet 1 and 3 are ten-minute ETH and BTC price topics, mainnet 1 and 2 are eight-hour log returns — so every request names the topic and, optionally, the network.

• Can a machine supply predictions instead of reading them?+

  Yes, and peaqOS never touches a key to do it. It validates the allo1… address offline, the operator registers from their own keyring, and peaqOS verifies the resulting registration or submission transaction against chain state before storing it as a machine registration record. Live state — funded, registered, submitting, stale, eligible — is re-read from chain on request, never served from the record. Start on testnet sandbox topic 69 or 77: no whitelist, no penalty. Mainnet requires explicit human enablement.

• How deterministic are responses?+

  A topic inference is the network’s collective prediction at a block height, so it moves every epoch — but the same height always returns the same value, and peaqOS reports the height and staleness alongside it. Values stay high-precision decimal strings end to end; only the interpretation block derives an approximate direction and percent move, and only for log-return topics.

• What happens if a request fails?+

  Allora errors are classified before they reach the agent, so a deterministic failure fails once instead of being retried: an unknown topic or malformed address is terminal, a route that answers 501 says the pinned emissions version needs a bump, and a transaction older than the chain LCD’s 200,000-block retention window is reported as pruned rather than as something to retry. The error is stored on the failed order run.