A draw anyone can re-check against the proof 

What the application needs

A draw has one hard requirement: the number that picked the winner must be checkable afterwards by somebody who does not trust the organiser. Everything else — tickets, entry windows, prize accounting — is ordinary program state.

• One random value per draw, bound to that draw and to nothing else.
• Evidence that survives the draw, so a loser can re-check it later.
• A number nobody could have known before the draw closed.
• A path that does not depend on an operator's honesty for the result to be auditable.

What Nuvex provides today

This is the one job family that is live in the programs. A request carries the job type, the input, the constraints and an optional callback. Fulfilment verifies an RFC 9381 ECVRF proof — ECVRF-EDWARDS25519-SHA512-TAI, 80-byte proof, 64-byte output — inside the verification program before the output is written.

• The alpha is built from the request account, the job type and the input, so a proof cannot be moved to another draw.
• Only an eligible node may fulfil: active, stake at or above the configured minimum, heartbeat inside the configured window, and a VRF key registered before the request.
• The result is stored in a VrfResult account owned by the verification program, which is what a participant re-checks against.
• A callback, when set, receives the 64-byte output and no accounts.

What does not exist

• Nothing in the repository sends the transaction: the node process is health-only, the TypeScript SDK's submitRequest throws on purpose, and the CLI reports the milestone it waits on.
• No fee moves. max_fee is stored and never charged, and ADR 0005 sets no basis points.
• No program is deployed to mainnet, and scripts/deploy-mainnet.sh exits before any transaction.
• The indexer and read API can list observed accounts when configured. The account is still the result; an API row is a copy.

What a developer would have to build

The verifiable part is the part Nuvex covers. The draw itself is the developer's program, and in the current milestone so is every transaction that touches the protocol.

• The draw program: tickets, entry window, mapping a 64-byte output to a winner, prize payout.
• The client or crank that actually submits the request, using the SDK's address derivation rather than its submit path.
• A callback handler with an empty accounts struct if it wants the notification, plus its own settlement instruction, because a callback cannot write state.
• The checker: a page or script that reads the stored output and proof and re-runs the verification off-chain.

What this example would have to disclose

One key has one output for one alpha, and a consumer can rely on that uniqueness. A consumer cannot rely on the output being unbiased against an operator who funded several keys before the request, because each of those proofs is valid and the operator picks which one to submit. Each extra key costs the configured minimum stake, and a minimum of zero does not resist it.

A draw with real money on it should say that in its own terms, and should not be run by someone who also operates the nodes.