I'm working on designing an application that requires a contract to mediate a transaction between a seller and a buyer.

The buyer will initiate the game by paying the contract, the contract will then take the "goods" from the seller and send them to the buyer, and finally send the money to the seller.

The "goods" in this case are just some data (that is NOT stored on the chain, and is generated off-chain by the seller.)

My question then is, how do I go from this to a working solidity contract?

My current design (my knowledge of solidity is very limited):

  1. There could be a contract function say i_need_to_buy() that the user will call thereby paying some gas etc.

  2. The contract will emit an event seller_send_goods_now() sending the buyer's public key.

  3. The seller will be waiting for this event (via web3.watch perhaps?) It'll do some off-chain computation (say encrypting the data with the buyer's public key - so only she can open it.)

  4. The seller will then call another contract function send_goods_back() sending the encrypted data to the contract.

  5. The contract will emit a new event goods_received() forwarding the data (essentially to everyone.)

  6. The buyer will be waiting for this event and has now received the goods. She decrypts the data and thanks Vitalik Buterin.

If seller doesn't send the "goods" the contract could just refund the money, right?

Is the design good enough? What would you change?

1 Answer 1


I can see several issues with this proposed design. Some of these are:

  • there is no way to ensure the data being sent is, in fact, legitimate;
  • if the data to be returned is large, that is expensive;
  • you could save data by sending only a hash on-chain and the data off-chain, but see issue #1 and also there is no way to ensure the recipient was actually sent anything not any way of verifying that the receiver doesn’t lie about receiving data; and
  • this is no step included in your proposal that actually pays the seller.
  • Wow this fast. Yeah, I need to decide when I'll pay the seller (that was an oversight on my part.) Apr 13, 2018 at 15:46
  • Thanks for bringing legitimacy to my attention. But I think I'll just skip it for now. Apr 13, 2018 at 15:47
  • Can you please expand on large data being expensive? Since I'm not storing the data at anytime on the on-chain, why does it being large matter? Apr 13, 2018 at 15:48
  • What did you mean by only a hash on-chain and data off-chain? Apr 13, 2018 at 15:49
  • On-chain means anything that gets recorded in the blockchain. Steps 1,2,4,5,6 are all on-chain operations. If you plan on returning data by blockchain, you’ll have to pay for the storage.
    – lungj
    Apr 13, 2018 at 23:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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