Making individual HTTP requests sucks, that’s why since Web2 we have been using bundles, image sprite sheets, and so on…

Same happens in Web3, and that’s why Multicall exists, but we can do better!

At DeFi Wonderland, we have developed a different approach to batch requests, which is infinite times more flexible: Constructor Batching Method.

The benefits

• Independent: Doesn’t require any extra deployed contracts to work (undistinguishable from a contract deployment).
• Versatile: Can perform complex code logic, not restricting itself to batching individual calls into an array.
• Efficient: Solidity logic (vs making calls) can make the reading more efficient, reducing the load on the RPC provider.

But how????

Solidity constructors are a thing of beauty which runs in the node’s memory before contract deployment, we are going to take advantage of that 😈.

The goal of the Contructor Batching Method is to force the RPC to process Solidity code in memory and return the execution result. Since Solidity doesn’t support returning arguments in the constructor logic, assembly is used to force returning data.

The magic of forcing the constructor to return data is that we save ourselves the step of deploying a contract and then calling the batching function. With this in mind, we can simulate the deployment, execute the constructor’s logic, include arbitrary calls to external contracts, and return the data we need. All in one step. All in one request.

<aside> 📍 Since the calls are made during the constructor runtime, all sub-calls to other contracts will be called with a msg.sender being the address where the virtual contract would be deployed. The contract cannot implement any external methods, as they will be inexistent during the creation time.

</aside>

Step by step

To illustrate this approach, two simple solidity contracts are created. The source code can be downloaded from https://github.com/defi-wonderland/rpc-batching-sample:

1. PoolManager: This contract simulates a pool manager containing a function capable of querying a single pool at a time.
2. BatchPoolManagerData: This contract implements where magic happens. It will perform the necessary calls, store them in an array, and then return all the data. By doing this, RPCs can simulate the deployment of this contract and get the data in a single call instead of having to call PoolManager's querying method multiple times.