> 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/start-here/win-power.md).

# WIN POWER

How $LOTRIO balances become draw weight, with clear examples and winner deductions.

WIN POWER, or **WP**, is the weight of a wallet in a draw. It is not a separate token and it is not something you buy directly.

```
raw WIN POWER  = floor($LOTRIO balance / 10,000)
live WIN POWER = max(raw WIN POWER - remaining winner deduction, 0)
```

## The simple rule

Every whole 10,000 `$LOTRIO` in a wallet creates 1 raw WP.

| `$LOTRIO` balance | Raw WP |
| ----------------: | -----: |
|            10,000 |      1 |
|            50,000 |      5 |
|           500,000 |     50 |
|         5,000,000 |    500 |

More WP means more weight, but never guarantees a prize.

## How odds work

Before a draw, imagine all WIN POWER as numbered positions in one long list. A wallet with 50 WP owns 50 positions; a wallet with 5 WP owns 5 positions.

For the first winner, a useful approximation is:

```
your chance = your WP / total WP of all eligible wallets
```

The contract then removes the first winner's weight and selects the second, then removes both previous winners and selects the third. This guarantees **three different wallets**.

{% hint style="info" %}
The exact probability of winning any of the three places depends on the WP held by the wallets selected before yours. The contract performs the selection without replacement.
{% endhint %}

## What changes your WP

| Action                     | Effect                                                       |
| -------------------------- | ------------------------------------------------------------ |
| Buy more `$LOTRIO`         | Raw WP increases from the new net balance                    |
| Sell `$LOTRIO`             | Raw WP decreases with the balance                            |
| Transfer to another wallet | Tokens and their proportional winner deduction move together |
| Win a prize                | Live WP is reduced by place                                  |
| Complete 24 prize draws    | 25% of each eligible winner deduction recovers               |
| Sell the full balance      | The remaining deduction on that sold balance is released     |
| Buy again later            | New net balance earns fresh raw WP                           |

{% hint style="info" %}
The Pons token cannot notify the lottery by itself, so WP changes are applied once the keeper relays the token's `Transfer` events. The relay cannot set balances — the lottery always rereads them from the token — and anyone can call `syncAccount(wallet)` to refresh a wallet. Pons system contracts, the team treasury wallet, the buyback burner, the lottery and the dead address never receive WP.
{% endhint %}

## Winner deductions

Winning does **not** burn or remove your `$LOTRIO` tokens. It reduces only the wallet's live WIN POWER.

| Place |       WP deduction |
| ----- | -----------------: |
| 1st   | 30% of snapshot WP |
| 2nd   | 20% of snapshot WP |
| 3rd   | 10% of snapshot WP |

Example: a wallet enters a draw with 50 WP and wins first place. A 15 WP deduction is recorded, so the wallet has 35 live WP while its token balance stays unchanged.

## Recovery

Every winner deduction has its own 96-draw recovery schedule. The contract returns 25% of that specific deduction after 24, 48, 72 and 96 subsequently completed prize draws. At the normal 15-minute cadence, the complete cycle is exactly one day.

| Completed draws after the win | Deduction remaining |
| ----------------------------: | ------------------: |
|                             0 |                100% |
|                            24 |                 75% |
|                            48 |                 50% |
|                            72 |                 25% |
|                            96 |                  0% |

For a wallet that wins first place with 100 snapshot WP, live WP moves through `70 → 77.5 → 85 → 92.5 → 100`. Second and third place start with smaller deductions, but use the same 96-draw recovery horizon.

Skipped windows and expired/reset draws do not advance recovery. A second win creates a separate schedule; it does not reset or accelerate an older one.

The lottery tracks fractional WP internally so small deductions and quarter recoveries affect odds instead of rounding to zero.

## Why moving tokens does not erase the deduction

A wallet-to-wallet transfer carries the same proportional share of the deduction with the tokens. Moving half of a winning balance moves half of its remaining deduction too.

The recovery dates move with that deduction. The keeper tracks recipient wallets and automatically applies each matured checkpoint; the recipient does not need to connect a wallet or press a claim button. The permissionless recovery function remains available as a fallback if keeper processing is temporarily delayed.

Trading behaves differently by design: selling releases the deduction in proportion to the share sold. Selling the full balance releases it completely, and a later taxed buy earns new WP from the new net balance.

{% content-ref url="/pages/i6f9W0i0drmpWnPARCn6" %}
[Prizes, claims & win deductions](/the-lottery/payouts-and-claims.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/start-here/win-power.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.
