URI Scheme with Metadata, Value and Bytecode
ERC-67 is a proposal that defines a format for encoding transactions into a URI, including a recipient, number of ethers (possibly zero), and optional bytecode. The motivation behind this proposal is to simplify the process of setting up transactions with a recipient, associated ethers, and optional bytecode, without requiring any fuss from the end user. Currently, implementations for this are inconsistent, and there isn't any standard way for stores that want payment in ether to put specific metadata about price on the call. The proposal goes beyond address and also includes optional bytecode and value. If properly implemented in all wallets, this should make execution of contracts directly from wallets much simpler. The proposal tries to keep backward compatibility and not break existing things, and there are no known security considerations at this time.
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.
Imagine these scenarios:
* An exchange or a instant converter like ShapeShift 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 execute a specific contract with given parameters.
* A dapp in Mist wants to simply ask the user to sign a transaction with a specific ABI in a single call.
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.
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 approve, based on each wallet UI.
Alternatively, the bytecode 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 bytecode.
ethereum:0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7?gas=100000&function=transfer(address 0xdeadbeef, uint 5)
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.View all