Lately I've been wondering about setting delays after initialization and resolution to avoid having more than a single transaction occur.

I've yet to give the docs a thorough enough of a read, but i'm thinking of something like

contract GameStake {

adress public playerOne;

address public playerTwo;

delay(15) {

//delayed execution, sends payment after 15 blocks of initialization.





  • 1
    Hi Dakota. You'll likely get a better response here if you ask a specific question about this. – Rob Hitchens Feb 25 '17 at 9:08
  • Hi rob I don't actually have any code yet, and I'm fairly new to programming in general. What I'd like to happen is have two players pool a bet, have them play a the game, have a lookup to that history (preferably swarm) to decide the winner and finally execute once the delay(x) is reached. I've probably made a number of errors in this, but I'd like to see or know of ways to make a wager and resolve it in a single transaction. – Dakota Quint Feb 25 '17 at 10:46

It would be technically possible to include delays using the block number or timestamp. It's unnecessarily awkward to make the contract "wake up" in the future. Clients can withdraw winnings, and the contract can check their entitlement, possibly with an eye on the clock.

Speaking in abstraction makes it a little tricky be precise, so let's talk about rock, paper, scissors. Suppose each player places a stake for each round.

The following description is predicated on the assumption that there's a user-friendly Dapp that hides all the transaction details from the users ... so they can play the game.

The system can know there's a winner after two stakes are placed. A non-obvious problem is everything on the blockchain is visible to a determined adversary. It means a player can cheat unless the "rock, paper or scissors" is stored in an encrypted way. During the betting phase, everything is hidden.

When all bets are in, the round would enter the settlement phase.

The clients would reveal the secrets they used to encode their bets (for round 123, my secret was 0x123). The contract would verify the secret is correct and the recorded information correctly decrypts to "rock, paper or scissors".

The contract would determine the winner immediately.

The winner would be required to claim their prize. That way, they provide the gas for transmission. This function would check the legitimacy of the claim.

In the settlement phase, it's possible a determined (and cheap) sore loser would refrain from the meager gas cost of checking in if they could determine that they lost (doable). That can be resolved with a rule that stipulates that they forfeit the round if they don't check in after a few blocks.

We can imagine a user interface that plays the game continuously, with previous rounds in settled or waiting states. Generally, payout would be immediate. When dishonest players participate, they would cause a brief delay settling specific rounds; always eventually resolved.

Hope it helps.


The Ethereum Alarm Clock contract allows you to schedule function calls for a specific block in the future. It doesn't rely on a third-party oracle to do so, though it does require that you know all details of the transaction at the time of scheduling.

Documentation, with examples, is here. If you prefer to use JavaScript library then you can find tutorial here.


Basic principle is that a contract function can only execute if some external party calls it. Delay are today managed by oracles (external party that watch for specific events and call your contract via a predefined interface that you implement. This only exists in public blockchain and not on private. Unless you reimplement them)

There is no (as far as I know) mechanism for a contract function to submit a transaction asynchronously and have it mined in a future bloc. That would have enabled to call your own contract and until the block number is not reached call async again). Maybe in a later Ethereum version of the EVM

So at the moment the simplest way is to get your contract initialized with the bets, participants and future timestamp. And from outside call the contract regularly to check if time is reached and then call the after delay code.

Good luck

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.