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

Jump to bottom

ERC 1361 - ETHPay : Standardized AppLinks for signing ETH transactions using an installed wallet on mobiles #1361

Closed
madhavanmalolan opened this issue Aug 29, 2018 · 7 comments
Closed

ERC 1361 - ETHPay : Standardized AppLinks for signing ETH transactions using an installed wallet on mobiles #1361

madhavanmalolan opened this issue Aug 29, 2018 · 7 comments
Labels
stale

Comments

@madhavanmalolan
Copy link

madhavanmalolan commented Aug 29, 2018 •
edited 

---
eip: <to be assigned>
title: Standardized AppLink for signing ETH Transactions using an installed wallet on mobile
author: Madhavan Malolan (@madhavanmalolan)
status: Draft
type: Interface
created: 2018-08-29
---

Simple Summary

Proposing standardizing the ethpay:// URI (AppLink) so that native app developers can invoke user's wallets to sign transactions.

Abstract

Proposing a simple mechanism that will allow developers to build DApps as native apps without having to maintain the users' wallets/private keys. DApps today are built primarily on the web because of the access to Web3 injections, but the user experience is lacking. Native apps provide a much richer experience. A MetaMask equivalent for native apps will help the developer community a long way.

Motivation

App developers today need to maintain the private keys and keep pace with the changes happening on the Web3 libraries. A large majority of people have some ethereum Wallet installed on their phone which already maintains their keys and accounts. Why should every app developer have to re-invent the wheel by building the entire wallet stack into their app? By having a standardised AppLink app developers can leverage the existance of other ethereum wallets on the user's phone to sign and send transactions.

Specification

The AppLink will be an URI of scheme ethpay://

Possible actions

  • sign : The wallet signs the data sent to it and redirects to a URI also specified in the request with the signature as a query parameter
  • sendSignedTransaction : The wallet signs a transaction and sends it to an Ethereum Node

Allowed parameters

  • action : may be one of sign or sendSignedTransaction
  • to : An Ethereum Address to which the transaction is to be sent. Required if action is sendSignedTransaction
  • value : Integral value of number of Wei to include in the transaction. Optional.
  • data : Data that needs to be signed. If action is sendSignedTransaction this should be hex encoded. Required if type is sign
  • gas : Amount of gas to be used in the transaction. Required if action is sendSignedTransaction
  • gasPrice : Gas price for the transaction. Optional. If not provided for action sendSignedTransaction, current gas price will be used.
  • redirectUri : The URI to which the wallet should redirect with signature after signing. Used only for action sign.

Rationale

The URI based AppLinks will allow app developers to request signing of transactions without needing to use any external library.
The users will not have to trust the app developer with their private keys, since it is maintained by a separate wallet app they already use.

Implementation

A rough implementation of this protocol has been done using Web3 1.0.0-beta on a React Native app. It uses Infura as an Ethereum node.

The implementation handles App Links and a basic implementation of an ETH wallet.

You can find the app's implementation here

Copyright

Copyright and related rights waived via CC0.
@madhavanmalolan madhavanmalolan changed the title ERC 1342 - ETHPay : Standardized AppLinks for signing ETH transactions using an installed wallet on mobiles ERC 1361 - ETHPay : Standardized AppLinks for signing ETH transactions using an installed wallet on mobiles Aug 29, 2018
@shrugs
Copy link

shrugs commented Aug 31, 2018

for sendSignedTransaction (maybe, signAndSendTransaction?), Would we not want the wallet app to redirect back to the original app after sending? I expect the original app would want information like a transaction hash.

@Dobrokhvalov
Copy link

I like the idea. However, there is an issue when multiple apps support the same URI scheme on iOS - https://stackoverflow.com/questions/13130442/multiple-apps-with-the-same-url-scheme-ios#13130479

One possible workaround can be using a dedicated website where user can choose his wallet. Something like this - https://www.youtube.com/watch?v=GMXEOdlR9L8&feature=youtu.be

We also have similar discussion on the WalletConnect's discourse - https://discuss.walletconnect.org/t/asymmetric-key-for-mobile-to-mobile/39/4?u=dobrokhvalov

cc @pedrouid

@madhavanmalolan
Copy link
Author

@shrugs I think that's a fair point. I imagined the apps to send tracking information in data. But there's nothing stopping us from having a callback

@pedrouid
Copy link
Contributor

pedrouid commented Sep 2, 2018

This is super cool and something we have been thinking a lot on WalletConnect as @Dobrokhvalov has pointed out. I would perhaps extend ERC-681 to include the redirectUri parameter. Currently wallets already listen for ethereum: scheme and we have actually used this as a base for WalletConnect Standard URI Format following the ERC-831 URI Format. It would be great to use this proposal to specifically improve ERC-681 to work better with AppLinks

@ChrisCates
Copy link

ChrisCates commented Mar 16, 2019 •
edited

@madhavanmalolan, it would be nice to have Swift and Java implementations.
There are web3 libraries for Swift and Java. It would probably be nice to build on top of those.

Curious if anyone here has found, or made their own solution.

@github-actions
Copy link

github-actions bot commented Dec 4, 2021

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

@github-actions github-actions bot added the stale label Dec 4, 2021
@github-actions
Copy link

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
stale
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@shrugs @ChrisCates @madhavanmalolan @Dobrokhvalov @pedrouid