ERC-7715: Grant Permissions from Wallets

ERCs
1

Adds JSON-RPC method for requesting permissions from a wallet

4 Likes
2

In the context of this ERC, How does wallet identify a DApp and ensure it was still the same DApp? It seems to me there are some implied assumptions that i might not know and probably better spell out.

If the assumption is that DApp maintains a secure connection with wallet, that shall be spelled out and investigated I think. For example, a hardware wallet could be connected to an offline DApp that only signs TX signature and be distributed in less common ways

1 Like
3

Is there still active work on this proposal? One question I have: this standard defines an expiry for the session end time, but Iā€™m thinking providing an additional constraint on the start time would be useful. Similar to how we have validAfter and validUntil in ERC-4337. Thoughts?

4

@jayk Its being actively worked on. Do you think validAfter should be at the top level request? IMO Its more fitting in the specific permission like this:

 permissions: [
          {
            type: 'native-token-transfer',
            data: {
                allowance: '0x1DCD6500',
                validAfter: 1737550474
            }
          }
        ],
5

Thanks for the response! Curious - what would be the use case for being able to specify different validAfters for different permissions? Would we also want to specify different validUntils for each as well then?

In the context of session keys, it seems simpler to think about a valid range at the key level, during which all of the permissions it has been granted is valid. Put another way, this would be equivalent to having time range be an additional permission which must be checked for each action. This is how Alchemy and ZeroDev do it today, with TimeRangeModule and TimestampPolicy, respectively.

6

If you check out the 7715 spec, currently we have RateLimitPermission for example in the spec. I think ZeroDev and Alchemy would map their permissions to a top level ones.
validUntil is the expiry and validAfter can be modeled as a separate permission.