A blockchain is no fun if you are not submitting transactions. Or at least if somebody is not submitting any. Here you will find some snippets for dealing with some common issues.
In addition to the
signAndSend helper on transactions,
.paymentInfo (with the exact same parameters) are also exposed. Using the same sender, it applies a dummy signature to the transaction and then gets the fee estimation via RPC.
Assuming you are sending a tx via
.signAndSend, the callback yields information around the tx pool status as well as any events when
isFinalized. If an extrinsic fails via
system.ExtrinsicFailed event, you can retrieve the error, if defined as an enum on a module.
As of the
@polkadot/api 2.3.1 additional result fields are exposed. Firstly there is
dispatchInfo: DispatchInfo which occurs in both
ExtrinsicFailed events. Additionally, on failures the
dispatchError: DispatchError is exposed. With this in mind, the above can be simplified to be -
The section above shows you how to listen for the result of a regular extrinsic. However, Sudo extrinsics do not directly report the success or failure of the underlying call. Instead, a Sudo transaction will return
result will be the information you are looking for.
To properly parse this information, we will follow the steps above, but then specifically peek into the event data to find the final result:
For most runtime modules, transactions need to be signed and validation for this happens node-side. There are however modules that accepts unsigned extrinsics, an example would be the Polkadot/Kusama token claims (which is here used as an example).
The signing is indicated by the first byte in the transaction, so in this case we have called
.send on it (no
.signAndSend), so it will be sent using the unsigned state, without signature attached.
Polkadot/Substrate provides a
utility.batch method that can be used to send a number of transactions at once. These are then executed from a single sender (single nonce specified) in sequence. This is very useful in a number of cases, for instance if you wish to create a payout for a validator for multiple eras, you can use this method. Likewise, you can send a number of transfers at once. Or even batch different types of transactions.
system.account query will always contain the current state, i.e. it will reflect the nonce for the last known block. As such when sending multiple transactions in quick succession (see batching above), there may be transactions in the pool that has the same nonce that
signAndSend would apply - this call doesn't do any magic, it simply reads the state for the nonce. Since we can specify options to the
signAndSend operation, we can override the nonce, either by manually incrementing it or querying it via
As a convenience function, the
accountNextIndex can be omitted by specifying a nonce of
-1, allow the API to do the lookup. In this case the above can be simplified even further,
The latter form is preferred since it dispatches the RPC calls for nonce and blockHash (used for mortality) in parallel and therefore will yield a better throughput, especially with the above bulk example.