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

# Safety

## What the operator cannot do

The short version: **no function lets the owner take user money.** Not the bankroll, not player credits, not the jackpot, not the Golden Chest fund.

|                                         |                                                                                                |
| --------------------------------------- | ---------------------------------------------------------------------------------------------- |
| 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 Golden Chest fund   | **No such function.** Each only exits 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 outside 80–97%                  | `setTable` recomputes RTP and reverts                                                          |
| Raise jackpot odds above 0.20%          | Contract constant                                                                              |
| Raise the protocol fee above 5%         | Contract constant                                                                              |
| Pause withdrawals, settlement or claims | No pause reaches them — pause stops new spins only                                             |

## What the operator *can* do

The remaining trust, honestly:

* **Set fees and the prize table**, within the hard caps, when no spin is in flight (the table also requires empty racks). A live spin always settles under the table it was bought under.
* **Restock racks.** The restocker supplies swap slippage (`minOut`), so a compromised restocker key could grief the vault through bad fills. Racks are kept shallow to bound this.
* **Pause new spins.** Settlement, cancellations, claims and LP withdrawals are never pausable.
* **Point the DEX router elsewhere.** The sharpest remaining edge: `setDex` combined with a restock could route vault USDG into a worthless pool. It's why ownership belongs on a multisig.

## Randomness

The **VRF** an on-chain commit–reveal hash chain, paid in ETH. The provider commits to its chain in advance and reveals in sequence, so the value a spin uses is fixed before the spin is bought and can't be picked to steer a result.

It's a **two-transaction** process. Your spin is recorded pending; the outcome is decided later by a callback (`onRandomness`). There's no transaction where anyone sees the result and reacts — operator, validator and player all learn it at the same moment.

The provider can be swapped by the owner, but **not while a spin is in flight** (`setRandomness` reverts `InFlight`).

If randomness never arrives, `cancelSpin(spinId)` refunds the **full pack price** after the rescue delay (48 h by default; 6 h floor, 7-day cap). It's 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 is paid in USDG instead and that money was **reserved before the spin was accepted**. If the vault couldn't cover the worst case, the spin never started.

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

That reservation releases at settlement and can't be drawn against by anything else in the meantime.

Payouts are pull-based: cards transfer with no receiver hooks and USDG books as a claimable credit, so nothing a winner does can brick the settlement callback.

## Known limitations

**Instant sell-back is a market sale.** `sellBack` burns the certificate, sells the stock on the DEX and pays the proceeds less a small spread. No frozen price, so no stale-mark risk to the vault. Split cards are refused.

**Splitting is permanent and voids the face.** A split card keeps its shares and its unwrap right but can never be sold back or consigned. The UI warns, the contract enforces (`CardSplit`).

**The jackpot and Golden Chest are irreversible.** Money routed into either fund has no withdrawal path, by design. It leaves only to a winner.

**Thin prize-stock liquidity.** Tokenized equities aren't deeply liquid. A large restock in a shallow pool moves the price against the vault. Fee tiers are chosen per pair from measured depth, and restocks are kept small.

**The bankroll is not riskless.** LPs take the other side of the game. Positive in expectation, but a top-tier run on a small bankroll is a real drawdown, and racked inventory carries equity price risk realized on rotation.

## Reporting something

Found a bug? Please don't open a public issue. Contact the team directly so it can be fixed before it's exploited.


---

# 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.takara.gg/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.
