A unified URI scheme for all payment target types allows applications
to offer user interactions with URIs that represent payment targets,
simplifying the introduction of new payment systems and applications.
This can easily be used for Ethereum and L2 “payments” for integration with payment platforms. There are examples for Bitcoin and Interledger Protocol Address w/ ENS-style addressing.
ERC: Standard URI scheme with metadata, value and byte code
01:12PM - 17 Feb 16 UTC
12:46PM - 16 Feb 18 UTC
This proposal is inspired by [BIP 21](https://github.com/bitcoin/bips/blob/maste
… r/bip-0021.mediawiki) and could apply to [IBAN address format](https://github.com/ethereum/wiki/wiki/ICAP:-Inter-exchange-Client-Address-Protocol) but can be extended to other proposed addresses formats. Imagine these scenarios:
- An exchange or a instant converter like shape shift wants to create a single ethereum address for payments that will be converted into credit in their internal system or output bitcoin to an address
- A store wants to show a QR code to a client that will pop up a payment for exactly 12.34 ethers, which contains metadata on the product being bought
- A betting site wants to provide a link that the user can click on his site and it will open a default ethereum wallet and and execute a specific contract with given parameters
- A dapp in Mist wants so simply ask the user to sign a transaction with a specific abi in a single call
In all these scenarios, the provider wants to set up internally a transaction, with a recipient, an associated number of ethers (or none) and optional byte code, 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: shape shift 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.
I propose adding, beyond address, also optional byte code and value to any proposed address standard. 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 byte code by reading the qr code.
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.
Clicking this link would open a transaction that would try to send _5 unicorns_ to address _deadbeef_. The user would then simply to approve, based on each wallet UI.
### Without byte code
Alternatively, the byte code could be generated by the client and the request would be in plain text:
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 byte code.
ethereum:0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7?gas=100000&function=transfer(address 0xdeadbeef, uint 5)
EIP-681: URL Format for Transaction Requests
Ethereum is already available here:
But we have to wait for adoption.
This uses an GANA registry. It shouldn’t be too hard to add another scheme.
EDIT: I’ve written one and submitted it to the registry. Hoping to hear back from them soon.