Following up from this question:

What exactly prevents multiple of the same calls to a weighted unsigned extrinsic from sequentially filling up a block and not leaving any room for any other transactions?

It looks like unsigned transactions should be configured to take a higher "base" priority:

..which makes sense because signed transactions include fees (and sometimes tips) which affect priority.

Is it a case of transaction priority or transaction validity due to the fact that an unsigned transaction has a nonce of zero?

1 Answer 1


Unsigned transactions should include some ValidateUnsigned logic which is used in the transaction queue to determine if an unsigned transaction should even be included in the block.

You can find an example of that here for the Claims Pallet: https://github.com/paritytech/polkadot/blob/master/runtime/common/src/claims.rs#L467

impl<T: Config> ValidateUnsigned for Pallet<T> {
    type Call = Call<T>;
        fn validate_unsigned(_source: TransactionSource, call: &Self::Call) -> TransactionValidity {

        // Verification logic here.
        // Must be lightweight so it does not take any significant weight,
        // else a transaction spammer could attack this chain.

        Ok(ValidTransaction {
            priority: PRIORITY,
            requires: vec![],
            provides: vec![("claims", signer).encode()],
            longevity: TransactionLongevity::max_value(),
            propagate: true,

This validate_unsigned function must be very lightweight since it will be processed for every unsigned transaction which matches the verification logic.

But ultimately, if you do not have an appropriate validate_unsigned logic, then yes, your chain can totally be filled up by unsigned transactions. So unsigned transactions are only appropriate where you can guarantee how many of them there will be that is valid, and that it wont DDOS your chain

Two examples:

  1. Allow up to N unsigned transaction per block. Reject the rest until the next block.
  2. Allow up to N users 1 free unsigned transaction. After which, the unsigned transaction is not valid anymore. (This is what happens in claims pallet)
  • Can we get the AccountId of the sender that sent the unsigned transaction ? Aug 26, 2022 at 7:56
  • 1
    no, it is not signed. there is no associated account id by definition.
    – Shawn Tabrizi
    Aug 26, 2022 at 9:50
  • I see, so is there a way that I can use to keep track of the user that has made the unsigned transaction ?? For example - I want to prevent spamming or DDOS attacks so I am thinking of adding a 'waiting time' for that user to call the extrinsic again. Is there a way through which I can achieve it ? Aug 26, 2022 at 10:08
  • it is unsigned... what you are asking for are the features of signed transactions
    – Shawn Tabrizi
    Aug 26, 2022 at 10:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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