> 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/trust-and-verification/security-and-fairness.md).

# Fairness explained

Why the keeper cannot choose winners, how the future-block snapshot can be verified, and what is trusted to the team.

## 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.

The lottery contract addresses them with a **participant snapshot** and a **future blockhash**.

Funding the pot is separate from selecting winners. Once ETH is inside the lottery contract, nobody — not the team, not the keeper — can withdraw it, change the odds, the payouts or the 15-minute interval. How the ETH gets *into* the lottery is a different question, answered under [What you trust the team with](#what-you-trust-the-team-with).

## 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     |
| Move the 80% fee share from the treasury into the lottery | Withdraw ETH from the lottery                |
| Pay gas for maintenance                                   | Pay the same wallet twice in one draw        |

## What you trust the team with

Pons pays all creator fees (≈1.7% of trading volume) to the team's treasury wallet. The 80% lottery share is then moved by the team's keeper from that wallet into the lottery before each draw. Unlike a fee-splitting contract, this transfer is **an operational commitment, not a rule enforced by code**: if the team stopped sending it, the lottery contract could not force it.

What keeps the commitment honest is that it is fully visible:

* every deposit is a `TreasuryFunded` event on the lottery contract, sent from the published treasury address;
* the creator fees the treasury earns are visible as Pons fee-escrow credits to that address;
* the website shows the live pot, which grows with trading and freezes at each draw.

What the team **cannot** do, whatever happens to the treasury: withdraw the pot, change the odds or payouts, change the 15-minute interval, pick winners, or give the treasury wallet WIN POWER (it is permanently excluded).

## What anyone can verify

For each completed draw, an independent observer can verify:

* every `TreasuryFunded` deposit and the address it came from;
* 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 payment and buyback transfer events;
* every burn sent to the dead address;
* every relayed token transfer and WIN POWER change.

## 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.

Pot funding depends on the team's keeper and treasury wallet. After graduation, Pons sweeps pool fees at most once per hour; the keeper pre-funds the pot from the treasury using a trade-time estimate and reconciles hourly, so a single round can be slightly above or below the exact 80% until the next sweep is accounted for.

The 5% buyback is a market purchase and can be targeted by sandwich attacks. The keeper sets a minimum output when it calls `buyAndBurn`. If the keeper has not burned for 7 days, anyone can call it and choose their own minimum, so that fallback purchase may get worse execution.

The Pons token has no hooks, so the lottery learns about balance changes from the keeper's transfer relay. The relay cannot set balances or WIN POWER — the lottery rereads every balance from the token — and anyone can call `syncAccount(wallet)` to refresh a wallet. The snapshot still uses WIN POWER as recorded in the lottery at commit time.

Trading, liquidity and fee delivery run on Pons V2 contracts that the project does not control. Pons' own documentation describes Pons V2 as unaudited, and the lottery and buyback burner contracts have not had an independent third-party audit.

{% 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 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/trust-and-verification/security-and-fairness.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.