Have a look here Understanding transactions better
Full nodes listen and broadcast transactions. As a full node you receive and can display the pending transactions in your transaction pool. That's what etherscan does. Maybe you can't access it through their API, their choice.
So you can get some of the pending transactions as a node, but you don't get to choose, and most likely some transactions will have been included in a block before they reach you in a pending state.
To answer the first part of your first question:
Are all ERC-20 token transfers are listed with the "0xddf252..." sha3 hash, and would the below code suffice for accurately capturing those transfers?
As far as I know, the ERC20 standard dictates the prototype of the transfer
function, but it doesn't dictate the prototype of the Transfer
event (or even the fact that this function should emit an event to begin with).
I might be wrong here, as evidently, OpenZeppelin have declared this event in their IERC20 interface:
event Transfer(address indexed from, address indexed to, uint256 value);
In either case, even if this event is not part of the ERC20 standard, it is widely acceptable to rely on it being emitted as a result of ERC20-token transfer operations.
A technical suggestion:
If you're using web3.js v1.x, then I recommend that you use this instead of that hard-coded value:
const tokenTransferHash = Web3.utils.keccak256("Transfer(address,address,uint256)");
Of course, you can initialize it once (i.e., in global scope, outside of any function).
To answer the second part of your first question:
Is there a separate function for new tokens minted, or is it safe to assume all newly minted tokens come from the '0x000000...' address?
The ERC20 standard does not state that a mint
function should be implemented to begin with.
So any ERC20-token contract which implements this function, is in fact extending the standard.
That said, it is widely acceptable that mint
functions emit a Transfer
event with the source address being zero, and that burn
functions (also not part of the standard) emit a Transfer
event with the target address being zero.
Of course, you should not rely on this fact without verifying it in the implementation of the contract that you're targeting.
Best Answer
This can be done by checking
For example, take a look at the transaction below, notice the 'to' field and 'contractAddress' field.