Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
ERC: Human-Readable Transaction Requests #1138
A standard format for providing additional human-readable data to smart contract functions using Ethereum function call URIs, as specified in ERC-681.
Including standard metadata in Transaction Request URIs will allow wallets to describe the proposed transaction to the end user in a more human-readable format, and also including the function parameter names that correspond to the passed arguments.
By implementing this ERC, a wallet will be able to display:
While the URL Format for Transaction Requests supports creating ETH transactions with minimum required data, not enough information is available in both the URI and blockchain to explain what parameters are being passed to the function.
As more wallets and dapps adopt the ERC-681 standard, we need a way for all this software to inform the end-user about the transactions being created. One of the greatest frustrations (and attack vectors) with existing methods and wallets is the difficulty in understanding transaction data. Software supporting these URI standards should be able to clearly tell an end-user about precisely what is being signed.
Function call URIs follow the ERC-681 protocol, with the following change:
Any arguments passed to the contract can be replaced into the
An optional helper can be included in this syntax to display numeric values (such as a token's value) with their appropriate decimal places. To do this, square brackets containing the number of decimal places between 0 and 18 can be included before the ending $ character:
Wallet apps should offer an option to view the details of the function call.
This view should clearly display:
If the wallet is capable of interpreting the contract address (for example, a known ERC-20 or ERC-721 token), it could display more information about the transaction. For example, if the wallet is able to resolve the name, icon, decimals, and symbol of a non-fungible token, it should do so and display these depending on the specific transaction's context.
Copyright and related rights waived via CC0.
This ERC is now compatible with the ERC-681 standard protocol.
An open question is verifying that the param names passed in the URI match the function's parameter names in the original ABI. Since this data is not included in the contract bytecode, it's difficult to enforce.
https://eips.ethereum.org/EIPS/eip-712 suggests a method of verifying the parameters, but this comes with its own set of problems.
wondering if it would not be better to use multihash here - HTTP/HTTPS centralizes again and content addressing would fit better into the ecosystem than the location addressing used here
I think this whole EIP has the wrong approach. You should NEVER trust a dapp to tell you what the transaction does. The client/wallet should always be the one trying to show the user the intended action, preferably using rad spec pulled from the contract (a lot of them publish already meta information to swarm, but nobody uses it yet) and if no info is available the client/wallet should provide it.
@alexvandesande I think you and I agree on this but I want to make sure, you should never trust the dapp without a mechanism for verifying what it says. I think it is fine to have the dapp provide the signer with information, as long as that information can be trustlessly verified with something (like the contract).
referenced this issue
Jun 20, 2018
Thank you for the suggestions. It would be very worthwhile for transaction requests to include human-readable data spec along with variable injection of verified params (perhaps radspec). I'll be updating the standard soon to take these ideas into account.