> For the complete documentation index, see [llms.txt](https://docs.megalottery.fun/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.megalottery.fun/trust-and-verification/security-and-fairness.md).

# Fairness explained

## The problem the design must solve

A fair draw needs to prevent two different kinds of manipulation:

1. changing the participant weights after seeing randomness;
2. letting an operator invent or replace the random number.

MEGA addresses them with a **participant snapshot** and a **future blockhash**.

## Plain-language explanation

When the draw starts, the contract freezes a cryptographic summary of every eligible wallet and its WP. It also names a future Robinhood L2 block that does not exist yet.

After that block is mined, its blockhash becomes the random seed. Winners must then match both the seed and the previously saved participant snapshot.

```
Participant list fixed first
→ future block happens later
→ blockhash becomes seed
→ proofs must match the fixed list
```

The keeper can submit transactions and proofs, but it cannot rewrite any of those saved values.

## What is a Merkle-sum snapshot?

It is a single on-chain root that commits to:

* every eligible wallet;
* each wallet's exact WP;
* the total WP across all wallets.

Later, a compact proof can show that a winner and its weight belonged to that root. A changed wallet or weight produces a different root and fails verification.

## Why a future block?

At snapshot time, the committed future block has not been mined, so its hash is not known to the keeper, users or contract. After mining, Robinhood Chain exposes the L2 blockhash through `ArbSys`.

The contract derives three random words from:

* the committed blockhash;
* reveal block number;
* draw request identifier;
* winner position index.

## What the keeper can and cannot do

| Keeper can                              | Keeper cannot                                |
| --------------------------------------- | -------------------------------------------- |
| Send a transaction when a step is ready | Start a draw before contract conditions pass |
| Read public holder and WP data          | Change the committed snapshot                |
| Build Merkle-sum proofs                 | Supply its own random number                 |
| Submit the expected winners             | Make an invalid winner pass verification     |
| Pay gas for maintenance                 | Pay the same wallet twice in one draw        |

## What anyone can verify

For each completed draw, an independent observer can verify:

* the committed pot and draw number;
* the participant root, total WP and eligible wallet count;
* the future reveal block;
* the captured blockhash-derived randomness;
* all three winner proofs and snapshot weights;
* prize and buyback events.

## Limitations of the model

Future-blockhash randomness is transparent and fully on-chain, but it is weaker than a dedicated VRF oracle because a block producer may have limited influence over block production.

The keeper must capture the blockhash before Robinhood Chain's 256-block lookup window expires. If it misses that window, the expired draw can be reset and restarted; no winner is selected from a missing hash.

{% content-ref url="/pages/brwHMXgzuyveRAo7nCaP" %}
[Contract controls](/trust-and-verification/contract-controls.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.megalottery.fun/trust-and-verification/security-and-fairness.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.