9. Extrinsics

9.1. Introduction

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.

9.2. Preliminaries

Definition 152. Extrinsic

An extrinsic , ${t}{x}$, is a tuple consisting of the extrinsic version, ${T}_{{v}}$ (Definition 153), and the body of the extrinsic, ${T}_{{b}}$.

$${t}{x}\:={\left({T}_{{v}},{T}_{{b}}\right)}$$

The value of ${T}_{{b}}$ varies for each version. The current version 4 is described in Section 9.3.1..

Definition 153. Extrinsic Version

${T}_{{v}}$ is a 8-bit bitfield and defines the extrinsic version. The required format of an extrinsic body, ${T}_{{b}}$, is dictated by the Runtime. Older or unsupported versions are rejected.

The most significant bit of ${T}_{{v}}$ indicates whether the transaction is signed (${1}$) or unsigned (${0}$). The remaining 7-bits represent the version number. As an example, for extrinsic format version 4, a signed extrinsic represents ${T}_{{v}}$ as 132 while an unsigned extrinsic represents it as 4.

9.3. Extrinsics Body

9.3.1. Version 4

Version 4 of the Polkadot extrinsic format is defined as follows:

$${T}_{{b}}\:={\left({A}_{{i}},{Sig},{E},{M}_{{i}},{F}_{{i}}{\left({m}\right)}\right)}$$

where

• ${A}_{{i}}$: the 32-byte address of the sender (Definition 154).

• ${Sig}$: the signature of the sender (Definition 155).

• ${E}$: the extra data for the extrinsic (Definition 156).

• ${M}_{{i}}$: the indicator of the Polkadot module (Definition 157).

• ${F}_{{i}}{\left({m}\right)}$: the indicator of the function of the Polkadot module (Definition 158).

Definition 154. Extrinsic Address

Account Id, ${A}_{{i}}$, is the 32-byte address of the sender of the extrinsic as described in the external SS58 address format.

Definition 155. Extrinsic Signature

The signature, ${Sig}$, is a varying data type indicating the used signature type, followed by the signature created by the extrinsic author. The following types are supported:

$$Sig := \begin{cases} 0, & \text{Ed25519, followed by: } (b_0, \ldots,b_{63}) \\ 1, & \text{Sr25519, followed by: } (b_0, \ldots,b_{63}) \\ 2, & \text{Ecdsa, followed by: } (b_0, \ldots,b_{64}) \end{cases}$$

Signature types vary in size, but each individual type is always fixed-size and therefore does not contain a length prefix. Ed25519 and 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 ${P}$.

$$\begin{aligned} P &:= \begin{cases} Raw, & \text{if } \|Raw\| \leq 256 \\ \text{Blake2}(Raw), & \text{if } \|Raw\| > 256 \\ \end{cases} \\ Raw &:= (M_i, F_i(m), E, R_v, F_v, H_h(G), H_h(B)) \end{aligned}$$

where

• ${M}_{{i}}$: the module indicator (Definition 157).

• ${F}_{{i}}{\left({m}\right)}$: the function indicator of the module (Definition 158).

• ${E}$: the extra data (Definition 156).

• ${R}_{{v}}$: 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.

• ${F}_{{v}}$: 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.

• ${H}_{{h}}{\left({G}\right)}$: a 32-byte array containing the genesis hash.

• ${H}_{{h}}{\left({B}\right)}$: a 32-byte array containing the hash of the block which starts the mortality period, as described in Definition 159.

Definition 156. Extra Data

Extra data, ${E}$, is a tuple containing additional metadata about the extrinsic and the system it is meant to be executed in.

$${E}\:={\left({T}_{mor},{N},{P}_{{t}}\right)}$$

where

• ${T}_{mor}$: contains the SCALE encoded mortality of the extrinsic (Definition 159).

• ${N}$: 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.

• ${P}_{{t}}$: a compact integer containing the transactor pay including tip.

Definition 157. Module Indicator

${M}_{{i}}$ is an indicator for the Runtime to which Polkadot module, ${m}$, the extrinsic should be forwarded to.

${M}_{{i}}$ is a varying data type pointing to every module exposed to the network.

$$M_i := \begin{cases} 0, & \text{System} \\ 1, & \text{Utility} \\ \ldots & \\ 7, & \text{Balances} \\ \ldots & \end{cases}$$

Definition 158. Function Indicator

${F}_{{i}}{\left({m}\right)}$ is a tuple which contains an indicator, ${m}_{{i}}$, for the Runtime to which function within the Polkadot module, ${m}$, the extrinsic should be forwarded to. This indicator is followed by the concatenated and SCALE encoded parameters of the corresponding function, ${p}{a}{r}{a}{m}{s}$.

