Verifiable Randomness Documentation

Verifiable Randomness Systems

View the Project on GitHub blockrand-api/blockrand-js

Multi-Winner Draws With Deterministic Ordering

The Hidden Problem

Most systems focus on selecting the correct winners.
Very few systems consider: The order in which winners are produced.

This seems harmless, but in real systems the order often determines:

If the ordering is not deterministic and auditable, the system can still be manipulated even if the winners are technically correct.

Example: Lottery With Tiered Rewards

Suppose we select 5 winners.

Rewards:

If the system only proves the winner set:

[A, B, C, D, E]

But not the deterministic order, an operator could reorder:

[E, B, C, D, A]

This silently changes who receives the grand prize.

Why “Set Equality” Is Not Enough

Many implementations verify only:

“Are these the correct 5 winners?”

But fairness requires:

“Were these winners produced in the only possible deterministic order?”

Without ordering guarantees:

Where Ordering Impacts Real Systems

Casinos

NFT & Token Launches

Tournaments

Raffles & Giveaways

Correct Design Principle

A fair multi-winner system must produce:

  1. A deterministic shuffled order
  2. Winners derived from that order
  3. Prize assignment based strictly on position

Nothing should be manually rearranged after generation.

Deterministic Ordering Mechanism

The standard approach:

  1. Start with a canonical list of participants
  2. Apply a deterministic Fisher–Yates shuffle
  3. Produce the full ordered sequence
  4. Assign rewards by index

Example final order:

[User42, User7, User91, User3, User55]

Position defines reward.

Why the Full Order Must Be Public

Publishing only the first winner is insufficient.

Full ordering allows:

In high-value systems, auditors often require:

The entire shuffled list.

Attack Scenario Without Deterministic Ordering

  1. System generates winners
  2. Internal operator views list
  3. Reorders before publishing
  4. Claims fairness

Because the winner set is unchanged, manipulation is difficult to prove.

This is a post-hoc manipulation attack.

Deterministic Replay Requirement

Anyone should be able to:

  1. Recompute entropy inputs
  2. Reproduce shuffle decisions
  3. Recreate identical ordering

If two independent implementations produce the same order:

The result is verifiably fair.

Common Implementation Mistakes

Sorting After Selection

Developers sometimes:

This destroys the original random ordering.

Mixing Business Logic Into RNG Phase

Examples:

Filtering must occur before randomness generation, not after.

Using Non-Deterministic Data Structures

Maps or sets with undefined iteration order cause:

Always use canonical, sorted input lists.

Minimal Audit Trail

A verifiable multi-winner draw should publish:

With these, any third party can reproduce the draw.

Why This Matters

Most public fairness controversies are not about:

“How winners were chosen”

They are about:

“Why did this specific person get the top reward?”

Deterministic ordering eliminates this ambiguity.

Key Takeaway

Fairness is not only about selecting the right winners.
It is about producing a single, immutable, reproducible ordering.

In provably fair systems: