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:
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()
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.