GroupOS Smart Account/WC POC

ianrowan commented 6 months ago

Description

We've been working with station to get our ERC4337 infra set up. They created packages under the name groupOS. The tl;dr is that we want to enable a flow similar to the demo they've provided for integrating their wallet connect hooks. The specifics of what this require is:

Creation of a smart account for an individual user(TODO, docs for this)
Build out a hidden page similar to code described in the example on the npm site page for@groupos/walletconnect - this is also the package that will be used for creating the wallet connect hook.
within the built out page, allow user to sign with their EOA wallet ext/MM as transaction requests arrive via wallet connect
Upon build out relaying on backend(or potentially frontend) to relay the signature to the smart account associated with the user.

Project Owner

@ianrowan

Engineering Requirements

Creation of an unscoped set of /wallet routes/pages that
1. Allow user to create a group OS smart account
2. Allow users to paste a wc connection link from another Dapp
3. Allow user to sign incoming requests
creation of model to store relevant smart account information per user address
Metamask/wallet adapter functions to request signature of transaction object per ERC4337/groupOs validation standard(TODO, add docs here)
Backend Route or frontend logic to push signed transaction to smart account(via chain or groupOS api). Either way user should only sign and we relay via our own pkey backend or push to groupOs on frontend

Acceptance Criteria

Users can create smart accounts and use them on an unscoped wallet page
wallet pages work the same way the demo provided above works w/ wallet connect + receiving transactions

Additional context

For context the typical wallet connect flow here(focusing only on desktop UX/non-QR code) from the user perspective is:

Signed in to common and on my wallet page(or w/e) - waiting for a Wallet connect link
On dapp user selects wallet connect + clicks copy link
paste link in my wallet page - upon successful connection wallet page moves to receive transaction view
when user cretes a tx on dapp - tx shows up in common wallet page automatically
They sign the tx with EOA
It(automatically) ends up on chain w/ no gas

dillchen commented 6 months ago

@ianrowan for the unscoped wallet page, let's do something basically that is -> https://www.figma.com/file/KOEVNGXStBhmX3NnYq7MxP/Community-Stake?type=design&node-id=1812-63466&mode=design&t=w1GVYke1zIrqcxrE-4

similar to this

and across the top add a + button (opens in app modal to paste the WC items)

dillchen commented 6 months ago

cc: @egetekiner for item number 4

Upon build out relaying on backend(or potentially frontend) to relay the signature to the smart account associated with the user.

While full arch for transaction relaying not really in scope, seems impt to ensure that Platform / Eng Leads are looped in at least lightly.

I think the full event storm etc should happen after we have the POC within our app

ianrowan commented 6 months ago

cc: @egetekiner for item number 4

Upon build out relaying on backend(or potentially frontend) to relay the signature to the smart account associated with the user.

While full arch for transaction relaying not really in scope, seems impt to ensure that Platform / Eng Leads are looped in at least lightly.

I think the full event storm etc should happen after we have the POC within our app

@dillchen For this one I'm almost pretty certain station will relay for us via an API call, just need to confirm. That's at least what I got from the value prop of their API/paymaster abilities etc

dillchen commented 6 months ago

@ianrowan makes sense, sorry I meant transaction Queuing / storage. I.e "I have received a tx back from some app, but I have not signed with my MM"

ianrowan commented 5 months ago

Step 1. (Allow user to create a group OS smart account)

will be covered by hypermeme wallet lite spec #7190

dillchen commented 3 months ago

@ianrowan would it be possible to to stub the other remaining bullet points, seems like other remaining functionality is the following

Metamask/wallet adapter functions to request signature of transaction object per ERC4337/groupOs validation standard(TODO, add docs here)

Backend Route or frontend logic to push signed transaction to smart account(via chain or groupOS api). Either way user should only sign and we relay via our own pkey backend or push to groupOs on frontend

Looks completed based on #8044

Creation of an unscoped set of /wallet routes/pages that

Allow user to create a group OS smart account Allow users to paste a wc connection link from another Dapp Allow user to sign incoming requests creation of model to store relevant smart account information per user address

ianrowan commented 3 months ago

@dillchen Created https://github.com/hicommonwealth/commonwealth/issues/8049 for the UI work left. Then there is also #7191

Just to be accurate #8044 creates a backend route that allows for creation and db storage/fetching of a users smart account.

The scope of #7191 and #8044 also have nothing to do with walletConnect to be clear for the demo purposes. These were roadmap specific tickets for tg bot and other relaying services using smart accounts. So the end result of a POC here would be:

User can create a smart account with us and them as signer
We can prompt user with a tx(ie send eth to x from smart account) and they can send it with one click(no sig)
Opens up for relaying via multi-auth patterns = POC our sessions/jwt provides auth, we push tx for user. Extends to tg and other services we need to relay from

So this is essentially everything above except for wallet connect(esp b/c w/o group OS WC is less straighforward) or at least isnt scoped for that b/c the purpose was for relaying, etc

dillchen commented 3 months ago

All makes sense to me — Will ensure that this context is relayed to rest of team

Sent via Superhuman @.***>

On Tue, Jun 04, 2024 at 3:47 PM, Ian Rowan @.***> wrote:

@dillchen https://github.com/dillchen Created #8049 https://github.com/hicommonwealth/commonwealth/issues/8049 for the UI work left. Then there is also #7191 https://github.com/hicommonwealth/commonwealth/issues/7191

Just to be accurate #8044 https://github.com/hicommonwealth/commonwealth/pull/8044 creates a backend route that allows for creation and db storage/fetching of a users smart account.

The scope of #7191 https://github.com/hicommonwealth/commonwealth/issues/7191 and #8044 https://github.com/hicommonwealth/commonwealth/pull/8044 also have nothing to do with walletConnect to be clear for the demo purposes. These were roadmap specific tickets for tg bot and other relaying services using smart accounts. So the end result of a POC here would be:

User can create a smart account with us and them as signer

We can prompt user with a tx(ie send eth to x from smart account) and they can send it with one click(no sig)

Opens up for relaying via multi-auth patterns = POC our sessions/jwt provides auth, we push tx for user. Extends to tg and other services we need to relay from

So this is essentially everything above except for wallet connect or at least isnt scoped for that b/c the purpose was for relaying, etc

— Reply to this email directly, view it on GitHub https://github.com/hicommonwealth/commonwealth/issues/6864#issuecomment-2148299882, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIWMHOVCKN5J7LJVDYYXMTZFYKUJAVCNFSM6AAAAABDW3NE6KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBYGI4TSOBYGI . You are receiving this because you were mentioned.Message ID: @.***>

jnaviask commented 2 weeks ago

Redundant.

hicommonwealth / commonwealth