Skip to main content

Types of Transactions (a.k.a. Extrinsics)

Pallets and Extrinsics​

Kusama is built using Substrate, a modular framework to efficiently build blockchains. Substrate's FRAME development environment provides modules called pallets and support libraries that you can use, modify, and extend to build the runtime logic to suit the needs of your blockchain. You can explore Substrate's FRAME pallets on this dedicated page.

Within each functional pallet on the blockchain, one can call its functions and execute them successfully, provided they have the permission to do so. Because these calls originate outside of the blockchain runtime, such transactions are referred to as extrinsics. Extrinsics normally contain a signature, some data to describe if the extrinsic has passed some validity checks and a reference to the pallet and call that it is intended for. For example, the Staking pallet contains all functions related to staking. A nominator can bond funds and nominate validators by issuing the respective extrinsics. Some extrinsics might also trigger an event on the chain such as a reward payout to the nominators.

Types of Extrinsics​

Now that we introduced the term extrinsic, let us dive deeper and understand what extrinsics really are. Extrinsics can be one of 3 distinct types:

  • Signed transactions: these must contain the signature of the account sending the inbound request to the runtime. With signed transactions, the account used to submit the request typically pays the transaction fee and must sign it using the account's private key.
  • Unsigned transactions: these don't carry any information about who submitted the transaction, since the format of this type of transaction doesn't require a signature. You can define what conditions must be met for such a transaction to be valid.
  • Inherents: are a special type of unsigned transaction made by block authors which carry information required to build a block such as timestamps, storage proofs and uncle blocks.

Signed transactions is the way that most users will interact with Kusama. Signed transactions come from an account that has funds, and therefore Kusama can charge a transaction fee as a way to prevent spam.

Unsigned transactions are for special cases where a user needs to submit an extrinsic from a key pair that does not control funds. For example, validators submit unsigned transactions in the form of "heartbeat" messages to indicate that they are online. These heartbeats must be signed by one of the validator's session keys. Session keys never control funds. Unsigned transactions are only used in special cases because, since Kusama cannot charge a fee for them, each one needs its own, custom validation logic.

Inherents are pieces of information that are not signed or included in the transaction queue. As such, only the block author can add inherents to a block. Inherents are assumed to be "true" simply because a sufficiently large number of validators have agreed on them being reasonable. For example, Kusama blocks include a timestamp inherent. There is no way to prove that a timestamp is true the way one proves the desire to send funds with a signature. Rather, validators accept or reject the block based on how reasonable they find the timestamp. In Kusama, it must be within some acceptable range of their own system clocks.

Here are some key differences between the different types of extrinsics:

  • Contrary to signed transactions, unsigned transaction types require implementing custom validation logic which can consume more resources for checking validity compared to signed transactions.
  • Unsigned transactions have no economic deterrent to prevent spam or replay attacks, so custom logic must account for protecting the network from these types of transactions being misused.
  • Inherents exist to address the need of adding some data to a block, whereas signed or unsigned transactions exist to potentially change the state of the blockchain.

Mortal and Immortal Extrinsics​

Transactions are generally irreversible once confirmed and added to the blockchain, an immutable ledger of all transactions. This means users must exercise caution, as mistakes such as sending KSM to the wrong address cannot be reverted. The permanence of transactions highlights the importance of careful verification before signing any transaction on a blockchain network. It is usually a good practice not to blind sign transactions to avoid being victim of an attack.

In blockchain terms, transactions can be mortal extrinsics (i.e. valid within a defined block interval, usually short), or immortal extrinsics (i.e. always valid). It is possible to make immortal transactions on Kusama. However, for security reasons, it is highly recommended not to do so and most wallet software will not allow you to make an immortal extrinsic.

Balance Transfers​

Balance transfers are transfers of token balances between accounts. This is the most well-known type of transfer.

Vested Transfers​

KSM may have a lock placed on them to account for vesting funds. Like other types of locks, these funds cannot be transferred but can be used in other parts of the protocol such as voting in governance or being staked as a validator or nominator.

Vesting funds are on a release schedule and unlock a constant number of tokens at each block (linear vesting) or can unlock the full amount after a specific block number (cliff vesting).

Verifying Extrinsics​

danger

Do not sign a transaction if you can't verify what you are signing or you suspect you might be signing a different extrinsic than the one intended.

Verifying the extrinsic you are signing can take some more time before signing for a transaction but it allows you to add an extra security step. There are a multitude of possible attacks that will prevent you to send funds to the desired destination account.

Shard Transactions​

The transactions that take place within Kusama's shards - parachains and parathreads - do not incur Relay Chain transaction fees. Users of shard applications do not even need to hold DOT tokens, as each shard has its own economic model and may or may not have a token. There are, however, situations where shards themselves make transactions on the Relay Chain.

Parachains have a dedicated slot on the Relay Chain for execution, so their collators do not need to own DOT in order to include blocks. The parachain will make some transactions itself, for example, opening or closing an XCM channel, participating in an auction to renew its slot, or upgrading its runtime. Parachains have their own accounts on the Relay Chain and will need to use those funds to issue transactions on the parachain's behalf.

Parathreads will also make all the same transactions that a parachain might. In addition, the collators need to participate in an auction every block to progress their chain. The collators will need to have DOT to participate in these auctions.

Block Limits and Transaction Priority​

Blocks in Kusama have both a maximum length (in bytes) and a maximum weight. Block producers will fill blocks with transactions up to these limits. A portion of each block - currently 25% - is reserved for critical transactions that are related to the chain's operation. Block producers will only fill up to 75% of a block with normal transactions. Some examples of operational transactions:

  • Misbehavior reports
  • Council operations
  • Member operations in an election (e.g. renouncing candidacy)

Block producers prioritize transactions based on each transaction's total fee. Since a portion of the fee will go to the block producer, producers will include the transactions with the highest fees to maximize their reward.

Polkadot-JS Guides

If you are an advanced user, see the Polkadot-JS guides about transfers.

Last updated on by Filippo