I have an Auction contract which has a function like this:

function bid() payable{
    //calculate and store highest bid value

But because each transaction takes time to mine, so when a user bids the highest amount, the highest bid displayed for other users takes time to be updated, which is undesirable because other users can't know what is the current minimum amount they have to bid to win.

So what should be a good solution to this problem? I thought of storing a highest bid variable in the server side that get updated whenever a user bids, but this could run into a problem when the transaction is canceled or violates something and reverted.

2 Answers 2


I hope you are storing the highest bid in your contract. In that case, you can handle this using your UI components. When someone places a bid you can show a loader, telling transaction pending verification and once the transaction is completed, you can display the success message as well as the then highest bid fetched from the contract.

The user(other users) can refresh the component to fetch the current highest bid from the contract before placing a bid herself. The fetching should be instantaneous. The placing of bid will take time to confirm.

You should not that in the ethereum world there is nothing that is instantaneous other than perhaps your local test network.

  • Problem is a user might wait forever to know the actual highest bid. For example: user A want to bid, but user B keeps on bidding 1$, 2$, ...(this could be multiple users keep on bidding). As it takes some time for each transaction to complete, user A will never know what is the actual highest value.
    – Indigo
    May 20, 2019 at 6:45
  • But user A can instantaneously know, what is the current highest bid recorded in the contract as a result of a verified transaction. You can refresh the UI component when user A shows an intent to place bid. The bid which he is going to place is with similar knowledge to other users. All users who refreshed at the same time get the same result.
    – Sanjay S B
    May 20, 2019 at 8:50

Consensys' guide about Smart Contract Security Best Practices, in its Known Attacks page explains with examples the risks and solutions of several security issues, and has some examples similar to yours, specifically the DoS with (Unexpected) revert section:

If attacker bids using a smart contract which has a fallback function that reverts any payment, the attacker can win any auction. When it tries to refund the old leader, it reverts if the refund fails. This means that a malicious bidder can become the leader while making sure that any refunds to their address will always fail. In this way, they can prevent anyone else from calling the bid() function, and stay the leader forever. A recommendation is to set up a pull payment system instead, as described earlier.

I would recommend reading the whole page, follow the recommendations and search for other resources to implement the better as possible security for your smart contracts.

Also, if you're still not using it, I would recommend using a library for secure smart contract development, like OpenZeppelin contracts.

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.