> 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/how-it-works.md).

# How it works

## The rack model

Cards sit on **racks** where one rack per (pack size, tier). A spin draws a tier, then draws a card from that tier's rack, and that specific card transfers to you.

This matters more than it sounds. The card you win **already existed** before you spun. It was bought on the market, escrowed, and put on a shelf. The machine cannot mint a prize on demand, so it can never owe you something it does not have.

## A spin, step by step

{% stepper %}
{% step %}

### You pay

You send ETH to the `ZapRouter`. It wraps to WETH, swaps exactly the pack price into USDG on Uniswap V3, and refunds every leftover WEI of ETH in the same transaction.

The router then calls `spin()` on the Machine. USDGis the settlement unit everywhere downstream but you never have to hold it.
{% endstep %}

{% step %}

### The vault reserves

Before the spin is accepted, the Machine reserves the pack's **worst-case payout** against the bankroll vault:

```
reserved = pack price × maxFaceBps   →   $10 × 8.88 = $88.80 on the $10 pack
```

`maxFaceBps` is the top non-jackpot face on the table (the legendary, 8.88×). If the vault does not have that much unreserved, the spin **reverts here** before you have a pending bet. This is what makes solvency physical rather than promised.
{% endstep %}

{% step %}

### Randomness is requested

The Machine asks the **VRF** for one word, forwarding the provider's per-request fee (currently zero). This is a two-transaction process: your spin is recorded as `Pending`, and the outcome is decided later by the reveal callback.

The house VRF is an on-chain commit–reveal hash chain (`CommitRevealAdapter`). The operator committed the tip of the chain **before any spin existed**, and each request also pins a per-request seed at request time. Nobody — not you, not the operator — knows the result at this point, because it does not exist yet. The operator can delay a reveal but can never choose the outcome.
{% endstep %}

{% step %}

### The reveal settles it

The operator publishes the next preimage. The chain checks `keccak256(preimage)` against the stored commitment, then walks one link down. The Machine takes the delivered `word` and:

* Takes `word % 10000` and walks the cumulative probability table to pick a **tier**
* Takes `keccak256(word) % rack.length` to pick a **card** from that tier's rack
* Pops that card off the rack and transfers the NFT to you

The two draws use different hash lanes, so the card pick is independent of the tier pick. Reveals are strictly FIFO; if a settlement callback ever reverts, its word is parked and anyone can redeliver it — the outcome is already fixed.
{% endstep %}

{% step %}

### Fees split, the vault settles

The pack price is divided (see [Fees](broken://pages/fe6f8324592ef11bfb2bb32d61470cdc881c3172)), the reservation is released, and the house's share flows into the vault.
{% endstep %}
{% endstepper %}

## What happens if the rack is empty

If a tier's rack ran dry between your request and its reveal, you are paid that tier's **face value in USDG** instead of a card.

This is not a failure mode bolted on, it is why the reservation exists. The money was set aside in step 2, so the fallback can always pay. You get the same value, in cash rather than shares.

## What happens if the reveal never comes

Every spin is refundable in full after `rescueDelay` (**2 days**). Anyone can call `cancelSpin(spinId)` it does not have to be you, and it does not require the operator. Fees are only taken at settlement, so a cancelled spin refunds the entire pack price as claimable credit.

## What a card actually is

An ERC-721 certificate holding real tokenized shares in escrow. You can hold it, unwrap it for the raw stock, instant-sell it back to the house, consign it to a rack to earn, Drop it to a friend, or trade it anywhere.

See [**Cards**](broken://pages/4ac477c23d748504453666a613bbac7308f42409) for the full detail.

## The safety properties, in order of importance

**Two-transaction randomness.** The outcome binds to a randomness request that already exists. There is no single transaction in which someone could see and react to the result.

**Solvency is physical.** A drawn card must already be on the rack. If it is not, the reserved USDG pays instead.

**Settlement can never be bricked.** Card transfers use a raw transfer with no receiver hook, and USDG winnings are booked as claimable credit rather than pushed. Nothing a winner does — including being a contract that reverts can stop the reveal callback from completing.

**The table freezes mid-flight.** Odds, fees and the randomness provider cannot be changed while any spin is pending. Changing the prize table additionally requires every rack to be empty, so a card can never be stranded under a tier that no longer exists.

**Pause stops new spins only.** Settlement, cancellations and claims can never be paused. If the operator pauses the machine, in-flight spins still settle and your credits are still claimable.

**Admin cannot reach the money.** There is no function — none — that lets the owner withdraw from the bankroll vault, take player credits, or touch the jackpot or chest funds.


---

# 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/how-it-works.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.