An extrinsic is a SCALE encoded array consisting of a version number, signature, and varying data types indicating the resulting Runtime function to be called, including the parameters required for that function to be executed.
Definition 142. Extrinsic
An extrinsic , , is a tuple consisting of the extrinsic version, (Definition 143), and the body of the extrinsic, .
The value of varies for each version. The current version 4 is described in Section 9.3.1..
Definition 143. Extrinsic Version
is a 8-bit bitfield and defines the extrinsic version. The required format of an extrinsic body, , is dictated by the Runtime. Older or unsupported version are rejected.
The most significant bit of indicates whether the transaction is signed () or unsigned (). The remaining 7-bits represent the version number. As an example, for extrinsic format version 4, an signed extrinsic represents as
132 while a unsigned extrinsic represents it as
9.3. Extrinsics Body
9.3.1. Version 4
Version 4 of the Polkadot extrinsic format is defined as follows:
: the 32-byte address of the sender (Definition 144).
: the signature of the sender (Definition 145).
: the extra data for the extrinsic (Definition 146).
: the indicator of the Polkadot module (Definition 147).
: the indicator of the function of the Polkadot module (Definition 148).
Definition 144. Extrinsic Address
Account Id, , is the 32-byte address of the sender of the extrinsic as described in the external SS58 address format.
Definition 145. Extrinsic Signature
The signature, , is a varying data type indicating the used signature type, followed by the signature created by the extrinsic author. The following types are supported:
Signature types vary in sizes, but each individual type is always fixed-size and therefore does not contain a length prefix.
Sr25519 signatures are 512-bit while
Ecdsa is 520-bit, where the last 8 bits are the recovery ID.
The signature is created by signing payload .
: the module indicator (Definition 147).
: the function indicator of the module (Definition 148).
: the extra data (Definition 146).
: a UINT32 containing the specification version (
spec_version) of the Runtime (Section C.4.1.), which can be updated and is therefore subject to change.
: a UINT32 containing the transaction version (
transaction_version) of the Runtime (Section C.4.1.), which can be updated and is therefore subject to change.
: a 32-byte array containing the genesis hash.
: a 32-byte array containing the hash of the block which starts the mortality period, as described in Definition 149.
Definition 146. Extra Data
Extra data, , is a tuple containing additional meta data about the extrinsic and the system it is meant to be executed in.
: contains the SCALE encoded mortality of the extrinsic (Definition 149).
: a compact integer containing the nonce of the sender. The nonce must be incremented by one for each extrinsic created, otherwise the Polkadot network will reject the extrinsic.
: a compact integer containing the transactor pay including tip.
Definition 147. Module Indicator
is an indicator for the Runtime to which Polkadot module, , the extrinsic should be forwarded to.
is a varying data type pointing to every module exposed to the network.
Definition 148. Function Indicator
is a tuple which contains an indicator, , for the Runtime to which function within the Polkadot module, , the extrinsic should be forwarded to. This indicator is followed by the concatenated and SCALE encoded parameters of the corresponding function, .
The value of varies for each Polkadot module, since every module offers different functions. As an example, the
Balances module has the following functions:
Definition 149. Extrinsic Mortality
Extrinsic mortality is a mechanism which ensures that an extrinsic is only valid within a certain period of the ongoing Polkadot lifetime. Extrinsics can also be immortal, as clarified in Section 22.214.171.124..
The mortality mechanism works with two related values:
: the period of validity in terms of block numbers from the block hash specified as in the payload (Definition 145). The requirement is and must be the power of two, such as
: the phase in the period that this extrinsic’s lifetime begins. This value is calculated with a formula and validators can use this value in order to determine which block hash is included in the payload. The requirement is .
In order to tie a transaction’s lifetime to a certain block () after it was issued, without wasting precious space for block hashes, block numbers are divided into regular periods and the lifetime is instead expressed as a "phase" () from these regular boundaries:
and are then included in the extrinsic, as clarified in Definition 146, in the SCALE encoded form of (Section 126.96.36.199.). Polkadot validators can use to figure out the block hash included in the payload, which will therefore result in a valid signature if the extrinsic is within the specified period or an invalid signature if the extrinsic "died".
The extrinsic author choses at block
10'000, resulting with . The extrinsic is then valid for blocks ranging from
refers to the SCALE encoded form of type and . is the size of two bytes if the extrinsic is considered mortal, or simply one bytes with the value equal to zero if the extrinsic is considered immortal.
The SCALE encoded representation of mortality deviates from most other types, as it’s specialized to be the smallest possible value, as described in Encode Mortality and Decode Mortality.
If the extrinsic is immortal, specify a single byte with the value equal to zero.
Algorithm 25. Encode Mortality
Algorithm 26. Decode Mortality
: the first byte of .
: the second byte of .
Limit(, , ): Ensures that is between and . If or is defined as , then there is no requirement for the specified minimum/maximum.
TZ(): returns the number of trailing zeros in the binary representation of . For example, the binary representation of
0010 1000, which has three trailing zeros.
: performs a binary right shift operation.
: performs a binary left shift operation.
: performs a bitwise OR operation.