ERC-681: Representing various transactions as URLs

jpitts · July 5, 2018, 7:06am

This is a very useful proposal by @nagydani that should be getting more attention now that UX (and what I would call “developer UX”) is such a high priority in the community.

Simple Summary
A standard way of representing various transactions, especially payment requests in Ethers and ERC #20 tokens as URLs.

Abstract
URLs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URL format for payment requests allows for instant invocation of the user’s preferred wallet application (even if it is a webapp or a swarm đapp), with the correct parameterization of the payment transaction only to be confirmed by the (authenticated) user.

github.com

nagydani/EIPs/blob/master/EIPS/eip-681.md

## Preamble

    EIP: 681
    Title: URL Format for Transaction Requests
    Author: Daniel A. Nagy <daniel@ethereum.org>
    Type: Standard Track
    Category: ERC
    Status: Draft
    Created: 2017-08-01
    Requires: 20, 137, 831

## Simple Summary
A standard way of representing various transactions, especially payment requests in Ethers and ERC #20 tokens as URLs.

## Abstract
URLs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URL format for payment requests allows for instant invocation of the user's preferred wallet application (even if it is a webapp or a swarm đapp), with the correct parameterization of the payment transaction only to be confirmed by the (authenticated) user.

## Motivation
The convenience of representing payment requests by standard URLs has been a major factor in the wide adoption of Bitcoin. Bringing a similarly convenient mechanism to Ethereum would speed up its acceptance as a payment platform among end-users. In particular, URLs embedded in broadcast Intents are the preferred way of launching applications on the Android operating system and work across practically all applications. Desktop web browsers have a standardized way of defining protocol handlers for URLs with specific protocol specifications. Other desktop applications typically launch the web browser upon encountering a URL. Thus, payment request URLs could be delivered through a very broad, ever growing selection of channels.

This file has been truncated. show original

pedrouid · July 5, 2018, 7:26am

Totally agree, we are working on implementing this as part of the WalletConnect standard. However I think this is a great start for doing transaction requests but I find that there is still more information needed to clearly provide human-readable machine-veriable transaction requests similar to Aragon’s Radspec as suggested by @avsa on the thread for EIP-1138

jpitts · July 5, 2018, 7:29am

Referencing these here:

mikro2nd · July 5, 2018, 10:25am

Agree that this is an important step in improving UX. I do have one (faint) concern:

chain_id is optional and contains the decimal chain ID, such that transactions on various test- and private networks can be requested. If no chain_id is present, the client’s current network setting remains effective.

Would it not be better to mandate that the default chain be the mainnet rather than something dependent on the client’s current settings. By relying on the client settings you’re introducing a vector for introducing debugging hassles:

A Play In One Act

<Enter A Bug>
Dev: What chain_id did you use?
User: ?
Dev: Did the URL contain a chain_id?
User <who doesn't really know what that would look like, but doesn't want to appear stupid>: I don't think there was one...

<By pure chance they're right this time>

Dev: OK, which blockchain was your client using at the time?
User: I've no idea. I think it may have been some test network.

<ad lib mayhem, heads exploding, fx fades>

…you get the idea, I hope!

Whereas, if the default is mandated to be the mainnet, there’s just one less (fertile) source for confusion when it comes to debugging.

Hope this makes some technical sense, but I confess I’m not well qualified to judge that – I’m just coming at it from a perspective of decades of debugging…

MicahZoltu · July 5, 2018, 11:58am

There is not a single chain that can be considered canonical. When a contentious fork occurs, there will be two “main” chains and it is up to users, exchanges, wallets, etc. to decide which one is “main”. People have argued in the past (and I have supported) that the chain ID should change with every fork, thus defaulting is also not really reasonable. Your client follows some chain, someone else’s client follows another chain, both clients call the chain they follow “main”, neither chain uses the same chain ID from before the fork.

nagydani · July 5, 2018, 12:28pm

It has been debated a bit, and to be honest I do not remember why it was decided this way, but I guess that it had something to do with being able to test URL’s without a network id on testnets as well as being able to transition to a different chain ID after some contentious hardfork.

mikro2nd · July 6, 2018, 11:53am

I’ll stand by my conviction that the existence of a hidden variable is a dangerous source of confusion that will result in misery for many people in time to come, and I strongly urge a reconsideration while the EIP is still in draft and amenable to change/improvement.

Perhaps a better solution than I first suggested is simply to make the chain element of the URL mandatory rather than “optional with a hidden default”.

ligi · July 30, 2018, 2:40pm

AFAIR the chain_id was made optional to provide some backward compatibility to ERC-67 - when making it mandatory would always break compatibility.
Also I do not really see the reason to make it mandatory - it is easy - if the parameter is not there -> then the value is 1. I dont’t see users knowing/remembering about chain_id’s in URLs as a valid case - they just will not know or remember - no matter if there is always a number or not. But just my 2cents.

php4fan · June 19, 2022, 10:00am

Why is there no explanation whatsoever in the specification about the pay- prefix??

The formal grammar specification says the url starts with ethereum: followed by an optional pay-, that is, either ethereum:0x..... or ethereum:pay-0x....., but says nothing about when the pay- prefix is allowed or required. Does it make no difference whatsoever? If so it should be specified, because it’s quite counterintuitive that there would be a prefix that you can arbitrarily include or leave out and it makes no difference at all.

Intuition suggests that maybe the ppay- prefix should be present when the transaction has a non-zero value, but (a) that’s entirely me speculating, it’s not stated anywhere, and (b) there are examples with non-zero value and with no pay- prefix.