Adds JSON-RPC method for requesting permissions from a wallet
8 Likes
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
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?
1 Like
@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
}
}
],
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.
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.
Given the fact that crypto assets are usually very volatile, would there be a way to update the permissions on the go?
1 Like
The 7715 spec is a significant value add to the wallet layer. However, during the implementation of the first iteration in MetaMask, I encountered a few pain points that I believe could hinder broader adoption.
I’ve opened a PR against the spec proposing some minor modifications to help make the standard more manageable for wallet implementations.
Feedback is welcome!
1 Like
ERC-7715 describes the PermissionResponse as being a (presumably TypeScript-like) union of the PermissionRequest type with additional properties. A PermissionRequest is a list of objects. Is it the author’s intention here to make the PermissionRequest a list of objects, as well? See the following for an excerpt from the document:
type PermissionRequest = {
chainId: Hex; // hex-encoding of uint256
address?: Address;
expiry: number; // unix timestamp
signer: {
type: string; // enum defined by ERCs
data: Record<string, any>;
};
permissions: {
type: string; // enum defined by ERCs
data: Record<string, any>;
}[];
}[];
// union of list and properties
type PermissionResponse = PermissionRequest & {
context: Hex;
accountMeta?: {
factory: `0x${string}`;
factoryData: `0x${string}`;
};
signerMeta?: {
// 7679 userOp building
userOpBuilder?: `0x${string}`;
// 7710 delegation
delegationManager?: `0x${string}`;
};
};
1 Like
I would like to raise a security concern around permission types or wallet implementations that rely only on a 4-byte function selector to decide whether a call is allowed.
Even if ERC-7715 itself does not mandate selector-only permissions, I think the specification or wallet guidance should explicitly warn against this pattern.
A 4-byte selector is not globally unique. Different function signatures can theoretically produce the same selector, and a malicious contract could intentionally expose a different function with the same selector.
For example, if a permission only checks something like selector == 0x12345678, without also binding the permission to a specific target contract and calldata constraints, the permission could become broader than the user intended.
This is especially concerning if a DApp or client provides the selector and the wallet UI displays it as if it clearly represents a trusted function. In that case, a user may believe they are granting permission for one function, while the actual execution could target another function with the same selector on a different or malicious contract.
I think permission validation should not rely on the selector alone. A safer model should bind the permission to information such as:
chainId
target contract address
verified function signature
expected selector
calldata length / structure
argument constraints
value / spending limits
expiration and revocation conditions
In other words, the permission should describe not just “which selector is allowed”, but “which function on which contract, with which calldata and argument constraints, is allowed.”
Maybe I’m overthinking this, but I’d be interested to hear what others think. Would it make sense to add an explicit security consideration recommending that wallet implementations and permission types avoid selector-only permissions?
1 Like