Security model

Randomness infrastructure earns trust by being precise about what it guarantees — and about what it doesn't yet. Both halves, plainly.

What holds, cryptographically

Nobody can forge an outcome. The on-chain verifier accepts exactly one proof per (key, input) pair — the uniqueness property of the VRF. The suite (VRAND-R255-TAI: ECVRF over ristretto255, SHA-256 try-and-increment hash-to-curve, verified with native curve syscalls) is specified in a public document with frozen test vectors; the implementation reproduces the C2SP reference vectors byte-exactly through a test seam and is differentially tested against an independent implementation.

Nobody can re-roll or precompute. The input alpha is frozen at request time and binds the previous slot's bank hash — a value that does not exist until the request's slot begins — plus your requester identity and seed. A request and its outcome can never land in the same slot (enforced), so the commitment always precedes the possibility of knowing the outcome. Prover key rotation in the request slot is rejected for the same reason.

Nobody can block resolution. fulfill and slash are permissionless and exempt from the pause flag — not as policy but as construction. The proof authenticates itself, so anyone may deliver it; after the window, anyone may slash. The admin cannot stand between a pending request and its resolution, and window parameters are snapshotted per-request so they cannot be moved retroactively.

Silence has a price. Non-delivery is the one failure cryptography cannot punish, so the bond does: your declared at-risk amount is reserved against the prover's bond and pays you exactly, automatically, on timeout.

You never trust a server. Verification is local and on by default in every SDK. A malicious RPC can make your request fail; it cannot make you accept a wrong outcome.

What we won't pretend

A prover can see its own outcome moments early. It computes the proof, so it knows beta before publishing. It cannot lie, cannot pick a different outcome, cannot un-commit — but for adversarial third-party use where early knowledge itself is the threat, this matters. This is the honest headline constraint of every single-key VRF service, ours included.

Status: a threshold (FROST-style) prover is built and reviewed in this repository — t-of-n machines jointly produce the same 80-byte proof the on-chain verifier already accepts, so no single machine sees the outcome early. Wiring it across genuinely independent operators is the current engineering milestone, and the claim will stay scoped to what the deployment actually achieves.

The first bonded fleet is operated by us. The registry is permissionless and the economics pay whoever delivers; we want independent provers in it. Until they exist, pinning to the VRAND fleet means trusting us not to peek — see above — while the bond still guarantees delivery.

Invariants that must never regress

These are load-bearing and treated as protocol law:

1. Uniqueness — one input, exactly one possible output.
2. Permissionless resolution — no admin, pause, or prover can block fulfill / slash / close_request.
3. Exact solvency — every open request's at-risk amount is reserved against its prover's bond (bond ≥ reserved, enforced on every path).
4. Commitment precedes outcome — same-slot fulfillment is rejected; alpha binds pre-existing public data only.

Provenance

The on-chain verifier is clean-room work from the C2SP specification, RFC 9381, and the Solana syscall ABI. The full protocol source — program, verifier, SDKs, prover daemon, threshold crypto — is Apache-2.0.