Open Standard · v1.0 · CC-BY-4.0 · For Developers
Open Standard Random Winner Protocol — Verifiable Giveaway Protocol v1.0
CC-BY-4.0 spec on GitHub, reference implementation, npm verifier package. A drop-in, deterministic SHA-256 algorithm any developer can audit, fork, or re-implement.
Published 2026-01-15 · Updated 2026-06-11 · Maintained by Rafflecopter · github.com/rafflecopter/open-standard-random-winner-protocol
Reference output — what the verifier sees
Winner
@dev_alex.ts
Selected at 2026-06-11T09:14:22.000Z
SHA-256 seed_hex
9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
Entries hashed
12,481
Algorithm
SHA-256 → HMAC-DRBG → Fisher-Yates
Why SHA-256 is the only verifiable choice
For a winner protocol to be auditable from outside, the same inputs must always produce the same output and any tampering must be mathematically detectable. SHA-256 (FIPS 180-4) gives you collision resistance: there is no known way to construct two different canonical-JSON inputs that hash to the same seed. Feed that seed into HMAC-DRBG (NIST SP 800-90A) and you get a deterministic CSPRNG whose output is statistically indistinguishable from true random under the random oracle model.
That combination means a third-party auditor with canonical.json and a verifier can reproduce the published seed_hex and the winner list byte-for-byte — or detect that the host swapped one in.
What this protocol calls "a fair draw"
A fair draw under the Open Standard Random Winner Protocol means four properties are simultaneously satisfied:
- Determinism. One canonical JSON ⇒ one winner. No timestamps, no PRNG state, no environment leakage.
- Uniformity. Every entry has equal probability after exclusions are applied, guaranteed by Fisher-Yates over a CSPRNG-shuffled list.
- Public auditability. The seed_hex and canonical JSON are published. Anyone can re-run the algorithm.
- Tamper evidence. Mutating one byte of the comment list, the timestamp, or the exclusion list yields a different seed_hex — verification fails immediately.
Developer hooks: spec, reference impl, npm verifier
1. The spec (CC-BY-4.0, GitHub-hosted)
Plain-Markdown specification at github.com/rafflecopter/open-standard-random-winner-protocol. Fork, file issues, propose RFCs. The license lets you build commercial products on top of it without asking us.
2. Reference implementation (TypeScript)
Drop-in TypeScript reference that mirrors the spec section by section. Used in production by Rafflecopter and intentionally kept readable over clever.
import { drawWinners } from "@rafflecopter/oswrp";
const result = drawWinners({
post_url: "https://www.instagram.com/p/<shortcode>/",
comments: [...],
timestamp: new Date().toISOString(),
winner_count: 1,
exclusions: [],
});
// → { seed_hex, winners, canonical_json }3. npm verifier package
Zero-dep audit package any platform can ship alongside their own draw tool. Re-derives the seed_hex from a canonical JSON and returns a structured pass/fail.
import { verify } from "@rafflecopter/oswrp-verifier";
const out = verify(canonicalJson, claimedWinner);
if (!out.verified) {
console.error("Tampered draw. Expected:", out.expected);
}How to wire it into your own platform
If you run a giveaway tool, sweepstakes platform, or community bot, you can become a compliant implementation in under an hour:
- Build your
canonical_jsonexactly as the spec defines (sorted lowercased usernames, ISO-8601 UTC timestamp). - Hash with SHA-256, seed HMAC-DRBG, shuffle with Fisher-Yates, apply exclusions, take the first N.
- Publish
seed_hex+canonical_jsonon every result page. Expose/api/verify/{seed_hex}. - Submit a PR to the registry at /registry/compliant-tools.
FAQ
What is the Open Standard Random Winner Protocol?
It is an open, CC-BY-4.0 licensed specification that defines a deterministic SHA-256-based algorithm for selecting random giveaway winners. Any developer can re-run the algorithm from the published canonical JSON and prove the announced winner is the only winner the protocol could have produced.
Why SHA-256 instead of Math.random or a server-side RNG?
Math.randomand most server-side RNGs are non-deterministic from the verifier's perspective: an auditor has no way to reproduce the result. SHA-256 fed into HMAC-DRBG (NIST SP 800-90A) is deterministic for a given input and collision-resistant, so the same canonical JSON always produces the same winner and any tampering changes the hash.
How do I install the npm verifier package?
Run npm i @rafflecopter/oswrp-verifier. Import verify(canonicalJson, claimedWinner) and it returns { verified: true, seedHex } or { verified: false, expected }. The package has zero runtime dependencies beyond Node's built-in crypto module.
What defines a fair draw under this protocol?
A draw is fair when (a) the comment list is sorted lowercased alphabetically before hashing, (b) the SHA-256 seed is derived from the canonical JSON of all inputs, (c) Fisher-Yates shuffles using HMAC-DRBG, and (d) the seed_hex and canonical JSON are published. Any third party can re-derive the winner and detect tampering.
Can I implement this in Go, Rust, or Python instead of Node?
Yes. The protocol is implementation-agnostic. As long as your implementation produces the same canonical JSON serialization, uses SHA-256 (FIPS 180-4) and HMAC-DRBG with SHA-256 (NIST SP 800-90A), and applies Fisher-Yates in the documented order, the output will match the reference implementation byte-for-byte. We track compliant implementations in the public registry.
Ship verifiable draws today
Open spec. MIT-licensed reference impl. Zero-dep npm verifier. Already implemented in production by Rafflecopter and the compliant tools registry.
Trusted by indie devs, sweepstakes platforms, and community managers running audited draws since 2026.