ledger grant issue

[AutoStake-com]

Further to this #623 (comment)

I also had a user on Evmos now in the same situation, I did a bit of digging and I found that the ones that are not working:
https://umee.mainnet.lcd.autostake.net/cosmos/authz/v1beta1/grants/granter/umee18nupa5ptx6n5q2240xpgm4pqlhy2080ztn9ms3
https://evmos.mainnet.lcd.autostake.net/cosmos/authz/v1beta1/grants/granter/evmos18m5jqxehad27zzyrdts4a7h0rmpncm4f3ughsy
contain a null expiration

whereas the ones that are working:
https://rebus.mainnet.lcd.autostake.net/cosmos/authz/v1beta1/grants/granter/rebus1sujs9xa0axafxwedujf9aafmkuse40j0eurwk4
contain a non null expiration

Now it do see check for the expiration in parseGrants() and wandering if there is a bug in the newer SDK's causing this null expiration?

Or am I completely wrong here? is it working for you?

[tombeynon]

Ah interesting - I've not seen this before! Do you know if they created the grant using REStake? I also wonder if that's a valid grant and would allow REStake or if the null expiry treats it as expired. IF it's valid then it should be pretty easy to update the REStake script to handle the null expiration and treat as valid.

[AutoStake-com]

I just asked and at least the Evmos one was done with CLI & Ledger

grants with a null expiration are valid grants, source is here:
https://www.mintscan.io/kujira/txs/E71AC7C094CD26F88B79D2BA120A93B9EE5E3F413FF959E91798BEF3E142E3BE

That is a grant that is working currently

[AutoStake-com]

I did try to edit the parseGrants() to remove the expiration check myself but everytime It messed up the entire thing, I just assumed it was because of a lack of context of the codebase and familiarity with javascript (more used to python and php here)

[vchong]

Is this still an issue? We're seeing the same symptoms. For tx authz grant command:

      --expiration int               Expire time as Unix timestamp. Set zero (0) for no expiry. Default is 0.

if we set --expiration 0, the grant looks like:

  claimGrant: {
    granter: 'foo',
    grantee: 'bar',
    authorization: {
      '@type': '/cosmos.authz.v1beta1.GenericAuthorization',
      msg: '/cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward'
    },
    expiration: null
  },
  stakeGrant: {
    granter: 'foo',
    grantee: 'bar',
    authorization: {
      '@type': '/cosmos.authz.v1beta1.GenericAuthorization',
      msg: '/cosmos.staking.v1beta1.MsgDelegate'
    },
    expiration: null
  }

which fails the check in

restake/src/utils/Helpers.mjs

Line 75 in daf955d

return Date.parse(el.expiration) > new Date();

and

restake/src/utils/Helpers.mjs

Line 93 in daf955d

return Date.parse(el.expiration) > new Date();

, i.e. they return false instead of true, because null is < new Date()?

Submitted PR #749 for this.

[tombeynon]

Strangely this seems to have caused some issues for me. It appears that the null expiration can potentially be unclear, i.e. it might mean an unlimited expiration, or it might mean already expired (potentially?).

CryptoOrg:

failed to execute message; message index: 0: failed to update grant with key
/cosmos.staking.v1beta1.MsgDelegate: authorization not found [cosmos/cosmos-sdk@v0.46.12/x/authz/keeper/keeper.go:105]

Evmos:

cannot delegate unvested coins. coins vested < delegation amount (0 < 14463256065805435217891)

Changing null expiration back so it's treated as an invalid grant fixes both of these issues.

Evmos could be a combination of an infinite grant and vesting tokens, but it's strange this is the first time I've seen it. Crypto.org is pretty clear that it's an invalid or expired grant.

@AutoStake-com @vchong I think for now we'll need to revert this change, and just encourage any users with infinite grants to set an expiration date using restake.app. Let me know if you have any better ideas, otherwise I'll revert it over the next day or so.