2

What would be the optimal way to accept order payments from users who have Ether on an exchange? I can't figure out how to link the orderID with the transaction, without creating a new contract for each order, since they won't be able to add parameters/call functions. Also will the exchange run into gas issues sending ether to a contract account?

1

On this basis: "they won't be able to add parameters/call functions",

I imagine a separate contract for each expected transfer sets up the simplest external interface everyone can understand and implement without great difficulty.

A contract factory isn't especially challenging to set up. Plan to spend a great deal of time on admin, corner cases and testing of the immutable code.

A downside of such an approach is the site owner ends up paying for a small contract deployment for each expected payment (OpEx).

For the payment senders, yes, they will have to pay gas for function execution, but you could take care to limit things to the normal send() with only the gas stipend. A departure from "normal" would cause unwanted friction IMO.

Hope it helps.

  • Thanks Rob, so the exchanges don't have a problem sending to contract accounts anymore? – ethereal Feb 11 '17 at 17:29
  • Possible to say that your fallback function requires only the 2,300 gas stipend and no extra arguments. Impossible to say no one will have a problem with it. – Rob Hitchens - B9lab Feb 11 '17 at 17:42

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.