RFC: Deferred Dispatch for `pallet-whitelist`

[muharem]

Summary

Extend pallet-whitelist so that dispatch_whitelisted_call and dispatch_whitelisted_call_with_preimage automatically defer execution when the call is not yet whitelisted, instead of failing. The deferred call can be dispatched later by anyone once the whitelist entry arrives, or cleaned up after expiration.

Problem

Today, dispatch_whitelisted_call* requires the call to already be whitelisted at the time of dispatch. This creates a sequencing problem in governance:

1. A governance proposal to dispatch a whitelisted call can only succeed if the whitelist entry is already in place.
2. If the whitelist entry hasn't been set yet (e.g., the Fellowship hasn't whitelisted it), the governance-enacted dispatch simply fails and is lost.
3. There is no mechanism to "park" an authorized dispatch and have it execute once the whitelist condition is met.

This forces tight coordination between the whitelisting body (e.g., Fellowship) and the dispatching body (e.g., general governance referendum), with no tolerance for ordering mismatches.

Details

Current Architecture

pallet-whitelist has two origin types:

• WhitelistOrigin — can whitelist/remove call hashes (typically the Fellowship).
• DispatchWhitelistedOrigin — can dispatch a whitelisted call with root origin (typically governance referenda).

The current calls are:

• whitelist_call(call_hash) — adds a call hash to the whitelist.
• remove_whitelisted_call(call_hash) — removes a call hash from the whitelist.
• dispatch_whitelisted_call(call_hash, call_encoded_len, call_weight_witness) — dispatches a whitelisted call from preimage storage.
• dispatch_whitelisted_call_with_preimage(call) — dispatches a whitelisted call with inline preimage.

All dispatch calls require the call to be present in the WhitelistedCall storage map at the time of execution. If the call is not whitelisted, the dispatch fails and the governance authorization is lost permanently.

The Sequencing Problem

Consider the typical governance flow:

1. Fellowship whitelists a call hash via whitelist_call.
2. A public referendum enacts dispatch_whitelisted_call for that hash.

If step 2 is enacted before step 1, the dispatch fails permanently. The referendum has already been decided and enacted — its authorization is consumed and lost. There is no retry mechanism.

Proposal

Modified Behavior of dispatch_whitelisted_call and dispatch_whitelisted_call_with_preimage

Both existing dispatch calls are modified with two changes:

1. Automatic deferral when not yet whitelisted

When called with DispatchWhitelistedOrigin and the call is not yet whitelisted, instead of returning an error, the call is stored as a deferred dispatch:

• Stores the call hash in the DeferredDispatch storage map with expire_at = now + T::DeferredDispatchExpiration.
• For dispatch_whitelisted_call_with_preimage, the preimage is noted in the preimage store via T::Preimages::note so it is available for later dispatch.
• Emits DispatchDeferred { call_hash }.
• Returns actual weight reflecting only the deferral cost.

2. Relaxed origin when a deferred entry exists

The origin check is relaxed:

• Current: Requires DispatchWhitelistedOrigin.
• New: Requires DispatchWhitelistedOrigin OR any origin if a DeferredDispatch entry exists for the call hash and not expired.

This allows anyone (including pallet origins) to trigger dispatch of a deferred call once it has been whitelisted, without needing to go through governance again.

The call must still be present in the WhitelistedCall storage — this requirement is unchanged.

When a deferred entry exists and the call is dispatched, the deferred entry is cleaned up as part of clean_and_dispatch.

New Call: remove_deferred_dispatch

#[pallet::call_index(4)]
pub fn remove_deferred_dispatch(
    origin: OriginFor<T>,
    call_hash: T::Hash,
) -> DispatchResultWithPostInfo

• Origin: any signed origin (permissionless).
• Behavior:
  • Fails if no deferred entry exists for call_hash (DeferredDispatchNotFound).
  • Fails if the entry has not yet expired (DeferredDispatchNotExpired).
  • Removes the entry from DeferredDispatch storage.
  • Emits DeferredDispatchRemoved { call_hash }.
  • Refunds transaction fees on success to incentivize cleanup.

New Config Parameter

/// The expiration duration for deferred dispatches. When a dispatch is
/// deferred, it expires at `now + DeferredDispatchExpiration`. After
/// expiration, anyone can remove the deferred entry via
/// `remove_deferred_dispatch`.
type DeferredDispatchExpiration: Get<BlockNumberFor<Self>>;

New Storage

/// Map of call hashes to their deferred dispatch expiration block.
#[pallet::storage]
pub type DeferredDispatch<T: Config> =
    StorageMap<_, Twox64Concat, T::Hash, BlockNumberFor<T>, OptionQuery>;

New Events

/// A dispatch was deferred for future execution because the call
/// was not yet whitelisted.
DispatchDeferred { call_hash: T::Hash },
/// A deferred dispatch entry was removed after expiration.
DeferredDispatchRemoved { call_hash: T::Hash },

New Errors

