In the source code where transaction mortality is defined, the comments say:

Create a new era based on a period (which should be a power of two between 4 and 65536 inclusive) and a block number on which it should start (or, for long periods, be shortly after the start).

However, the Polkadot Wiki states that:

The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period...

...The BlockHashCount parameter store on-chain is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against.

First, why is the period value mapped to a power of 2 for an era in a mortal transaction?

Secondly, can I set a value larger than 2400 for the period of my transaction mortality?

1 Answer 1


The reasoning behind the first question is basically compactness for transaction serialization. The whole mortal/immortal info fits into 2 bytes. The first being an Enum variant for Mortal(blocks) or Immortal. So immortal transactions just use one byte, whereas mortals use 2, being the second byte the mortality. The point is that 1 byte can only represent 256 values, hence the mortality is given by 2 ** (byte_value). And the implementation will always round to the next upper power of 2 for any input value for the period (f.e., 2500 --> 4096).

Moving to the second question, the transaction needs to reference a BlockHash in the state, as said by the wiki. The runtime stores a map of BlockHash => BlockNumber for the previous BlockHashCount number of blocks in a FIFO queue. BlockHashCount is a system parameter currently set to 2400 in Polkadot and Kusama. So with this runtime parameter, 4096 is the highest "real" value you can set mortality to, however it may still fail after 2400 blocks with AncientBirthBlock error message.

(Kudos to @joepetrowski for the relevant info for this answer)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.