Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable delegations from contract accounts #29

Open
danfinlay opened this issue Nov 17, 2022 · 0 comments · May be fixed by #34
Open

Enable delegations from contract accounts #29

danfinlay opened this issue Nov 17, 2022 · 0 comments · May be fixed by #34

Comments

@danfinlay
Copy link

There are two basic ways:

  • Just add an EIP-1271 validator in the signature verification logic loop (if the account has code deployed, call the 1271 validation message)
  • EIP-4337 compatibility (Involves much larger changes to Delegatable, as the 4337 relay handles multiple things Delegatable does today, including batching).
danfinlay added a commit that referenced this issue Nov 21, 2022
Fixes #29

Adds Support for [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) for allowing contract accounts to give and receive delegations.

Required one additional bit to the `SignedDelegation` and `SignedInvocation` types: `signerIsContract`. If this bit is `true`, then the first 20 bytes of the `signature` field is treated as the address of a contract to treat as the intended signer, and that contract is sent the remaining `signature: bytes` along with the delegation type hash to determine for itself whether this proof should be treated as valid authorization.

I formerly was somewhat against using EIP-1271 in this way, because I had seen some contract accounts merely allow assigning a single signer as their EIP1271 recovery strategy, which completely undermines the entire point of having a contract account. My position on this has evolved a bit, to  believe that correct usage is possible, and so we shouldn't let the possibility of flawed contract accounts prevent good ones from participating in this.

For example, good usage might look like a multisig might have a custom datastructure for representing which accounts' signatures are included, and including all the signatures combined in the `signature` payload.

Larger controller sets like a token-weighted DAO might involve too many signatures to submit as a delegation/invocation as `calldata`, but I'll leave that research as to do.
@danfinlay danfinlay linked a pull request Nov 21, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant