Currently this repository hosts Proof-of-Concept contracts for ENSv2. See the ENSv2 design doc for details of the system architecture.
At present the following contracts are implemented:
- RegistryDatastore - an implementation of the registry datastore defined in the design doc. All registry contracts must use a singleton instance of the datastore for storage of subregistry and resolver addresses.
- ERC1155Singleton - an implementation of the ERC1155 standard that permits only a single token per token ID. This saves on gas costs for storage while also permitting easy implementation of an
ownerOffunction. - BaseRegistry - an implementation of the registry defined in the design doc, to be used as a base class for custom implementations.
- RootRegistry - an implementation of an ENSv2 registry to be used as the root of the name hierarchy. Owned by a single admin account that can authorise others to create and update TLDs. Supports locking TLDs so they cannot be further modified.
- ETHRegistry - a basic implementation of an ENSv2 .eth registry. Supports locking TLDs and name expirations; when a name is expired, its resolver and subregistry addresses are zeroed out. User registrations and renewals are expected to occur via a controller contract that handles payments etc, just as in ENSv1.
- UserRegistry - a sample implementation of a standardized user registry contract. Supports locking subnames.
- UniversalResolver - a sample implementation of the ENSv2 resolution algorithm.
The ENSv2 contracts module uses forge + hardhat combined to allow for simple unit testing, e2e tests (incl. CCIP-Read support), performant build forks, etc.
https://book.getfoundry.sh/getting-started/installation
Install foundry: guide
Install packages (bun)
bun installforge buildTesting is done in both forge and hardhat, so you can use the helper script.
bun run test$ forge fmt$ forge snapshotFoundry also comes with cast, anvil, and chisel, all of which are useful for local development (docs)