ERC-67: URI Scheme with Metadata, Value and Bytecode

Format for encoding transactions into a URI

Metadata

Status: WithdrawnStandards Track: ERCCreated: 2016-02-17

Authors

Alex Van de Sande (@alexvansande)

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This proposal (inspired by BIP 21) defines a format for encoding a transaction into a URI, including a recipient, number of ethers (possibly zero), and optional bytecode.

Motivation

Imagine these scenarios:

In all these scenarios, the provider wants to internally set up a transaction, with a recipient, an associated number of ethers (or none) and optional bytecode, all without requiring any fuss from the end user that is expected simply to choose a sender and authorise the transaction.

Currently implementations for this are wonky: ShapeShift creates tons of temporary addresses and uses an internal system to check which one correspond to which metadata, there isn't any standard way for stores that want payment in ether to put specific metadata about price on the call and any app implementing contracts will have to use different solutions depending on the client they are targeting.

The proposal goes beyond address, and also includes optional bytecode and value. Of course this would make the link longer, but it should not be something visible to the user. Instead it should be shown as a visual code (QR or otherwise), a link, or some other way to pass the information.

If properly implemented in all wallets, this should make execution of contracts directly from wallets much simpler as the wallet client only needs to put the bytecode obtained by reading the QR code.

Specification

If we follow the bitcoin standard, the result would be:

Other data could be added, but ideally the client should take them from elsewhere in the blockchain, so instead of having a label or a message to be displayed to the users, these should be read from an identity system or metadata on the transaction itself.

Example 1

Clicking this link would open a transaction that would try to send 5 unicorns to address deadbeef. The user would then simply approve, based on each wallet UI.

Without Bytecode

Alternatively, the bytecode could be generated by the client and the request would be in plain text:

Example 2

This is the same function as above, to send 5 unicorns from he sender to deadbeef, but now with a more readable function, which the client converts to bytecode.