EIP 4337 introduced a counterfactual Wallet deployer pattern using initCodes, which allows one to send a transaction from an account that doesn't exist on chain until the tx is processed.
I bet we could support the same initCode + Wallet deployer pattern within the delegation schema to offer some potential. If nothing else, a counterfactual contract account could both receive and issue a delegation.
I'm not sure if there's any benefit for a 4337-style contract account to be the "end of the line" receiver of a delegation, since depending on how the UserOperation was constructed, they could already (under 4337) deploy the contract as part of calling the method.
But, supporting intermediate delegations seems like a good long term feature, so I'm opening this as a possible future enhancement.
EIP 4337 introduced a counterfactual Wallet deployer pattern using initCodes, which allows one to send a transaction from an account that doesn't exist on chain until the tx is processed.
I bet we could support the same
initCode+Wallet deployerpattern within thedelegationschema to offer some potential. If nothing else, a counterfactual contract account could both receive and issue a delegation.I'm not sure if there's any benefit for a 4337-style contract account to be the "end of the line" receiver of a delegation, since depending on how the UserOperation was constructed, they could already (under 4337) deploy the contract as part of calling the method.
But, supporting intermediate delegations seems like a good long term feature, so I'm opening this as a possible future enhancement.