Technical Trust · NIST FIPS 180-4 · Auditable
SHA-256 Verified Giveaway — Cryptographic Proof of Fair Draw
NIST FIPS 180-4 hash function applied to giveaway fairness — the same math that secures Bitcoin. Every winner ships with a 64-character SHA-256 receipt anyone can re-compute in 3 seconds.
Result page · what participants see
@maria_costa
Comment #847 of 4,231 · drawn from instagram.com/p/Cx9abc
SHA-256 receipt
VERIFIED7a3f9d8c4e1b2a6f5d8e9c7b3a1f4d6e8c2b9a7d3e5f1c8b4a6d9e2f7c3b5a1dRe-hash the canonical input to confirm. Re-verify at /api/verify/7a3f9d8c...
Why SHA-256 is the right primitive for a giveaway
A giveaway draw is, mathematically, a one-shot commitment problem: the host needs to convince an audience that the winner was chosen from a fixed input set, without privileged re-rolls. SHA-256 solves this in one line — the hash of the input set commits the host to exactly one possible winner, before anyone sees it.
- Collision resistance: no two different inputs are known to produce the same SHA-256 hash. NIST FIPS 180-4 security level: 128 bits.
- Pre-image resistance: given a hash, you cannot construct an input that produces it. Brute-force cost: ~2^256 operations.
- Avalanche property: a single comma in the input changes roughly half the bits in the output. Tampering is detectable instantly.
- Standardized & ubiquitous: available in every browser (SubtleCrypto), every language stdlib, every blockchain. No proprietary dependency.
What makes a draw "fair" in mathematical terms
Fairness in random selection is not a vibe — it is a measurable property. A draw is fair when it satisfies three conditions simultaneously: uniform distribution (every entry has probability 1/N of winning), determinism (same input always produces same output, so the host cannot re-roll), and public verifiability(anyone, including a participant with no access to the host's server, can recompute the result).
Plain JavaScript Math.random() fails verifiability — it uses entropy nobody else can observe. A blockchain VRF satisfies verifiability but adds cost and latency. SHA-256 over canonical input satisfies all three at zero cost: the entropy is the comment list itself, which is already public.
How the receipt is generated (3 steps)
1. Canonicalize the inputs
Collect the comment list, lowercase each username, sort alphabetically, attach the post URL, the UTC timestamp, and any exclusions. Serialize as deterministic JSON (sorted keys, no whitespace).
2. Hash with SHA-256
Feed the canonical JSON into SHA-256. The output is a 64-character hex string — the receipt. This single value is the host's binding commitment. The hash is then used as the seed of an HMAC-DRBG (NIST SP 800-90A) for the actual Fisher-Yates shuffle.
receipt = sha256(canonical_json(input)) // e.g. "7a3f9d8c4e1b2a6f5d8e9c7b3a1f4d6e..."
3. Publish receipt + canonical input
The result page shows both the receipt and the input it was computed from. Any third party can SHA-256 the input themselves and confirm the receipt matches — or fail loudly if it doesn't.
What the SHA-256 receipt actually proves
The receipt does not prove the host ran the draw at the claimed time — that requires an external timestamp authority (OpenTimestamps, Bitcoin block anchoring) and we expose that optionally. What the receipt does prove, unconditionally, is:
- The published winner is the only winner derivable from the published input set under the published algorithm.
- If the host privately swapped a different winner in after the draw, the receipt would no longer match — and any participant can detect it by running 1 hash.
- The input set was fixed before the receipt was published. Otherwise the host would have had to find a second-preimage of SHA-256, which is computationally infeasible.
FAQ
What does "SHA-256 verified giveaway" actually mean?
It means the winner is bound to a 256-bit cryptographic hash computed over the full input set (post URL, comment list, timestamp, exclusions). Anyone can re-hash the same inputs and confirm the hash matches the one published with the winner. If a single comment or timestamp changes, the hash changes, and the proof breaks.
Why use SHA-256 specifically instead of a simpler random number generator?
SHA-256 is standardized in NIST FIPS 180-4 and is considered collision-resistant under standard cryptographic assumptions. It is the same hash function used in Bitcoin block headers, TLS certificates, and Git commit IDs. A regular RNG (Math.random, /dev/urandom) gives no public proof — the host could re-roll until a friend wins. SHA-256 binds the output to the input, so re-rolling is detectable.
Can the host fake the SHA-256 hash to pick a friend?
No. To make a chosen friend win, the host would need to find an input set that (a) contains the friend's username and (b) produces a SHA-256 hash that maps to that friend after the deterministic shuffle. That is a second-preimage attack on SHA-256, which is computationally infeasible — equivalent to brute-forcing 2^256 possibilities. The math is the same that protects Bitcoin from double-spending.
How does an audience member verify the draw on their own?
Open the result page, click the SHA-256 hash badge, and you get the canonical JSON of the input set. Paste it into any SHA-256 calculator (or run sha256sum locally). If your computed hash equals the published hash, the draw is verified. We also expose a public endpoint at /api/verify/{hash} that does it automatically.
Is the SHA-256 hash the same as a blockchain transaction?
It uses the same hash primitive but does not require a blockchain. The hash is published on the result page (and indexable by search engines, archived by Wayback Machine, screenshotable by participants), which is sufficient for audit. We optionally anchor the hash to OpenTimestamps so it inherits Bitcoin-level temporal proof, but the core verification works without any chain.
Trusted by 12,400+ technical hosts
Run your next giveaway with a SHA-256 receipt
Free, no signup, no card. Implements the open Verifiable Giveaway Protocol v1.0 (CC-BY-4.0). Open source reference implementation on GitHub.