I'm very new to solidity and blockchain development in general, so please bear with me. I've seen an example on a yield farm, where it seems to be storing info about how many LP tokens users have deposited in each pool. They have a function that, given someone's address and a pool id, will return info about how many LP's they've deposited into that pool, how much they're owed in rewards, etc. To show this info on the front-end, they have a constant storing all the pool ids, and they loop through and make individual calls with the wallet address and each pool id, and then use all those responses to display the info.

It seems really inefficient to me to have to make all of those individual calls from the client, rather than having an extra contract function that could loop through each one and collect all of the data, and then return it in a single response. I assume there's a reason they're doing it the way they are, but I'm not really clear on it. I know it's supposed to be important to keep contract size down - but is it really worth having to make so many extra calls? I'm not even totally sure if there's a real difference between contract functions calling each other in a loop, as opposed to the client calling them all in a loop, because I don't know exactly what's even responsible for handling the processing, or if it's maybe ultimately the same amount of work/time from the client, due to how web3js works.

I just want to know which approach should be better, and why exactly that is.

2 Answers 2


It definitely depends on the use case. It also depends if a function is calling another function or if the state is being modified.

In this case they are just reading the state with view functions which wouldn't cost any gas as far as I know. It seems like they tried to save on gas by not including a few extra lines of code, a loop perhaps, on the initial deployment of the smart contract(s). In blockchain application development every byte counts so that's likely why they made that decision.

In traditional, cloud-based applications the story might be different as you wouldn't want to make 15 calls to a database when you could just make one. Unless you are loading a large amount of data and need a smooth user experience.


The difference is the price!

The bigger the contract the bigger the cost. It will depend of your use case but generally speaking you want to keep your contract as small as possible. In the immediate term it will be cheaper to deploy and in the long run your users will save on gas.

You want to avoid storing lot's of data in your contract or functions that can be run in the front end.

Keep the contract basic without affecting security. If a task can be computed in the front end then you want to do it on the front end.

  • Is rpc overhead just not a concern whatsoever? It just seems atrociously inefficient to have to make 15 rpc requests to call a function 15 times, instead of just having one extra function in my contract that can return all the data I need, and then I make one rpc request, get one response, and done. I don't see how it costs anyone more gas, but deploy costs would be a little higher. To me it seems like you'd have far better performance and save a lot on RPC costs though, and it would scale much better. I do appreciate the response - just trying to push back on it a bit to see how well it holds Oct 27, 2021 at 4:12
  • But one way or another. Your going trough the RPC to make your call. It also largely depend on your use case, how your contract is built. The way you load the front end will also play a role. Some project hang there while the entire sets of data is loaded. I prefer gradual loading. So in my case it was better to call each contract one at the time and populate the UI. You might notice some calls take longer than others, In the end I beleive it comes down to the user experience. Oct 27, 2021 at 4:23

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.