Skip to content
Live in the programs · since Milestone 3

A request carries a job type, an input, constraints and an optional callback. Randomness is the first job type: a node returns an 80-byte ECVRF proof, the verification program checks it on-chain, and the 64-byte output is written before anything else happens. Milestone 4 can list those accounts from the read API. The account is still the result.

The standards and libraries the proof rests on

  • RFC 9381
  • ECVRF
  • Ed25519
  • SHA-512
  • solana-ecvrf
  • Anchor
  • LiteSVM

What a request carries

Live

The request account stores the job type, at most 256 bytes of input, the slot it expires at, a max_fee ceiling that is recorded and never charged, and an optional callback program with at most 128 bytes of data. The default pubkey means no callback; a callback that is set receives the output and no accounts.

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

Verification happens inside the program

Live

The alpha is built by the protocol from the string nuvex-vrf-v1, the request account, the job type and the input, never from instruction data. The verification program checks the proof with solana-ecvrf 0.0.1 and writes the 64-byte output to an account bound to that one request.

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

Proving stays with the key holder

nuvex_sdk::prove_vrf takes the secret, the request, the job type and the input on the host and returns the 80-byte proof and the 64-byte output. The proving feature is not compiled into the programs, and the SDKs still refuse to send a transaction.

prove.rs
// Rust SDK, secret stays local
let proof = nuvex_sdk::prove_vrf(
    &secret, &request, JobType::Vrf, &input,
)?;
 
// proof.proof: [u8; 80], proof.output: [u8; 64]

These are uses of a verified 64-byte output, not deployments. Nothing is live on mainnet.

Draws

A raffle, a lottery or a loot roll settles in the callback, and the proof stays on the request so anyone can re-check the roll afterwards.

Ordering

Shuffling a queue, an allowlist or a turn order without a trusted party running the shuffle somewhere nobody can see.

Allocation

Picking winners, traits or slots from a fixed set, where a recipient wants to know why they got what they got.