Skip to content

Back to the catalog

NuvexNetwork/nuvex
github.comrepo

NuvexNetwork/nuvex

Nuvex is a Solana-native verifiable compute and oracle protocol, still pre-mainnet, whose own README documents unresolved security gaps instead of hiding them: its VRF proof verification relies on solana-ecvrf 0.0.1 (RFC 9381 ECVRF-Edwards25519-SHA512-TAI) which has no known audit, max_fee is stored but never actually charged, and VRF fulfillment is first-come among any node meeting the configured stake/heartbeat threshold — meaning an operator who funds several keys at a low minimum stake can selectively pick which randomness output gets used. The deploy-mainnet script is stubbed to exit before any transaction, and unresolved design questions (fee shares, challenge/reject state transitions) are tracked as explicitly blocked ADRs rather than quietly shipped.

TL;DR An early-stage Solana VRF/oracle protocol whose own docs flag an unaudited verifier crate and a multi-key Sybil weakness in its "first-come" randomness fulfillment model, with mainnet deploy deliberately disabled.
Open original ↗
Document

What it is

NuvexNetwork/nuvex, a pre-mainnet Solana verifiable compute and oracle protocol. The repository itself is scoped to on-chain programs, SDKs, CLI, and a health-only node — the website, docs site, and off-chain services live in separate repos.

Preconditions / Affected

Milestone 3 is the current state: VRF fulfillment via solana-ecvrf 0.0.1 works, but nothing moves money and nothing deploys to mainnet. Node fulfillment requires: the node is active, stake meets the configured minimum, heartbeat is inside the configured window, and the key was registered before the request. A minimum stake of zero satisfies this trivially, which is explicitly called out as not resisting the multi-key selection problem.

How it works

Three unresolved issues are tracked as deliberately blocked ADRs rather than left undocumented:

  • ADR 0004: no audit exists for solana-ecvrf 0.0.1, the crate verifying ECVRF proofs.
  • ADR 0001: challenge/reject/fail state transitions are forbidden; only cancel, expire, and VRF fulfillment are live transitions right now.
  • ADR 0003: fee shares and weighted selection don't exist — fulfillment is first-come among nodes meeting the predicate, with no weighted lottery, and max_fee is stored but never collected.

What to do

  • make check runs formatting, Clippy, cargo build-sbf for the three programs plus the test callback consumer, Rust tests, and JS SDK tests. Requires Solana CLI and platform tools; program tests load target/deploy/*.so via LiteSVM 0.17 (needs the default SBF architecture because verification calls sol_sha512).
  • Build the node image with docker build -f node/Dockerfile -t nuvex-oracle-node:local .
  • Copy env/.env.local.example to .env.local before pointing any process at a cluster — RPC URLs, program IDs, and key paths are environment variables, not source defaults.
  • Development program keypairs are gitignored under keys/program/; public IDs in Anchor.toml are local-only IDs, not something to treat as stable.
  • Do not run scripts/deploy-mainnet.sh expecting it to deploy — it exits before sending any transaction, by design.

Caveats

Milestone 4 (indexer, Postgres, API, dashboard) is scoped next, but fees remain unset until ADR 0005 names basis points, and mainnet deployment is explicitly out of scope until then. The page states "no audit report was found" for solana-ecvrf 0.0.1 — this is an absence noted by the maintainers, not a confirmed negative audit result.

Organisations named here

  • ECVRF-EDWARDS25519-SHA512-TAI
  • RFC 9381

Technologies named here

  • solana-ecvrf
  • nuvex
  • LiteSVM
  • nuvex-oracle-node
  • make check
  • sdk/rust and sdk/js
  • cli/
  • Solana CLI and platform tools
  • Docker
  • Solana
  • Rust

Related in Blockchain