/// No deferred dispatch entry exists for this call hash.
DeferredDispatchNotFound,
/// The deferred dispatch entry has not yet expired.
DeferredDispatchNotExpired,

Conclusion

This proposal adds automatic deferred dispatch to pallet-whitelist by modifying the two existing dispatch calls. When a governance-authorized dispatch arrives before the whitelist entry, it is silently stored instead of failing. The deferred call can then be triggered by anyone once whitelisted, or cleaned up after expiration.

[muharem]

do not implement until there is no consensus

[ggwpez]

Yes, I think this would work.

The alternative is that the dispatch would not discard the call when it was not yet whitelisted, but would put it into a retry map.

The upside is that we don't need to change our tooling to create referenda or anything but the downside is that they will all have a fixed timeout (but we could add a function to adjust the timeout, if needed).

@bkchr wdyt?

[bkchr]

The alternative is that the dispatch would not discard the call when it was not yet whitelisted, but would put it into a retry map.

Yeah this is what I meant in my comment in the other issue. Basically, first check if the whitelisted hash exists, if not we put it into a map and wait. The whitelist would directly check the map if the dispatchable is there.

[muharem]

@ggwpez @bkchr sounds good. I have updated the proposal

[bkchr]

2. Relaxed origin when a deferred entry exists

The origin check is relaxed:

* **Current:** Requires `DispatchWhitelistedOrigin`.

* **New:** Requires `DispatchWhitelistedOrigin` **OR** any origin if a `DeferredDispatch` entry exists for the call hash and not expired.

I don't get this, why we need this? The deferred call should be automatically dispatched when the whitelist comes in.

Also we could maybe just make the removal automatic after the timeout has expired.

[muharem]

@bkchr I generally follow the single responsibility principle - that's why the first version had a separate defer_dispatch call, and why I avoided overloading whitelist_call with a dispatch path.

There's also a practical concern: making whitelist_call dispatch a deferred call would require extending its signature with at least a weight witness argument to account for the dispatch weight. We could store call_encoded_len alongside the deferred entry to avoid passing it again, but the resulting API feels incoherent to me.

Regarding automatic expiration cleanup. I follow the principle Gav has communicated ones - if something can be triggered off-chain, don't use on-chain hooks (like on_idle) for it. Which also make sense to me. That's why I used remove_deferred_dispatch, a permissionless extrinsic rather than an automatic hook.

[bkchr]

Yeah okay, as this is here some niche use case. Let's do what you proposed. We will any way need to interact with the chain from the outside.

[jessechejieh]

@bkchr @muharem @ggwpez it's my understanding that consensus has been reached, working on an impl here.

[bkontur]

I'd like to raise a related question about whether this RFC could be scoped slightly wider to also cover a cross-chain large-call dispatch use case we've been solving ad-hoc.

The generic problem

When a call originates on chain A (e.g. AssetHub, post-AHM) but must execute on chain B (e.g. the relay chain), and the call carries a large payload (Wasm blob, preimage, etc.), we don't want to ship the full payload over XCM. The natural pattern is:

1. Chain A authorizes a call_hash on chain B (tiny XCM message)
2. Anyone submits the full call on chain B; it executes iff hash(call) == authorized_hash and has not expired

We implemented exactly this in #7592, but hardcoded to a single extrinsic (Paras::force_set_current_code → authorize_force_set_current_code_hash / apply_authorized_force_set_current_code).

One of the open questions I left in that PR was: "Can we achieve the same with pallet-whitelist?"

We've now discovered another case for force_register.

The questions

1. Could this RFC be extended so that pallet-whitelist becomes the generic primitive for any "authorize-by-hash, apply-by-anyone, expire-if-unused" dispatch pattern — covering both:

   • The governance sequencing problem this RFC targets, and
   • The cross-chain large-call problem Add Paras authorize_code_hash + apply_authorized_code feature #7592 solved ad-hoc?

   Specifically: an unsigned apply_whitelisted_call(call) — the call is brought inline by the submitter, hash-checked against the whitelist in validate_unsigned (to prevent spam from oversized bogus blobs), and dispatched. That way we probably don't need pallet-preimage on the RC — one step closer to removing balances from the RC?

   We'd keep pallet-whitelist on the RC (whitelist_call + unsigned apply_whitelisted_call).

2. Do we need the preimage.note step for dispatching whitelisted calls on the RC, where we don't want to handle deposits and balances in the future? Is there any security rationale behind preimage.note?

3. Worth folding into this RFC, or better as a follow-up?

---

cc: @karolk91 — you also suggested using pallet-whitelist for this.

cc: @bkchr — would this be a good generic solution (discussed here, or do you see any issues with an unsigned apply_whitelisted_call?

[bkchr]

3. Worth folding into this RFC, or better as a follow-up?

Please create a follow-up RFC.

would this be a good generic solution

The pallet is probably a good idea for this. For a full review, I wait on your proposal.

[PSYKYODAI]

Looking forward to the XCM extension @bkontur, is the RFC out yet?