provider.on misunderstanding

[msweb3]

topicSets = [
    utils.id("Transfer(address,address,uint256)"),
    null,
    [
        hexZeroPad(myAddress, 32),
        hexZeroPad(myOtherAddress, 32)
    ]
]
provider.on(topicSets, (log) => {
   console.log(log);
})

1. Should I use WebSocket ?
2. and ethers.js v6 doesn't have ethers.utils and hexZeroPad.. code provided BELOW is correct ?

let topicSets = [
  ethers.id("Transfer(address,address,uint256)"),
  null,
  [
    ethers.zeroPadValue("0x18Bdd742BE01302Ad33c9cDC8CD689F30659c887", 32),
    ethers.zeroPadValue("0x3a92BC78554207eBac9A4758FE3035AD96A1408e", 32),
  ],
];

[msweb3]

Oh, is it only for checking TOKEN transfers ? How can I use it for ETH transfers ?

[ricmoo]

There is no way to detect ETH transfers in Ethereum without building a custom solution. Transferring ETH doesn’t place any value in the bloom filter for the block, so it doesn’t get indexed. It would also be difficult to track, as internally contracts can send ether along with any call.

You might look into TheGraph, which may be able to generate an index for you.

[msweb3]

also is it possible to update address list dynamically ?

[
    ethers.zeroPadValue("0x18Bdd742BE01302Ad33c9cDC8CD689F30659c887", 32),
    ethers.zeroPadValue("0x3a92BC78554207eBac9A4758FE3035AD96A1408e", 32),
  ],

[ricmoo]

No, the filter is serialized at the time you listen to specifically prevent people accidentally mutating something and having it start returning inconsistent data.

In most cases the filter is loaded remotely as well, so mutating the original JavaScript object would be further removed from where the change would be necessary.

If I understand correctly?

[msweb3]

https://gist.github.com/mosquitoms/d50d8ad88318cc568a1fb25d18a7eba1

Something like this

[ricmoo]

Yes that is fine. I guess I didn’t understand what you meant by dynamic. Whatever you pass in will be the filter. :)

[ricmoo]

Your conversion to v6 looks perfect. You can use WebSocketProvider, but you can use any provider. I usually use a normal JsonRpcProvider (which uses http), as it doesn’t rely on any special server infrastructure and is more resilient since it doesn’t require long-lived connects (which can fail if an intermediate service hiccups).