DA0-DA0 / dao-dao-ui

InterChain DAO tooling UI.
https://daodao.zone
27 stars 21 forks source link

FeeGrant Action #1061

Open JakeHartnell opened 1 year ago

JakeHartnell commented 1 year ago

Feegrant allows for paying gas fees on behalf of other users! Now that we have better support for protobufs, it could be a great feature to support.

Use case: letting multisig members vote and execute proposals without having to pay gas from their personal accounts.

Use case 2: letting a bot execute transactions for the DAO without having to pay gas.

https://docs.cosmos.network/main/modules/feegrant

JakeHartnell commented 1 year ago

@TrevorJTClarke, maybe Croncat can supersede the need for this and accomplish this usecase better?

mikedotexe commented 1 year ago

maybe Croncat can supersede the need for this and accomplish this use case better?

We discussed this yesterday, actually. I feel very confident on how to implement Fee Grant on the contract level after seeing this repo from an Osmosis homie:

https://github.com/iboss-ptk/sovereign-contract-account/blob/f6684f566f41f8d1eef65597dfd18c43d588cd91/contracts/contract-account/src/contract.rs#L31-L54

Note that when you're checking the grants using junod it seems like the sure-fire way to confirm is to use junod q feegrant grant [addr1] [addr2]

I think it's inevitable that CronCat uses Fee Grant, but at the moment we're less than 2 weeks away from the security audit, and we're splitting out into several atomic contracts, racing toward that finish line. So not sure how soon DAO DAO might find it useful, but we're likely unable to ship Fee Grant within a a couple weeks, fwiw

JakeHartnell commented 1 year ago

maybe Croncat can supersede the need for this and accomplish this use case better?

We discussed this yesterday, actually. I feel very confident on how to implement Fee Grant on the contract level after seeing this repo from an Osmosis homie:

https://github.com/iboss-ptk/sovereign-contract-account/blob/f6684f566f41f8d1eef65597dfd18c43d588cd91/contracts/contract-account/src/contract.rs#L31-L54

Note that when you're checking the grants using junod it seems like the sure-fire way to confirm is to use junod q feegrant grant [addr1] [addr2]

I think it's inevitable that CronCat uses Fee Grant, but at the moment we're less than 2 weeks away from the security audit, and we're splitting out into several atomic contracts, racing toward that finish line. So not sure how soon DAO DAO might find it useful, but we're likely unable to ship Fee Grant within a a couple weeks, fwiw

No need to ship feegrant, I was mostly wondering if Croncat replaces the need for feegrant somewhat. At least for this use case: letting a bot execute transactions for the DAO without having to pay gas.

mikedotexe commented 1 year ago

this use case: letting a bot execute transactions for the DAO without having to pay gas.

I see, thank you. Yes, and actually Nino created a CronCat task with queries and transforms that did something like this.

Here's the message to CronCat:

{
  "create_task": {
    "task": {
      "interval": "Immediate",
      "cw20_coins": [],
      "stop_on_fail": false,
      "actions": [
        {
          "msg": {
            "wasm": {
              "execute": {
                "contract_addr": "'$DAO_ADDRESS'",
                "msg": "base64({'execute':{'proposal_id':''}})",
                "funds": []
              }
            }
          },
          "gas_limit": 300000
        }
      ],
      "queries": [
        {
          "check_passed_proposals": {
            "dao_address": "'$DAO'"
          }
        }
      ],
      "transforms": [
        {
          "action_idx": 0,
          "query_idx": 0,
          "action_path": [
            {
              "key": "execute"
            },
            {
              "key": "proposal_id"
            }
          ],
          "query_response_path": []
        }
      ]
    }
  }
}

source here

What it does is this… It says, "hey, I'd like to send a message to a DAO, but I don't know the message yet, because that depends on some stuff that'll happen on-chain." This task's queries and transforms will check for proposals whose status is passed, hence waiting to be executed. When it gets that proposal ID that's returned, it uses transforms to say, "hey remember that Action I told you to take, so only one, so index 0? I have the details to create a complete message now. So I shall insert the returned proposal ID from the only query, index 0, and shim that value into execute message. When I created that task, I gave the basic structure with most of it figured out except the proposal ID."

Now that it's complete, the execute action will call the DAO directly.


I just noticed that the new version of DAO DAO has a parameter to only allow members to execute. For instance, looks like the Red DAO is set up like this. (junod q wasm contract-history juno14ffx88tk6f4twhfk3cxa7mg9r94g2hswhkgp0px2ehmuleq8l5equxczny -o json | jq)

So we'd modify our CronCat task so it calls an intermediary "Team Executor" contract. Perhaps the executor has a method that verifies it's a bona fide CronCat address by querying our factory contract. Then it sends the execute message to the DAO's proposal contract.

I suppose that contract should be given Red tokens, for instance, and have a method to stake/unstake DAO tokens.

Then have the DAO do a custom message » Fee Grant type, granting BasicAllowance to the executor.

So on the CronCat side, I think the only thing that would differ from Nino's example is the action's contract_addr to the executor.