3

Let's imagine that we have some blacklist pallet that stores accounts that are restricted to make some calls. How do we implement origins filtering based on that blacklist for other pallets?

We could add corresponding logic to our own pallets, but it is not suitable for external pallets we use. We also could implement this (I guess) through adding SignedExtension but it is also an inappropriate solution.

It would be nice to implement this as runtime-level logic similar to how we can filter calls with system pallet's BaseCallFilter and it would be great to be able to return custom error. What are the options? Maybe we could customize RuntimeOrigin or smt?

1
  • does the blacklist change or it fixed?
    – dadzerlaze
    May 22, 2023 at 9:03

1 Answer 1

1

Take a look at the pallet-assets's CreateOrigin. https://github.com/paritytech/substrate/blob/e85188b800c63ca3be545c1a43a0927fe0b6fd11/frame/assets/src/lib.rs#L271-L277

Here's an example, we configured a whitelist([ROOT]) for it. https://github.com/darwinia-network/darwinia/blob/ae96c262f7998174081ec57e9d45b600aaa24cec/runtime/darwinia/src/pallets/assets.rs#L41-L43

You might not need to use EnsureOriginWithArg, you should also take a look at EnsureOrigin.

1
  • Yes, wrapping RuntimeOrigin is a nice substrate-style solution for adjusting origin handling logic, thank you! But only in scope of specific pallet. Are there any ideas of implementing this as runtime-level logic? Like if we want to build a runtime with some role-based access to calls or something like that. Is that feasible without delving into dark deepes of substrate? May 24, 2023 at 13:33

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.