# Introduction ### Introduction The CORE ID is a distributed, open, and extensible naming system based on the CORE Chain. CORE ID’s job is to map human-readable names like ‘alice.core’ to machine-readable identifiers such as Core addresses, other cryptocurrency addresses, content hashes, and metadata. CORE ID also supports ‘reverse resolution’, making it possible to associate metadata such as canonical names or interface descriptions with Ethereum addresses. CORE ID has similar goals to DNS, the Internet’s Domain Name Service, but has significantly different architecture due to the capabilities and constraints provided by the Core blockchain. Like DNS, CORE ID operates on a system of dot-separated hierarchical names called domains, with the owner of a domain having full control over subdomains. Top-level domains, like ‘.core’, are owned by smart contracts called registrars, which specify rules governing the allocation of their subdomains. Anyone may, by following the rules imposed by these registrar contracts, obtain ownership of a domain for their own use. CORE ID also supports importing in DNS names already owned by the user for use on CORE ID. Because of the hierarchal nature of CORE ID, anyone who owns a domain at any level may configure subdomains - for themselves or others - as desired. For instance, if Alice owns 'alice.core', she can create 'pay.alice.core' and configure it as she wishes. CORE ID is deployed on the Core main network and on several test networks. If you use a library such as the etherjs Javascript library, or an end-user application, it will automatically detect the network you are interacting with and use the CORE ID deployment on that network. You can try CORE ID out for yourself now by using the CORE ID App, or by using any of the many CORE ID enabled applications on our homepage. ### CORE ID Architecture CORE ID has two principal components: the registry, and resolvers. The CORE ID registry consists of a single smart contract that maintains a list of all domains and subdomains, and stores three critical pieces of information about each: > * The owner of the domain > * The resolver for the domain > * The caching time-to-live for all records under the domain The owner of a domain may be either an external account (a user) or a smart contract. A registrar is simply a smart contract that owns a domain and issues subdomains of that domain to users that follow some set of rules defined in the contract. Owners of domains in the CORE ID registry may: > * Set the resolver and TTL for the domain > * Transfer ownership of the domain to another address > * Change the ownership of subdomains The CORE ID registry is deliberately straightforward and exists only to map from a name to the resolver responsible for it. Resolvers are responsible for the actual process of translating names into addresses. Any contract that implements the relevant standards may act as a resolver in CORE ID. General-purpose resolver implementations are offered for users whose requirements are straightforward, such as serving an infrequently changed address for a name. Each record type - cryptocurrency address, IPFS content hash, and so forth - defines a method or methods that a resolver must implement in order to provide records of that kind. New record types may be defined at any time via the EIP standardization process, with no need to make changes to the CORE ID registry or to existing resolvers in order to support them. Resolving a name in CORE ID is a two-step process: First, ask the registry what resolver is responsible for the name, and second, ask that resolver for the answer to your query. In the above example, we're trying to find the Core address pointed to by 'foo.core'. First, we ask the registry which resolver is responsible for 'foo.core'. Then, we query that resolver for the address of 'foo.core'. #### Namehash Resource constraints in smart contracts make interacting directly with human-readable names inefficient, so CORE ID works purely with fixed length 256-bit cryptographic hashes. In order to derive the hash from a name while still preserving its hierarchal properties, a process called Namehash is used. For example, the namehash of 'alice.core' is *0x787192fc5378cc32aa956ddfdedbf26b24e8d78e40109add0eea2c1a012c3dec*; this is the representation of names that is used exclusively inside CORE ID. Namehash is a recursive process that can generate a unique hash for any valid domain name. Starting with the namehash of any domain - for example, 'alice.core' - it's possible to derive the namehash of any subdomain - for example 'iam.alice.core' - without having to know or handle the original human-readable name. It is this property that makes it possible for CORE ID to provide a hierarchal system, without having to deal with human-readable text strings internally. Before being hashed with namehash, names are first normalized, using a process called UTS-46 normalization. This ensures that upper- and lower-case names are treated equivalently, and that invalid characters are prohibited. Anything that hashes and resolves a name **must** first normalize it, to ensure that all users get a consistent view of CORE ID. # Connect to CORE ID using ethers.js Core id is compatible with ens, you can use ethers.js to connect to CORE ID ``` import { ethers } from "ethers"; const network = { name: "CORE", chainId: 1116, ensAddress: "0x00000000003dB7663112d1e121c6D2bb8220F671" }; //const provider = new ethers.providers.JsonRpcProvider("https://rpc.coredao.org/", network) const provider = new ethers.providers.Web3Provider(window.ethereum, network) await provider.getBalance("coreid.core"); // { BigNumber: "26959293642897667667" } await provider.resolveName("coreid.core"); // '0x9826a59Aa17C36e88AA2F6dC367772381f034401' await provider.lookupAddress("0x9826a59Aa17C36e88AA2F6dC367772381f034401"); // 'coreid.core' // Requires primary name to be set ``` For more information on how to use it, you can check out the [ethers.js docs](https://docs.ethers.io/v5/api/providers/provider/#Provider--ens-methods) # CID SDK ## Use cidjs SDK to interact with Core ID contracts ## CID.js Javascript bindings for the CORE ID .core Domain ### Overview of the API #### Installation Install @ciddomains/cidjs, alongcide [web3](https://www.npmjs.com/package/web3). ``` npm install @ciddomains/cidjs web3 ``` #### Getting Started All that's needed to get started is a web3 provider instance, you should pass it and select network id when creating a new CID instance. ``` // core mainnet domain example, getAddress const CID = require('@ciddomains/cidjs').default const Web3 = require('web3') async function main(name) { const provider = new Web3.providers.HttpProvider("https://rpc.coredao.org") let cid = new CID({ provider }) const address = await cid.name(name).getAddress() // 0x123 console.log("name: %s, address: %s", name, address) } main("coreid.core") // 0x9826a59Aa17C36e88AA2F6dC367772381f034401 ``` #### Reverse Resolution ``` // core mainnet domain example, getName const CID = require('@ciddomains/cidjs').default const Web3 = require('web3') async function main(address) { const provider = new Web3.providers.HttpProvider("https://rpc.coredao.org") let cid = new CID({ provider }) const {name} = await cid.getName(address) console.log("name: %s, address: %s", name, address) } main("0x9826a59Aa17C36e88AA2F6dC367772381f034401") // coreid.core ``` #### exports ``` default - CID getCidAddress getResolverContract getCIDContract namehash labelhash ``` #### CID Interface ``` name(name: String) => Name ``` Returns a Name Object, that allows you to make record queries. ``` resolver(address: EvmAddress) => Resolver ``` Returns a Resolver Object, allowing you to query names from this specific resolver. Most useful when querying a different resolver that is different than is currently recorded on the registry. E.g. migrating to a new resolver ``` async getName(address: EvmAddress) => Promise ``` Returns the reverse record for a particular Evm address. ``` async setReverseRecord(name: Name) => Promise ``` Sets the reverse record for the current Evm address #### Name Interface ```ts async getOwner() => Promise ``` Returns the owner/controller for the current CID name. ```ts async setOwner(address: EvmAddress) => Promise ``` Sets the owner/controller for the current CID name. ```ts async getResolver() => Promise ``` Returns the resolver for the current CID name. ```ts async setResolver(address: EvmAddress) => Promise ``` Sets the resolver for the current CID name. ```ts async getTTL() => Promise ``` Returns the TTL for the current CID name. ```ts async getAddress(coinId: String) => Promise ``` Returns the address for the current CID name for the coinId provided. ```ts async setAddress(coinId: String, address: EvmAddress) => Promise ``` Sets the address for the current CID name for the coinId provided. ```ts async getContent() => Promise ``` Returns the contentHash for the current CID name. ```ts async setContenthash(content: ContentHash) => Promise ``` Sets the contentHash for the current CID name. ```ts async getText(key: String) => Promise ``` Returns the text record for a given key for the current CID name. ```ts async setText(key: String, recordValue: String) => Promise ``` Sets the text record for a given key for the current CID name. ```ts async setSubnodeOwner(label: String, newOwner: EvmAddress) => Promise ``` Sets the subnode owner for a subdomain of the current CID name. ```ts async setSubnodeRecord(label: String, newOwner: EvmAddress, resolver: EvmAddress, ttl: ?Number) => Promise ``` Sets the subnode owner, resolver, ttl for a subdomain of the current CID name in one transaction. ```ts async createSubdomain(label: String) => Promise ``` Creates a subdomain for the current CID name. Automatically sets the owner to the signing account. ```ts async deleteSubdomain(label: String) => Promise ``` Deletes a subdomain for the current CID name. Automatically sets the owner to "0x0..." ### Resolver Interface ```ts address ``` Static property that returns current resolver address ```ts name(name) => Name ``` Returns a Name Object that hardcodes the resolver Build SDK and test on your test machine ```shell yarn install yarn run build node main.js ``` # HTTP API **Convert Name to Address** ``` // Replace "123.core" with your name const name = "123.core"; const response = await fetch(`https://coreid.org/api?method=getAddress&name=${name}`); const { address } = await response.json(); //0x810791a3f967EB66B75aEb62251795d181bce680 ``` **Convert Address to Name** ``` // Replace "address" with the address you want to lookup. const address = "0x1234...abcdef"; const response = await fetch(`https://coreid.org/api?method=getName&address=${address}`); const { name } = await response.json(); ``` #### Get all domains ``` const response = await fetch(`https://coreid.org/api?method=getAllDomains`); ``` #### Get Websites ``` const response = await fetch(`https://coreid.org/api?method=getWebsites`); ``` # Published Contracts CID Token Contract: *0x000000000E1D682Cc39ABe9B32285fdEa1255374* *----------------------------------------*\ \ Domain NFT Contract: *0x75eB562081dE66B982Df285Ac3922E143936D718* Name Service Contract ```json { "Registry": "0x00000000003dB7663112d1e121c6D2bb8220F671", "PublicResolver": "0x96BA99fa095f0dbfe81De678492fB44D16371a43", "RegistrarController": "0xc1E3943c1C7e36d3E1e032052F1f2719a1d9Cd8e", "ReverseRegistrar": "0x69Cbf7dd65341EC3E85A62C103d1b87a3F3A4503", "BaseRegistrarImplementation": "0x75eB562081dE66B982Df285Ac3922E143936D718" } ``` # Core rpc ``` Network Name: Core Chain MainNet RPC: https://rpc.coredao.org/ ChainID: 1116 NetworkID: 1116 Currency Symbol: CORE Explorer: https://scan.coredao.org ``` # CORE ID enabling your dapp CORE ID integration in an application encompasses several critical features, each of which can be implemented independently. While comprehensive CORE ID integration is ideal, even basic support can be a huge benefit to users. Below, we outline three levels of CORE ID integration. Level 1 is easily achieved and provides high impact for users, while levels 2 and 3 provide more functionality to your users, improving your dApp's usability and your users' experience interacting with your DApp. ### 1. Resolving CORE ID names The first step to supporting CORE ID in your application is making your application understand CORE ID names, and accepting them anywhere an address is accepted. To understand how to do this, see Resolving Names. If possible, when a user enters an CORE ID name instead of an address, remember the CORE ID name, not the address it currently resolves to. This makes it possible for users to update their CORE ID names and have applications they used the name in automatically resolve to the new address, in the same way that you would expect your browser to automatically direct you to the new IP address if a site you use changes servers. If your application deals with user funds or other critical resources, you may want to keep track of the address a name resolves to and warn them when it changes, to ensure they are aware of the change. By accepting CORE ID names in your application, you remove the need for users to copy and paste - or worse, type out - long and opaque Core addresses, which leads to errors and lost funds. ### 2. Support Reverse Resolution The second level of CORE ID integration involves displaying CORE ID names wherever your app currently displays addresses. If a user entered an CORE ID in your DApp, you should retain this name and show it to them whenever you would normally show the address. If a user entered an address, or the address was obtained from elsewhere, you may still be able to show an CORE ID name, by doing Reverse Resolution. This permits you to find the canonical name for an address and display that when possible. If no canonical name is provided, your application can fall back to displaying the address as it did previously. By supporting reverse resolution, you make it easier for your users to identify accounts they interact with, associating them with a short human-readable name instead of a long opaque Core address. ### 3. Let Users Name Things The final step for comprehensive CORE ID integration is to facilitate associating CORE ID names with resources created by or managed with your application. This can take two forms: #### Name Registration By obtaining an CORE ID name for your product and allowing users to easily register subdomains, you can provide users with an easy way to name resources created in your DApp. For example, if your DApp is a cryptocurrency wallet, you can make it easy for users to obtain an CORE ID domain of the form *theirname.yourwallet.core*, allowing them to give their name out to others more easily. To learn how to do this, see Writing a Registrar in the Smart Contract Developer Guide. #### Name Updates By providing users with an easy way to update a name they own to point at your application’s resources, users can assign names they already own to your DApp's resources. See Managing Names to learn how to do this. # CORE ID Registry | description | | --------------------- | | The CORE ID registry. | ### Registry [Source](https://github.com/ensdomains/ens/blob/master/contracts/ENS.sol) The CORE ID registry is the core contract that lies at the heart of CORE ID resolution. All CORE ID lookups start by querying the registry. The registry maintains a list of domains, recording the owner, resolver, and TTL for each, and allows the owner of a domain to make changes to that data. The CORE ID registry is specified in [EIP 137](https://eips.ethereum.org/EIPS/eip-137). ### Get Owner ``` function owner(bytes32 node) external view returns (address); ``` Returns the owner of the name specified by `node`. ### Get Resolver ``` function resolver(bytes32 node) external view returns (address); ``` Returns the address of the resolver responsible for the name specified by `node`. ### Get TTL ``` function ttl(bytes32 node) external view returns (uint64); ``` Returns the caching time-to-live of the name specified by `node`. Systems that wish to cache information about a name, including ownership, resolver address, and records, should respect this value. If TTL is zero, new data should be fetched on each query. ### Set Owner ``` function setOwner(bytes32 node, address owner) external; ``` Reassigns ownership of the name identified by `node` to `owner`. Only callable by the current owner of the name. Emits the following event: ``` event Transfer(bytes32 indexed node, address owner); ``` ### Set Resolver ``` function setResolver(bytes32 node, address resolver) external; ``` Updates the resolver associated with the name identified by `node` to `resolver`. Only callable by the current owner of the name. `resolver` must specify the address of a contract that implements the Resolver interface. Emits the following event: ``` event NewResolver(bytes32 indexed node, address resolver); ``` ### Set TTL ``` function setTTL(bytes32 node, uint64 ttl) external; ``` Updates the caching time-to-live of the name identified by `node`. Only callable by the current owner of the name. Emits the following event: ``` event NewTTL(bytes32 indexed node, uint64 ttl); ``` ### Set Subdomain Owner ``` function setSubnodeOwner(bytes32 node, bytes32 label, address owner) external; ``` Creates a new subdomain of `node`, assigning ownership of it to the specified `owner`. If the domain already exists, ownership is reassigned but the resolver and TTL are left unmodified. `label` is the keccak256 hash of the subdomain label to create. For example, if you own *alice.c*ore and want to create the subdomain *iam.alice.core*, supply `namehash('alice.core')` as the `node`, and `keccak256('iam')` as the `label`. Emits the following event: ``` event NewOwner(bytes32 indexed node, bytes32 indexed label, address owner); ``` #### Set Record ``` function setRecord(bytes32 node, address owner, address resolver, uint64 ttl); ``` Sets the owner, resolver, and TTL for an CORE ID record in a single operation. This function is offered for convenience, and is exactly equivalent to calling `setResolver`, `setTTL` and `setOwner` in that order. #### Set Subdomain Record ``` function setSubnodeRecord(bytes32 node, bytes32 label, address owner, address resolver, uint64 ttl); ``` Sets the owner, resolver and TTL for a subdomain, creating it if necessary. This function is offered for convenience, and permits setting all three fields without first transferring ownership of the subdomain to the caller. #### Set Approval ``` function setApprovalForAll(address operator, bool approved); ``` Sets or clears an approval. Approved accounts can execute all CORE ID registry operations on behalf of the caller. #### Check Approval ``` function isApprovedForAll(address owner, address operator) external view returns (bool); ``` Returns true if `operator` is approved to make CORE ID registry operations on behalf of `owner`. #### Check Record Existence ``` function recordExists(bytes32 node) public view returns (bool); ``` Returns true if `node` exists in this CORE ID registry. This will return false for records that are in the legacy CORE ID registry but have not yet been migrated to the new one. # Name processing | description | | -------------------------------------------------- | | Describes how to normalize and hash CORE ID names. | In place of human-readable names, CORE ID works purely with fixed length 256-bit cryptographic hashes. In order to derive the hash from a name while still preserving its hierarchal properties, a process called Namehash is used. For example, the namehash of 'alice.core' is *0x787192fc5378cc32aa956ddfdedbf26b24e8d78e40109add0eea2c1a012c3dec*; this is the representation of names that is used exclusively inside CORE ID. Before being hashed with namehash, names are first normalized, using a process called UTS-46 normalization. This ensures that upper- and lower-case names are treated equivalently, and that invalid characters are prohibited. Anything that hashes and resolves a name **must** first normalize it, to ensure that all users get a consistent view of CORE ID. ### Normalising Names Before a name can be converted to a node hash using Namehash, the name must first be normalized and checked for validity - for instance, converting *fOO.*core into *foo.*core, and prohibiting names containing forbidden characters such as underscores. It is crucial that all applications follow the same set of rules for normalization and validation, as otherwise two users entering the same name on different systems may resolve the same human-readable name into two different CORE ID names. Applications using CORE ID and processing human-readable names must follow [UTS46](http://unicode.org/reports/tr46/) for normalization and validation. Processing should be done with non-transitional rules, and with UseSTD3ASCIIRules=true. ### Hashing Names Namehash is a recursive process that can generate a unique hash for any valid domain name. Starting with the namehash of any domain - for example, 'alice.core' - it's possible to derive the namehash of any subdomain - for example 'iam.alice.core' - without having to know or handle the original human-readable name. It is this property that makes it possible for CORE ID to provide a hierarchal system, without having to deal with human-readable text strings internally. #### Terminology * domain - The complete, human-readable form of a name; eg, *iam.alice.*core. * label - A single component of a domain - eg, *iam*, *alice*, or *eth*core. * label hash - the output of the keccak-256 function applied to a label; eg, `keccak256(‘core’) = 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0` * node - The output of the `namehash` function, used to uniquely identify a name in CORE ID. #### Algorithm First, a domain is divided into labels by splitting on periods (‘.’). So, ‘abc.wallet.core’ becomes the list \[‘abc’, ‘wallet’, ‘core’]. The namehash function is then defined recursively as follows: ``` namehash([]) = 0x0000000000000000000000000000000000000000000000000000000000000000 namehash([label, …]) = keccak256(namehash(…), keccak256(label)) ``` A sample implementation in Python is provided below. ``` def namehash(name): if name == '': return '\0' * 32 else: label, _, remainder = name.partition('.') return sha3(namehash(remainder) + sha3(label)) ``` Namehash is specified in [EIP 137](https://eips.ethereum.org/EIPS/eip-137). ### # Public Resolver | description | | ---------------------------- | | The default public resolver. | [Source](https://github.com/ensdomains/resolvers/blob/master/contracts/PublicResolver.sol) PublicResolver implements a general-purpose CORE ID resolver that is suitable for most standard CORE ID use-cases. The public resolver permits updates to CORE ID records by the owner of the corresponding name. The public resolver implements the following EIPs: * [EIP 137](https://eips.ethereum.org/EIPS/eip-137) - Contract address interface (`addr()`). * [EIP 165 ](https://eips.ethereum.org/EIPS/eip-165)- Interface Detection (`supportsInterface()`). * [EIP 181](https://eips.ethereum.org/EIPS/eip-181) - Reverse resolution (`name()`). * [EIP 205](https://eips.ethereum.org/EIPS/eip-205) - ABI support (`ABI()`). * [EIP 619](https://github.com/ethereum/EIPs/pull/619) - SECP256k1 public keys (`pubkey()`). * [EIP 634](https://eips.ethereum.org/EIPS/eip-634) - Text records (`text()`). * [EIP 1577](https://eips.ethereum.org/EIPS/eip-1577) - Content hash support (`contenthash()`). * [EIP 2304](https://eips.ethereum.org/EIPS/eip-2304) - Multicoin support (`addr()`). {% hint style="warning" %} While the `PublicResolver`provides a convenient default implementation, many resolver implementations and versions exist. Callers **must not** assume that a domain uses the current version of the public resolver, or that all of the methods described here are present. To check if a resolver supports a feature, see [Check Interface Support](broken://pages/PWBsuLsTHfKzzf24CtBe). {% endhint %} ### Check Interface Support ``` function supportsInterface(bytes4 interfaceID) external pure returns (bool) ``` CORE ID uses [ERC 165](https://eips.ethereum.org/EIPS/eip-165) for interface detection. ERC 165 requires that supporting contracts implement a function, `supportsInterface`, which takes an interface ID and returns a boolean value indicating if this interface is supported or not. Interface IDs are calculated as the exclusive-or of the four-byte function identifiers of each function included in the interface. For example, `addr(bytes32)` has the function ID *0x3b3b57de*. Because it is the only function in the Core Address interface, its interface ID is also *0x3b3b57de*, and so calling `supportsInterface(0x3b3b57de)` will return *true* for any resolver that supports `addr()`. ERC 165 has an interface ID of *0x01ffc9a7*, so `supportsInterface(0x01ffc9a7)` will always return true for any ERC 165 supporting contract (and hence for any resolver). Note that the public resolver does not expose explicit interfaces for setter functions, so there are no automated means to check for support for a given setter function. ### Get Core Address ``` function addr(bytes32 node) external view returns (address) ``` Returns the Core address associated with the provided `node`, or 0 if none. This function has interface ID *0x3b3b57de*. This function is specified in [EIP 137](https://eips.ethereum.org/EIPS/eip-137). ### Set Core Address ``` function setAddr(bytes32 node, address addr) external; ``` Sets the Core address associated with the provided `node` to `addr`. Only callable by the owner of `node`. Emits the following event: ``` event AddrChanged(bytes32 indexed node, address a); ``` ### Get Blockchain Address ``` function addr(bytes32 node, uint coinType) external view returns(bytes memory); ``` Returns the Blockchain address associated with the provided `node` and `coinType`, or 0 if none. This function has interface ID *0xf1cb7e06*. This function is specified in [EIP 2304](https://eips.ethereum.org/EIPS/eip-2304). The return value is the cryptocurrency address in its native binary format and each blockchain address has a different encoding and decoding method. For example, the Bitcoin address `1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa` base58check decodes to the 21 bytes `0062e907b15cbf27d5425399ebf6f0fb50ebb88f18` then scriptPubkey encodes to 25 bytes `76a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac` whereas the BNB address `bnb1grpf0955h0ykzq3ar5nmum7y6gdfl6lxfn46h2` Bech32 decodes to the binary representation `40c2979694bbc961023d1d27be6fc4d21a9febe6`. To convert the binary representation into the address, use `formatsByCoinType[SYMBOL].encoder(binary)` of [address-encoder](https://github.com/ensdomains/address-encoder). A zero-length string will be returned if the specified coin ID does not exist on the specified node. ### Set Blockchain Address ``` function setAddr(bytes32 node, uint coinType, bytes calldata a) external; ``` Sets the blockchain address associated with the provided `node` and `coinType` to `addr`. `coinType` is the cryptocurrency coin type index from [SLIP44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). To convert the address into the binary representation, use `formatsByName[SYMBOL].decoder(text)` of [address-encoder](https://github.com/ensdomains/address-encoder) Only callable by the owner of `node`. Emits the following event: ``` event AddressChanged(bytes32 indexed node, uint coinType, bytes newAddress); ``` ### Get Canonical Name ``` function name(bytes32 node) external view returns (string memory); ``` Returns the canonical CORE ID name associated with the provided `node`. Used exclusively for reverse resolution. This function has interface ID *0x691f3431*. This function is specified in [EIP 181](https://eips.ethereum.org/EIPS/eip-181). ### Set Canonical Name ``` function setName(bytes32 node, string calldata name) external; ``` Sets the canonical CORE ID name for the provided `node` to `name`. Only callable by the owner of `node`. Emits the following event: ``` event NameChanged(bytes32 indexed node, string name); ``` ### Get Content Hash ``` function contenthash(bytes32 node) external view returns (bytes memory); ``` Returns the content hash for `node`, if one exists. Values are formatted as machine-readable [multicodecs](https://github.com/multiformats/multicodec), as specified in [EIP 1577](https://eips.ethereum.org/EIPS/eip-1577). `contenthash` is used to store IPFS and Swarm content hashes, which permit resolving CORE ID addresses to distributed content (eg, websites) hosted on these distributed networks. This function has interface ID *0xbc1c58d1*. This function is specified in [EIP 1577](https://eips.ethereum.org/EIPS/eip-1157). ### Set Content Hash ``` function setContenthash(bytes32 node, bytes calldata hash) external; ``` Sets the content hash for the provided `node` to `hash`. Only callable by the owner of `node`. Values are formatted as machine-readable [multicodecs](https://github.com/multiformats/multicodec), as specified in [EIP 1577](https://eips.ethereum.org/EIPS/eip-1577). Emits the following event: ``` event ContenthashChanged(bytes32 indexed node, bytes hash); ``` ### Get Contract ABI ``` ABI(bytes32 node, uint256 contentTypes) external view returns (uint256, bytes memory); ``` Returns a matching ABI definition for the provided `node`, if one exists. `contentTypes` is the bitwise-OR of the encodings that the caller can accept. If multiple content types are specified, the resolver will select one to return. Currently supported content types are: | Content Type ID | Description | | --------------- | ------------------------ | | 1 | JSON | | 2 | zlib-compressed JSON | | 4 | [CBOR](https://cbor.io/) | | 8 | URI | `ABI` returns a two-tuple of the content type ID and the ABI data. If no data of the appropriate content type ID was found, 0 is returned for the content type ID, and the ABI data will be the empty string. This function has interface ID *0x2203ab56*. This function is specified in [EIP 205](https://eips.ethereum.org/EIPS/eip-205). ### Set Contract ABI ``` function setABI(bytes32 node, uint256 contentType, bytes calldata data) external ``` Sets or updates ABI data for `node`. `contentType` specifies the content type ID (see [Get Contract ABI](broken://pages/PWBsuLsTHfKzzf24CtBe) for valid values); exactly one type ID must be specified. `data` contains the encoded ABI data. To clear ABI data for a name, specify the empty string for `data`. Only callable by the owner of `node`. Emits the following event: ``` event ABIChanged(bytes32 indexed node, uint256 indexed contentType); ``` ### Get Public Key ``` function pubkey(bytes32 node) external view returns (bytes32 x, bytes32 y) ``` Returns the ECDSA SECP256k1 public key for `node`, as a 2-tuple `(x, y)`. If no public key is set, `(0, 0)` is returned. This function has interface ID *0xc8690233*. This function is specified in [EIP 619](https://github.com/ethereum/EIPs/issues/619). ### Set Public Key ``` function setPubkey(bytes32 node, bytes32 x, bytes32 y) external ``` Sets the ECDSA SECP256k1 public key for `node` to `(x, y)`. Only callable by the owner of `node`. Emits the following event: ``` event PubkeyChanged(bytes32 indexed node, bytes32 x, bytes32 y); ``` ### Get Text Data ``` function text(bytes32 node, string calldata key) external view returns (string memory) ``` Retrieves text metadata for `node`. Each name may have multiple pieces of metadata, identified by a unique string `key`. If no text data exists for `node` with the key `key`, the empty string is returned. Standard values for `key` are: | key | Meaning | | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | email | An email address | | url | A URL | | avatar | A URL to an image used as an avatar or logo | | description | A description of the name | | notice | A notice regarding this name | | keywords | A list of comma-separated keywords, ordered by most significant first; clients that interpresent this field may choose a threshold beyond which to ignore | In addition, anyone may specify vendor-specific keys, which must be prefixed with `vnd.`. The following vendor-specific keys are currently known: | key | Meaning | | ----------- | --------------- | | com.twitter | Twitter handle | | com.github | Github username | This function has interface ID 0x59d1d43c. This function is specified in [EIP 634](https://eips.ethereum.org/EIPS/eip-634). ### Set Text Data ``` function setText(bytes32 node, string calldata key, string calldata value) external ``` Sets text metadata for `node` with the unique key `key` to `value`, overwriting anything previously stored for `node` and `key`. To clear a text field, set it to the empty string. Only callable by the owner of `node`. Emits the following event: ``` event TextChanged(bytes32 indexed node, string indexedKey, string key); ``` ### Multicall ``` function multicall(bytes[] calldata data) external returns(bytes[] memory results) ``` Permits users to set multiple records in a single operation. Use `encodeABI` function to encode your contract calls and pass it to `data`. The frontend usage will be as follows: ``` var addrSet = resolver.contract.methods['setAddr(bytes32,address)'](node, accounts[1]).encodeABI(); var textSet = resolver.contract.methods.setText(node, "url", "https://ethereum.org/").encodeABI(); var tx = await resolver.multicall([addrSet, textSet], {from: accounts[0]}); ``` # Resolving Names On Chain CORE ID resolution is straightforward enough it can be done trivially without a library. First, we define some pared-down interfaces containing only the methods we need: ``` abstract contract COREID { function resolver(bytes32 node) public virtual view returns (Resolver); } abstract contract Resolver { function addr(bytes32 node) public virtual view returns (address); } ``` For resolution, only the `resolver` function in the CORE ID contract is required; other methods permit looking up owners and updating CORE ID from within a contract that owns a name. With these definitions, looking up a name given its node hash is straightforward: ``` contract MyContract { // Same address for Mainet, Ropsten, Rinkerby, Gorli and other networks; COREID coreid = COREID(0x00000000003dB7663112d1e121c6D2bb8220F671); function resolve(bytes32 node) public view returns(address) { Resolver resolver = coreid.resolver(node); return resolver.addr(node); } } ``` While it is possible for a contract to process a human-readable name into a node hash, we highly recommend working with node hashes instead, as they are easier and more efficient to work with, and allow contracts to leave the complex work of normalizing the name to their callers outside the blockchain. Where a contract always resolves the same names, those names may be converted to a node hash and stored in the contract as a constant.
# Reverse Registrar | description | | ---------------------------------------------------------------------------------------------------- | | The registrar responsible for managing reverse resolution via the .addr.reverse special-purpose TLD. | [Source](https://github.com/ensdomains/ens/blob/master/contracts/ReverseRegistrar.sol) Reverse resolution in Core ID - the process of mapping from an Ethereum address (eg, 0x1234...) to an Core ID name - is handled using a special namespace, *.addr.reverse*. A special-purpose registrar controls this namespace and allocates subdomains to any caller based on their address. For example, the account *0x314159265dd8dbb310642f98f50c066173c1259b* can claim *314159265dd8dbb310642f98f50c066173c1259b.addr.reverse.* After doing so, it can configure a resolver and expose metadata, such as a canonical Core ID name for this address. The reverse registrar provides functions to claim a reverse record, as well as a convenience function to configure the record as it's most commonly used, as a way of specifying a canonical name for an address. The reverse registrar is specified in [EIP 181](https://eips.ethereum.org/EIPS/eip-181). ### Claim Address ``` function claim(address owner) public returns (bytes32); ``` Claims the caller's address in the reverse registrar, assigning ownership of the reverse record to `owner`. Equivalent to calling `claimWithResolver(owner, 0)`. ### Claim Address with Resolver ``` function claimWithResolver(address owner, address resolver) public returns (bytes32) ``` Claims the caller's address in the reverse registrar, assigning ownership of the reverse record to `owner`. If `resolver` is nonzero, also updates the record's resolver. After calling this function: * The reverse record for the caller (*1234....addr.reverse*) is owned by `owner`. * If `resolver` is nonzero, the reverse record for the caller has its resolver set to `resolver`; otherwise it is left unchanged. ### Set Name ``` function setName(string memory name) public returns (bytes32) ``` Configures the caller's reverse Core ID record to point to the provided `name`. This convenience function streamlines the process of setting up a reverse record for the common case where a user only wants to configure a reverse name and nothing else. It performs the following steps: 1. Sets the reverse record for the caller to be owned by the ReverseRegistrar. 2. Sets the reverse record for the caller to have `defaultResolver` as its resolver. 3. Sets the `name()` field in the `defaultResolver` for the caller's reverse record to `name`. In short, after calling this, a user has a fully configured reverse record claiming the provided `name` as that account's canonical name. Users wanting more flexibility will need to use `claim` or `claimWithResolver` and configure records manually on their chosen resolver contract. ### Get Reverse Record Node ``` function node(address addr) public pure returns (bytes32) ``` Accepts an address, and returns the node (namehash output) for the address's reverse record. This function is provided as a convenience for contracts wishing to look up metadata for an address, and avoids the need for those contracts to handle the hex encoding and hashing necessary to derive the required value. ### Get Default Resolver ``` Resolver public defaultResolver; ``` Returns the address of the resolver contract that the `ReverseRegistrar` uses for `setName`. # Core.Limo Decentralized Gateway ### What is CORE.LIMO? A privacy preserving CORE ID gateway for resolving CORE ID .core domain records and associated IPFS/IPNS/Skynet content (Web 3.0). LIMO allows users and dApp developers to effortlessly access and host static sites built with a combination of IPFS/IPNS/Skynet and CORE ID. LIMO is intended to be operated as a reliable and secure public good for all users. ### Do you know the eth.limo gateway? On ethereum, if you have a ***vitalik.eth*** domain, then you can make and access the ipfs decentralized website via [vitalik.eth.limo](< https://vitalik.eth.limo/.>) Now that the .core domain gateway is also here, you can easily make a decentralized website without the need for a server. This is the home page of our IPFS version of the site: [**coreid.core.limo**](https://coreid.core.limo)\ coreid.core domain details: [app.coredao.id/name/coreid.core/Details](https://app.coredao.id/name/coreid.core/Details) ### ### Why do we need CORE.LIMO? Core internet infrastructure is becoming increasingly centralized and as such, several existential threats have emerged that undermine the principles of an decentralized, open and free internet: * Single points of failure (Cloudflare, CDNs, etc) * Lack of non-commercial infrastructure * Opacity of terms of service agreements and moderation policies * Proliferation of proprietary browser extensions which require centralized services (Unstoppable domains, etc…) * The erosion of the “commons” and “public space” * Web 3.0 adoption is still nascent * Most browsers cannot natively access DID/IPFS/IPNS/Skynet For end users, this means a limited selection of poor quality services that increasingly resemble a cable TV package. The LIMO project brings additional resiliency to dApps by providing an alternative means of access as a public good. Application owners can directly participate in the roadmap of LIMO, giving key stakeholders influence over the services they depend upon. As the decentralized web continues to grow, it is imperative that community projects facilitate the transition from Web 2.0 to Web 3.0. ### How does CORE.LIMO work? LIMO operates as a reverse proxy for .core domain and IPFS content. LIMO uses a wildcard DNS record \*.core.limo to dynamically capture requests for all .core domains. The LIMO service automatically resolves the IPFS/IPNS/Skynet contenthash of the requested CORE ID record and returns the corresponding static content over HTTPS. Since native IPFS/IPNS/Skeynet resolution capabilities are missing from the majority of browsers, CORE.LIMO represents a bridge from the “normal” internet to the decentralized one. # Create a decentralized website This tutorial is for developer If you have no development experience, please check: [Quickly create decentralized website](https://docs.coredao.id/decentralized-website/quickly-create-decentralized-website) ### ### Creating a decentralized website is simple and requires two steps in total. ### 1. upload your html web folder to IPFS You can upload html by installing the [IPFS desktop application](https://github.com/ipfs/ipfs-desktop/releases), or by third-party websites such as [Pinata.cloud](https://www.pinata.cloud/) (Recommend) Here is a demo site code, you can download it: {% embed url="" %} {% tabs %} {% tab title=" Pinata.cloud" %} Go to [**Pinata.cloud**](https://www.pinata.cloud/) and register an account Unzip the file and modify the code. Upload your ***html*** **F*****older***, make sure it includes index.html
{% endtab %} {% tab title=" IPFS desktop application" %}

