Existing use cases of `pallet_utility::as_derivative` in XCM

In Introduce whitelist for Transact and limit UMP processing to 10 messages per block by KiChjang · Pull Request #6280 · paritytech/polkadot · GitHub, we are trying to whitelist RuntimeCalls so as to prevent infinite nestings and recursions on extrinsics that can nest other RuntimeCalls. Moonbeam has indicated that they are using pallet_utility::as_derivative for some of their use-cases, and so this PR would break their business logic.

What we are currently thinking is that we should instead go deeper into the matching and whitelist all current valid use-cases of pallet_utility::as_derivative and reject all others.

Are there any other parachain teams that rely on as_derivative or other similar extrinsics that nest runtime calls for their normal business logic?

In Equilibrium, we use the as_derivative method to interact with Multichain bridge contracts on Moonbeam. When a user wants to withdraw tokens to Ethereum we send funds to a derivated sovereign account on Moonbeam and do a call EVM contracts from this acc. This improves user experience and allows to transfer of funds from Equilibrium to Ethereum in one user tx

Acala / Karura are also using this to generate sub accounts for our liquid staking protocol in order to nominate more than 24 validators.

Someone should to write a script to analysis all the transacts on Polkadot & Kusama, so we can be reasonably confident that those kinds of changes won’t break parachains.

Hey, some implementation details from the Lido on Polkadot and Kusama team:

  1. There are certain use cases of nesting calls we have for liquid staking at Lido on Polkadot and Kusama. For staking via XCM we use three nested calls (RuntimeCall::utility + RuntimeCall::utility + RuntimeCall::Staking or RuntimeCall::xcmPallet).

Here is the full list of calls used:

  • nominate()
  • bond()
  • bondExtra()
  • unbond()
  • withdrawUnbonded()
  • rebond()
  • chill()
  • limitedReserveTransferAssets()
  1. Abusive nesting usage may be addressed either by whitelisting those calls that are confirmed to be in use by different teams/products or by restricting nesting levels at a certain constant, also confirmed by exact use cases, e.g. five.

  2. Whitelisting as_derivative also helps: Introduce whitelist for Transact and limit UMP processing to 10 messages per block by KiChjang · Pull Request #6280 · paritytech/polkadot · GitHub

Thanks everyone for the participation! It turned out that we could simply whitelist as_derivative altogether, so we don’t need much of this data.

1 Like