Make this an ERC (or have I missed it?)

[juanfranblanco]

Multicall is let's say, "Awesome" and solves many problems for all users, it will be ideal if it is more widely known. Have you thought about creating an ERC? Or have I missed it?

[mds1]

Hmm interesting idea, haven't thought of creating an ERC for it. Do you think publicity is the main benefit?

And given that it's a standalone contract that already exists (and requires me to deploy), compared to a standard for anyone to implement, would that qualify as an ERC? I'm not familiar enough with the process, but definitely open to doing it.

[juanfranblanco]

@mds1 Apologies, my github notifications are always overflown. Yes, I think it will truly benefit as a generic standard. For example many libraries of different languages can implement it to query data using the deployed smart contract. Later on as we move to L3s, it can also become also a predefined contract that everyone expects.

Here is the process https://github.com/ethereum/EIPs, I am no expert on the creation, but I am sure it will be straightforward

[mds1]

That seems reasonable me and I'm happy to help with working on an ERC for this. I probably won't have the time to drive it forward for at least a few weeks though, unfortunately. @abigger87 Any chance you would be interesting in leading an ERC for this?

I know @sambacha mentioned in #31 he was working on EIP. I'm not sure if it was for this specifically or something else, but let's see what he says to avoid conflicting ERCs/duplicate effort.

[sambacha]

That seems reasonable me and I'm happy to help with working on an ERC for this. I probably won't have the time to drive it forward for at least a few weeks though, unfortunately. @abigger87 Any chance you would be interesting in leading an ERC for this?

I know @sambacha mentioned in #31 he was working on EIP. I'm not sure if it was for this specifically or something else, but let's see what he says to avoid conflicting ERCs/duplicate effort.

Thanks for the mention, and hey @juanfranblanco - are you in the Wallet Core Devs Discord? The EIP usage is for verifying the correct response when switching to a new RPC provider endpoint that it is returning the correct data (chainid, etc).

I would be interested in making a more generic EIP, also specifically (or additionally) providing a json rpc method for eth_multicall (we use this for our own services actually).

Let me know if sounds within your ideal scope,

Cheers

[juanfranblanco]

@sambacha No I am not, what discord is that, is not in EthR&D? IMHO I don't think if fits on the wallet_multicall or eth_multicall as this is mainly a standard smart contract. So many users will be using not just from a wallet but for backend purposes, and again the smart contract may vary as we have seen here, it is in version 3. That is moving the responsibility to other layer, for example another scenario is that you may interact with the multicall smart contract from another smart contract at using an extended input to interact with it.

Edit: But ideally in the best of all worlds, it should be a precompiled for all chains, or something that can be verified if exists, which is the main issue. Maybe chains should have an overall configuration that is exposed, with the multicall smart contract address, do they support eip1559 etc. Other future use cases like Proof Of Humanity address. Etc as I am constantly having people asking questions from different chains, and these could be loaded from these.

Edit2: eth_chainInfo ?

[sambacha]

@sambacha No I am not, what discord is that, is not in EthR&D? IMHO I don't think if fits on the wallet_multicall or eth_multicall as this is mainly a standard smart contract. So many users will be using not just from a wallet but for backend purposes, and again the smart contract may vary as we have seen here, it is in version 3. That is moving the responsibility to other layer, for example another scenario is that you may interact with the multicall smart contract from another smart contract at using an extended input to interact with it.

Edit: But ideally in the best of all worlds, it should be a precompiled for all chains, or something that can be verified if exists, which is the main issue. Maybe chains should have an overall configuration that is exposed, with the multicall smart contract address, do they support eip1559 etc. Other future use cases like Proof Of Humanity address. Etc as I am constantly having people asking questions from different chains, and these could be loaded from these.

Edit2: eth_chainInfo ?

I will reach out to you on the R&D discord - and eth_chaininfo sounds so obvious you wonder why it already isn't a thing.
Additionally here is the eth_multicall RPC method I am referring to: covalenthq/erigon@7a70eb6

As for the backend usage, yes, I have seen Uniswap's usage for front end along with Sushiswap's. For reference, sushi's contract, https://github.com/boringcrypto/BoringFinance/blob/BentoBox-Support/contracts/BoringHelper.sol is great but its a pain not having a generic interface like uniswap's version here https://etherscan.io/address/0x1f98415757620b543a52e61c46b32eb19261f984#code

Though I think I am expanding the semantics of the canonical usage of multicall. Speak soon

[juanfranblanco]

@sambacha

Additionally here is the eth_multicall RPC method I am referring to: https://github.com/covalenthq/erigon/commit/7a70eb6ccb99eb242b066e23026de41f3bf70561

Ahh that is different, but also the same, I can see we will end up supporting all the versions, the contract, the node, etc. Also here is an example of adding paging on mine to avoid hammering the node, ie.. when doing 10000s of calls to get tokens balances.
https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Contracts/QueryHandlers/MultiCall/MultiQueryHandler.cs#L180