> 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/the-lottery/how-it-works.md).

# How a draw works

## First: what happens when the timer ends?

The user does nothing. A keeper service watches the contract and sends the required maintenance transactions. The contract accepts a step only when its own timing and state checks pass.

```
Timer is due
→ check pot and eligible wallets
→ snapshot WIN POWER
→ commit a future block
→ read that future blockhash
→ verify three different winners
→ pay ETH and run buyback & burn
```

## Conditions for a real draw

All three conditions must be true:

1. The default 15-minute interval is due.
2. The available lottery treasury is at least **0.05 ETH**.
3. At least **three different wallets** have 1 or more live WP.

If the timer is due but the pot or participant count is too low, that window is skipped and the timer starts a new interval. No partial draw occurs.

## Step 1 — Snapshot and commit

The contract saves:

* the ETH pot used for this draw;
* the total WIN POWER;
* the number of eligible wallets;
* a Merkle-sum root committing to every eligible wallet and its WP;
* a future Robinhood L2 block number.

This is the cutoff. Trading remains open, but balance changes after the snapshot count only toward a later draw.

{% hint style="success" %}
The participant snapshot is fixed **before** the future randomness block exists. Nobody can wait to see the random value and then add WP to that draw.
{% endhint %}

## Step 2 — Capture future-block randomness

After the committed future block is mined, its blockhash becomes available on-chain. The contract reads it through Robinhood Chain's `ArbSys` system contract and derives three random words.

The keeper does not provide the random number. It only asks the contract to read the already committed blockhash.

## Step 3 — Verify three winners

The keeper submits the wallet and Merkle-sum proof for each expected winner. The contract independently checks:

* the wallet existed in the committed snapshot;
* its submitted WP is correct;
* the random position falls inside that wallet's WP range;
* the same wallet is not used twice.

If any check fails, settlement reverts and nobody is paid from an invalid result.

## Step 4 — Pay and finalize

The committed pot is divided as follows:

| Destination      | Pot share |
| ---------------- | --------: |
| 1st-place wallet |       50% |
| 2nd-place wallet |       30% |
| 3rd-place wallet |       15% |
| Buyback and burn |        5% |

ETH is normally sent directly to each winner. A failed direct payment is reserved for that wallet and can later be withdrawn through `claim()`.

The buyback is best-effort: if the Uniswap swap cannot execute, winner payments still complete and the unused ETH remains in the treasury for a future pot.

## What the keeper actually does

The keeper is an operator-run bot that:

* notices when a draw step is ready;
* sends the public maintenance transaction;
* builds winner proofs from on-chain data;
* pays its own transaction gas.

It cannot change the pot, snapshot, blockhash or winner checks. Users do not need to run the keeper or send draw transactions themselves.

{% content-ref url="/pages/oI0eLaRUyN5LnpFPBMxb" %}
[Fairness explained](/trust-and-verification/security-and-fairness.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/the-lottery/how-it-works.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.