$${F}_{{i}}{\left({m}\right)}\:={\left({m}_{{i}},{p}{a}{r}{a}{m}{s}\right)}$$

The value of ${m}_{{i}}$ varies for each Polkadot module since every module offers different functions. As an example, the Balances module has the following functions:

$$Balances_i := \begin{cases} 0, & \text{transfer} \\ 1, & \text{set\_balance} \\ 2, & \text{force\_transfer} \\ 3, & \text{transfer\_keep\_alive} \\ \ldots & \end{cases}$$

9.3.2. Mortality

Definition 159. 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 9.3.2.2..

The mortality mechanism works with two related values:

• ${M}_{{{per}}}$: the period of validity in terms of block numbers from the block hash specified as ${H}_{{h}}{\left({B}\right)}$ in the payload (Definition 155). The requirement is ${M}_{{{per}}}\geq{4}$ and ${M}_{{{per}}}$ must be the power of two, such as 32, 64, 128, etc.

• ${M}_{{{pha}}}$: 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 ${M}_{{{pha}}}<{M}_{{{per}}}$.

In order to tie a transaction’s lifetime to a certain block (${H}_{{i}}{\left({B}\right)}$) 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" (${M}_{{{pha}}}$) from these regular boundaries:

$${M}_{pha}={H}_{{i}}{\left({B}\right)} \; mod \; {M}_{{{per}}}$$

${M}_{{{per}}}$ and ${M}_{{{pha}}}$ are then included in the extrinsic, as clarified in Definition 156, in the SCALE encoded form of ${T}_{mor}$ (Section 9.3.2.2.). Polkadot validators can use ${M}_{{{pha}}}$ 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".

9.3.2.1. Example

The extrinsic author choses ${M}_{{{per}}}={256}$ at block 10'000, resulting with ${M}_{{{pha}}}={16}$. The extrinsic is then valid for blocks ranging from 10'000 to 10'256.

9.3.2.2. Encoding

${T}_{mor}$ refers to the SCALE encoded form of type ${M}_{{{per}}}$ and ${M}_{{{pha}}}$. ${T}_{mor}$ is the size of two bytes if the extrinsic is considered mortal, or simply one bytes with a value equal to zero if the extrinsic is considered immortal.

$${T}_{mor}\:={E}{n}{c}_{{{S}{C}}}{\left({M}_{{{per}}},{M}_{{{pha}}}\right)}$$

The SCALE encoded representation of mortality ${T}_{mor}$ 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 a value equal to zero.

Algorithm 25. Encode Mortality

\begin{algorithm}
\caption{Encode Mortality}
\begin{algorithmic}
    \Require{$M_{per}, M_{pha}$}
    \Return $0 \enspace \textbf{if} \enspace \textit{extrinsic is immortal}$
    \State \textbf{init} $factor = $\call{Limit}{$M_{per} \gg 12, 1, \phi$}
    \State \textbf{init} $left = $\call{Limit}{\call{TZ}{$M_{per}$}$ - 1, 1, 15$}
    \State \textbf{init} $right = \frac{M_{pha}}{factor} \ll 4$
    \Return $left|right$
\end{algorithmic}
\end{algorithm}

Algorithm 26. Decode Mortality

\begin{algorithm}
\caption{Decode Mortality}
\begin{algorithmic}
    \Require{$T_{mor}$}
    \Return $\textit{Immortal} \enspace \textbf{if} \enspace T^{b0}_{mor} = 0$
    \State \textbf{init} $enc = T^{b0}_{mor} + (T^{b1}_{mor} \ll 8)$
    \State \textbf{init} $M_{per} = 2 \ll (enc\ mod\ (1 \ll 4))$
    \State \textbf{init} $factor =$ \call{Limit}{$M_{per} \gg 12, 1, \phi$}
    \State \textbf{init} $M_{pha} = (enc \gg 4) * factor$
    \Return $(M_{per}, M_{pha})$
\end{algorithmic}
\end{algorithm}

where

• ${T}^{{{b}{0}}}_{\left\lbrace{mor}\right\rbrace}$: the first byte of ${T}_{mor}$.

• ${T}^{{{b}{1}}}_{\left\lbrace{mor}\right\rbrace}$: the second byte of ${T}_{mor}$.

• Limit(${num}$, ${min}$, ${max}$): Ensures that ${num}$ is between ${min}$ and ${max}$. If ${min}$ or ${max}$ is defined as $\phi$, then there is no requirement for the specified minimum/maximum.

• TZ(${num}$): returns the number of trailing zeros in the binary representation of ${num}$. For example, the binary representation of 40 is 0010 1000, which has three trailing zeros.

• $\gg$: performs a binary right shift operation.

• $\ll$: performs a binary left shift operation.

• ${\mid}$ : performs a bitwise OR operation.