A lending market or a perpetuals program wants a fresh price and a bound on staleness. The API can median public observations. No program can read that median from an account.
Label
Concept
Job type
Price, off-chain median
Nuvex path
API response, not an account
Deployments
None. Programs reject a Price request.
What the application needs
A price consumer cares less about where a number came from than about whether it is recent, whether one source can move it, and what the program should do when the feed goes quiet.
- A price with a timestamp or slot, and a rule for rejecting it when it is too old.
- Aggregation across sources, so one lying or broken source cannot set the number.
- A confidence or deviation bound the program can act on.
- Defined behaviour when the feed is unavailable, rather than an undefined liquidation.
What Nuvex provides today
The reusable part is the request lifecycle, not the data. Price is one of the five job identifiers, a request can already carry an input, constraints and a callback, and the node registry already enforces a heartbeat window on whoever would fulfil the work.
- oracle-corerequests, callbacksLive
- oracle-registrynodes, stake, slashLive
- verificationECVRF proofsLive
The architecture also fixes where the data may not come from: on-chain programs stay deterministic and free of HTTP, databases and model runtimes, and the read API is explicitly not a source of protocol truth.
What does not exist
An on-chain price verifier. GET /v1/prices can median fresh public observations, and programs still reject a Price request, so a consuming program cannot read that median from an account.
“On-chain price, data, compute, and inference verifiers are still absent.”
Stale observations are dropped using the provider timestamp. A source that fails is listed and not replaced. A lying venue can still move the median, and the chain does not check it.
What a developer would have to build
The off-chain median exists. A program that needs the number in an account still has to wait, because nothing on-chain verifies it.
- A way to read GET /v1/prices, knowing a 422 means there is no median.
- Fallback behaviour in the consuming program for that empty case.
- An on-chain check, which this tree does not have. A majority of HTTP responses is not a proof.
Honest status
Planned means a later milestone has to design this. The price median is an API response, not an account a program can read. Data jobs are still unspecified.
On this page
