HomeEIPsNewsletter
EIPsERC-831
ERC-831

URI Format for Ethereum

A way of creating Ethereum URIs for various use-cases.
StagnantStandards Track: ERC
Created: 2018-01-15
Requires: EIP-67, EIP-681
ligi (@ligi)
DiscussionsOriginal linkEdit
1 min read

ERC-831 is a standard for creating Ethereum URIs, which are used for cross-application signaling between loosely coupled applications. These URIs can be embedded in QR codes, hyperlinks, emails, or chat messages, and allow for instant invocation of the user's preferred wallet application. The URI format contains "ethereum" or "eth" in the schema (protocol) part and is constructed with an optional prefix and mandatory payload. The prefix defines the use-case for the URI, and if no prefix is given, "pay-" is assumed for backward compatibility with EIP-67. The payload's content depends on the prefix and is defined in the ERC for the specific use-case.

The need for ERC-831 arose when refining EIP-681, which is a standard for URL format for transaction requests. ERC-831 aims to keep backward compatibility with EIP-67 and not break existing things. The open prefix approach was chosen to adopt future use-cases and not block the whole "ethereum:" scheme for a limited set of use-cases that existed at the time of writing.

To ensure that the amount transacted is the same as the amount intended, the amount communicated to the human user should be easily verifiable by inspection, including the order of magnitude. In case of ERC-20 token payments, the interface should display the amount in the units specified in the token contract. Otherwise, it should be displayed as expressed in the URL, possibly alerting the user to the uncertainty of the nominal unit. The use of scientific notation with an exponent corresponding to the nominal unit of the transacted token is advisable to facilitate human inspection of the amount.

In summary, ERC-831 is a standard for creating Ethereum URIs that allow for cross-application signaling between loosely coupled applications. It aims to keep backward compatibility with EIP-67 and adopt future use-cases with an open prefix approach. The standard also provides guidelines for displaying the amount transacted to ensure that it is the same as the amount intended.

Video
Anyone may contribute to propose contents.
Go propose
Original

Abstract

URIs 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 URI format allows for instant invocation of the user's preferred wallet application.

Specification

Syntax

Ethereum URIs contain "ethereum" or "eth" in their schema (protocol) part and are constructed as follows:

request                 = "eth" [ "ereum" ] ":" [ prefix "-" ] payload
prefix                  = STRING
payload                 = STRING

Semantics

prefix is optional and defines the use-case for this URI. If no prefix is given: "pay-" is assumed to be concise and ensure backward compatibility to EIP-67. When the prefix is omitted, the payload must start with 0x. Also prefixes must not start with 0x. So starting with 0x can be used as a clear signal that there is no prefix.

payload is mandatory and the content depends on the prefix. Structuring of the content is defined in the ERC for the specific use-case and not in the scope of this document. One example is EIP-681 for the pay- prefix.

Rationale

The need for this ERC emerged when refining EIP-681. We need a container that does not carry the weight of the use-cases. EIP-67 was the first attempt on defining Ethereum-URIs. This ERC tries to keep backward compatibility and not break existing things. This means EIP-67 URIs should still be valid and readable. Only if the prefix feature is used, EIP-67 parsers might break. No way was seen to avoid this and innovate on the same time. This is also the reason this open prefix approach was chosen to being able to adopt to future use-cases and not block the whole "ethereum:" scheme for a limited set of use-cases that existed at the time of writing this.

Security Considerations

There are no known security considerations at this time.

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

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
Serve Ethereum Builders, Scale the Community.
Resources
GitHub
Supported by