-
Notifications
You must be signed in to change notification settings - Fork 827
Add ERC: Unidirectional Wallet Uplink aka UWULink #1043
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
Conversation
|
✅ All reviewers have approved. |
Co-authored-by: lightclient <[email protected]>
ERCS/erc-7946.md
Outdated
| dApps often require users to perform multistep interactions, such as approving a token and then executing a | ||
| swap. Traditionally, accomplishing this has required multiple user confirmations or complex wallet connectivity. | ||
| Recent standards like EIP-5792 and EIP-7702 introduced ways to batch multiple calls into one atomic operation via | ||
| JSON-RPC (e.g. `wallet_sendCalls`). However, those solutions assume an active connection |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sendCalls does not require a from address and no prior connection is required
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To what interface would you send the wallet_sendCalls RPC? In practice you connect a wallet first, check capabilities, and use wallet_sendCalls only if it's available. It seems like connecting a wallet is a prerequisite to know where to send the RPC.
This would be very different from the dApp having all actions available in the unconnected state, and when you trigger an action (e.g. a swap) it could pop up a modal with the QR code to perform the action, and/or a link with the uwulink scheme, a la magnet link, that triggers the transaction for any extension that registered itself to handle the scheme
|
The commit 0da12b9 (as a parent of 01fd850) contains errors. |
SamWilsn
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm reasonably happy with this proposal's formatting so far. The only outstanding issues is the protocol buffers reference. You can't exactly implement this proposal without understanding protobufs, but referring to its standard is likely to be contentious among editors.
Thank you for fixing the errors! I was a bit stumped on that. What makes protobuf different than JSON + a JSON schema that it would need to be referenced? |
|
JSON is defined in RFC 8259 and JSON Schema isn't strictly required to build a compatible implementation. I do see your point though. I'll see if we can allow Protobufs. |
eip-review-bot
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All Reviewers Have Approved; Performing Automatic Merge...
@tinaszheng