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

# Networks, validators, build, upgrade

This section is a public summary of how Fast Poker is operated. Sensitive procedures such as key rotation, incident response, and multisig proposal authoring are not published here.

## Operating surfaces

| Surface          | Role                                                           |
| ---------------- | -------------------------------------------------------------- |
| Solana programs  | Settlement, custody, reward accounting, and durable state.     |
| MagicBlock / TEE | Fast gameplay and card privacy.                                |
| Dealer Service   | Permissionless crank that moves tables forward.                |
| Frontend         | Reference app at `https://fast.poker`.                         |
| Indexer          | Optional fast reads for hand history, leaderboards, and stats. |

## Program upgrades

Fast Poker uses multisig-controlled program administration. Upgrades and sensitive changes should be visible on chain before execution according to their governance tier.

The long-term goal is frozen upgrade authority once the protocol is mature enough to no longer require active patching.

## Hot configuration

Some values can be changed without a full program upgrade, such as table configuration, SNG pool economics, allowlists, approved signers, jackpot base denominators, and governed emission parameters.

Those changes still flow through the program's configured authority path. The frontend should treat on-chain state as the source of truth.

Current SNG deployments require a global 437-byte `EmissionCtrl`, 21 83-byte `PoolIdle` accounts, a 415-byte `SngDuelState` for every 6-max/9-max reusable table, and a 634-byte transient `SngSettlementRecord` for each record-enabled game. Initialize/migrate and verify those accounts before enabling the matching dealer release. Program, public IDL, dealer, frontend, and indexer should roll out as one compatible release.

## Dealer Service

The Dealer Service is permissionless. Anyone can run it. The public release repository is `https://github.com/FastPoker/dealer-service`.

Operational guidance:

* Run one dealer per table set unless you deliberately partition with table filters.
* Keep the payer wallet funded for L1 transaction fees.
* Monitor heartbeat and metrics output.
* Use reliable RPC.
* Keep the dealer version in sync with the deployed program version.

## Frontend

`https://fast.poker` is the reference frontend. Builders can use the released source at `https://github.com/FastPoker/frontend`, or build their own wallet-facing client. See [Frontend integration](/integrations/frontend-integration.md).

If the reference frontend is unavailable, on-chain balances and protocol accounts still exist.

## Indexer

The indexer improves read speed for surfaces like hand history and leaderboards. It is not the custody layer and should not be treated as the source of truth for funds.

Builders can operate the released read-side service at `https://github.com/FastPoker/indexer`, or build their own service for faster history, stats, and leaderboards. See [Indexer integration](/integrations/indexer-integration.md).

When in doubt, read Solana state directly.

## Status resources

| Resource      | URL                         |
| ------------- | --------------------------- |
| Fast Poker    | `https://fast.poker`        |
| Solana status | `https://status.solana.com` |
| MagicBlock    | `https://magicblock.gg`     |