In the pallet_multisig, there are two storage maps Multisigs for the multisigs and Calls for the actual call in a multisig. The pallet has two distinct pricing components for its bloat deposit:
// One storage item; key size is 32; value is size 4+4+16+32 bytes = 56 bytes.
pub const DepositBase: Balance = deposit(1, 88);
// Additional storage item size of 32 bytes.
pub const DepositFactor: Balance = deposit(0, 32);
But when you look at how these are used, you see that store_call_and_reserve uses data.encoded_len() + 31 as the byte length used with the DepositFactor to price the Calls mapping, despite the byte size of this needing to be sizeof([u8; 32]||(OpaqueCall<T>, T::AccountId, BalanceOf<T>) which is something like 32 + data.encoded_len() + 32 + 128 in Polkadot/Kusama.
Isn't this under pricing in this case?
I ask because there is very scarce information on how storage deposits should properly be set, so I'm not totally sure I am interpreting everything properly.
Side question: Why would one split this representations into two distinct maps like this? It seems having call in multisig itself would be a safer static representation, now there is an implicit runtime invariant about maps being synchronised.
