I am trying to conceptualization how a specific kind of smart contract would be written.

The contract would basically handle deposits and withdrawals of ETH or some sort of ERC20 token.

The balances would then be used to play various off chain games, mostly multiple player casino style stuff like Texas Holdem. The games are offchain because they require alot of operations and the Tx fees would not be user friendly.

Users would increase (or decrease) their balances inside the contract from playing these games.

I want to give the users the ability to withdraw their balances back to their wallets at anytime but I have to be able to check against the game servers to make sure they are not currently in a game while they are trying to withdraw.

I am trying to prevent a scenario where a player would enter a game (like poker) stake their balance off chain but withdraw it from the contract while the game is in progress. Then if they lose there is no balance to transfer to the other player.

I'm not sure what the correct approach would be to do this? Could creating a token/custom wallet or oraclizing the withdrawal help in anyway?

Any insight would be greatly appreciated!

Thank You

3 Answers 3


You could have the withdrawal be timelocked for an hour and require a security deposit. If you can prove that the user was still playing via signatures from state channels, you can prove that they nefariously tried withdrawing and claim their withdrawal and security deposit.

  • Could you explain implementing "signatures from state channels" I'm not familiar with that
    – Dan
    Jul 14, 2018 at 22:54
  • You should take a look at Plasma Cash -> karl.tech/plasma-cash-simple-spec, as it will shed some light as to how to do the actual off chain asset management and on chain conflict resolution. Jul 16, 2018 at 5:10

You have off-chain game play, so there is an element of trust in the game servers. You have separate funds in play from funds that are free to withdraw (unencumbered).

A simple formulation would be to transfer funds into the care of the game system and it's accounting process until funds are taken out of live play and available for withdraw.

In case that isn't clear.

Alice has 10 ether. She buys 5 chips for 5 ether and she has 5 ether available for withdrawal. She cash her chips in when they are not in play, but that is a game-server concern because it knows which ones are "free and clear" and which ones are in play. When Alice sells, say 7 chips (lucky Alice), she gets 7 ether back.

A contract can handle the deposit and withdrawal of ether. It can handle to trade for chips by taking the ether away (transfer to owner) and emitting an event. It is the game server's responsibility to credit her with casino chips. The contract will merely emit an event so it knows what it should do.

Similarly, when Alice cashes in her chips, the game server will take the chips away and transfer corresponding amount of ether into Alice's account. Alice can withdraw ether to exit the establishment.

This is an admittedly over-simplified example to give you some ideas.

pragma solidity 0.5.1;

contract Holdem {

    mapping(address => uint) public balances;

    event LogDeposit(address sender, uint amount);
    event LogWithdrawal(address receiver, uint amount);
    event LogTransfer(address sender, address receiver, uint amount);

    function depost() public payable {
        balances[msg.sender] += msg.value;
        emit LogDeposit(msg.sender, msg.value);

    function withdraw(uint amount) public {
        uint bal = balances[msg.sender];
        require(bal >= amount, "Insufficient Funds.");
        balances[msg.sender] -= amount;
        emit LogWithdrawal(msg.sender, amount);

    function transfer(uint amount, address receiver) public {
        uint bal = balances[msg.sender];
        require(bal >= amount, "Insufficient Funds.");
        balances[msg.sender] -= amount;
        balances[receiver] += amount;
        emit LogTransfer(msg.sender, receiver, amount);


The transfer() function lets Alice give to the house, and lets the house give to Alice. It emits an event that is sufficient for an honest house to account for funds received.

Astute observers will note that there is nothing stopping the house from withdrawing winnings (in the honest case) or everything (in the exit scam case). One would need to add strict restrictions on the house's ability to withdraw funds (chips should be collateralized) as well as evidence that the games are fair before the "off-chain" parts of such a system would be trustworthy.

Hope it helps.


What you are talking about is essentially the concept of off-chain "orcales". For examples of how this is done, you can look at facilities such as those supplied by https://chain.link.

The general methodology consists of creating contract functions which can be called by code running outside the blockchain (the same way a wallet or dapp calls an on-chain contract), for the purpose of supplying data from the off-chain world.

In a scenario like the one you are describing, your off-chain game servers would need to "lock" a certain amount of value on-chain, and then "unlock" whatever value wasn't spent during gameplay. Obviously, the contract functions they call would need to be "onlyOwner" functions (i.e., have access controls) and you may also potentially want to engage in some cryptography of the exchanged data. Everything on chain is visible, even if variables are declared "private" in Solidity. Therefore, keeping information passing on/off-chain private is non-trivial.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.