skip to content
rhr
demo
contents06 Custody and your money
rhr — documentation

06, fairness & security

Custody and your money

Games run off-chain for speed, but your balance lives in an on-chain vault with strict rules, and this page is honest about what those rules cannot cover.

on this page

Games are fast because results are tracked off-chain. Your money is not held off-chain. It sits in a vault contract on Robinhood Chain whose rules the server cannot rewrite. This page explains who can do what, what the rules guarantee and, just as important, what they do not.

Two layers

LayerWhat it doesWho runs it
Game serverSeats you, runs the games, keeps the ledger, signs checkpoints and withdrawal vouchersThe RHR operator
Vault contractHolds every deposit, accepts or rejects checkpoints, pays withdrawals, runs the escape hatchNobody. It is code on the chain

How results are recorded

The server keeps a double-entry ledger. Every game settles as one balanced entry: each player's net result, plus the rake. The ledger has accounts for each player's available and reserved money, game escrow, rake, accrued rakeback, the jackpot and tournament escrow.

After every settlement the server checks that the ledger balances and fails loudly if it does not. Whatever left one account landed in another, and nothing was created or lost. The check runs after every game, not once a day.

How results reach the chain

The server's signing key, the settler, bundles the net changes into a checkpoint and sends it to the vault. By default it cuts a checkpoint every 60 seconds when there is something to settle, or sooner when 50 games are waiting. Before it signs a withdrawal voucher for you, it forces a checkpoint that includes your latest results.

The vault accepts a checkpoint only if all of this holds:

  • Its number is the next one in the sequence, and the signature comes from the current settler.
  • The list of players and the list of changes have the same length, within a fixed cap.
  • The changes plus the rake add up to exactly zero.
  • No player's balance goes below zero.
  • The rake stays under a per-checkpoint limit, and the total amount moved is bounded.
  • Afterwards the vault's USDG balance still covers every player balance, the uncollected rake and the queued withdrawals added together.

Anything else is rejected.

What the rules guarantee

  • Nobody can mint money. Checkpoints must net to zero, so the settler can move value between players but cannot create it.
  • The rake is capped. A single checkpoint can book only so much rake.
  • The owner and the guardian cannot move player balances. The only thing that changes balances is a checkpoint, and it has to pass every check above. Every role is listed on the contracts page.
  • The vault stays fully backed. It rejects any change that would leave it owing more than it holds.
  • The rake has one destination. The rake router is fixed when the vault is deployed, and it is the only place rake can go.
  • You can always start an exit. See the escape hatch below. Pausing never blocks it.

What the rules do not cover

The vault cannot see games. It checks that a checkpoint adds up and is signed by the settler. It cannot check that the games it reports really happened. That makes the settler a trusted role, and it is the main trust assumption in RHR.

If the settler's key were stolen, or the operator turned malicious, the attacker could report fake results that shift balances from some players to others. The contracts limit the damage. They do not remove it.

  • Every checkpoint is capped in how much it can move and how much rake it can take.
  • The guardian can pause settlement and withdrawal vouchers, and can cancel large withdrawals that are still waiting in the queue.
  • The owner, a multisig Safe in production, can replace the settler, but only after a 48-hour timelock. That is longer than the 24-hour escape hatch, so anyone who sees a new settler proposed can leave before it can sign. A proposal not accepted within 7 days after that expires.
  • Large withdrawals wait in a queue before they are paid, which buys the guardian time to act.

These are brakes, not guarantees. If you are not comfortable trusting the operator within those limits, keep less in the vault.

The guardian cuts both ways. It can stop a thief's withdrawal, and it can also hold up a legitimate large one. It cannot take the money: a cancelled withdrawal goes back to the player's balance.

The escape hatch

If the settler disappears, or you simply stop trusting the server, you do not need anyone's permission to leave.

  1. Call requestForceWithdraw() on the vault from your wallet. You need a balance above zero.
  2. Wait 24 hours.
  3. Within the next 3 days, call executeForceWithdraw(). The vault pays you the lowest balance you had since the request, and never more than you hold at that moment.

If you let those 3 days pass, the request expires. Nothing is lost: the money stays in the vault, and you can request again and wait another 24 hours. You can also cancel a request at any time.

What it pays. The vault notes your balance when you ask. Every later debit lowers that figure, such as a loss checkpointed after the request or a voucher you cash, and no credit raises it. Winnings checkpointed after the request stay in the vault, for a normal cash-out or a new request. That is on purpose: if a thief ever stole the settler key and credited money to an accomplice, the hatch would not let that money out.

It works while the vault is paused and with no settler at all. Your profile page has a button for it. These are also functions on the vault contract itself, so they work even if this website is down. You can call them with any tool that talks to contracts, for example the write tab of a block explorer, as long as the contract's source is verified there.

If the server is still running when you ask, it sees the request. It stops seating you, issues no new vouchers, and keeps checkpointing your finished games, wins included, so your balance in the vault matches its ledger. Withdrawals already waiting in the queue when you ask are not part of the request: cancel them first, which puts the money back on your balance, then request.

What the escape hatch does not do:

  • If the server is gone, it pays from what the last checkpoint says you own. Results from games that were never checkpointed are not included.
  • It does not pay out winnings credited after the request. They wait in the vault.
  • It is slow on purpose and it costs gas.
  • It is a last resort, not a shortcut. While the server runs normally, checkpoints land about every minute, so by the time the delay ends your on-chain balance already reflects your games.
  • It cannot move USDG that the token itself refuses to move. See the next section.

Token issuer risk

The money in the vault is USDG, a token issued by Global Dollar. Its issuer controls the token's contract, and issuers of stablecoins like this can freeze individual addresses or pause the token. If the vault's address, or yours, were frozen, no RHR contract could move that USDG: not a checkpoint, not a withdrawal, not the escape hatch. That risk sits outside the contracts, and nothing in RHR can fix it.

Aborted games and refunds

If the server has a fault, for example it crashes and restarts, it aborts the game that was in progress. Every buy-in is refunded in full and no rake is taken, so nobody loses any money. An abort does cancel the game's result: if you were ahead, you get your buy-in back, not the pot. A game that is cancelled at the start because fewer than two players remain is treated the same way.

What is, and is not, on-chain

Per-game commitments are not anchored on-chain. The server publishes them and your browser checks them. Only deposits, withdrawals, settlement checkpoints and jackpot payouts touch the chain. See The provably fair spin for what that means for verification. Collusion between the server and a player is a trust assumption, and there are no house bots at real-money tables.

What can still go wrong

  1. A bug in the contracts. They are unaudited.
  2. A stolen or misused settler key, within the limits above.
  3. The USDG issuer freezing an address or pausing the token.
  4. The server being offline. You can still exit through the escape hatch: 24 hours after you ask, within 3 days.
  5. The server colluding with a player, which is a trust assumption.
  6. You: fake sites, phishing, or signing something you did not read.

A short checklist

  • Deposit only what you can afford to lose.
  • Cash out wins regularly instead of letting a big stash sit.
  • Check every contract address against the contracts page.
  • Never share your seed phrase or private key with anyone, for any reason.