Add Confirmed Toll Parameter When Sending ETH To Avoid Admin Frontrunning

Problem

The current version of Umbra.sol contract has the following method:

  function setToll(uint256 _newToll) public onlyOwner {
    toll = _newToll;
  }

I believe it can raise some trust concerns: in its current implementation the toll can be changed without users’ awareness.

We can imagine the following scenario:

1. User sends a transaction with X+T1 as a total amount, where X is intended transfer amount and T is toll
2. Contract owner sets the toll to T2 (which, for instance, is higher than T1)
3. A transaction setting the new toll gets mined first
4. User’s transaction gets mined second, the actual amount transferred to the recipient becomes X+T1-T2

Potential issues:

• Users’ transactions can be spoiled. For example, if they are processed by an automated payment system, receiving lesser amount would render a payment invalid, which would lead to loosing the funds.
• It could be seen as a potential attack vector for a contract owner to steal users’ funds. Owner could watch the network for a transaction that transfers a certain amount of ETH, and while the transaction is still in the mempool, they could try to broadcast a transaction changing toll that would get mined before the user’s transaction.

Possible solutions

Getting rid of the toll completely

It seems to be the most simple way of solving the problem. Though probably there are some reasons to leave it (like spam protection, etc), so I think it can be a good opportunity to discuss them and determine the importance of having toll.

Accepting confirmedToll as a sendEth argument

A user would be able to confirm amount of toll they agree to pay. We could check if confirmedToll equals current toll set in the contract and reject a transaction if it doesn’t. This can protect a user from loosing their funds in the described scenario, but we can also keep the toll if it proves to be useful.

Making toll immutable

We could leave it just as a constructor argument, thus removing setToll function and resolving the trust issue.

[apbendi]

Great thanks @mds1 and @mvlabat. We will go with this approach!

[mvlabat]

Hi folks! @apbendi, sorry for missing your question. Yeah, I think that those proposed solutions are also valid options. But I still believe that the confirmedToll parameter is the most simple and secure one among the others that we’ve discussed, so I’ll be absolutely happy if you decide to go with this approach.