the API eth.getPastLogs() requires 4 topics to match the log indexing capabilities of the EVM. It appears to require a full 32 byte number for the match to work. i.e.

eth.getPastLogs((fromBlock:0, toBlock: 'latest', address '0xabc',
    topics: [ null, '0x25', null, null ] })

will not find a topic that has


in it

but this will match said topic:

eth.getPastLogs((fromBlock:0, toBlock: 'latest', address '0xabc',
    topics: [ null,'0x0000000000000000000000000000000000000000000000000000000000000025', null, null ] })

So first question - is this a bug, and second question, how do I get bignumber.js to force an output of all 32 bytes? toString(16) doesn't give me the leading zeros or the '0x'. Do I have to write a special function or is there one there already in web3.js and I just can't find it?


Is it a bug? Possibly, but if so it's a won't-fix: https://github.com/ethereum/web3.js/issues/431

How to get the appropriate 32-byte padding for a BigNumber? As you suggest it feels like there should be a function to do this in web3.js, but the simple solution is just to do something like:

function bigNumberToPaddedBytes32(num) {
    var n = num.toString(16).replace(/^0x/, '');
    while (n.length < 64) {
        n = "0" + n;
    return "0x" + n;
  • so in the absense of an ABI (such as with getPastLogs)everything is treated as bytes32... good to know... – Paul S Sep 28 '17 at 13:10

I upvoted the above answer but it will soon be out of date because web3.js in v1.0 exposes the padding functions. It's better not to reinvent the wheel.

So my code looks like this:

topic = '0x' + web3.utils.padLeft(new BigNumber(someNumber).toString(16), 64);

BigNumber BN.j library also have length argument in toString(base, length) method:

topic = '0x' + new web3.utils.BN(someNumber).toString(16, 64);

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.