> For the complete documentation index, see [llms.txt](https://docs.lotrio.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lotrio.app/the-lottery/how-it-works.md).

# How a draw works

A plain-language walkthrough from fees filling the pot to three paid winners.

## Before a draw — how the pot grows

`$LOTRIO` trades on the Pons V2 launchpad. Every buy and sell pays 2%: a 1% Pons trading fee plus a 1% creator tax. Pons keeps 0.3% of the trade value and pays the remaining 1.7% — the creator fees — to the team's treasury wallet.

Every 15 minutes, right before the draw, the keeper:

1. totals the creator fees accrued since the last draw — those Pons has already credited to the treasury, plus pool fees Pons has not swept yet, valued at each trade's price;
2. sends **80%** of that amount from the treasury wallet into the lottery contract (1.36% of the trade value);
3. leaves the other **20%** with the team for marketing and operations (0.34% of the trade value).

```
Trade on Pons pays 2%
├─ 0.3%  Pons protocol
└─ 1.7%  creator fees → team treasury wallet
           every 15 minutes, right before the draw
           ├─ 80%  → lottery contract (TreasuryFunded event)
           └─ 20%  → stays with the team (marketing / operations)
```

The pot on the website grows live as people trade and freezes at each draw. After graduation, Pons sweeps pool fees to the treasury at most once per hour, so the keeper pre-funds the pot from the treasury and reconciles against the real swept amounts every hour.

{% hint style="warning" %}
The 80% transfer is sent by the team's keeper from the team wallet. It is an operational commitment, not a rule enforced by a contract — but every deposit is public: it appears as a `TreasuryFunded` event on the lottery contract from the published treasury address. See [Fees, prize pool & burn](/the-lottery/tokenomics.md#how-to-verify-the-deposits).
{% endhint %}

## 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
→ keeper moves the 80% share into the lottery
→ check pot and eligible wallets
→ snapshot WIN POWER
→ commit a future block
→ read that future blockhash
→ verify three different winners
→ pay ETH to three winners
→ send 5% to buyback & burn
```

## Conditions for a real draw

All three conditions must be true:

1. The 15-minute interval is due.
2. The pot 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 round is skipped and a new 15-minute interval starts. No partial draw occurs. The skipped amount is not lost: the 80% share keeps accumulating and is added to the next round's pot.

## 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 5% goes to the separate buyback burner contract. The keeper later calls its `buyAndBurn` with a minimum output, which buys `$LOTRIO` on Pons and sends every token to the dead address. If the lottery cannot send the 5% to the burner, winner payments still complete and that ETH rolls into the next pot (`BuybackDeferred`). If the keeper has not burned for 7 days, anyone can trigger the burn.

Each winner deduction also receives four immutable recovery checkpoints at draw `+24`, `+48`, `+72` and `+96`. At the normal 15-minute cadence, the full cycle is exactly one day. Due checkpoints are applied before another participant snapshot can be committed. Skipped and reset draws do not count.

## What the keeper actually does

The keeper is a team-run bot that:

* totals the creator fees and moves the 80% lottery share from the treasury into the lottery before each draw;
* notices when a draw step is ready and sends the public maintenance transaction;
* builds winner proofs from on-chain data;
* relays `$LOTRIO` `Transfer` events to the lottery, because the Pons token has no hooks of its own;
* calls the buyback burner's `buyAndBurn` with slippage protection;
* advances bounded WIN POWER recovery checkpoints;
* pays its own transaction gas.

Inside the lottery it cannot change the pot, snapshot, blockhash or winner checks, and it cannot withdraw anything. The transfer relay cannot set balances either: the lottery always rereads each wallet's `$LOTRIO` balance from the token. 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.lotrio.app/the-lottery/how-it-works.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.