The idea was to store the encrypted number of tokens,and when user was sending his private key, smart-contract would decrypt the data and perform an action of sending tokens to someone else. The catch is, user doesn't have his own ethereum address, so I need another private key generated for this and everything will be performed by one account from back-end. Also this will be one-time action - once private key sent and tokens released there will be no need for this private key anymore, so it's ok for it to be exposed to public chain.

I've found the only solution is to encrypt off-chain, keep it in smart-contract and for someone to read it there and decrypt again off-chain, but I need to perform an action after this so it doesn't fit here.

Hope for any suggestions, thanks.

1 Answer 1


store the encrypted number of tokens, and when user was sending his private key ... smart-contract would ... sending tokens to someone else.

I'm going to set "private key" aside and call it simply "secret" to reflect that this is a password and not a wallet private key.

You'll have a contract that contains virtual "Drop Boxes" each of which contains a balance of funds owed and a destination address. These drop boxes would be organized in a mapping using "puzzles" to index. The puzzles would be hashes of unchangeable properties of the drop box contents (e.g. the destination) and a secret word.

The user's UI would compute a hash of, e.g., hash(destination, secret word). The user, or server would create a drop box identified by the hash, and write the box contents to the contract - amount, destination, expiry, etc.

That's the "challenge" stage. The "response" stage has the user present the secret. If the secret maps to a known drop box then the contract forwards funds to the destination specified in the drop box details.

Once used, "secrets" are burned. Take care to reject deposits using hashes with secrets are already solved. There is a race condition/front-running risk. It's important that the drop box contains unambiguous information about where to send the funds and only there. This, because the "secrets" are revealed in the tx.pool and everyone can see them even before the solution transactions are mined.

Hope it helps.

  • Thanks a lot! I totally forgot about a race condition, yeah that might be not possible in a way it was planned, I'll take into consideration your idea. May 11, 2019 at 18:56
  • any simple project that has implemented this?
    – Edwin O.
    Jun 21 at 16:24
  • This was a student project for B9lab's Certified Ethereum Developer course. There are hundreds of attempts on github, most with code-reviews and a succession of corrections to early iterations covering various pitfalls. . Jun 21 at 18:44

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.