Skip to content
Three programs · one request account

oracle-core creates requests and performs callbacks, oracle-registry holds nodes and stake, and verification checks proofs. Nothing else is on-chain. Milestone 4 copies those accounts into PostgreSQL so the API and console can list them.

The on-chain surface and the tools that test it

  • oracle-core
  • oracle-registry
  • verification
  • Anchor
  • LiteSVM
  • PDA seeds

A job-agnostic request, so a new job means a new verifier and not a new core program

ProgramsAnchor 1.2
  • oracle-corerequests, callbacksLive
  • oracle-registrynodes, stake, slashLive
  • verificationECVRF proofsLive

oracle-core

Live

Creates requests, accounts for fees, finalises and performs the callback CPI. request_randomness is not an entrypoint: the job type is a field.

oracle-registry

Live

Registers nodes, locks stake, records heartbeats and accepts a slash amount from the configured slash authority.

verification

Live

Checks the ECVRF proof against the key stored on the node account. Challenges are reserved for a later milestone.

crates/

Shared types, the PDA seeds that tests/fixtures/pda-seeds.json also pins, and the cryptography boundary, so the programs cannot drift apart on a layout.

The live transitions

Live

A request account is created already in Pending. The requester may cancel while the slot is below expires_slot, any crank may expire it once that slot passes, and fulfill takes a VRF request straight to CallbackExecuted once the proof is accepted.

Open requestOPEN
job_type
VRF
requester
your program
input
32-byte seed
callback
consumer program
max_fee
recorded, not charged
Illustration · not chain data

The forbidden edges

ADR 0001 classifies every pair of states. The multi-step assignment path is reserved and no instruction performs it. Every edge into or out of Challenged, Rejected and Failed stays forbidden, because the protocol does not yet know how a challenge returns to finality.

VerificationRFC 9381
  1. COMMITTEDproof submitted with the output
  2. VERIFIEDECVRF checked by the program
  3. FINALIZED64-byte output written
  4. EXECUTEDcallback ran, no accounts passed
Illustration · not chain data

The indexer and the API live in nuvex-services. They exist so an operator can inspect accounts without subscribing to a cluster. They do not finalise a result.

Indexer

In development

start polls getProgramAccounts for the configured program ids and decodes request, node, registry, protocol and VrfResult layouts. It writes PostgreSQL or a JSON snapshot. Missing RPC, program ids, or a persist target exits 2. It does not invent rows.

Read API

In development

GET /v1/requests, /v1/nodes and /v1/network return 200 from that store, including an empty list. They return 503 when no store is configured. GET /health returns authority: none. Jobs and models stay 501.

Console and CLI

In development

The site reads NEXT_PUBLIC_API_URL when set. nuvex network reads NUVEX_API_URL and refuses to invent status if it is unset. Illustration panels stay labelled. A missing indexed row is not proof the account is absent on chain.

Account model, ADR 0002

Live

Every account is a PDA. A request is seeded by the requester and a 32-byte id, so one user cannot occupy another user's id. No account stores a URL or an unbounded list.

Callback model, ADR 0006

Live

The CPI carries the 64-byte output and the stored callback bytes, and passes zero accounts. A fulfiller cannot choose what the callee touches. A failing callback reverts the transaction.

Upgrade model, ADR 0007

Planned

Upgrade authority is a multisig, never the deploy keypair. Nothing is deployed, and scripts/deploy-mainnet.sh exits before any transaction.