> For the complete documentation index, see [llms.txt](https://docs.ethpm.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ethpm.com/erc1319.md).

# ERC1319: Package Registry Standard

An ethPM registry is an on-chain datastore for package releases. For each package release, three pieces of information are committed to storage:

* a package name
* a package version
* the content-addressed URI associated with the package's manifest.

[ERC1319](http://eips.ethereum.org/EIPS/eip-1319) was written to define the API for an on-chain ethPM registry. It is the minimum feasible API for a registry to interoperate with various ethPM tooling. It is encouraged for people to build their own registry implementations that extend upon the standard to support any kind of specialized behavior.

#### Reference Registry Implementations

There are a couple different implementations of ERC1319 available. 

* [Escape-Truffle](https://github.com/ethpm/escape-truffle/)
  * Solidity implementation with release deletion (but prevents re-releasing the same package version)
* [Simple Registry](https://github.com/ethpm/solidity-registry)
  * Solidity implementation without release deletion
* Vyper (experimental)
  * [with release deletion](https://github.com/ethereum/web3.py/blob/master/ethpm/assets/vyper_registry/registry_with_delete.vy)
  * [without release deletion](https://github.com/ethereum/web3.py/blob/master/ethpm/assets/vyper_registry/registry.vy)

#### Deploying your own registry.

ethPM-CLI provides [a simple command](/ethpm-developer-guide/install-a-package.md#deploying-a-registry) deploy the Simple Registry to any blockchain.

Escape-Truffle provides [this script](https://github.com/ethpm/escape-truffle/blob/master/scripts/deploy.sh) to assist with deploying its series of smart contracts.

#### Package Naming and Versioning

As of ethPM V3, the `name` and `version` field of a manifest are no longer strictly required. Best practice is that every package **should** define these in their manifest. Some tooling may even go as far as requiring these fields are defined before cutting a release. When a package is released on a registry, users must provide an official `name` and `version` under which to identify a release on the blockchain. The following table defines how a package should be identified, considering the various cases when manifest defines / omits the `name` and `version`, and whether or not the manifest is stored on an on-chain registry.

|                           | Manifest contains name and version                               | Manifest omits name and version              |
| ------------------------- | ---------------------------------------------------------------- | -------------------------------------------- |
| Sourced from registry     | Manifest `name, version` **must** match registry `name, version` | Registry `name, version` is valid identifier |
| Not sourced from registry | Manifest `name, version` is the valid identifier                 | Ambiguous, user must define `name, version`  |