initia-labs / initia-registry

Initia Registry The Initia Registry serves as a central repository containing crucial metadata for chains within the Initia ecosystem. It houses configuration files such as and , which are vital for initiating and interacting with nodes, as well as understanding the available assets on each chain. The registry also includes files, which provide users with a comprehensive overview of each chain, including its category, description, and status. Additionally, the registry includes files in the root directory, outlining the recommended metadata structure. These schemas are dynamic, subject to revisions based on evolving user needs, and may include optional fields beyond the current schema specifications. Adding a Rollup to Initia Registry • **Fork the Repository**: Begin by forking the repository where the Initia Registry is hosted. • **Add a New Directory**: Create a directory named after the chain you intend to add. • **Include Necessary Files**: • : Populate this file with the metadata of the chain. • : Include metadata concerning the assets available on the chain. • : Provide metadata about the IBC connections and channels, ensuring the file name adheres to the alphabetical order of the chain names, e.g., Achain-Bchain.json. • **Create a Pull Request**: Submit your modifications for review to merge them into the main repository. contains metadata about the chain, such as the chain name, chain ID, EVM chain ID, and network type. This information is essential for users to interact with the chain and its associated assets. JSON Structure | **Field** | **Type** | **Required?** | **Description** | | ----------------------- | ------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | | Yes | Path or URL to the corresponding JSON schema (e.g., ). | | | | Yes | Unique, lowercase name of the chain, often used for folder names and identification in registries. | | | | Yes | A human-readable name for display purposes. | | | | Yes | The chain’s official ID (e.g. ). | | | | Optional | The EVM-compatible Chain ID. Present only for EVM-based chains (e.g., ). | | | | Yes | The Bech32 address prefix (used in Cosmos-based addresses). | | | | Yes | Describes the network environment (e.g., , , or ). | | | | Optional | Link to the chain’s official website or documentation. | | | | Yes | Contains endpoints for interacting with the chain. Typically includes subfields like , , , , each an array of endpoint objects with an property. | | | | Optional | Supported cryptographic key algorithms (e.g., ). | | | | Optional | The SLIP-0044 coin type is used for generating HD wallet paths (commonly for Cosmos chains). | | | | Optional | Contains , detailing denominations and gas price information for transaction fees. | | | | Optional | An array of fee token objects, each with , , , , . | | | | Optional | An array of image objects for chain logos or branding. Often includes URLs. | | | | Optional | Direct link to a PNG version of the chain’s image/logo. | | | | Optional | Alternative or simplified object to store image URIs ( ) for the chain’s logo. | | | | Optional | Additional chain metadata. May contain fields like , , , , , etc. | | | | Yes (L2) | The OP bridge identifier, if the chain is connected via OP bridging. | | | | Yes (L2) | One or more denoms used in OP bridging. | | | | Yes (L2) | Executor service endpoint for advanced chain operations. | | | | Yes (L2) | An array describing IBC channel details (e.g., , , , and the counterpart ). | | | | Optional (L2) | URL pointing to the file for this chain. | | | | Optional (L2) | Information specific to the chain’s rollup type, with fields like (e.g. , ) and . | > **Note**: is only relevant for EVM-compatible chains and not part of the standard Cosmos chain schema. A sample includes the following information. is inspired by the Token Lists project on Ethereum which helps discoverability of ERC-20 tokens by providing a mapping between ERC-20 contract addresses and their associated metadata. is a similar mechanism to allow frontends and other UIs to fetch metadata associated with Cosmos SDK denoms, especially for assets sent over IBC. This standard is a work in progress. You'll notice that the format of assets in the structure is a strict superset json representation of the banktypes.DenomMetadata from the Cosmos SDK. This is purposefully done so that this standard may eventually be migrated into a Cosmos SDK module in the future, so it can be easily maintained on the chain instead of on GitHub. For better understanding, the denoms in the assetlist.json file can be categorized into the following types: • Cosmos denom • A native denomination supported by Cosmos SDK applications, generally prefixed with to indicate a decimal scale of 6. • Example: • Coin metadata • In a Move contract, this refers to the object address generated from the coin’s creator and symbol, represented in hexadecimal format. • Example: • Move denom (only exist on Move chains) • If the coin is not generated by the 0x1 module (e.g., ibc, l2 prefixed) but instead created by a regular user, it will have the prefix. • Since the module of Initia L1 is integrated with Move fungible assets, it is possible to use the prefixed denom as-is. • Example: • EVM denom (only exist on EVM chains) • If the coin is created by EVM contract, it will has a denom like format on EVM chain. • Example: • Op denom • A denomination transferred from Initia to L2 via the module, prefixed with . • Example: • IBC denom • A denomination transferred via the module, prefixed with . • Example: How to Derive a Bridged Token Denom For tokens bridged from L1, the denom can vary depending on the type of bridge used. In order for token bridging to work correctly, you must add the appropriate denom to your assetlist. We have two scenarios for calcu…