I was looking at the new smart contracts submitted list on Etherscan to pass the afternoon, and I came across this one:


The contract seems to be a simple game of Q&A, but I noticed the original answer could be seen in plain sight here:


The answer reads "A phonE", and I thought it would get stolen quickly, since I can't be the only one doing this. I decided to take it, contact the owner, and return it to safety. I made some tests on the TestNet to see if everything worked (you need to send 1 ETH to submit a message), and it went fine. This is the testing contract address, you can check the transactions to see the process I was going to follow:


As you can see, everything went fine, so I decided to do it on the MainNet. However, even though the messages and all are correct, it ate my ETH and nothing happened. I have accepted the loss of the Ether, but I am wondering, why would it not work, even tho it did on the TestNet?


I wrote a blog post to relate your misadventure in more detail. Here is what happened:

  • Using their first account, they deployed a HiddenQuestionSender contract, which passes through commands, with this transaction.
  • 12 days later, using their second account, they deploy their X_GAME contract with this transaction.
  • Right after that, using their first account, they tell HiddenQuestionSender to set up the question, StartGame with 0 Ether, and change the hash, NewQuestion, with this transaction. In the call data, you can see the question but not the answer; but it doesn’t matter in the end. You can also find the new fake hash: 0xaee11ed86334ac3afdac440921f36b90a937dfbc02f43b02a81b763b769fca4a.
  • Right after that again, using their second account, they call StartGame with 1.03 Ether with this transaction. Notice the TxReceipt Status: Success.
  • Later, you tried your luck with this transaction and 1.01 Ether. You lost it to the contract.
  • At some point, they collected their rewards, with this transaction, which is also listed in the internal transactions of X_GAME. It’s the only one there, and is too late to alert you.

For others reading this, it would have been possible to detect something fishy earlier with web3.eth.getStorageAt(X_GAME.address, slotIndex) and:

  • At slot 1, find out that questionSender is not their address but strangely that of a smart contract: HiddenQuestionSender
  • At slot 2, find out that responseHash does not match web3.sha3(“A phonE”)

You could also have used Ganache to --fork from the main net and safely test the outcome of your own attack.

  • Bless you my man. This should be made public knowledge. – mariohm1311 Jul 4 '18 at 15:56

Sorry you fell for this!

NewQuestion was called before you attempted to take the ether.

I believe this is the transaction that did it: https://www.etherchain.org/tx/f1df0e4113cdd8e864235ff2bbd472c98703794ae10e923cd51c8aea260f102a/parityTrace. Search for 0x3e3ee859, which is the function selector for NewQuestion(string,bytes32).

  • 1
    Ah, thank you. I'll remove that bit from the answer. – smarx Jun 29 '18 at 1:49
  • Is that present on Etherscan? If not, that's a bug that would need to be fixed – mariohm1311 Jun 29 '18 at 6:42
  • Sure, etherscan.io/…. – smarx Jun 29 '18 at 6:43
  • The honeypot takes advantage of the fact that Etherscan doesn't list all passed messages in "internal transactions." I think the specific limitation here is that messages with 0 ether attached aren't listed. – smarx Jun 29 '18 at 6:44
  • Oh man, I didn't know that. I supposed the smart contract thaat received my ETH had something to do. Shouldn't that be fixed on Etherscan's end? – mariohm1311 Jun 29 '18 at 6:48

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.