Milestone 0 · Milestones
Nuvex maintainers
What landed
Milestone 0 set up the tree every later milestone fills in: the program crates, the shared libraries, the node skeleton, the API and indexer schema, both SDKs and the documentation. Since then the website, the documentation and the off-chain services have moved into repositories of their own, and this one is the protocol.
- programs/ — oracle-core, oracle-registry and verification, as three Anchor programs.
- crates/ — shared types, PDA seeds and the cryptography boundary.
- sdk/rust and sdk/js — PDA helpers, with no instruction submission.
- cli/ — the nuvex binary with node, request, registry, staking and network commands.
- node/ — a health-only oracle node process.
- tests/ — LiteSVM, integration and the callback consumer.
- env/ and security/ — example environment files, the threat model and the operational policy.
- oracle-corerequests, callbacksLive
- oracle-registrynodes, stake, slashLive
- verificationECVRF proofsLive
A job-agnostic request
The shape of the protocol was fixed before any handler existed. A request carries a job type, an input, constraints and a callback, so a new job family means a new verifier and an off-chain executor rather than a new core program. There is no request_randomness entrypoint.
“Job kinds are Vrf, Price, Data, Compute, and AiInference. Only the kind identifier exists today.”
What did not land
At Milestone 0 there were no instruction handlers at all. The audit scope document is blunt about what reviewing that revision would have achieved.
“Milestone 0 has no instruction handlers. An audit of this revision would only confirm that absence.”
The same file asks for the audit to be scheduled after VRF verification and callbacks exist, and again before mainnet. The deployment script for mainnet exits before any transaction.
Decisions left open on purpose
Two questions were left unanswered rather than filled in with something plausible: which VRF construction to verify, and which request transitions should exist. Both became decision records, and both were answered later by evidence rather than by convenience.
“These are blocked on purpose. The next milestone must not invent them in a pull request that only wants the code to compile.”
The transition graph that followed allows cancel and expire, and later the single VRF fulfilment edge. Every challenge, reject and fail edge stays forbidden until a record designs it.
Checking the tree yourself
One command runs formatting, Clippy, cargo build-sbf for the three programs and the test callback consumer, the Rust tests and the JavaScript SDK tests. The program tests load the built objects from target/deploy, because verification calls sol_sha512.
make check
# the node image is built from the same tree
docker build -f node/Dockerfile -t nuvex-oracle-node:local .
# RPC URLs, program ids and key paths are variables, never defaults in source
cp env/.env.local.example .env.local
