Possible to listen events for HD Wallet addresses?

[helvenk]

As for simple dai contract, the official demo code like:

// Receive an event when ANY transfer occurs
daiContract.on("Transfer", (from, to, amount, event) => {
    console.log(`${ from } sent ${ formatEther(amount) } to ${ to}`);
    // The event object contains the verbatim log data, the
    // EventFragment and functions to fetch the block,
    // transaction and receipt and event functions
});

// A filter for when a specific address receives tokens
myAddress = "0x8ba1f109551bD432803012645Ac136ddd64DBA72";
filter = daiContract.filters.Transfer(null, myAddress)
// {
//   address: 'dai.tokens.ethers.eth',
//   topics: [
//     '0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef',
//     null,
//     '0x0000000000000000000000008ba1f109551bd432803012645ac136ddd64dba72'
//   ]
// }

// Receive an event when that filter occurs
daiContract.on(filter, (from, to, amount, event) => {
    // The to will always be "address"
    console.log(`I got ${ formatEther(amount) } from ${ from }.`);
});

How to listen so many sub addresses of HD Wallet ?

[ricmoo]

You will have to listen for each address you care about. There is no way to listen to an xpub key directly. And if you have too many events you may start getting throttled.

If you have a lot to pay attention to, it might make more sense to listen to all Transfer events and filter it in code.

When dealing with an HD wallet you may also want to adhere to the gap outlined in BIP-32.

[helvenk]

Thanks for your reply. If listening only the Transfer event for every sub addresses on Filter like:

const filter =daiContract.filters.Transfer(null, [addr1, addr2, ...])

Would it have some performance things or delaying or some others? And this way may have nothing to do with HD wallet.

And is there other way like listening xpub key as Bitcoin that you have heard to share with me? Such as other libraries or third api service.

[zemse]

Yes, you can derive the xpubkey and derive addresses from it. If your wallets lie on the path m/44'/60'/0'/0/${i}, then we reach the m/44'/60'/0'/0 node to generate the xpubkey. So that holders of the xpubkey can only derive addresses below it and not all of your addresses are given.

const { HDNode } = ethers.utils;

// in your wallet
const masterNode = HDNode.fromMnemonic('the mnemonic phrase')
const accountNode = masterNode.derivePath("m/44'/60'/0'/0");
const xpubkey = accountNode.neuter().extendedKey; // you can share this xpubkey with someone so they can derive addresses

// on the server who listens for event
const readOnlyNode = HDNode.fromExtendedKey(xpubkey);
const address0 = readNode.derivePath('0').address;
const address1 = readNode.derivePath('1').address;
// then listen for events using these addresses

[helvenk]

I just wonder if so many addresses(over thousands) in the listening list may have some performance problems? Or to listen the xpub key instead of addresses, maybe not ethers.js but other libraries can do it?

[zemse]

I just wonder if so many addresses(over thousands) in the listening list may have some performance problems?

I think listening for logs for a huge number of addresses should linearly experience performance problems. Since using the contract.on ethers.js API, throwing up a lot of listeners would trigger a lot of requests for each pooling interval.

Or to listen the xpub key instead of addresses, maybe not ethers.js but other libraries can do it?

xpubkey is not directly accepted by any standard ethereum RPC methods. Any mods on an ethereum node can allow them to accept xpubkey through a non-standard RPC.

However, getLogs RPC API that an ethereum node provides also accepts an array of addresses. contract.on uses this under the hood.

So if you directly use eth_getLogs call, you can query events for multiple ERC20 tokens as well as user addresses, between two given block numbers.

const logs = await provider.send('eth_getLogs', [{
  address: ['0x12..', '0x34..'], // erc20 contract addresses
  fromBlock,
  toBlock,
  topics: [
    ethers.utils.id('Transfer(address,address,uint256)'),
    null,
    ['0x56..', '0x78..'] // user addresses
  ]
}])

AFAIR, there is even a limit to a request length that a node can accept meaning if you just put 1000s of addresses, there is a network error that says huge request. There could be a way to change the server settings to allow huge requests, but I just had a few thousands of addresses to listen to, so I broke them into chunks of 200 addresses for listening. But in your case, seems you can even have millions of addresses to listen to. If you are short on server resources, you can simply increase the query interval to span across multiple blocks. This would result in some amount of delay for knowing an incoming transfer.

[helvenk]

So kind of you, I truly appreciate your help. Now I have learned more informations and I'll have a try then.

Maybe I don't have so much addresses to listen, hundreds enough. But some Exchanges like Binance、CoinBase would work it out, that's why I asking for a better way to subscribe transfer event for HD wallet.