The callback function is executed when the Node sends the transaction hash back to your process.
This typically happens almost immediately, and as such, it does not indicate that the transaction has been mined; you still need to take the transaction hash and use it in order to obtain the receipt; furthermore, you still need to take that receipt and wait for several confirmations of your transaction (where 12 confirmations are considered as a proof of your transaction permanently added to the blockchain).
The on
function allows you to wait for the transaction hash or for the receipt or for each confirmation.
So it generally provides a wider range of options; see this coding example (it is given for function sendTransaction
, but I believe that it works the same for function sendSignedTransaction
).
Here is a better explanation that I've come up with:
Function sendSignedTransaction
returns a Promise
object.
This object has an on
function which can handle either one of the following events:
'transactionHash'
'receipt'
'confirmation'
'error'
If you pass a callback to function sendSignedTransaction
, then before this function returns the Promise
object, it handles the 'transactionHash'
and 'error'
events for you.
So in essence, this:
web3.eth.sendSignedTransaction(transaction, (err, hash) => {console.log(hash)})
Is equivalent to this:
web3.eth.sendSignedTransaction(transaction)
.on('transactionHash', (hash) => {console.log(hash)})
.on('error', (err) => {})
Note that this "chaining" of on
function-calls is made possible by the fact that the on
function returns the Promise
object after handling the specified event.