Type alias MetadataRegistry

Type declaration

• Optional $schema?: string

  The schema used by this registry. Many JSON editors can automatically provide inline documentation and autocomplete support using the $schema property, so it is recommended that registries include it. E.g.: https://cashtokens.org/bcmr-v2.schema.json

• Optional chains?: {
      [splitId: string]: ChainHistory;
  }

  A map of split IDs tracked by this registry to the ChainHistory for that chain/network.

  The split ID of a chain is the block header hash (A.K.A. block ID) of the first unique block after the most recent tracked split – a split after which both resulting chains are considered notable or tracked by the registry. (For chains with no such splits, this is the ID of the genesis block.)

  Note, split ID is inherently a "relative" identifier. After a tracked split, both resulting chains will have a new split ID. However, if a wallet has not yet heard about a particular split, that wallet will continue to reference one of the resulting chains by its previous split ID, and the split-unaware wallet may create transactions that are valid on both chains (losing claimable value if the receivers of their transactions don't acknowledge transfers on both chains). When a registry trusted by the wallet notes the split in it's chains map, the wallet can represent the split in the user interface using the the latest ChainSnapshot for each chain and splitting coins prior to spending (by introducing post-split coins in each transaction).

  This map may exclude the following well-known split IDs (all clients supporting any of these chains should build-in ChainHistory for those chains):

  • 0000000000000000029e471c41818d24b8b74c911071c4ef0b4a0509f9b5a8ce: A.K.A. mainnet – the BCH side of the BCH/XEC split.
  • 00000000ae25e85d9e22cd6c8d72c2f5d4b0222289d801b7f633aeae3f8c6367: A.K.A testnet4 – the test network on which CHIPs are activated simultaneously with mainnet (May 15 at 12 UTC).
  • 00000000040ba9641ba98a37b2e5ceead38e4e2930ac8f145c8094f94c708727: A.K.A. chipnet – the test network on which CHIPs are activated 6 months before mainnet (November 15 at 12 UTC).

  All other split IDs referenced by this registry should be included in this map.

  • [splitId: string]: ChainHistory

• Optional defaultChain?: string

  The split ID of the chain/network considered the "default" chain for this registry. Identities that do not specify a IdentitySnapshot.splitId are assumed to be set to this split ID. For a description of split IDs, see MetadataRegistry.chains.

  If not provided, the defaultChain is 0000000000000000029e471c41818d24b8b74c911071c4ef0b4a0509f9b5a8ce, the BCH side of the BCH/XEC split (mainnet). Common values include:

  • 00000000ae25e85d9e22cd6c8d72c2f5d4b0222289d801b7f633aeae3f8c6367 (testnet4)
  • 00000000040ba9641ba98a37b2e5ceead38e4e2930ac8f145c8094f94c708727 (chipnet)

• Optional extensions?: Extensions

  A mapping of Registry extension identifiers to extension definitions. Extensions may be widely standardized or application-specific.

  Standardized extensions for Registrys include the locale extension. See https://github.com/bitjson/chip-bcmr#locales-extension for details.

• Optional identities?: {
      [authbase: string]: IdentityHistory;
  }

  A mapping of authbases to the IdentityHistory for that identity.

  An authbase is a 32-byte, hex-encoded transaction hash (A.K.A. TXID) for which the zeroth-descendant transaction chain (ZDTC) authenticates and publishes an identity's claimed metadata.

  Identities may represent metadata registries, specific types of tokens, companies, organizations, individuals, or other on-chain entities.

  • [authbase: string]: IdentityHistory

• latestRevision: string

  The timestamp of the latest revision made to this registry version. The timestamp must be provided in simplified extended ISO 8601 format, a 24-character string of format YYYY-MM-DDTHH:mm:ss.sssZ where timezone is zero UTC (denoted by Z). Note, this is the format returned by ECMAScript Date.toISOString().

• Optional license?: string

  The license under which this registry is published. This may be specified as either a SPDX short identifier (https://spdx.org/licenses/) or by including the full text of the license.

  Common values include:

  • CC0-1.0: https://creativecommons.org/publicdomain/zero/1.0/
  • MIT: https://opensource.org/licenses/MIT

• registryIdentity: OffChainRegistryIdentity | string

  The identity information of this particular registry, provided as either an authbase (recommended) or an IdentitySnapshot.

  An authbase is a 32-byte, hex-encoded transaction hash (A.K.A. TXID) for which the zeroth-descendant transaction chain (ZDTC) authenticates and publishes all registry updates. If an authbase is provided, the registry's identity information can be found in identities[authbase], and clients should immediately attempt to verify the registry's identity on-chain. (See https://github.com/bitjson/chip-bcmr#chain-resolved-registries)

  If an IdentitySnapshot is provided directly, this registry does not support on-chain resolution/authentication, and the contained IdentitySnapshot can only be authenticated via DNS/HTTPS.

• Optional tags?: {
      [identifier: string]: Tag;
  }

  A map of registry-specific Tags used by this registry to convey information about identities it tracks.

  Tags allow registries to group identities into collections of related identities, marking characteristics or those identities. Tags are standardized within a registry and may represent either labels applied by that registry (e.g. individual, organization, token, wallet, exchange, staking, utility-token, security-token, stablecoin, wrapped, collectable, deflationary, governance, decentralized-exchange, liquidity-provider, sidechain, sidechain-bridge, etc.) or designations by external authorities (certification, membership, ownership, etc.) that are tracked by that registry.

  Tags may be used by clients in search, discover, and filtering of identities, and they can also convey information like accreditation from investor protection organizations, public certifications by security or financial auditors, and other designations that signal legitimacy and value to users.

  • [identifier: string]: Tag

• version: {
      major: number;
      minor: number;
      patch: number;
  }

  The version of this registry. Versioning adheres to Semantic Versioning (https://semver.org/).

  • major: number

    The major version is incremented when an identity is removed.

  • minor: number

    The minor version is incremented when an identity is added or a new identity snapshot is added.

  • patch: number

    The patch version is incremented when an existing identity or identity snapshot is modified (e.g. to correct an error or add a missing piece of information) or when other registry properties (e.g. registry name, description, uris, etc.) are modified.

    Generally, substantive changes to an existing identity should be made using a new identity snapshot in a minor version upgrade – this allows clients to provide a better user experience by noting the change in relevant user interfaces.

    For example, patch upgrades might include spelling corrections in an existing snapshot or the addition of an icon containing a higher-resolution version of an existing icon image. On the other hand, a rebranding in which the icon is substantially changed may warrant a new identity snapshot to be added in a minor version upgrade.