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

# Safety

### What the operator cannot do

The short version: **there is no function that lets the owner take user money.** Not the bankroll, not player credits, not the jackpot, not the egg fund.

This is worth stating precisely because "the team can rug" is the default and correct assumption about a project like this. Here is what stops it.

|                                  |                                                                                                |
| -------------------------------- | ---------------------------------------------------------------------------------------------- |
| Withdraw from the bankroll vault | **No such function.** `draw()` is `onlyMachine` and only ever buys inventory or pays a buyback |
| Take player credits              | **No such function.** `claim()` sends to the caller                                            |
| Take the jackpot or egg fund     | **No such function.** They only exit to a winner                                               |
| Block a card redemption          | **No such function.** `unwrap` checks ownership and nothing else                               |
| Change odds mid-spin             | Reverts while any spin is in flight                                                            |
| Set RTP below 80%                | `setTable` recomputes RTP and reverts outside 80–97%                                           |
| Raise jackpot odds above 0.20%   | Contract constant                                                                              |
| Raise the protocol fee above 5%  | Contract constant                                                                              |

### What the operator *can* do

Being honest about the remaining trust:

* **Set fees and the prize table**, within the hard caps, when no spin is in flight. A live spin always settles under the table it was bought under.
* **Restock racks.** The restocker sets swap slippage, so a compromised restocker key could grief the vault through bad fills. Racks are kept shallow to bound this.
* **Pause new spins.** Settlement, cancellations and claims are never pausable.

### Randomness

Chainlink VRF v2.5, paid in native BNB.

Randomness is a **two-transaction** process. Your spin is recorded as pending, and the outcome is decided later by a callback from the coordinator. There is no transaction in which anyone can see the result and react the operator, a validator and you all learn it at the same moment.

The provider can be swapped by the owner, but **not while a spin is in flight**.

If Chainlink never fulfils, `cancelSpin(spinId)` refunds the full pack price after 2 days. It is permissionless — anyone can call it for anyone.

### Solvency

Solvency is physical, not promised.

A drawn card must already be sitting on the rack. If the rack ran dry between request and fulfilment, the tier's face value is paid in USDT instead  and that money was **reserved before the spin was accepted**. If the vault could not cover the worst case, the spin never started.

```
reserved per in-flight spin = pack price × maxFaceBps
```

That reservation is released at settlement and cannot be drawn against by anything else in the meantime.


---

# 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.stoxa.app/controls-and-safety/safety.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.