> For the complete documentation index, see [llms.txt](https://reverie.gitbook.io/wall-usdstreet-on-rh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://reverie.gitbook.io/wall-usdstreet-on-rh/investors/the-rails.md).
# The two rails
$STREET, share claims, and exactly what has to be true before either rail is armed.
Two rails, separate on purpose. One moves value **in**; the other moves it **out**. **Neither is armed.**
> **The honest sentence, and the only one marketing may use:** play earns claims, and a licensed partner settles the eligible ones. The line it may not use is anything that names a stock, a yield, a return or an amount.
## What the game is not
The game server is **not the brokerage**. It emits and records claims. A licensed venue settles them, owns KYC, and is the only party that ever touches a real security. Nothing in the codebase custodies an asset. The game never asks for a seed phrase or a private key — wallet interaction is a signature over a login string and nothing else.
## Rail 1 — cash → $STREET
**The chain moved to Solana.** $STREET is an **SPL token on Solana** (mainnet-beta) and **Phantom** is both the wallet and the identity: signing in is a signature over a login string, never a seed phrase or a key. The earlier Robinhood Chain / MetaMask path is removed rather than deprecated — the client resolves one family, Solana, with `off` (credits only) as the only other state.
**Status: the mint does not exist.** No contract address is configured, the mainnet flag is `0`, and an unconfigured mint resolves to credits-only. The treasury key is a Worker secret rather than a file in the tree, and recording the mint, funding the treasury and arming mainnet are separate operator steps — none of them taken.
* Chain family, chain id and the live flag are reported truthfully by the health endpoints, read from the real configuration rather than a constant.
* Mainnet is refused unless the owner explicitly sets the live flag. A mainnet chain id with the flag off reports *"mainnet chain id set but the live flag is off — settlement stays sim"* and stays in sim.
* The pool is player-funded. Withdrawals pay only while the pool can cover them; otherwise the honest answer is shown — *check back later*. No queue, no promise, no partial fill that leaves somebody holding a claim on an empty pool.
**Before the owner arms it:** a treasury key held outside the repository with a signing path that never puts it in a Worker environment variable; a funded pool with a published reserve and the *check back later* path exercised on testnet; and counsel on the jurisdiction the pool operates from.
## Rail 2 — play → SHARE CLAIM → tokenized stock
**Status: built, and settling only in cash.** There are two fulfillment paths and neither delivers a stock today:
* **On-chain (the DEX path).** Built against the old chain and switched off in the deployed build; a Solana wallet is refused before a swap is attempted, because pools for those names do not exist on Solana yet.
* **Partner (the API path).** Manual CSV fulfillment is the fallback; the partner adapter carries idempotency keys and a circuit breaker and stays a stub until venue credentials exist.
Until one of them can fill, the product's own sentence is the shorter one: play earns claims, and a claim becomes cash at a published rate.
```
play → validated outcome → claim points → hold → eligibility
→ batch → partner settles → tokenized stock in the player's own account
```
### Where a claim comes from
Only from a validated outcome the server computed, never from anything a client said.
| Source | Points / $100 |
| --------------------------------------------------- | ------------- |
| Realised P\&L on a closed position | 10 |
| A corner that settled | 12 |
| A call-out on the kerb (THE CURB) | 12 |
| A pit round's pot | 14 |
| Placing at the bell | 16 |
| Placing on the **open** ladder, which has no buy-in | 20 |
| An act of the campaign, once each | 25 |
Six of the seven are zero-sum: a counterparty was on the other side, or the corner's cut came out of fee flow a venue already took. **The campaign act is the single faucet in the product and is documented as one** — permitted only because an act completes once and there is a fixed, small number of them, so the lifetime total per account is bounded before a broker starts. It cannot be farmed, only finished. House money — the pit's locals, the kerb's house man — never earns a claim at all.
The idempotency key is built from the thing that happened — `fill:SYMBOL:tick:seq` — so the same outcome cannot earn twice however it is replayed.
### The gates, in order
1. **Quarantine.** A flagged account plays normally and earns nothing.
2. **The daily cap.** 400 points per account per day, however good somebody is — the cap is what makes the budget bind at the account level rather than only at the pool level.
3. **The budget.** Pre-funded from reserve and reserved atomically in D1, so two zones cannot both accrue the last points. When it is gone, accrual stops. It does not borrow.
4. **The hold.** 24 hours before a claim can be claimed — long enough to unwind a bad day's abuse before anything leaves.
5. **Eligibility.** Answered by the venue, cached for an hour, never assumed.
6. **Expiry.** 30 days, so a claimable claim nobody claims goes stale rather than sitting as an open-ended liability.
### The state machine
Forward-only. `EARNED → HELD → RESERVED → SUBMITTED → SETTLED`, with `REFUNDED` and `EXPIRED` terminal. Nothing walks back.
### Fulfillment
**Manual fulfillment** — a CSV batch out, a signed result in — is the default, the fallback, and what ships. The **partner adapter** carries idempotency keys and a circuit breaker that trips after three failures, and does not pretend to work.
### Nothing strands
A claim below the minimum settlement size, or one the venue will not take, converts to in-game cash at a fixed published rate shown on the button before it is pressed. A build where a claim can strand took something and gave nothing back.
**Before the owner arms it:** a signed agreement with a licensed venue and their KYC flow in front of eligibility; the batch export and signed-result ingest running end to end on testnet including a rejected batch; the reserve funded and its burn-down modelled at the real population; and counsel on what the claim is, in the jurisdiction it settles in.
## THE REAL BOARD — and the state it is actually in
A deliberate two-state design, and **the deployed configuration is now in the second state**:
* **No allowlist published — the street's board.** It lists the floor's invented names, which are not securities, so it asks for no wallet and no identity check and nothing leaves the game. A settled claim carries its ticker, receipt, share count and basis, marks live on the desk, and sells back for cash at the mark.
* **An allowlist published — the venue board.** `SETTLEMENT_ALLOWLIST` currently reads **`AAPL,MSFT,NVDA`**, which puts the desk in venue mode: eligibility is the venue's answer (a linked wallet, the identity check, the jurisdiction), a stale answer is a refusal, and settlement targets a real tokenized equity.
### What a settlement actually is, today: cash
**No claim can currently settle into a stock**, and that is worth stating first because it is the difference between what the rail is designed to do and what it does.
The stock path was a quoted DEX swap on the old chain, delivering a tokenized stock token into the player's wallet. When $STREET and identity moved to Solana, two things followed:
1. **Pools for those names do not exist on Solana yet**, so a Solana wallet is refused before a swap is attempted — *stock-token fills are cash until Solana pools are wired*.
2. **The fill is switched off in the deployed build** regardless of wallet, so there is no configuration in which it currently fills.
Every one of those paths ends the same way: **cash at the published rate**. Nothing strands, and nothing is promised that cannot be delivered.
| Control | How it works |
| ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Cash is the floor, and today the whole floor** | Every path — wrong chain, switched off, no quote, cannot sign, swap reverted — ends in cash at the published rate |
| **Pinned contracts** | When the rail does fill, each name is fixed to its official token address; a same-ticker lookalike is refused by not being on the table, and a test holds the addresses |
| **Quote before fill** | Quoted first with a 1% slippage ceiling; no quote means cash |
| **Not a NYSE share** | What the rail would deliver is a tokenized stock token trading 24/7 on a DEX. The product says so on the desk a player reads, not only here |
| **The game never holds a security** | It would buy an existing on-chain token at market and send it on; it mints, custodies and transfers nothing itself |
## The settlement preference
A player ranks up to five names from the venue's published allowlist and the venue fills the first one it can. Order is the whole expression — no weighting, no split, no basket, because each would be an instruction about how to allocate somebody's money.
The allowlist is the operator's and there is **no default**: it is read from configuration on every claims call, and it currently publishes AAPL, MSFT and NVDA. Because it lives in the Worker's vars, changing the list takes a deploy.
These are the only real tickers anywhere in the product. Nothing in the simulation reads that table — the floor's own twenty-four names are invented and always were.
## What $STREET buys — once the mint exists
A capped exchange seat (1,000, numbered, resold player-to-player), buy-ins at bigger pit tables, spectator action from the rim, capital, property, backing another player's career, and a season. **It never buys power** — the seat gates access only, and a test asserts the gate list contains no stat, no fill, no price and no probability.
No mint is published, so none of that is purchasable with a token yet; the game runs on credits until it is.
---
# 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://reverie.gitbook.io/wall-usdstreet-on-rh/investors/the-rails.md?ask=&goal=
```
`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.