The 30-second summary
Chainlink VRF delivers a random number to a smart contract along with an on-chain cryptographic proof. The proof is verified inside the EVM, so any contract that consumes VRF gets an unforgeable, on-chain-checkable randomness primitive. The cost is real: gas for the request, gas for the callback, LINK for the oracle, and a few blocks of latency.
Provable.io delivers the same "publish-a-hash, then reveal" guarantee — but off-chain, over HTTP, in tens of milliseconds, for free at the volumes most apps care about. You get a serverHash committed in advance and a deterministic outcome anyone can re-derive from the seeds.
If your randomness consumer is a smart contract that has to settle on-chain in the same transaction, use VRF. If your consumer is a web app, a game server, a backend service, or anything that just needs to publish proof of the draw, an HTTP API is dramatically simpler and cheaper.
Feature matrix
| Capability | Provable.io | Chainlink VRF |
|---|---|---|
| Where the result lands | HTTP response (JSON) | Smart contract callback (on-chain) |
| Verification surface | Anyone with the seeds + hash, off-chain | Anyone on-chain via the VRF coordinator |
| Cost per draw | Free up to per-account daily quota | Gas + LINK fee (varies by chain & gas price) |
| Latency | ~tens of ms | A few blocks (seconds to ~minute) |
| Pre-commitment to seed | Yes — /api/commit publishes serverHash before the call | VRF public key is fixed per subscription |
| Game primitives | dice, shuffle, weighted pick, bytes, distributions | raw uint256 — you implement the rest |
| Streaming / batch | Yes — SSE + batch endpoint | One callback per request |
| Open-source verifier | Yes (npm package) | Yes (Solidity verifier in Chainlink contracts) |
| Best for | Web apps, game servers, raffles, A/B tests, off-chain mints | Smart contracts that consume randomness on-chain |
When Chainlink VRF is the right answer
VRF is purpose-built for one job and does it extremely well: getting trustworthy randomness into a smart contract in a way the EVM itself can verify. Reach for it when:
- The consumer is a Solidity contract that must settle on-chain (DeFi raffle, on-chain lottery, on-chain card game).
- Holders need to verify the draw without ever leaving the chain or trusting an off-chain operator.
- The economic value of an individual draw is high enough that the LINK + gas cost is rounding error.
When Provable.io is the right answer
The vast majority of "I need fair randomness" use cases don't actually need an on-chain settlement — they need a result the public can check. For those, an off-chain provably fair API is the right shape:
- Web-app giveaways and raffles. No wallet, no gas. Publish the
serverHashin a tweet before entries close; reveal the seed after. See the raffle picker. - Off-chain mints and trait reveals. Many NFT collections do the metadata reveal off-chain; Provable.io gives holders a way to confirm the trait roll wasn't post-hoc engineered.
- Card and casino-style games that run on a game server. See the card shuffler.
- Experimentation platforms that need bucket assignments to be re-derivable years later. See A/B test bucketing.
- Real-time consumers (live dealers, simulators) where waiting two Ethereum blocks per draw is a non-starter.
Try a provably fair draw with no wallet
This is the off-chain equivalent of requestRandomWords — except the result is back in milliseconds and the proof is a tiny JSON payload anyone can verify.
curl "https://api.provable.io/api/ints?clientSeed=vrf-alternative-demo&count=1&min=1&max=1000000"Hybrid patterns
Off-chain doesn't have to mean "not anchored on-chain." Two common patterns:
- On-chain commit, off-chain reveal. Anchor the
serverHashin a cheap on-chain transaction before the event. Run the draw via Provable.io. Anchor the revealedserverSeedafter. You get on-chain provability without paying LINK per draw. - Client seed from a block hash. Use a future block hash as the
clientSeed. Neither side controls it, and the timing is unambiguous.
FAQ
Is Provable.io a drop-in replacement for VRF?
If your consumer lives off-chain — yes, with a simpler API and zero per-call cost. If your consumer is a smart contract that must verify randomness inside its own execution, no — VRF is the right tool for that job and we don't try to be it.
What's the worst-case trust assumption?
That Provable.io published an honest serverHash before learning the clientSeed. The commit-reveal flow (/api/commit + /api/reveal) eliminates the rest of the surface: the server hash is published before any client input, so the server can't grind.
What about VRF v2.5 subscriptions / native LINK billing?
Those make VRF cheaper, but the structural cost — gas for two on-chain transactions per draw — remains. For high-frequency off-chain consumers (think: a card game dealing thousands of hands an hour), an HTTP API at zero marginal cost is still the right shape.