Deciding which of many equal claims gets filled first — an allocation queue, a tie-break between identical bids, a shuffled allowlist — without a trusted party running the shuffle.
Label
Concept
Job types
Vrf today, Price and Data planned
Nuvex path
Partly live, partly undesigned
Deployments
None. This is a sketch.
What the application needs
A prediction market has two separate fairness problems. One is ordering: when several claims are equivalent, something has to break the tie without favouring an insider. The other is settlement: the market has to learn what actually happened.
- A tie-break or shuffle that the market operator cannot steer.
- A permutation that can be recomputed by anyone from published values.
- A settlement source for the outcome, with a bound on how stale it may be.
- Resistance to grinding: nobody should be able to retry until the ordering suits them.
What Nuvex provides today
The ordering half can lean on the live VRF path: a verified 64-byte output, bound to one request, is enough to seed a permutation that any observer can recompute. The request also records who fulfilled it, with the stake and heartbeat values that were checked, as assigned_node, assigned_stake and assigned_heartbeat.
- job_type
- VRF
- requester
- your program
- input
- 32-byte seed
- callback
- consumer program
- max_fee
- recorded, not charged
Fulfilment is first-come among nodes that meet the ADR 0003 predicate. There is no weighted lottery and no assigned set, so nothing about the ordering depends on a private backend choosing a fulfiller.
What does not exist
- Settlement data on-chain. A public price median exists off-chain, and programs still reject a Price request. Data jobs have no named source check.
- Any notion of a sequencer or ordering service inside the protocol. Nuvex returns a value; the ordering is the caller's.
- Commit and reveal, which ADR 0004 places at Milestone 6 for deterministic compute.
- Fees and rewards, so there is no economic reason for a node to race for this work yet.
What a developer would have to build
- The permutation itself, derived deterministically from the 64-byte output, plus the published method so anyone can repeat it.
- A grinding-resistant request policy: who may open the request, when, and with which input.
- The whole settlement path, from an outside source to on-chain state, since no data job runs.
- Transaction submission, which the SDKs still refuse to do.
Honest status
Half of this concept maps onto something implemented and half of it maps onto a reserved job identifier. It is marked planned for that reason: a market built on it today would be using verifiable randomness and its own settlement, not a Nuvex data feed.
“Job kinds are Vrf, Price, Data, Compute, and AiInference. Only the kind identifier exists today.”
On this page
