Allow feegrant for whitelisted contracts

[zanicar]

Feature : Allow feegrant for whitelisted contracts

Summary

Currently, we can create Feegrants for the msg cosmwasm.wasm.v1.MsgExecuteContract, however, that is an extremely broad feegrant. A granter might not be comfortable subsidizing most possible txs of the grantee, esp on a permissionless Cosmwasm chain. The solution we propose is to allow feegrant for individual/set-of-whitelisted contracts.

Problem Definition

On permissionless wasm chains, where the dapp contracts are more decoupled from the protocol, a general feegrant using AllowedMsgAllowance for cosmwasm.wasm.v1.MsgExecuteContract is too permissive.

e.g If a new NFT marketplace dapp wants to subsidize its users fees for launch week, there is no way they can provide the feegrant ensuring that it cant be used for other contracts.

Proposed Feature

Similar to how wasmd provides custom Authz extensions, we propose the implementation of custom FeeAllowanceI extension.

// AllowedContractAllowance creates allowance only for MsgExecuteContract msgs which executes specified contracts.
message AllowedContractAllowance {
  option (gogoproto.goproto_getters)         = false;
  option (cosmos_proto.implements_interface) = "cosmos.feegrant.v1beta1.FeeAllowanceI";
  option (amino.name)                        = "cosmos-sdk/AllowedContractAllowance";

  google.protobuf.Any allowance = 1 [(cosmos_proto.accepts_interface) = "cosmos.feegrant.v1beta1.FeeAllowanceI"];

  // allowed_contracts are the contracts for which the grantee has the access.
  repeated string allowed_contracts = 2;
}

This allows a dapp developer to provide feegrants for all their contracts, while ensuring other dapps cannot take advantage of the granters funds. And thus enables improved UX for dapps.

[alpe]

Thanks for bringing this idea up! This seems very useful and like authz I can imagine some more use cases exists for fine grained filters and limits. It would be good to discuss them and share ideas. For example,

• do we want to limit the execution to some concrete payload or message key as we did with authz, too ?
• do we rely on nested allowance for the msg type or inline it? Some combinations may not make sense.
• same for spend limit and expiration?

I think the general concept of FeeAllowanceI with implementations that support nesting other allowances is very powerful. The user on the client side would be able to compose them for their needs. Although this may require some skills and good understanding of what's possible and the composition order. The simplest start would be the AllowedContractAllowance indeed. Personally, I think a non empty allowance object should be required but curious to hear other use cases.

My last point is CLI support. This may be getting a bit messy when we keep adding more allowance types. We have the following already in the SDK. Adding allowed_contracts would not make it worse. WDYT?

Examples:
simd tx feegrant grant cosmos1skjw... cosmos1skjw... --spend-limit 100stake --expiration 2022-01-30T15:04:05Z or
simd tx feegrant grant cosmos1skjw... cosmos1skjw... --spend-limit 100stake --period 3600 --period-limit 10stake --expiration 2022-01-30T15:04:05Z or
simd tx feegrant grant cosmos1skjw... cosmos1skjw... --spend-limit 100stake --expiration 2022-01-30T15:04:05Z
    --allowed-messages "/cosmos.gov.v1beta1.MsgSubmitProposal,/cosmos.gov.v1beta1.MsgVote"

[webmaster128]

If we make a CosmWasm specific alternative to AllowedMsgAllowance, we can reduce the inner allowance to basic and periodic fee allowance. This then covers amounts and expiration.

  // allowance can be any of basic and periodic fee allowance.
  google.protobuf.Any allowance = 1 [(cosmos_proto.accepts_interface) = "cosmos.feegrant.v1beta1.FeeAllowanceI"];

do we want to limit the execution to some concrete payload or message key as we did with authz, too ?

I think that would be powerful and consistent, reusing existing code.

[dgabriele]

Please do this 👍🏼 - At Gelotto, we'd love to reduce the number of approvals users have to perform in the FE as well as the tx fees they have to pay. Instead, we'd prefer to pay fees out of our own backend. Something like this would go a long way to make that possible without requiring us to build our own idiosyncratic solution

[Rcontre360]

Hi! at chelo labs we would love to see this feature :pray: