EthPM URI Specification

StagnantStandards Track: ERC
Created: 2020-09-04
Requires: EIP-2678
Nick Gheorghita (@njgheorghita), Piper Merriam (@pipermerriam), g. nicholas d'andrea (@gnidan), Benjamin Hauser (@iamdefinitelyahuman)
DiscussionsOriginal linkEdit
1 min read

The ERC-2942 EthPM URI Specification is a proposal for a custom URI scheme that can be used to identify EthPM assets within the Ethereum Package Manager ecosystem. This scheme allows users and tooling to easily specify a package, registry, or release with a single string, simplifying the steps required to install, publish, or distribute EthPM packages. The scheme includes a required "scheme" field, which must be either "ethpm" or "erc1319", and a "registry_address" field, which should be either an ENS name or a 0x-prefixed, checksummed address. An optional "chain_id" field can be included to represent the chain ID on which the registry is located, and optional "package_name" and "package_version" fields can be included to specify the target package and version. The specification also includes guidelines for safely escaping URL-unsafe characters in the package version. The need for this ERC emerged when refining EIP-681, and the proposal aims to maintain backward compatibility with EIP-67 URIs while allowing for future use cases and innovation. At the time of writing, there are no known security considerations for this specification.

Anyone may contribute to propose contents.
Go propose

Simple Summary

A custom URI scheme to identify an EthPM registry, package, release, or specific contract asset within a release.


When interacting with the EthPM ecosystem, users and tooling can benefit from a URI scheme to identify EthPM assets. Being able to specify a package, registry, or release with a single string makes simplifies the steps required to install, publish, or distribute EthPM packages.




  • Required
  • Must be one of ethpm or erc1319. If future versions of the EthPM registry standard are designed and published via the ERC process, those ERCs will also be valid schemes.


  • Required
  • This SHOULD be either an ENS name or a 0x-prefixed, checksummed address. ENS names are more suitable for cases where mutability of the underlying asset is acceptable and there is implicit trust in the owner of the name. 0x prefixed addresses are more preferable in higher security cases to avoid needing to trust the controller of the name.


  • Optional
  • Integer representing the chain id on which the registry is located
  • If omitted, defaults to 1 (mainnet).


  • Optional
  • String of the target package name


  • Optional
  • String of the target package version
  • If the package version contains any url unsafe characters, they MUST be safely escaped
  • Since semver is not strictly enforced by the ethpm spec, if the package_version is omitted from a uri, tooling SHOULD avoid guessing in the face of any ambiguity and present the user with a choice from the available versions.


  • Optional
  • A path that identifies a specific asset within a versioned package release.
  • This path MUST conform to the JSON pointer spec and resolve to an available asset within the package.


Most interactions within the EthPM ecosystem benefit from a single-string representation of EthPM assets; from installing a package, to identifying a registry, to distributing a package. A single string that can faithfully represent any kind of EthPM asset, across the mainnet or testnets, reduces the mental overload for new users, minimizes configuration requirements for frameworks, and simplifies distribution of packages for package authors.

Test Cases

A JSON file for testing various URIs can be found in the ethpm-spec repository fixtures.


The EthPM URI scheme has been implemented in the following libraries:

Security Considerations

In most cases, an EthPM URI points to an immutable asset, giving full security that the target asset has not been modified. However, in the case where an EthPM URI uses an ENS name as its registry address, it is possible that the ENS name has been redirected to a new registry, in which case the guarantee of immutability no longer exists.

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.
Supported by