Upload your html folder

#### #### Make sure you have index.html in your folder
{% endtab %} {% endtabs %} ### 2. save the above IPFS hash (CID) in the domain name. Copy the CID of this folder {% tabs %} {% tab title=" Pinata.cloud" %}
{% endtab %} {% tab title=" IPFS desktop application" %}
{% endtab %} {% endtabs %} #### Save (ipfs\:// + CID) to the IPFS content in the domain. #### example: ipfs\://QmaRtXePh833Ds3bMNW6qgrnH4AmYc3mEKv3SQPNynXtSE
Demo domain: [app.coredao.id/name/coreid.core/Details](https://app.coredao.id/name/coreid.core/Details) #### Congratulations, your IPFS decentralized site has been created and you can access it by name + core.limo #### example: [***coreid.core.limo***](https://coreid.core.limo) ***----------------------------------------------------------------*** ### ***FAQ*** #### Why does my page not display? Make sure your folder containing index.html is uploaded to IPFS, sometimes you need to wait a few minutes for the upload to complete. And copy the CID of the folder, not the index.html cid. We recommend using [Pinata.cloud](https://Pinata.cloud) for uploads, which does not require you to install the IPFS desktop application. You can also use this gateway to check if your html upload is complete, replace your IPFS CID and open it in your browser. #### How do I update my website? You need to modify the html file locally and re-upload a new folder. Then copy the new folder CID and save it to the domain. After saving, it usually takes more than 10 minutes + to update because of caching. #### Experiencing other problems? Join Telegram: English: Chinese: # Quickly create decentralized website This tutorial is for everyone and no coding experience is required. ![](https://3744657518-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkouT6qypYCxvKrJ2G7F0%2Fuploads%2FDhSkLVtgG9EudKS1ZEYZ%2F0.png?alt=media) Use 4EVERLAND to quickly host your website on IPFS and access via .core domain ### Quickly deploy your website on IPFS **-Login** [**4EVERLAND**](https://www.4everland.org/) **with your Web3 identity.** **– Select hosting and create a project**
You can directly import your github repo or you can choose to build from an IPFS cid and 4EVERLAND template. You don't want to authorize your Github, you can still deploy via [4EVERLAND Hosting Cli](https://docs.4everland.org/hositng/hosting-cli). **– Configuration (Deploy from github repo)**
4EVERLAND supports IPFS, Arweave and Dfinity as the website hosting network. Pls select IPFS as the hosting layer. And in this page you can do some configuration according to your needs.\ We highly recommend you to turn on the switch “deploy hook” so that your website on IPFS will be updated automatically according to your github updates, it will greatly reduce your operation and maintenance energy.If you own a .core domain, do you know you own a website domain as well? Earlier, the CORE ID team released their decentralized gateway [core.limo](http://core.limo/) to assist .core holders in achieving Web2 accessibility for their bound IPFS content.\ Therefore, if you deploy your website on IPFS, your core.limo can serve as your website domain! This tutorial will show you in detail how to deploy your website on IPFS and configure your .core domain as the website domain.\ (And because 4EVERLAND offers free IPFS storage and bandwidth for each user, the deployment will be 100% free!) **– Configuration (Deploy from 4EVERLAND template)**
If you don’t have a code background or don't have a website repo in github. 4EVERLAND template must be the best choice for you to own a dedicated website. Still choose IPFS as the hosting layer and you can insert any links you want to show in your website. ### Binding your .core domain **– Enter your domain name and copy the CID**
(Path: details, settings-domain) \ (Path: Hosting--domain)
After the deployment, pls check your project details, settings-domain or directly find the domain settings and select the deployed project. Then you can bind your .core domain. Enter your .core name and copy your IPFS CID (IPNS not supported yet), then click [app.coredao.id/](https://app.coredao.id/) and login to the platform via your address including your .core domain! **– Paste your CID** ![](https://3744657518-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkouT6qypYCxvKrJ2G7F0%2Fuploads%2FoJEgKogRnpjxsgMALiuy%2F7.png?alt=media) Paste the ipfs\:// + CID (the IPFS hash you just copied in 4EVERLAND) in your .core domain dashboard-IPFS Content and signature via your metamask. (The CID will be synchronized on chain, so you need to spend some gas to finish the deployment) Once you complete the banding process, your **dedicated website domain is \.limo** **Congrats, you finished all the deployment processes and now own a .core domain website, hosted on IPFS and accessible via \.limo!** ### ### About 4EVERLAND 4EVERLAND is a Web 3.0 cloud computing platform that integrates storage, computing, and network core capabilities. It aims to help the user to make a smooth leap from Web 2.0 to Web 3.0 and become the infrastructure for millions of Web 3.0 developers and applications. Join 4EVERLAND community: [**Website**](https://www.4everland.org/) **|**[ **Twitter**](https://twitter.com/4everland_org) **|**[ **Telegram**](https://t.me/org_4everland) **|**[ **Discord**](https://discord.com/invite/Cun2VpsdjF) **|**[ **Reddit**](https://www.reddit.com/r/4everland/) **|**[ **Medium**](https://4everland.medium.com/)**|** [**Email**](mailto:contact@4everland.org) ### About CORE ID CORE ID offers a decentralized domain service on the CORE Chain, providing an open and extensible naming system with .core domains. Users can benefit from 'reverse resolution' for metadata, paving the way for the future of domain management. [**Website**](https://coredao.id/) **|**[ **Twitter**](https://twitter.com/CoreDaoID) **|**[ **Telegram**](https://t.me/CoreIDOfficial) **|**[ **Discord**](https://discord.gg/XuaQNGHzqk) **|**[**Docs**](https://docs.coredao.id/) # Create decentralized blog This tutorial is for everyone and no coding experience is required. Planet is a free and open source tool for publishing and following web content. It doesn't rely on a central server or service, and instead uses IPFS for peer-to-peer content distribution. Download Planet (Mac): Planet doesn't have a windows client at the moment. Step 1: Publish your blog using Planet
Right-click on your blog and select "Show IPFS and CID"
Step 3: Copy the CID
Step 4: Save the CID to your domain
Congratulations, your decentralized blog has been released. demo blog: [https://vitalik2.core.limo/](https://vitalik2.core.limo/) # Set Up a Wallet On CORE Mainnet, we currently support **Metamask** Wallet and **WalletConnect**. ### Metamask Wallet #### What is a Metamask Wallet? **MetaMask** is a digital wallet that is specific to Core. There are other wallets available, and CORE ID supports bunch of them as well, but MetaMask is still the most popular one. It’s connected to your web browser as an extension where you can hold and spend Core. You’ll need to connect your wallet to Foundation in order to participate in the marketplace. #### **How do I set up a Metamask wallet?** * Download and install the [MetaMask browser extension](https://metamask.io/download.html) through their website. * Select “Create a Wallet.” * Create a username and password. * Pay close attention to your uniquely assigned Secret Recovery Phrase, and store it somewhere safe. If you lose this series of words or forget what order they’re in, you *will* lose access to your wallet and it will be unrecoverable. We recommend writing the phrase on a piece of paper and storing it in a memorable, safe, and secure spot. * Confirm the phrase by placing all of the words in the correct order as they were assigned. * Now, MetaMask is set up and should appear in your browser extensions. * If you have any trouble, visit [MetaMask Support](https://metamask.zendesk.com/hc/en-us). # Register for a .core Domain #### 1. Go to [app.coredao.id](https://app.coredao.id) Click “Connect” on the top right corner to connect your wallet to [CORE Mainnet](https://docs.coredao.id/core-rpc).
#### 2. Search for a name, for example, to register abc.core, you can search for abc
#### 3. Click the Register button and confirm the transaction.
#### 4. Congratulations, your domain name has been successfully registered! # Set your domain name Find your domain, and under the Details tab, you can edit your various wallet addresses, IPFS hash contents, and custom data. When you fill in the data, anyone can view them through your domain. 1. The domains you have registered will be displayed at [app.coredao.id](https://app.coredao.id/), click on a domain to enter the details page. ![](https://3744657518-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkouT6qypYCxvKrJ2G7F0%2Fuploads%2FRtWv1GjMjmBjq7x6SFpx%2Fimage.png?alt=media\&token=09ecaee1-0de4-4735-8d24-5b672e796eb1) 2. In the domain details page, you can view and modify some information. ![](https://3744657518-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkouT6qypYCxvKrJ2G7F0%2Fuploads%2FOBd5DY1tMyTDbQ4Ektjm%2Fimage.png?alt=media\&token=87255faf-2995-4d0d-8011-b06c868f2434) For example, the address in Address -> CORE, if someone transfers money to this domain, it will eventually be transferred to this address. You can also modify description, email, twitter, etc. Anyone can see them, but only you can modify them. Do not modify Resolver unless you are a professional developer # Set primary name 1. Go to [app.coredao.id](https://app.coredao.id) and connect to the wallet, click “Primary Name” ![](https://3744657518-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkouT6qypYCxvKrJ2G7F0%2Fuploads%2FxMAOXVwMEwCTTDnVM6le%2Fimage.png?alt=media\&token=ac935c28-d124-4dfb-87f1-98588ad2097c) 2. Choose one of your names and save it. ![](https://3744657518-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkouT6qypYCxvKrJ2G7F0%2Fuploads%2FIJJzlDzqCKh6IZ6YZtQ5%2Fimage.png?alt=media\&token=f0b2f4d8-2dd3-4f23-9e71-6ef9b7c678b3) Now that it's set up, go to [www.lfgswap.finance](https://www.lfgswap.finance/) and have a look.
# Set Subdomains **CORE ID supports unlimited levels of subdomains** If you have a hello.core, you can create subdomains for free as follows: *One.hello.*core *home.hello.*core *green.home.hello.*core *go.green.home.hello.*core ...... For each subdomain, you can bind different data # CID Token $CID Contract: **0x000000000E1D682Cc39ABe9B32285fdEa1255374** Buy CID on LFG Swap: Buy CID on Archerswap: AVE Chart: CMC: Scan / Holder: