I’m part of an international team working on an Ethereum App project that needs to be able to communicate with existing Ethereum wallets using an ABI encoded function name utilizing EIP-67. We, as users and developers, would like support for an EIP-67 URI with a data perimeter that includes an encoded function name and the functions’ arguments. Thus, we ask if generic support for the ability to invoke functions on ETH contracts — that’s not a payable function yet still paying the GAS — can be added to already existing Ethereum wallets on the market?
We understand most wallets don’t want to enable arbitrary functions, yet are fully capable of doing such in a manner that will release them from legal liability by including it within an advanced settings area for user customization and providing a warning to the user(s) — and even preventing payable functions but allowing GAS payments to go through when interfacing with an ETH contract. May the wallet(s) choose to support implementing this with a blatant warning to the user(s) so to release the wallet providers from legal liability?
All that is being asked is if Ethereum wallets, could further support users, and developers, by supporting EIP-67 compliant URIs (e.g. via scanned QR code) with a data payload that includes the ABI encoded function name and encoded function arguments. Our team is confident that by enabling, EIP-67 compliant URIs with a data payload that includes the ABI encoded function name and encoded function arguments, will further expand the Ethereum ecosystem and aid in increased adoption via mobile users. Thus, allowing EIP-67 URIs with a data perimeter that includes an encoded function name and the functions’ arguments would be a net positive overall when implemented within mobile ETH wallets.
We're 100% completed with v1.0 of our app and have passed reviews by both iOS and Android.
Sincerely, we await your response.