Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resurrect EIP-831 and add "eth" shorhand #5335

Merged
merged 2 commits into from
Aug 5, 2022
Merged

Resurrect EIP-831 and add "eth" shorhand #5335

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4424ba5
Resurrect EIP-831 and add "eth" shorhand
ligi Jul 25, 2022
5b80849
Update EIPS/eip-831.md
ligi Jul 28, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 12 additions & 15 deletions EIPS/eip-831.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,17 +1,16 @@
---
eip: 831
title: URI Format for Ethereum
author: ligi <ligi@ligi.de>
description: A way of creating Ethereum URIs for various use-cases.
author: ligi (@ligi)
discussions-to: https://ethereum-magicians.org/t/eip-831-uri-format-for-ethereum/10105
status: Draft
type: Standards Track
category: ERC
status: Stagnant
created: 2018-01-15
ligi marked this conversation as resolved.
Show resolved Hide resolved
requires: 67, 681
---

## Simple Summary

A standard way of creating Ethereum URIs for various use-cases.

## 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.
Expand All @@ -20,27 +19,25 @@ URIs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages prov

### Syntax

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

request = "ethereum" ":" [ prefix "-" ] payload
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 ERC-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 ERC-681 for the pay- prefix.
`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](./eip-67.md). 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](./eip-681) for the pay- prefix.

## Rationale

The need for this ERC emerged when refining ERC-681. We need a container that does not carry the weight of the use-cases. ERC-67 was the first attempt on defining Ethereum-URIs. This ERC tries to keep backward compatibility and not break existing things. This means ERC-67 URIs should still be valid and readable. Only if the prefix feature is used, ERC-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.
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.

## References
## Security Considerations

1. ERC-681, ./eip-681.md
2. ERC-67, ./eip-67.md
There are no known security considerations at this time.

## Copyright

Expand Down