I am writing an ICO(Presale) contract which have different phases of sale and different starting prices for each phase. Also, on each token sale the price of tokens increase by a static value. After all the tokens locked for Phase 1 is finished, It will automatically start Phase 2.

To give an easier description: Phase 1: Total tokens: 100 Starting price: 10 Increase on each token sale: 10 Phase 2: Total tokens: 1000 Starting price: 100 Increase on each token sale: 100

For example, in Phase 1 if no tokens are sold yet and you buy 10 tokens, you have to pay: 10+20+30+40...+90 usdt. Then, next buyer will buy from 100 usdt.

If 96 tokens are sold and you buy 5 tokens 96+4=100 + 1(from Phase 2).

In front-end, when users display this page and enter the amount of tokens they want to buy, they will get some estimated price but if other users buy some tokens in the meantime, token prices will be different since prices are dynamic and also there is a big price change when entering the next phase.

My question here is: what is the best way to handle this?

-Do I need to call the contract in some time intervals to give a better user experience?

-Should I to handle this by watching events and calling a backend server in some time intervals to get the final state to prevent loading my node provider too much?

-Should I just give some warning to users to check the transaction before confirming?

First two options I think still is not enough since price can still change while metamask is popping up and until user click confirm transaction. So how should I handle this?

1 Answer 1


I think using both 1 and 3 is the best method.

I would refresh the prices and the page every interval. This interval just needs to be around the block-time of the blockchain you're using. So for ethereum I would say 10 seconds is actually sufficient. But even making 1 RPC call every second to the node provider is common in most dapp I've seen.

Then, when the user is about to sign/send the transaction (basically clicking the button on your page that does so), refreshing the prices is generally a good idea.

In any case, a good smart contract should have what it's called a "slippage" check, i.e. a way to revert the transaction if the price moved too much against the user. In your case the user will send a "max price" he's willing to pay, and this price can be the one shown on the UI or slightly higher (sometimes the page has a setting for that).

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.