# 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}}$ is the multi-address of the sender defined in 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).

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.