With Ethereum it's notoriously difficult to accept deposits from many users due high operational costs for making new ETH addresses. On the other hand, if all users of a service send ETH to one address it would be impossible to track who sent which funds.

To solve the tracking issue when sending funds to a single address, a user suggests using the "satoshi" method as a marker for user deposits in Bitcoin in this question.

Another method I’ve seen used on bitcoin is using satoshis as a marker. For example, when paying for a one bitcoin item, an additional 7 satoshi could be added to the amount due to distinguish from another user asked to add 6 satoshi. Payments must be in exact amounts for this to work (but you can always refund an incorrect payment, less fees, to a sender). This does not scale all that well if your IDs must be permanent. This avoids the need for users to interact with a contract to include metadata.

In short, the method allows all users of a service to deposit funds to the same Bitcoin address while allowing us to keep track of who deposited which funds.

I would like to know if this concept can be applied to Ethereum.

Off hand I can think of two potential issues with this method:

  • If we reserve 1 ETH address for 100 users, we are adding a minuscule amount of $$$ to each payment
  • It only works when we know in advance how much the user intends to deposit (otherwise there's no way of calculating how much extra "wei" was added to a payment (so it won't work for general deposits)

What are some of the other pros and cons of using this protocol to keep track of user deposits? Are the issues above solvable?



I guess it depends on the amounts users should deposit.

1 Ether is 1000000000000000000 weis. So if users are supposed to deposit 1 Eth, it means you have plenty of "unused" zeros to use as markers - you could for example use 10 right-most zeros as markers which would give you plenty of unique IDs.

But if users are supposed to deposit for example around 1000 weis, then you have a lot less room for IDs.

Another option in Ethereum is to use a similar mechanism with gas price - currently the average gas price is around 80000000000 weis (80 gweis) so there also is plenty of extra zeros.

Or a third option could be gas limit - the benefit with this is that it doesn't cost anything extra to specify. So using gas limit of 10 million costs the same as using a gas limit of 11 million (as long as the transaction doesn't require that much gas).

However, the only truly scalable way is to have a real smart contract which accepts user input in some way - for example user IDs.

  • thanks for your reply. "However, the only truly scalable way is to have a real smart contract which accepts user input in some way - for example user ID" - Isn't the "gas costs" for smart contracts significantly higher than normal transactions? This could potentially negate the benefits of this approach.. – S.O.S Jan 14 at 18:53
  • Also, most users are depositing funds via traditional exchanges (or traditional wallets) which don't usually support complex type of transactions via smart contracts.. – S.O.S Jan 14 at 18:54
  • 1
    Yes, the gas costs are higher when interacting with a contract. And yes, if sending from an exchange it's often not possible to interact with a contract and not possible to set custom gas price or gas limit – Lauri Peltonen Jan 14 at 19:18
  • Another option when recipient is an EOA account is to use transaction's data field to include some sort of id. For contracts you can define a custom function. – Ismael Jan 14 at 22:19
  • @_LauriPeltonen @Ismael If a user deposited funds and forgot to specify id in transaction's data field or forgot to add the instructed amount of "wei' to the total payment amount -- is it still possible for the user to prove they were the sender of the funds after the fact? – S.O.S Jan 14 at 23:47

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.