Decentralized poker, with every hand of state recorded on a Verus
chain. Players, the dealer, and the cashier each control a Verus
identity; the gameplay protocol is a sequence of
updateidentity writes against those identities' content
multimaps (CMMs). There is no central server, no off-chain
matchmaking, and no separate audit log — the chain is the audit log.
Status: Active development. The poker product is functional end-to-end on a local Verus regtest (
VRSCTEST). There is no mainnet release at this time.
| Role | Identity (dev regtest) | Responsibilities |
|---|---|---|
| Dealer | d1.<parent>@ |
Hosts tables, drives the per-hand state machine, deals cards. |
| Player | p1.<parent>@, p2.<parent>@, … |
Buys in with sendcurrency, signs deck-shuffle steps, places bets. |
| Cashier | cashier.<parent>@ |
Custodies payin funds, settles payouts, blinds the deck. |
A single bet binary plays all three roles — selected by the first
argument (./bin/bet start dealer, ./bin/bet start player, etc.).
A fully-local development cycle needs a patched verusd running the
VRSCTEST chain. The end-to-end bring-up (chain config, identity
registration, helper scripts) is documented in
docs/tutorials/cli-auto-vrsctest.md.
Once that's in place:
# Build
git clone --recurse-submodules <fork-url> bet
cd bet
make -j$(nproc)
# Run a 2-player hand (each command in its own terminal / tmux pane)
cd poker
./bin/bet start cashier
./bin/bet start dealer
./bin/bet start player -c config/p1.ini
./bin/bet start player -c config/p2.iniThe legacy positional form (./bin/bet dealer, ./bin/bet player,
./bin/bet cashier) is preserved for compatibility.
GUI mode (per-player) starts a local WebSocket on the port from
config/pN.ini:
./bin/bet start player -c config/p1.ini --gui
# Then open http://localhost:9001/ from a pangea-poker build.Detailed build instructions:
docs/guides/build-from-source.md.
bet is structured around the single-writer-per-identity rule:
every identity in play has exactly one owning node, and that node
is the only one allowed to update its CMM. The dealer writes the
table identity's hand state; each player writes their own identity's
deck-shuffle output; the cashier writes payment acknowledgements
and settlement on its own identity. Reading is open — every
participant can getidentitycontent any identity to reconstruct the
full game. The state machine in
docs/reference/game-states.md
enumerates the 14 hand states; the full key-by-key reference is in
docs/reference/vdxf-keys.md.
bet itself opens only WebSocket ports for GUI integration. There
is no inter-node TCP — coordination flows entirely through the chain.
| Port | Default for | Configurable in |
|---|---|---|
| 9000 | Dealer GUI | dealer:gui_ws_port |
| 9001 | Player 1 GUI | verus:ws_port (p1.ini) |
| 9002 | Player 2 / cashier GUI | verus:ws_port / cashier:gui_ws_port |
The chain RPC is whichever port your verusd is configured for
(18843 on the dev regtest); the verus CLI handles that connection
on bet's behalf.
The full doc tree is under docs/:
- Documentation Index — top-level navigation.
- Building from source — system
packages, recursive submodule clone,
make -j. - VRSCTEST Local Setup —
bring up a local regtest with the patched
verusd. - System Architecture — layered design, RPC abstraction, where each module lives.
- Verus Overview — how identities, CMMs, and VDXF keys are used.
- Game State Machine —
the 14
G_*states and the writer for each. - Keys and Data Structure —
every CMM key
betreads or writes, with payload shapes. - Player Join Flow — the full player join + payin sequence.
- GUI Message Formats — WebSocket wire format for GUI integrators.
- Glossary — terminology (CMM, vdxfid, primaryaddresses, single-writer rule, etc.).
Configuration lives under poker/config/. Each node reads a
subset of:
dealer.ini/player.ini/pN.ini/cashier.ini— per-node knobs.blockchain.ini— chain CLI and currency name.keys.ini— identity short names and VDXF key prefix..rpccredentials— Verus daemon RPC user/password.
Reference: dealer_configuration.md |
player_configuration.md |
cashier_configuration.md.
All wallet operations route through the paired Verus daemon's
wallet — bet does not implement key management of its own.
Day-to-day tasks:
# Get a fresh receiving address from your wallet
verus -chain=VRSCTEST getnewaddress
# Check balance
./bin/bet balance
# Withdraw to an arbitrary R-address
./bin/bet withdraw <amount|all> <destination_address>The GUI withdrawRequest / withdraw methods (player and cashier
nodes) provide the same functionality through the WebSocket
front-end.
See LICENSE.