Smart Contract Wallet Support

[jaydenwindle]

Hey folks! Was DMing with @galligan about this and figured I'd post here to start a convo with the broader team/community as well.

We (@FUTUREPRIMITIVEXYZ) are working on a project that makes use of smart contract wallets, and would love to collaborate on an XIP that adds support for SCWs to the XMTP protocol. Our ideal solution would be EVM-native, using EIP-1271 to allow EOAs to sign on behalf of a SCW to send and receive XMTP messages.

Matt had mentioned that there were on-going efforts to add delegation support to the protocol, which seems like it might be closely related. I'd love to learn more about how the team is currently thinking of / designing for wallet delegation.

The naive implementation of SCW support that comes to mind would involve performing an RPC call to verify signatures each time the SCW tries to interact with the XMTP network. This introduces some interesting edge cases (as the signer would be an EOA, whose permissions to sign for the SCW could change over time) as well as potential latency issues.

Would love to hear perspectives from the team/community around how smart contract wallet support could be implemented, and what the best path towards standardizing this in an XIP is. Thanks!

[saulmc]

Love it. EIP-1271 support is a must-have for sender verification in marketing and customer support use cases, as well as for unblocking communication using multisig and smart wallet accounts.

Tagging in @jazzz and @PranayAnchuri who've been thinking on this for a while.

[neekolas]

This is definitely something we want to support, and love the proposal. It's worth digging in to the ways XMTP currently uses wallet signatures on the network.

1. We sign the user's XMTP IdentityKey with the wallet when we publish their contact to the network. We currently use the public key associated with that signature to compute the wallet address so that message recipients know who the message is coming from.
2. When a user connects to XMTP for the first time we upload an encrypted copy of their private key bundle to the network. The encryption key used is a wallet signature of some random bytes + a header of some human readable text. When a new client is instantiated we download the encrypted private key from the network and prompt for a new signature based on the original random bytes. If the signatures match, the private key bundle can be decrypted and the new client will have access to the original private key bundle.

I can see a pretty clear path to solving 1 for smart contract wallets. We just would have to encode some additional information with the identity keys that would indicate that it is a smart contract wallet and what smart contract should be used to validate the signature. We could add some caching to minimize the number of RPCs required.

2 is trickier. We need a byte-perfect signature match to decrypt the private key bundle. If the authorized EOA for the SCW changes, the signatures will change and the bundle will no longer be decryptable. I think we would have to implement some other form of key storage to make that work.

[jaydenwindle]

Thanks for the response @neekolas! This is super helpful. Agreed that the first point is an easy fix.

The second point is really interesting - I had wondered if key management would become an issue.

What is the mechanism for storing encrypted keys in the XMTP protocol today? Is there a possible future where XMTP nodes become responsible for generating keys and/or storing keys (encrypted or unencrypted), or is that outside the ideal scope for nodes? What is the team's current thinking around wallet delegation (as that seems like it might be relevant here)?

Solving the second point seems like it will require dedicated logic for handling key generation, storage, and transfer for smart contract wallets.

One naive implementation that comes to mind:

• When the initial owner generates keys for an address that is a SCW, those keys are stored in an unencrypted state by the XMTP node, and access to them is gated by signature
• All messages to/from the SCW address are encrypted using the key generated by the initial owner
• When a new SCW owner interacts with the XMTP network for the first time, they generate a new key using their wallet address
• XMTP decrypts all existing messages for the SCW address using the stored unencrypted key, and re-encrypts them using the newly generated key
• Repeat whenever ownership of the SCW changes hands

This solution would require XMTP nodes to store unencrypted keys. It also would likely be linearly complex, which could introduce latency issues when a SCW with a large message history changes hands.

A small variation on the above solution would involve the XMTP node generating and storing the key for SCW messages, and gating access to that key based on EOA owner signatures. This would get around the linear complexity of re-keying message history, but introduces the issue of centralized key management.

Curious to hear your thoughts on these potential paths. Would also love to hear any other potential solutions the team has thought of or is considering to solve this :)