.hash => Hash
getter, we can simply use this to view the actual hash.
getHeader
, which once again returns a header extended with the author:
.toHuman()
is used to format the extrinsic into a human-readable representation. You can inspect/extract specific fields from the decoded extrinsic as required. For instance ex.method.section
would return the pallet that executed this transaction.
phase
is an enum that would be isApplyExtrinsic
with the index in the cases where it refers to an extrinsic in a block. This index maps through the order of the extrinsics as found.
To perform a mapping between the two, we need information from from both sources, as per the example below.
system.ExtrinsicSuccess
and system.ExtrinsicFailed
events. The same logic can be applied to inspect any other type of expected event.
.entries()/.keys()
on double maps?.entries()
retrieving (StorageKey, Codec)[]
and .keys()
retrieving StorageKey[]
EraIndex
):
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.
.signAndSend
, the callback yields information around the tx pool status as well as any events when isInBlock
or isFinalized
. If an extrinsic fails via system.ExtrinsicFailed
event, you can retrieve the error if defined as an enum on a module.
@polkadot/api
2.3.1 additional result fields are exposed. Firstly there is dispatchInfo: DispatchInfo
which occurs in both ExtrinsicSuccess
& ExtrinsicFailed
events. Additionally, on failures the dispatchError: DispatchError
is exposed. With this in mind, the above example can be simplified to be:
Sudid(result)
, where 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:
.send
on it (no .sign
or .signAndSend
), so it will be sent using the unsigned state without the signature attached.
Note: The status event is only available on providers that support subscriptions, such as WSProvider
or ScProvider
. On HttpProvider
, which does not have bi-directional capabilities. There are no subscriptions, so it cannot listen to the events that are emitted by the transaction pool. In the case of HttpProvider
the result, object returned will always be the non-unique transaction hash.
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 many 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 several transfers at once or batch different types of transactions.
.paymentInfo
helper method described earlier, and it is usually less than the sum of the fees for each transaction.
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 with the same nonce that signAndSend
would apply - this call does not do any magic. It simply reads the state for the nonce. Since we can specify options for the signAndSend
operation, we can override the nonce, either by manually incrementing it or querying it via rpc.system.accountNextIndex
.
accountNextIndex
can be omitted by specifying a nonce of -1
, allowing the API to do the lookup. In this case, the above example can be simplified even further: