> 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.&#x20;

* [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`  |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ethpm.com/erc1319.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
