You've already forked chip-bcmr
v2
This commit is contained in:
Jason Dreyzehner
@@ -2,37 +2,33 @@
|
|||||||
"$ref": "#/definitions/Registry",
|
"$ref": "#/definitions/Registry",
|
||||||
"$schema": "http://json-schema.org/draft-07/schema#",
|
"$schema": "http://json-schema.org/draft-07/schema#",
|
||||||
"definitions": {
|
"definitions": {
|
||||||
"Extensions": {
|
"ChainHistory": {
|
||||||
"additionalProperties": {},
|
"$ref": "#/definitions/RegistryTimestampKeyedValues<ChainSnapshot>",
|
||||||
"description": "A mapping of extension identifiers to extension definitions. Extensions may be widely standardized or registry-specific, and extension definitions may be values of any type.",
|
"description": "A block height-keyed map of {@link ChainSnapshot } s documenting the evolution of a particular chain/network's identity. Like {@link IdentityHistory } , this structure allows wallets and other user interfaces to offer better experiences when a chain identity is rebranded, redenominated, or other important metadata is modified in a coordinated update."
|
||||||
"type": "object"
|
|
||||||
},
|
},
|
||||||
"IdentityHistory": {
|
"ChainSnapshot": {
|
||||||
"description": "An array of `IdentitySnapshot`s, ordered from newest to oldest documenting the evolution of a particular identity. Typically, the current identity information is the record at index `0`, but in cases where a planned migration has not yet begun (the snapshot's `time.begin` has not been reached), the record at index `1` is considered the current identity.\n\nThis strategy allows wallets and other user interfaces to offer better experiences when an identity is rebranded, a token redenominated, or other important metadata is modified in a coordinated update. For example, a wallet may warn token holders of a forthcoming rebranding of fungible tokens they hold; after the change, the wallet may continue to offer prominent interface hints that the rebranded tokens was recently updated.\n\nNote, only the `IdentitySnapshot`s at index `0` and `1` can be considered part of an identities \"current\" information (based on their `time` settings in relation to current time). E.g. even if two snapshots have active, overlapping migration periods (i.e. the snapshot at `2` is still relevant for the snapshot at `1`), clients should only attempt to display the migration from the snapshot at index `1` to that at index `0`.",
|
|
||||||
"items": {
|
|
||||||
"$ref": "#/definitions/IdentitySnapshot"
|
|
||||||
},
|
|
||||||
"type": "array"
|
|
||||||
},
|
|
||||||
"IdentitySnapshot": {
|
|
||||||
"additionalProperties": false,
|
"additionalProperties": false,
|
||||||
"description": "A snapshot of the metadata for a particular identity at a specific time.",
|
"description": "A snapshot of the metadata for a particular chain/network at a specific time. This allows for registries to provide similar metadata for each chain's native currency unit (name, description, symbol, icon, etc.) as can be provided for other registered tokens.",
|
||||||
"properties": {
|
"properties": {
|
||||||
"description": {
|
"description": {
|
||||||
"description": "A string describing this identity for use in user interfaces. Descriptions longer than `160` characters may be elided in some interfaces.\n\nE.g. `The common stock issued by ACME, Inc.`, `A metadata registry maintained by Company Name, the embedded registry for Wallet Name.`; `Software developer and lead maintainer of Wallet Name.`; etc.",
|
"description": "A string describing this identity for use in user interfaces.\n\nIn user interfaces with limited space, descriptions should be hidden beyond the first newline character or `140` characters until revealed by the user.\n\nE.g.:\n- `The common stock issued by ACME, Inc.`\n- `A metadata registry maintained by Company Name, the embedded registry for Wallet Name.`\n- `Software developer and lead maintainer of Wallet Name.`",
|
||||||
"type": "string"
|
"type": "string"
|
||||||
},
|
},
|
||||||
"extensions": {
|
"extensions": {
|
||||||
"$ref": "#/definitions/Extensions",
|
"$ref": "#/definitions/Extensions",
|
||||||
"description": "A mapping of `IdentitySnapshot` extension identifiers to extension definitions. Extensions may be widely standardized or registry-specific, and extension definitions may be values of any type.\n\nStandardized extensions for `IdentitySnapshot`s include the `authchain` extension. See https://github.com/bitjson/chip-bcmr#authchain-extension for details."
|
"description": "A mapping of `IdentitySnapshot` extension identifiers to extension definitions. {@link Extensions } may be widely standardized or application-specific.\n\nStandardized extensions for `IdentitySnapshot`s include the `authchain` extension. See https://github.com/bitjson/chip-bcmr#authchain-extension for details."
|
||||||
},
|
},
|
||||||
"name": {
|
"name": {
|
||||||
"description": "The name of this identity for use in interfaces. Names longer than `20` characters may be elided in some interfaces.\n\nE.g. `ACME Class A Shares`, `ACME Registry`, `Satoshi Nakamoto`, etc.",
|
"description": "The name of this identity for use in interfaces.\n\nIn user interfaces with limited space, names should be hidden beyond the first newline character or `20` characters until revealed by the user.\n\nE.g. `ACME Class A Shares`, `ACME Registry`, `Satoshi Nakamoto`, etc.",
|
||||||
|
"type": "string"
|
||||||
|
},
|
||||||
|
"splitId": {
|
||||||
|
"description": "The split ID of this identity's chain of record.\n\nIf undefined, defaults to {@link Registry.defaultChain } .",
|
||||||
"type": "string"
|
"type": "string"
|
||||||
},
|
},
|
||||||
"status": {
|
"status": {
|
||||||
"description": "The status of this identity, must be `active`, `inactive`, or `burned`. If omitted, defaults to `active`.\n- Identities with an `active` status should be actively tracked by clients.\n- Identities with an `inactive` status may be considered for archival by clients and may be removed in future registry versions.\n- Identities with a `burned` status have been destroyed by setting the latest identity output to a data-carrier output (`OP_RETURN`), permanently terminating the authchain. Clients should archive burned identities and – if the burned identity represented a token type – consider burning any remaining tokens of that category to reclaim funds from those outputs.",
|
"description": "The status of this identity, must be `active`, `inactive`, or `burned`. If omitted, defaults to `active`.\n- Identities with an `active` status should be actively tracked by clients.\n- Identities with an `inactive` status may be considered for archival by clients and may be removed in future registry versions.\n- Identities with a `burned` status have been destroyed by setting the latest identity output to a data-carrier output (`OP_RETURN`), permanently terminating the authchain. Clients should archive burned identities and – if the burned identity represented a token type – consider burning any remaining tokens of that category to reclaim funds from those outputs.",
|
||||||
"enum": ["active", "inactive", "burned"],
|
"enum": ["active", "burned", "inactive"],
|
||||||
"type": "string"
|
"type": "string"
|
||||||
},
|
},
|
||||||
"tags": {
|
"tags": {
|
||||||
@@ -42,28 +38,102 @@
|
|||||||
},
|
},
|
||||||
"type": "array"
|
"type": "array"
|
||||||
},
|
},
|
||||||
"time": {
|
"token": {
|
||||||
"additionalProperties": false,
|
"additionalProperties": false,
|
||||||
"description": "The timing information for the introduction of this identity snapshot. Each timestamps may be provided as either an ISO string (simplified extended ISO 8601 format) or as a locktime value: an integer from `0` to `4294967295` (inclusive) where values less than `500000000` are understood to be a block height (the current block number in the chain, beginning from block `0`), and values greater than or equal to `500000000` are understood to be a Median Time Past (BIP113) UNIX timestamp.\n\nGenerally, timestamps should be provided as an ISO string unless on-chain artifacts require the locktime value (e.g. an on-chain migration that is set to complete at a particular locktime value).",
|
"description": "A data structure indicating how the chain's native currency units should be displayed in user interfaces.",
|
||||||
"properties": {
|
"properties": {
|
||||||
"begin": {
|
"decimals": {
|
||||||
"description": "The timestamp at which this identity snapshot begins to be active. If `complete` isn't specified, this is a precise time at which this snapshot takes effect and clients should begin using the new information.",
|
"description": "An integer between `0` and `18` (inclusive) indicating the divisibility of the primary unit of this native currency.\n\nThis is the number of digits that can appear after the decimal separator in currency amounts. For a currency with a `symbol` of `SYMBOL` and a `decimals` of `2`, an amount of `12345` should be displayed as `123.45 SYMBOL`.\n\nIf omitted, defaults to `0`.",
|
||||||
"type": ["string", "number"]
|
"type": "number"
|
||||||
},
|
},
|
||||||
"complete": {
|
"symbol": {
|
||||||
"description": "The timestamp at which this identity snapshot is fully in effect. This value should only be provided if the snapshot takes effect over a period of time (e.g. an in-circulation token identity is gradually migrating to a new category). In these cases, clients should gradually migrate to using the new information beginning after the `begin` time and completing at the `complete` time.",
|
"description": "An abbreviation used to uniquely identity this native currency unit.\n\nSymbols must be comprised only of capital letters, numbers, and dashes (`-`). This can be validated with the regular expression: `/^[-A-Z0-9]+$/`.",
|
||||||
"type": ["string", "number"]
|
"type": "string"
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
"required": ["begin"],
|
"required": ["symbol"],
|
||||||
"type": "object"
|
"type": "object"
|
||||||
},
|
},
|
||||||
|
"uris": {
|
||||||
|
"$ref": "#/definitions/URIs",
|
||||||
|
"description": "A mapping of identifiers to URIs associated with this identity. URI identifiers may be widely-standardized or registry-specific. Values must be valid URIs, including a protocol prefix (e.g. `https://` or `ipfs://`). Clients are only required to support `https` and `ipfs` URIs, but any scheme may be specified.\n\nThe following identifiers are recommended for all identities:\n- `icon`\n- `web`\n\nThe following optional identifiers are standardized:\n- `blog`\n- `chat`\n- `forum`\n- `icon-intro`\n- `registry`\n- `support`\n\nFor details on these standard identifiers, see: https://github.com/bitjson/chip-bcmr#uri-identifiers\n\nCustom URI identifiers allow for sharing social networking profiles, p2p connection information, and other application-specific URIs. Identifiers must be lowercase, alphanumeric strings, with no whitespace or special characters other than dashes (as a regular expression: `/^[-a-z0-9]+$/`).\n\nFor example, some common identifiers include: `discord`, `docker`, `facebook`, `git`, `github`, `gitter`, `instagram`, `linkedin`, `matrix`, `npm`, `reddit`, `slack`, `substack`, `telegram`, `twitter`, `wechat`, `youtube`."
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"required": ["name", "token"],
|
||||||
|
"type": "object"
|
||||||
|
},
|
||||||
|
"Extensions": {
|
||||||
|
"additionalProperties": {
|
||||||
|
"anyOf": [
|
||||||
|
{
|
||||||
|
"type": "string"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"additionalProperties": {
|
||||||
|
"type": "string"
|
||||||
|
},
|
||||||
|
"type": "object"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"additionalProperties": {
|
||||||
|
"additionalProperties": {
|
||||||
|
"type": "string"
|
||||||
|
},
|
||||||
|
"type": "object"
|
||||||
|
},
|
||||||
|
"type": "object"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
"description": "A mapping of extension identifiers to extension definitions. Extensions may be widely standardized or application-specific, and extension definitions must be either:\n\n- `string`s,\n- key-value mappings of `string`s, or\n- two-dimensional, key-value mappings of `string`s.\n\nThis limitation encourages safety and wider compatibility across implementations.\n\nTo encode an array, it is recommended that each value be assigned to a numeric key indicating the item's index (beginning at `0`). Numerically-indexed objects are often a more useful and resilient data-transfer format than simple arrays because they simplify difference-only transmission: only modified indexes need to be transferred, and shifts in item order must be explicit, simplifying merges of conflicting updates.\n\nFor encoding of more complex data, consider using base64 and/or string-encoded JSON.",
|
||||||
|
"type": "object"
|
||||||
|
},
|
||||||
|
"IdentityHistory": {
|
||||||
|
"$ref": "#/definitions/RegistryTimestampKeyedValues<IdentitySnapshot>",
|
||||||
|
"description": "A timestamp-keyed map of {@link IdentitySnapshot } s documenting the evolution of a particular identity. Typically, the current identity information is the latest record when lexicographically sorted, but in cases where a planned migration has not yet begun (the snapshot's timestamp has not yet been reached), the immediately preceding record is considered the current identity.\n\nThis strategy allows wallets and other user interfaces to offer better experiences when an identity is rebranded, a token redenominated, or other important metadata is modified in a coordinated update. For example, a wallet may warn token holders of a forthcoming rebranding of fungible tokens they hold; after the change, the wallet may continue to offer prominent interface hints that the rebranded token identity was recently updated.\n\nNote, only the latest two {@link IdentitySnapshot } s should be considered part of an identity's \"current\" information. E.g. even if two snapshots have active, overlapping migration periods (i.e. an older snapshot's\n {@link IdentitySnapshot.migrated } timestamp has not yet been reached), clients should only attempt to display the migration from the previous to the latest snapshot.\n\nIf the current snapshot's {@link IdentitySnapshot.migrated } isn't specified, the snapshot's index is a precise time at which the snapshot takes effect and clients should begin using the new information. If `migrated` is specified, the snapshot's index is the timestamp at which the transition is considered to begin, see {@link IdentitySnapshot.migrated } for details.\n\nEach 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()`.\n\nIn the case that an identity change occurs due to on-chain activity (e.g. an on-chain migration that is set to complete at a particular locktime value), registry-recorded timestamps reflect the real-world time at which the maintainer of the registry believes the on-chain activity to have actually occurred. Likewise, future-dated timestamps indicate a precise real-world time at which a snapshot is estimated to take effect, rather than the Median Time Past (BIP113) UNIX timestamp or another on-chain measurement of time."
|
||||||
|
},
|
||||||
|
"IdentitySnapshot": {
|
||||||
|
"additionalProperties": false,
|
||||||
|
"description": "A snapshot of the metadata for a particular identity at a specific time.",
|
||||||
|
"properties": {
|
||||||
|
"description": {
|
||||||
|
"description": "A string describing this identity for use in user interfaces.\n\nIn user interfaces with limited space, descriptions should be hidden beyond the first newline character or `140` characters until revealed by the user.\n\nE.g.:\n- `The common stock issued by ACME, Inc.`\n- `A metadata registry maintained by Company Name, the embedded registry for Wallet Name.`\n- `Software developer and lead maintainer of Wallet Name.`",
|
||||||
|
"type": "string"
|
||||||
|
},
|
||||||
|
"extensions": {
|
||||||
|
"$ref": "#/definitions/Extensions",
|
||||||
|
"description": "A mapping of `IdentitySnapshot` extension identifiers to extension definitions. {@link Extensions } may be widely standardized or application-specific.\n\nStandardized extensions for `IdentitySnapshot`s include the `authchain` extension. See https://github.com/bitjson/chip-bcmr#authchain-extension for details."
|
||||||
|
},
|
||||||
|
"migrated": {
|
||||||
|
"description": "The timestamp at which this identity snapshot is fully in effect. This value should only be provided if the snapshot takes effect over a period of time (e.g. an in-circulation token identity is gradually migrating to a new category). In these cases, clients should gradually migrate to using the new information beginning after the identity snapshot's timestamp and the `migrated` time.\n\nThis 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()`.",
|
||||||
|
"type": ["number", "string"]
|
||||||
|
},
|
||||||
|
"name": {
|
||||||
|
"description": "The name of this identity for use in interfaces.\n\nIn user interfaces with limited space, names should be hidden beyond the first newline character or `20` characters until revealed by the user.\n\nE.g. `ACME Class A Shares`, `ACME Registry`, `Satoshi Nakamoto`, etc.",
|
||||||
|
"type": "string"
|
||||||
|
},
|
||||||
|
"splitId": {
|
||||||
|
"description": "The split ID of this identity's chain of record.\n\nIf undefined, defaults to {@link Registry.defaultChain } .",
|
||||||
|
"type": "string"
|
||||||
|
},
|
||||||
|
"status": {
|
||||||
|
"description": "The status of this identity, must be `active`, `inactive`, or `burned`. If omitted, defaults to `active`.\n- Identities with an `active` status should be actively tracked by clients.\n- Identities with an `inactive` status may be considered for archival by clients and may be removed in future registry versions.\n- Identities with a `burned` status have been destroyed by setting the latest identity output to a data-carrier output (`OP_RETURN`), permanently terminating the authchain. Clients should archive burned identities and – if the burned identity represented a token type – consider burning any remaining tokens of that category to reclaim funds from those outputs.",
|
||||||
|
"enum": ["active", "burned", "inactive"],
|
||||||
|
"type": "string"
|
||||||
|
},
|
||||||
|
"tags": {
|
||||||
|
"description": "An array of `Tag` identifiers marking the `Tag`s associated with this identity. All specified tag identifiers must be defined in the registry's `tags` mapping.",
|
||||||
|
"items": {
|
||||||
|
"type": "string"
|
||||||
|
},
|
||||||
|
"type": "array"
|
||||||
|
},
|
||||||
"token": {
|
"token": {
|
||||||
"additionalProperties": false,
|
"additionalProperties": false,
|
||||||
"description": "If this identity is a type of token, a data structure indicating how tokens should be displayed in user interfaces. Omitted for non-token identities.",
|
"description": "If this identity is a type of token, a data structure indicating how tokens should be displayed in user interfaces. Omitted for non-token identities.",
|
||||||
"properties": {
|
"properties": {
|
||||||
"category": {
|
"category": {
|
||||||
"description": "The current token category used by this identity. Often, this will be equal to the identities authbase, but some token identities must migrate to new categories for technical reasons.",
|
"description": "The current token category used by this identity. Often, this will be equal to the identity's authbase, but some token identities must migrate to new categories for technical reasons.",
|
||||||
"type": "string"
|
"type": "string"
|
||||||
},
|
},
|
||||||
"decimals": {
|
"decimals": {
|
||||||
@@ -75,7 +145,7 @@
|
|||||||
"description": "Display information for non-fungible tokens (NFTs) of this identity. Omitted for token categories without NFTs.",
|
"description": "Display information for non-fungible tokens (NFTs) of this identity. Omitted for token categories without NFTs.",
|
||||||
"properties": {
|
"properties": {
|
||||||
"description": {
|
"description": {
|
||||||
"description": "A string describing how this identity uses NFTs (for use in user interfaces). Descriptions longer than `160` characters may be elided in some interfaces.\n\nE.g. `ACME DEX NFT order receipts are issued when you place orders on the decentralized exchange. After orders are processed, order receipts can be redeemed for purchased tokens or sales proceeds.`; `ACME Game collectable NFTs unlock unique playable content, user avatars, and item skins in ACME Game Online.`; etc.",
|
"description": "A string describing how this identity uses NFTs (for use in user interfaces). Descriptions longer than `160` characters may be elided in some interfaces.\n\nE.g.:\n- \"ACME DEX NFT order receipts are issued when you place orders on the decentralized exchange. After orders are processed, order receipts can be redeemed for purchased tokens or sales proceeds.\";\n- \"ACME Game collectable NFTs unlock unique playable content, user avatars, and item skins in ACME Game Online.\"; etc.",
|
||||||
"type": "string"
|
"type": "string"
|
||||||
},
|
},
|
||||||
"fields": {
|
"fields": {
|
||||||
@@ -83,7 +153,7 @@
|
|||||||
"additionalProperties": false,
|
"additionalProperties": false,
|
||||||
"properties": {
|
"properties": {
|
||||||
"description": {
|
"description": {
|
||||||
"description": "A string describing how this identity uses NFTs (for use in user interfaces). Descriptions longer than `160` characters may be elided in some interfaces.\n\nE.g. `The BCH value pledged at the time this receipt was issued.`; `The number of tokens sold in this order.`; `The seat number associated with this ticket.`; `The IPFS` collectable NFTs unlock unique playable content, user avatars, and item skins in ACME Game Online.`; etc.",
|
"description": "A string describing how this identity uses NFTs (for use in user interfaces). Descriptions longer than `160` characters may be elided in some interfaces.\n\nE.g.:\n- `The BCH value pledged at the time this receipt was issued.`\n- `The number of tokens sold in this order.`\n- `The seat number associated with this ticket.`",
|
||||||
"type": "string"
|
"type": "string"
|
||||||
},
|
},
|
||||||
"encoding": {
|
"encoding": {
|
||||||
@@ -98,8 +168,8 @@
|
|||||||
"hex",
|
"hex",
|
||||||
"https-url",
|
"https-url",
|
||||||
"ipfs-cid",
|
"ipfs-cid",
|
||||||
"locktime",
|
"utf8",
|
||||||
"utf8"
|
"locktime"
|
||||||
],
|
],
|
||||||
"type": "string"
|
"type": "string"
|
||||||
}
|
}
|
||||||
@@ -136,10 +206,10 @@
|
|||||||
},
|
},
|
||||||
"extensions": {
|
"extensions": {
|
||||||
"$ref": "#/definitions/Extensions",
|
"$ref": "#/definitions/Extensions",
|
||||||
"description": "A mapping of NFT field extension identifiers to extension definitions. Extensions may be widely standardized or registry-specific, and extension definitions may be values of any type."
|
"description": "A mapping of NFT field extension identifiers to extension definitions. {@link Extensions } may be widely standardized or application-specific."
|
||||||
},
|
},
|
||||||
"name": {
|
"name": {
|
||||||
"description": "The name of this field for use in interfaces. Names longer than `20` characters may be elided in some interfaces.\n\nE.g. `BCH Pledged`, `Tokens Sold`, `Seat Number`, `IPFS Content Identifier`, `HTTPS URL` etc.",
|
"description": "The name of this field for use in interfaces. Names longer than `20` characters may be elided in some interfaces.\n\nE.g.:\n- `BCH Pledged`\n- `Tokens Sold`\n- `Seat Number`,\n- `IPFS Content Identifier`\n- `HTTPS URL`",
|
||||||
"type": "string"
|
"type": "string"
|
||||||
},
|
},
|
||||||
"uris": {
|
"uris": {
|
||||||
@@ -155,10 +225,10 @@
|
|||||||
},
|
},
|
||||||
"parse": {
|
"parse": {
|
||||||
"additionalProperties": false,
|
"additionalProperties": false,
|
||||||
"description": "Parsing and interpretation information for all NFTs of this category.\n\nParsing instructions are provided in the `bytecode` property, and the results are interpreted using the `types` property.",
|
"description": "Parsing and interpretation information for all NFTs of this category; this enables generalized wallets to parse and display detailed information about all NFTs held by the wallet, e.g. `BCH Pledged`, `Order Price`, `Seat Number`, `Asset Number`, `IPFS Content Identifier`, `HTTPS URL`, etc.\n\nParsing instructions are provided in the `bytecode` property, and the results are interpreted using the `types` property.",
|
||||||
"properties": {
|
"properties": {
|
||||||
"bytecode": {
|
"bytecode": {
|
||||||
"description": "A segment of hex-encoded Bitcoin Cash VM bytecode that parses NFT commitments of this category and returns a list of NFT field values via the altstack. The `bytecode` is taken as locking bytecode evaluated after pushing the full NFT commitment to the stack (as if pushed in a single-operation unlocking bytecode).\n\nIf the resulting stack is not valid (a single \"truthy\" element remaining on the stack) – or if the altstack is empty – parsing has failed and clients should represent the NFT as unable to be parsed (e.g. simply display the full `commitment`).\n\nOn successful parsing evaluations, the bottom item on the altstack indicates the type of the NFT according to the matching definition in `types`. If no match is found, clients should represent the NFT as unable to be parsed.",
|
"description": "A segment of hex-encoded Bitcoin Cash VM bytecode that parses UTXOs holding NFTs of this category, identifies the NFT's type within the category, and returns a list of the NFT's field values via the altstack.\n\nThe parse `bytecode` is evaluated by instantiating and partially verifying a standardized NFT parsing transaction:\n- version: `2`\n- inputs: - 0: Spends the UTXO containing the NFT with an empty unlocking bytecode and sequence number of `0`. - 1: Spends index `0` of the empty hash outpoint, with locking bytecode set to `parse.bytecode`, unlocking bytecode `OP_1` (`0x51`) and sequence number `0`.\n- outputs: - 0: A locking bytecode of OP_RETURN (`0x6a`) and value of `0`.\n- locktime: `0`\n\nAfter input 1 of this NFT parsing transaction is evaluated, if the resulting stack is not valid (a single \"truthy\" element remaining on the stack) – or if the altstack is empty – parsing has failed and clients should represent the NFT as unable to be parsed (e.g. simply display the full `commitment` as a hex-encoded value in the user interface).\n\nOn successful parsing evaluations, the bottom item on the altstack indicates the type of the NFT according to the matching definition in `types`. If no match is found, clients should represent the NFT as unable to be parsed.\n\nFor example:\n- `00d26b` (OP_0 OP_UTXOTOKENCOMMITMENT OP_TOALTSTACK) takes the full contents of the commitment as a fixed type; this can be used for collections of unique, \"numbered\" NFTs. (Commitments of `01`, `02`, `03`, etc.)\n- `00d2517f7c6b` (OP_0 OP_UTXOTOKENCOMMITMENT OP_1 OP_SPLIT OP_SWAP OP_TOALTSTACK OP_TOALTSTACK) splits the commitment after 1 byte, pushing the first byte to the altstack as an NFT type and the remaining segment of the commitment as the first NFT field value.",
|
||||||
"type": "string"
|
"type": "string"
|
||||||
},
|
},
|
||||||
"types": {
|
"types": {
|
||||||
@@ -167,12 +237,12 @@
|
|||||||
"description": "A definition for one type of NFT within a token category. NFT types are indexed by the expected hex-encoded value of the bottom altstack item following evaluation of `token.nft.parse.bytecode`. The remaining altstack items are mapped to NFT fields according to the `fields` property of the matching NFT type.",
|
"description": "A definition for one type of NFT within a token category. NFT types are indexed by the expected hex-encoded value of the bottom altstack item following evaluation of `token.nft.parse.bytecode`. The remaining altstack items are mapped to NFT fields according to the `fields` property of the matching NFT type.",
|
||||||
"properties": {
|
"properties": {
|
||||||
"description": {
|
"description": {
|
||||||
"description": "A string describing this NFT type for use in user interfaces. Descriptions longer than `160` characters may be elided in some interfaces.\n\nE.g. `Receipts issued by the exchange to record details about purchases. After settlement, these receipts are redeemed for the purchased tokens.`; `Receipts issued by the crowdfunding campaign to document the value of funds pledged. If the user decides to cancel their pledge before the campaign completes, these receipts can be redeemed for a full refund.`; `Tickets issued for events at ACME Stadium.`; `Sealed ballots certified by ACME decentralized organization during the voting period. After the voting period ends, these ballots must be revealed to reclaim the tokens used for voting.`; etc.",
|
"description": "A string describing this NFT type for use in user interfaces.\n\nIn user interfaces with limited space, names should be hidden beyond the first newline character or `140` characters until revealed by the user.\n\nE.g.:\n- \"Receipts issued by the exchange to record details about purchases. After settlement, these receipts are redeemed for the purchased tokens.\";\n- \"Receipts issued by the crowdfunding campaign to document the value of funds pledged. If the user decides to cancel their pledge before the campaign completes, these receipts can be redeemed for a full refund.\";\n- \"Tickets issued for events at ACME Stadium.\";\n- Sealed ballots certified by ACME decentralized organization during the voting period. After the voting period ends, these ballots must be revealed to reclaim the tokens used for voting.\"",
|
||||||
"type": "string"
|
"type": "string"
|
||||||
},
|
},
|
||||||
"extensions": {
|
"extensions": {
|
||||||
"$ref": "#/definitions/Extensions",
|
"$ref": "#/definitions/Extensions",
|
||||||
"description": "A mapping of NFT type extension identifiers to extension definitions. Extensions may be widely standardized or registry-specific, and extension definitions may be values of any type."
|
"description": "A mapping of NFT type extension identifiers to extension definitions. {@link Extensions } may be widely standardized or application-specific."
|
||||||
},
|
},
|
||||||
"fields": {
|
"fields": {
|
||||||
"description": "A list of identifiers for fields contained in NFTs of this type. On successful parsing evaluations, the bottom item on the altstack indicates the matched NFT type, and the remaining altstack items represent NFT field contents in the order listed (where `fields[0]` is the second-to-bottom item, and the final item in `fields` is the top of the altstack).\n\nFields should be ordered by recommended importance from most important to least important; in user interfaces, clients should display fields at lower indexes more prominently than those at higher indexes, e.g. if some fields cannot be displayed in minimized interfaces, higher-importance fields can still be represented. (Note, this ordering is controlled by the bytecode specified in `token.nft.parse.bytecode`.)",
|
"description": "A list of identifiers for fields contained in NFTs of this type. On successful parsing evaluations, the bottom item on the altstack indicates the matched NFT type, and the remaining altstack items represent NFT field contents in the order listed (where `fields[0]` is the second-to-bottom item, and the final item in `fields` is the top of the altstack).\n\nFields should be ordered by recommended importance from most important to least important; in user interfaces, clients should display fields at lower indexes more prominently than those at higher indexes, e.g. if some fields cannot be displayed in minimized interfaces, higher-importance fields can still be represented. (Note, this ordering is controlled by the bytecode specified in `token.nft.parse.bytecode`.)",
|
||||||
@@ -201,11 +271,11 @@
|
|||||||
"type": "object"
|
"type": "object"
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
"required": ["fields", "parse"],
|
"required": ["parse"],
|
||||||
"type": "object"
|
"type": "object"
|
||||||
},
|
},
|
||||||
"symbol": {
|
"symbol": {
|
||||||
"description": "An abbreviation used to uniquely identity this token category.",
|
"description": "An abbreviation used to uniquely identity this token category.\n\nSymbols must be comprised only of capital letters, numbers, and dashes (`-`). This can be validated with the regular expression: `/^[-A-Z0-9]+$/`.",
|
||||||
"type": "string"
|
"type": "string"
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
@@ -217,7 +287,7 @@
|
|||||||
"description": "A mapping of identifiers to URIs associated with this identity. URI identifiers may be widely-standardized or registry-specific. Values must be valid URIs, including a protocol prefix (e.g. `https://` or `ipfs://`). Clients are only required to support `https` and `ipfs` URIs, but any scheme may be specified.\n\nThe following identifiers are recommended for all identities:\n- `icon`\n- `web`\n\nThe following optional identifiers are standardized:\n- `blog`\n- `chat`\n- `forum`\n- `icon-intro`\n- `registry`\n- `support`\n\nFor details on these standard identifiers, see: https://github.com/bitjson/chip-bcmr#uri-identifiers\n\nCustom URI identifiers allow for sharing social networking profiles, p2p connection information, and other application-specific URIs. Identifiers must be lowercase, alphanumeric strings, with no whitespace or special characters other than dashes (as a regular expression: `/^[-a-z0-9]+$/`).\n\nFor example, some common identifiers include: `discord`, `docker`, `facebook`, `git`, `github`, `gitter`, `instagram`, `linkedin`, `matrix`, `npm`, `reddit`, `slack`, `substack`, `telegram`, `twitter`, `wechat`, `youtube`."
|
"description": "A mapping of identifiers to URIs associated with this identity. URI identifiers may be widely-standardized or registry-specific. Values must be valid URIs, including a protocol prefix (e.g. `https://` or `ipfs://`). Clients are only required to support `https` and `ipfs` URIs, but any scheme may be specified.\n\nThe following identifiers are recommended for all identities:\n- `icon`\n- `web`\n\nThe following optional identifiers are standardized:\n- `blog`\n- `chat`\n- `forum`\n- `icon-intro`\n- `registry`\n- `support`\n\nFor details on these standard identifiers, see: https://github.com/bitjson/chip-bcmr#uri-identifiers\n\nCustom URI identifiers allow for sharing social networking profiles, p2p connection information, and other application-specific URIs. Identifiers must be lowercase, alphanumeric strings, with no whitespace or special characters other than dashes (as a regular expression: `/^[-a-z0-9]+$/`).\n\nFor example, some common identifiers include: `discord`, `docker`, `facebook`, `git`, `github`, `gitter`, `instagram`, `linkedin`, `matrix`, `npm`, `reddit`, `slack`, `substack`, `telegram`, `twitter`, `wechat`, `youtube`."
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
"required": ["name", "time"],
|
"required": ["name"],
|
||||||
"type": "object"
|
"type": "object"
|
||||||
},
|
},
|
||||||
"Registry": {
|
"Registry": {
|
||||||
@@ -225,12 +295,23 @@
|
|||||||
"description": "A Bitcoin Cash Metadata Registry is an authenticated JSON file containing metadata about tokens, identities, contract applications, and other on-chain artifacts. BCMRs conform to the Bitcoin Cash Metadata Registry JSON Schema, and they can be published and maintained by any entity or individual.",
|
"description": "A Bitcoin Cash Metadata Registry is an authenticated JSON file containing metadata about tokens, identities, contract applications, and other on-chain artifacts. BCMRs conform to the Bitcoin Cash Metadata Registry JSON Schema, and they can be published and maintained by any entity or individual.",
|
||||||
"properties": {
|
"properties": {
|
||||||
"$schema": {
|
"$schema": {
|
||||||
"description": "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://raw.githubusercontent.com/bitjson/chip-bcmr/master/registry-v1.schema.json`",
|
"description": "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`",
|
||||||
|
"type": "string"
|
||||||
|
},
|
||||||
|
"chains": {
|
||||||
|
"additionalProperties": {
|
||||||
|
"$ref": "#/definitions/ChainHistory"
|
||||||
|
},
|
||||||
|
"description": "A map of split IDs tracked by this registry to the {@link ChainHistory } for that chain/network.\n\nThe 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.)\n\nNote, 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 {@link ChainSnapshot } for each chain and splitting coins prior to spending (by introducing post-split coins in each transaction).\n\nThis map may exclude the following well-known split IDs (all clients supporting any of these chains should build-in {@link ChainHistory } for those chains):\n\n- `0000000000000000029e471c41818d24b8b74c911071c4ef0b4a0509f9b5a8ce`: A.K.A. mainnet – the BCH side of the BCH/XEC split.\n- `00000000ae25e85d9e22cd6c8d72c2f5d4b0222289d801b7f633aeae3f8c6367`: A.K.A testnet4 – the test network on which CHIPs are activated simultaneously with mainnet (May 15 at 12 UTC).\n- `00000000040ba9641ba98a37b2e5ceead38e4e2930ac8f145c8094f94c708727`: A.K.A. chipnet – the test network on which CHIPs are activated 6 months before mainnet (November 15 at 12 UTC).\n\nAll other split IDs referenced by this registry should be included in this map.",
|
||||||
|
"type": "object"
|
||||||
|
},
|
||||||
|
"defaultChain": {
|
||||||
|
"description": "The split ID of the chain/network considered the \"default\" chain for this registry. Identities that do not specify a {@link IdentitySnapshot.splitId } \nare assumed to be set to this split ID. For a description of split IDs, see {@link Registry.chains } .\n\nIf not provided, the `defaultChain` is `0000000000000000029e471c41818d24b8b74c911071c4ef0b4a0509f9b5a8ce`, the BCH side of the BCH/XEC split (mainnet). Common values include:\n- `00000000ae25e85d9e22cd6c8d72c2f5d4b0222289d801b7f633aeae3f8c6367` (testnet4)\n- `00000000040ba9641ba98a37b2e5ceead38e4e2930ac8f145c8094f94c708727` (chipnet)",
|
||||||
"type": "string"
|
"type": "string"
|
||||||
},
|
},
|
||||||
"extensions": {
|
"extensions": {
|
||||||
"$ref": "#/definitions/Extensions",
|
"$ref": "#/definitions/Extensions",
|
||||||
"description": "A mapping of `Registry` extension identifiers to extension definitions. Extensions may be widely standardized or registry-specific, and extension definitions may be values of any type.\n\nStandardized extensions for `Registry`s include the `locale` extension. See https://github.com/bitjson/chip-bcmr#locales-extension for details."
|
"description": "A mapping of `Registry` extension identifiers to extension definitions.\n {@link Extensions } may be widely standardized or application-specific.\n\nStandardized extensions for `Registry`s include the `locale` extension. See https://github.com/bitjson/chip-bcmr#locales-extension for details."
|
||||||
},
|
},
|
||||||
"identities": {
|
"identities": {
|
||||||
"additionalProperties": {
|
"additionalProperties": {
|
||||||
@@ -250,10 +331,10 @@
|
|||||||
"registryIdentity": {
|
"registryIdentity": {
|
||||||
"anyOf": [
|
"anyOf": [
|
||||||
{
|
{
|
||||||
"type": "string"
|
"$ref": "#/definitions/IdentitySnapshot"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"$ref": "#/definitions/IdentitySnapshot"
|
"type": "string"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"description": "The identity information of this particular registry, provided as either an authbase (recommended) or an `IdentitySnapshot`.\n\nAn 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)\n\nIf 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."
|
"description": "The identity information of this particular registry, provided as either an authbase (recommended) or an `IdentitySnapshot`.\n\nAn 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)\n\nIf 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."
|
||||||
@@ -289,20 +370,34 @@
|
|||||||
"required": ["version", "latestRevision", "registryIdentity"],
|
"required": ["version", "latestRevision", "registryIdentity"],
|
||||||
"type": "object"
|
"type": "object"
|
||||||
},
|
},
|
||||||
|
"RegistryTimestampKeyedValues<ChainSnapshot>": {
|
||||||
|
"additionalProperties": {
|
||||||
|
"$ref": "#/definitions/ChainSnapshot"
|
||||||
|
},
|
||||||
|
"description": "A field keyed by timestamps to document the evolution of the field. Each 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()`.\n\nFor example, to insert a new value: ```ts const result = { ...previousValue, [(new Date()).toISOString()]: newValue }; ```",
|
||||||
|
"type": "object"
|
||||||
|
},
|
||||||
|
"RegistryTimestampKeyedValues<IdentitySnapshot>": {
|
||||||
|
"additionalProperties": {
|
||||||
|
"$ref": "#/definitions/IdentitySnapshot"
|
||||||
|
},
|
||||||
|
"description": "A field keyed by timestamps to document the evolution of the field. Each 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()`.\n\nFor example, to insert a new value: ```ts const result = { ...previousValue, [(new Date()).toISOString()]: newValue }; ```",
|
||||||
|
"type": "object"
|
||||||
|
},
|
||||||
"Tag": {
|
"Tag": {
|
||||||
"additionalProperties": false,
|
"additionalProperties": false,
|
||||||
"description": "Tags allow registries to classify and group identities by a variety of characteristics. Tags are standardized within a registry and may represent either labels applied by that registry or designations by external authorities (certification, membership, ownership, etc.) that are tracked by that registry.\n\nExamples of possible tags include: `individual`, `organization`, `token`, `wallet`, `exchange`, `staking`, `utility-token`, `security-token`, `stablecoin`, `wrapped`, `collectable`, `deflationary`, `governance`, `decentralized-exchange`, `liquidity-provider`, `sidechain`, `sidechain-bridge`, `acme-audited`, `acme-endorsed`, etc.\n\nTags may be used by clients in search, discovery, 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 integrity and value to users.",
|
"description": "Tags allow registries to classify and group identities by a variety of characteristics. Tags are standardized within a registry and may represent either labels applied by that registry or designations by external authorities (certification, membership, ownership, etc.) that are tracked by that registry.\n\nExamples of possible tags include: `individual`, `organization`, `token`, `wallet`, `exchange`, `staking`, `utility-token`, `security-token`, `stablecoin`, `wrapped`, `collectable`, `deflationary`, `governance`, `decentralized-exchange`, `liquidity-provider`, `sidechain`, `sidechain-bridge`, `acme-audited`, `acme-endorsed`, etc.\n\nTags may be used by clients in search, discovery, 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 integrity and value to users.",
|
||||||
"properties": {
|
"properties": {
|
||||||
"description": {
|
"description": {
|
||||||
"description": "A string describing this tag for use in user interfaces. Descriptions longer than `160` characters may be elided in some interfaces.\n\nE.g. `An identity maintained by a single individual.`; `An identity representing a type of token.`; `An on-chain application that has passed security audits by ACME, Inc.`; etc.",
|
"description": "A string describing this tag for use in user interfaces.\n\nIn user interfaces with limited space, descriptions should be hidden beyond the first newline character or `140` characters until revealed by the user.\n\nE.g.:\n- `An identity maintained by a single individual.`\n- `An identity representing a type of token.`\n- `An on-chain application that has passed security audits by ACME, Inc.`",
|
||||||
"type": "string"
|
"type": "string"
|
||||||
},
|
},
|
||||||
"extensions": {
|
"extensions": {
|
||||||
"$ref": "#/definitions/Extensions",
|
"$ref": "#/definitions/Extensions",
|
||||||
"description": "A mapping of `Tag` extension identifiers to extension definitions. Extensions may be widely standardized or registry-specific, and extension definitions may be values of any type."
|
"description": "A mapping of `Tag` extension identifiers to extension definitions.\n {@link Extensions } may be widely standardized or application-specific."
|
||||||
},
|
},
|
||||||
"name": {
|
"name": {
|
||||||
"description": "The name of this tag for use in interfaces. Names longer than `20` characters may be elided in some interfaces.\n\nE.g. `Individual`, `Token`, `Audited by ACME, Inc.`, etc.",
|
"description": "The name of this tag for use in interfaces.\n\nIn user interfaces with limited space, names should be hidden beyond the first newline character or `20` characters until revealed by the user.\n\nE.g.:\n- `Individual`\n- `Token`\n- `Audited by ACME, Inc.`",
|
||||||
"type": "string"
|
"type": "string"
|
||||||
},
|
},
|
||||||
"uris": {
|
"uris": {
|
||||||
@@ -10,11 +10,31 @@ export type URIs = {
|
|||||||
|
|
||||||
/**
|
/**
|
||||||
* A mapping of extension identifiers to extension definitions. Extensions may
|
* A mapping of extension identifiers to extension definitions. Extensions may
|
||||||
* be widely standardized or registry-specific, and extension definitions may
|
* be widely standardized or application-specific, and extension definitions
|
||||||
* be values of any type.
|
* must be either:
|
||||||
|
*
|
||||||
|
* - `string`s,
|
||||||
|
* - key-value mappings of `string`s, or
|
||||||
|
* - two-dimensional, key-value mappings of `string`s.
|
||||||
|
*
|
||||||
|
* This limitation encourages safety and wider compatibility across
|
||||||
|
* implementations.
|
||||||
|
*
|
||||||
|
* To encode an array, it is recommended that each value be assigned to a
|
||||||
|
* numeric key indicating the item's index (beginning at `0`).
|
||||||
|
* Numerically-indexed objects are often a more useful and resilient
|
||||||
|
* data-transfer format than simple arrays because they simplify difference-only
|
||||||
|
* transmission: only modified indexes need to be transferred, and shifts in
|
||||||
|
* item order must be explicit, simplifying merges of conflicting updates.
|
||||||
|
*
|
||||||
|
* For encoding of more complex data, consider using base64 and/or
|
||||||
|
* string-encoded JSON.
|
||||||
*/
|
*/
|
||||||
export type Extensions = {
|
export type Extensions = {
|
||||||
[identifier: string]: unknown;
|
[extensionIdentifier: string]:
|
||||||
|
| string
|
||||||
|
| { [key: string]: string }
|
||||||
|
| { [keyA: string]: { [keyB: string]: string } };
|
||||||
};
|
};
|
||||||
|
|
||||||
/**
|
/**
|
||||||
@@ -38,19 +58,27 @@ export type Extensions = {
|
|||||||
*/
|
*/
|
||||||
export type Tag = {
|
export type Tag = {
|
||||||
/**
|
/**
|
||||||
* The name of this tag for use in interfaces. Names longer than `20`
|
* The name of this tag for use in interfaces.
|
||||||
* characters may be elided in some interfaces.
|
|
||||||
*
|
*
|
||||||
* E.g. `Individual`, `Token`, `Audited by ACME, Inc.`, etc.
|
* In user interfaces with limited space, names should be hidden beyond
|
||||||
|
* the first newline character or `20` characters until revealed by the user.
|
||||||
|
*
|
||||||
|
* E.g.:
|
||||||
|
* - `Individual`
|
||||||
|
* - `Token`
|
||||||
|
* - `Audited by ACME, Inc.`
|
||||||
*/
|
*/
|
||||||
name: string;
|
name: string;
|
||||||
/**
|
/**
|
||||||
* A string describing this tag for use in user interfaces. Descriptions
|
* A string describing this tag for use in user interfaces.
|
||||||
* longer than `160` characters may be elided in some interfaces.
|
|
||||||
*
|
*
|
||||||
* E.g. `An identity maintained by a single individual.`; `An identity
|
* In user interfaces with limited space, descriptions should be hidden beyond
|
||||||
* representing a type of token.`; `An on-chain application that has passed
|
* the first newline character or `140` characters until revealed by the user.
|
||||||
* security audits by ACME, Inc.`; etc.
|
*
|
||||||
|
* E.g.:
|
||||||
|
* - `An identity maintained by a single individual.`
|
||||||
|
* - `An identity representing a type of token.`
|
||||||
|
* - `An on-chain application that has passed security audits by ACME, Inc.`
|
||||||
*/
|
*/
|
||||||
description?: string;
|
description?: string;
|
||||||
/**
|
/**
|
||||||
@@ -88,8 +116,7 @@ export type Tag = {
|
|||||||
uris?: URIs;
|
uris?: URIs;
|
||||||
/**
|
/**
|
||||||
* A mapping of `Tag` extension identifiers to extension definitions.
|
* A mapping of `Tag` extension identifiers to extension definitions.
|
||||||
* Extensions may be widely standardized or registry-specific, and extension
|
* {@link Extensions} may be widely standardized or application-specific.
|
||||||
* definitions may be values of any type.
|
|
||||||
*/
|
*/
|
||||||
extensions?: Extensions;
|
extensions?: Extensions;
|
||||||
};
|
};
|
||||||
@@ -105,7 +132,7 @@ export type Registry = {
|
|||||||
* The schema used by this registry. Many JSON editors can automatically
|
* The schema used by this registry. Many JSON editors can automatically
|
||||||
* provide inline documentation and autocomplete support using the `$schema`
|
* provide inline documentation and autocomplete support using the `$schema`
|
||||||
* property, so it is recommended that registries include it. E.g.:
|
* property, so it is recommended that registries include it. E.g.:
|
||||||
* `https://raw.githubusercontent.com/bitjson/chip-bcmr/master/registry-v1.schema.json`
|
* `https://cashtokens.org/bcmr-v2.schema.json`
|
||||||
*/
|
*/
|
||||||
$schema?: string;
|
$schema?: string;
|
||||||
/**
|
/**
|
||||||
@@ -164,7 +191,7 @@ export type Registry = {
|
|||||||
* support on-chain resolution/authentication, and the contained
|
* support on-chain resolution/authentication, and the contained
|
||||||
* `IdentitySnapshot` can only be authenticated via DNS/HTTPS.
|
* `IdentitySnapshot` can only be authenticated via DNS/HTTPS.
|
||||||
*/
|
*/
|
||||||
registryIdentity: string | IdentitySnapshot;
|
registryIdentity: IdentitySnapshot | string;
|
||||||
/**
|
/**
|
||||||
* A mapping of authbases to the `IdentityHistory` for that identity.
|
* A mapping of authbases to the `IdentityHistory` for that identity.
|
||||||
*
|
*
|
||||||
@@ -202,10 +229,65 @@ export type Registry = {
|
|||||||
tags?: {
|
tags?: {
|
||||||
[identifier: string]: Tag;
|
[identifier: string]: Tag;
|
||||||
};
|
};
|
||||||
|
/**
|
||||||
|
* The split ID of the chain/network considered the "default" chain for this
|
||||||
|
* registry. Identities that do not specify a {@link IdentitySnapshot.splitId}
|
||||||
|
* are assumed to be set to this split ID. For a description of split IDs,
|
||||||
|
* see {@link Registry.chains}.
|
||||||
|
*
|
||||||
|
* If not provided, the `defaultChain` is
|
||||||
|
* `0000000000000000029e471c41818d24b8b74c911071c4ef0b4a0509f9b5a8ce`, the BCH
|
||||||
|
* side of the BCH/XEC split (mainnet). Common values include:
|
||||||
|
* - `00000000ae25e85d9e22cd6c8d72c2f5d4b0222289d801b7f633aeae3f8c6367`
|
||||||
|
* (testnet4)
|
||||||
|
* - `00000000040ba9641ba98a37b2e5ceead38e4e2930ac8f145c8094f94c708727`
|
||||||
|
* (chipnet)
|
||||||
|
*/
|
||||||
|
defaultChain?: string;
|
||||||
|
/**
|
||||||
|
* A map of split IDs tracked by this registry to the {@link 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 {@link 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 {@link 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.
|
||||||
|
*/
|
||||||
|
chains?: {
|
||||||
|
[splitId: string]: ChainHistory;
|
||||||
|
};
|
||||||
/**
|
/**
|
||||||
* A mapping of `Registry` extension identifiers to extension definitions.
|
* A mapping of `Registry` extension identifiers to extension definitions.
|
||||||
* Extensions may be widely standardized or registry-specific, and extension
|
* {@link Extensions} may be widely standardized or application-specific.
|
||||||
* definitions may be values of any type.
|
|
||||||
*
|
*
|
||||||
* Standardized extensions for `Registry`s include the `locale` extension. See
|
* Standardized extensions for `Registry`s include the `locale` extension. See
|
||||||
* https://github.com/bitjson/chip-bcmr#locales-extension for details.
|
* https://github.com/bitjson/chip-bcmr#locales-extension for details.
|
||||||
@@ -225,23 +307,27 @@ export type Registry = {
|
|||||||
|
|
||||||
/**
|
/**
|
||||||
* A snapshot of the metadata for a particular identity at a specific time.
|
* A snapshot of the metadata for a particular identity at a specific time.
|
||||||
*
|
|
||||||
*/
|
*/
|
||||||
export type IdentitySnapshot = {
|
export type IdentitySnapshot = {
|
||||||
/**
|
/**
|
||||||
* The name of this identity for use in interfaces. Names longer than
|
* The name of this identity for use in interfaces.
|
||||||
* `20` characters may be elided in some interfaces.
|
*
|
||||||
|
* In user interfaces with limited space, names should be hidden beyond
|
||||||
|
* the first newline character or `20` characters until revealed by the user.
|
||||||
*
|
*
|
||||||
* E.g. `ACME Class A Shares`, `ACME Registry`, `Satoshi Nakamoto`, etc.
|
* E.g. `ACME Class A Shares`, `ACME Registry`, `Satoshi Nakamoto`, etc.
|
||||||
*/
|
*/
|
||||||
name: string;
|
name: string;
|
||||||
/**
|
/**
|
||||||
* A string describing this identity for use in user interfaces.
|
* A string describing this identity for use in user interfaces.
|
||||||
* Descriptions longer than `160` characters may be elided in some interfaces.
|
|
||||||
*
|
*
|
||||||
* E.g. `The common stock issued by ACME, Inc.`, `A metadata
|
* In user interfaces with limited space, descriptions should be hidden beyond
|
||||||
* registry maintained by Company Name, the embedded registry for Wallet
|
* the first newline character or `140` characters until revealed by the user.
|
||||||
* Name.`; `Software developer and lead maintainer of Wallet Name.`; etc.
|
*
|
||||||
|
* E.g.:
|
||||||
|
* - `The common stock issued by ACME, Inc.`
|
||||||
|
* - `A metadata registry maintained by Company Name, the embedded registry for Wallet Name.`
|
||||||
|
* - `Software developer and lead maintainer of Wallet Name.`
|
||||||
*/
|
*/
|
||||||
description?: string;
|
description?: string;
|
||||||
/**
|
/**
|
||||||
@@ -251,35 +337,19 @@ export type IdentitySnapshot = {
|
|||||||
*/
|
*/
|
||||||
tags?: string[];
|
tags?: string[];
|
||||||
/**
|
/**
|
||||||
* The timing information for the introduction of this identity snapshot.
|
* The timestamp at which this identity snapshot is fully in effect. This
|
||||||
* Each timestamps may be provided as either an ISO string (simplified
|
* value should only be provided if the snapshot takes effect over a period
|
||||||
* extended ISO 8601 format) or as a locktime value: an integer from `0` to
|
* of time (e.g. an in-circulation token identity is gradually migrating to
|
||||||
* `4294967295` (inclusive) where values less than `500000000` are understood
|
* a new category). In these cases, clients should gradually migrate to
|
||||||
* to be a block height (the current block number in the chain, beginning from
|
* using the new information beginning after the identity snapshot's timestamp
|
||||||
* block `0`), and values greater than or equal to `500000000` are understood
|
* and the `migrated` time.
|
||||||
* to be a Median Time Past (BIP113) UNIX timestamp.
|
|
||||||
*
|
*
|
||||||
* Generally, timestamps should be provided as an ISO string unless on-chain
|
* This timestamp must be provided in simplified extended ISO 8601 format, a
|
||||||
* artifacts require the locktime value (e.g. an on-chain migration that is
|
* 24-character string of format `YYYY-MM-DDTHH:mm:ss.sssZ` where timezone is
|
||||||
* set to complete at a particular locktime value).
|
* zero UTC (denoted by `Z`). Note, this is the format returned by ECMAScript
|
||||||
|
* `Date.toISOString()`.
|
||||||
*/
|
*/
|
||||||
time: {
|
migrated?: number | string;
|
||||||
/**
|
|
||||||
* The timestamp at which this identity snapshot begins to be active. If
|
|
||||||
* `complete` isn't specified, this is a precise time at which this
|
|
||||||
* snapshot takes effect and clients should begin using the new information.
|
|
||||||
*/
|
|
||||||
begin: string | number;
|
|
||||||
/**
|
|
||||||
* The timestamp at which this identity snapshot is fully in effect. This
|
|
||||||
* value should only be provided if the snapshot takes effect over a period
|
|
||||||
* of time (e.g. an in-circulation token identity is gradually migrating to
|
|
||||||
* a new category). In these cases, clients should gradually migrate to
|
|
||||||
* using the new information beginning after the `begin` time and completing
|
|
||||||
* at the `complete` time.
|
|
||||||
*/
|
|
||||||
complete?: string | number;
|
|
||||||
};
|
|
||||||
/**
|
/**
|
||||||
* If this identity is a type of token, a data structure indicating how tokens
|
* If this identity is a type of token, a data structure indicating how tokens
|
||||||
* should be displayed in user interfaces. Omitted for non-token identities.
|
* should be displayed in user interfaces. Omitted for non-token identities.
|
||||||
@@ -287,7 +357,7 @@ export type IdentitySnapshot = {
|
|||||||
token?: {
|
token?: {
|
||||||
/**
|
/**
|
||||||
* The current token category used by this identity. Often, this will be
|
* The current token category used by this identity. Often, this will be
|
||||||
* equal to the identities authbase, but some token identities must migrate
|
* equal to the identity's authbase, but some token identities must migrate
|
||||||
* to new categories for technical reasons.
|
* to new categories for technical reasons.
|
||||||
*/
|
*/
|
||||||
category: string;
|
category: string;
|
||||||
@@ -321,25 +391,30 @@ export type IdentitySnapshot = {
|
|||||||
* interfaces). Descriptions longer than `160` characters may be elided in
|
* interfaces). Descriptions longer than `160` characters may be elided in
|
||||||
* some interfaces.
|
* some interfaces.
|
||||||
*
|
*
|
||||||
* E.g. `ACME DEX NFT order receipts are issued when you place orders on
|
* E.g.:
|
||||||
* the decentralized exchange. After orders are processed, order receipts
|
* - "ACME DEX NFT order receipts are issued when you place orders on the
|
||||||
* can be redeemed for purchased tokens or sales proceeds.`; `ACME Game
|
* decentralized exchange. After orders are processed, order receipts can
|
||||||
* collectable NFTs unlock unique playable content, user avatars, and item
|
* be redeemed for purchased tokens or sales proceeds.";
|
||||||
* skins in ACME Game Online.`; etc.
|
* - "ACME Game collectable NFTs unlock unique playable content, user
|
||||||
|
* avatars, and item skins in ACME Game Online."; etc.
|
||||||
*/
|
*/
|
||||||
description?: string;
|
description?: string;
|
||||||
/**
|
/**
|
||||||
* A mapping of field identifier to field definitions for the data fields
|
* A mapping of field identifier to field definitions for the data fields
|
||||||
* that can appear in NFT commitments of this category.
|
* that can appear in NFT commitments of this category.
|
||||||
*/
|
*/
|
||||||
fields: {
|
fields?: {
|
||||||
[identifier: string]: {
|
[identifier: string]: {
|
||||||
/**
|
/**
|
||||||
* The name of this field for use in interfaces. Names longer than
|
* The name of this field for use in interfaces. Names longer than
|
||||||
* `20` characters may be elided in some interfaces.
|
* `20` characters may be elided in some interfaces.
|
||||||
*
|
*
|
||||||
* E.g. `BCH Pledged`, `Tokens Sold`, `Seat Number`,
|
* E.g.:
|
||||||
* `IPFS Content Identifier`, `HTTPS URL` etc.
|
* - `BCH Pledged`
|
||||||
|
* - `Tokens Sold`
|
||||||
|
* - `Seat Number`,
|
||||||
|
* - `IPFS Content Identifier`
|
||||||
|
* - `HTTPS URL`
|
||||||
*/
|
*/
|
||||||
name?: string;
|
name?: string;
|
||||||
/**
|
/**
|
||||||
@@ -347,11 +422,10 @@ export type IdentitySnapshot = {
|
|||||||
* interfaces). Descriptions longer than `160` characters may be
|
* interfaces). Descriptions longer than `160` characters may be
|
||||||
* elided in some interfaces.
|
* elided in some interfaces.
|
||||||
*
|
*
|
||||||
* E.g. `The BCH value pledged at the time this receipt was issued.`;
|
* E.g.:
|
||||||
* `The number of tokens sold in this order.`; `The seat number
|
* - `The BCH value pledged at the time this receipt was issued.`
|
||||||
* associated with this ticket.`; `The IPFS`
|
* - `The number of tokens sold in this order.`
|
||||||
* collectable NFTs unlock unique playable content, user avatars, and item
|
* - `The seat number associated with this ticket.`
|
||||||
* skins in ACME Game Online.`; etc.
|
|
||||||
*/
|
*/
|
||||||
description?: string;
|
description?: string;
|
||||||
/**
|
/**
|
||||||
@@ -392,8 +466,8 @@ export type IdentitySnapshot = {
|
|||||||
| 'hex'
|
| 'hex'
|
||||||
| 'https-url'
|
| 'https-url'
|
||||||
| 'ipfs-cid'
|
| 'ipfs-cid'
|
||||||
| `locktime`
|
| 'utf8'
|
||||||
| 'utf8';
|
| `locktime`;
|
||||||
}
|
}
|
||||||
| {
|
| {
|
||||||
type: 'number';
|
type: 'number';
|
||||||
@@ -447,36 +521,63 @@ export type IdentitySnapshot = {
|
|||||||
uris?: URIs;
|
uris?: URIs;
|
||||||
/**
|
/**
|
||||||
* A mapping of NFT field extension identifiers to extension
|
* A mapping of NFT field extension identifiers to extension
|
||||||
* definitions. Extensions may be widely standardized or
|
* definitions. {@link Extensions} may be widely standardized or
|
||||||
* registry-specific, and extension definitions may be values of
|
* application-specific.
|
||||||
* any type.
|
|
||||||
*/
|
*/
|
||||||
extensions?: Extensions;
|
extensions?: Extensions;
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
/**
|
/**
|
||||||
* Parsing and interpretation information for all NFTs of this category.
|
* Parsing and interpretation information for all NFTs of this category;
|
||||||
|
* this enables generalized wallets to parse and display detailed
|
||||||
|
* information about all NFTs held by the wallet, e.g. `BCH Pledged`,
|
||||||
|
* `Order Price`, `Seat Number`, `Asset Number`,
|
||||||
|
* `IPFS Content Identifier`, `HTTPS URL`, etc.
|
||||||
*
|
*
|
||||||
* Parsing instructions are provided in the `bytecode` property, and the
|
* Parsing instructions are provided in the `bytecode` property, and the
|
||||||
* results are interpreted using the `types` property.
|
* results are interpreted using the `types` property.
|
||||||
*/
|
*/
|
||||||
parse: {
|
parse: {
|
||||||
/**
|
/**
|
||||||
* A segment of hex-encoded Bitcoin Cash VM bytecode that parses NFT
|
* A segment of hex-encoded Bitcoin Cash VM bytecode that parses UTXOs
|
||||||
* commitments of this category and returns a list of NFT field values
|
* holding NFTs of this category, identifies the NFT's type within the
|
||||||
* via the altstack. The `bytecode` is taken as locking bytecode
|
* category, and returns a list of the NFT's field values via the
|
||||||
* evaluated after pushing the full NFT commitment to the stack (as if
|
* altstack.
|
||||||
* pushed in a single-operation unlocking bytecode).
|
|
||||||
*
|
*
|
||||||
* If the resulting stack is not valid (a single "truthy" element
|
* The parse `bytecode` is evaluated by instantiating and partially
|
||||||
* remaining on the stack) – or if the altstack is empty – parsing has
|
* verifying a standardized NFT parsing transaction:
|
||||||
* failed and clients should represent the NFT as unable to be parsed
|
* - version: `2`
|
||||||
* (e.g. simply display the full `commitment`).
|
* - inputs:
|
||||||
|
* - 0: Spends the UTXO containing the NFT with an empty
|
||||||
|
* unlocking bytecode and sequence number of `0`.
|
||||||
|
* - 1: Spends index `0` of the empty hash outpoint, with locking
|
||||||
|
* bytecode set to `parse.bytecode`, unlocking bytecode `OP_1`
|
||||||
|
* (`0x51`) and sequence number `0`.
|
||||||
|
* - outputs:
|
||||||
|
* - 0: A locking bytecode of OP_RETURN (`0x6a`) and value of `0`.
|
||||||
|
* - locktime: `0`
|
||||||
|
*
|
||||||
|
* After input 1 of this NFT parsing transaction is evaluated, if the
|
||||||
|
* resulting stack is not valid (a single "truthy" element remaining on
|
||||||
|
* the stack) – or if the altstack is empty – parsing has failed and
|
||||||
|
* clients should represent the NFT as unable to be parsed (e.g. simply
|
||||||
|
* display the full `commitment` as a hex-encoded value in the user
|
||||||
|
* interface).
|
||||||
*
|
*
|
||||||
* On successful parsing evaluations, the bottom item on the altstack
|
* On successful parsing evaluations, the bottom item on the altstack
|
||||||
* indicates the type of the NFT according to the matching definition in
|
* indicates the type of the NFT according to the matching definition in
|
||||||
* `types`. If no match is found, clients should represent the NFT as
|
* `types`. If no match is found, clients should represent the NFT as
|
||||||
* unable to be parsed.
|
* unable to be parsed.
|
||||||
|
*
|
||||||
|
* For example:
|
||||||
|
* - `00d26b` (OP_0 OP_UTXOTOKENCOMMITMENT OP_TOALTSTACK) takes the full
|
||||||
|
* contents of the commitment as a fixed type; this can be used for
|
||||||
|
* collections of unique, "numbered" NFTs. (Commitments of `01`, `02`,
|
||||||
|
* `03`, etc.)
|
||||||
|
* - `00d2517f7c6b` (OP_0 OP_UTXOTOKENCOMMITMENT OP_1 OP_SPLIT OP_SWAP
|
||||||
|
* OP_TOALTSTACK OP_TOALTSTACK) splits the commitment after 1 byte,
|
||||||
|
* pushing the first byte to the altstack as an NFT type and the
|
||||||
|
* remaining segment of the commitment as the first NFT field value.
|
||||||
*/
|
*/
|
||||||
bytecode: string;
|
bytecode: string;
|
||||||
/**
|
/**
|
||||||
@@ -502,19 +603,23 @@ export type IdentitySnapshot = {
|
|||||||
name: string;
|
name: string;
|
||||||
/**
|
/**
|
||||||
* A string describing this NFT type for use in user interfaces.
|
* A string describing this NFT type for use in user interfaces.
|
||||||
* Descriptions longer than `160` characters may be elided in
|
|
||||||
* some interfaces.
|
|
||||||
*
|
*
|
||||||
* E.g. `Receipts issued by the exchange to record details about
|
* In user interfaces with limited space, names should be hidden
|
||||||
|
* beyond the first newline character or `140` characters until
|
||||||
|
* revealed by the user.
|
||||||
|
*
|
||||||
|
* E.g.:
|
||||||
|
* - "Receipts issued by the exchange to record details about
|
||||||
* purchases. After settlement, these receipts are redeemed for the
|
* purchases. After settlement, these receipts are redeemed for the
|
||||||
* purchased tokens.`; `Receipts issued by the crowdfunding campaign
|
* purchased tokens.";
|
||||||
|
* - "Receipts issued by the crowdfunding campaign
|
||||||
* to document the value of funds pledged. If the user decides to
|
* to document the value of funds pledged. If the user decides to
|
||||||
* cancel their pledge before the campaign completes, these receipts
|
* cancel their pledge before the campaign completes, these receipts
|
||||||
* can be redeemed for a full refund.`; `Tickets issued for events
|
* can be redeemed for a full refund.";
|
||||||
* at ACME Stadium.`; `Sealed ballots certified by ACME
|
* - "Tickets issued for events at ACME Stadium.";
|
||||||
* decentralized organization during the voting period. After the
|
* - Sealed ballots certified by ACME decentralized organization
|
||||||
* voting period ends, these ballots must be revealed to reclaim the
|
* during the voting period. After the voting period ends, these
|
||||||
* tokens used for voting.`; etc.
|
* ballots must be revealed to reclaim the tokens used for voting."
|
||||||
*/
|
*/
|
||||||
description?: string;
|
description?: string;
|
||||||
/**
|
/**
|
||||||
@@ -544,9 +649,8 @@ export type IdentitySnapshot = {
|
|||||||
uris?: URIs;
|
uris?: URIs;
|
||||||
/**
|
/**
|
||||||
* A mapping of NFT type extension identifiers to extension
|
* A mapping of NFT type extension identifiers to extension
|
||||||
* definitions. Extensions may be widely standardized or
|
* definitions. {@link Extensions} may be widely standardized or
|
||||||
* registry-specific, and extension definitions may be values of
|
* application-specific.
|
||||||
* any type.
|
|
||||||
*/
|
*/
|
||||||
extensions?: Extensions;
|
extensions?: Extensions;
|
||||||
};
|
};
|
||||||
@@ -567,7 +671,7 @@ export type IdentitySnapshot = {
|
|||||||
* if the burned identity represented a token type – consider burning any
|
* if the burned identity represented a token type – consider burning any
|
||||||
* remaining tokens of that category to reclaim funds from those outputs.
|
* remaining tokens of that category to reclaim funds from those outputs.
|
||||||
*/
|
*/
|
||||||
status?: 'active' | 'inactive' | 'burned';
|
status?: 'active' | 'burned' | 'inactive';
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* A mapping of identifiers to URIs associated with this identity. URI
|
* A mapping of identifiers to URIs associated with this identity. URI
|
||||||
@@ -603,10 +707,17 @@ export type IdentitySnapshot = {
|
|||||||
*/
|
*/
|
||||||
uris?: URIs;
|
uris?: URIs;
|
||||||
|
|
||||||
|
/**
|
||||||
|
* The split ID of this identity's chain of record.
|
||||||
|
*
|
||||||
|
* If undefined, defaults to {@link Registry.defaultChain}.
|
||||||
|
*/
|
||||||
|
splitId?: string;
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* A mapping of `IdentitySnapshot` extension identifiers to extension
|
* A mapping of `IdentitySnapshot` extension identifiers to extension
|
||||||
* definitions. Extensions may be widely standardized or registry-specific,
|
* definitions. {@link Extensions} may be widely standardized or
|
||||||
* and extension definitions may be values of any type.
|
* application-specific.
|
||||||
*
|
*
|
||||||
* Standardized extensions for `IdentitySnapshot`s include the `authchain`
|
* Standardized extensions for `IdentitySnapshot`s include the `authchain`
|
||||||
* extension. See
|
* extension. See
|
||||||
@@ -616,24 +727,104 @@ export type IdentitySnapshot = {
|
|||||||
};
|
};
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* An array of `IdentitySnapshot`s, ordered from newest to oldest documenting
|
* A snapshot of the metadata for a particular chain/network at a specific
|
||||||
|
* time. This allows for registries to provide similar metadata for each chain's
|
||||||
|
* native currency unit (name, description, symbol, icon, etc.) as can be
|
||||||
|
* provided for other registered tokens.
|
||||||
|
*/
|
||||||
|
export type ChainSnapshot = Omit<IdentitySnapshot, 'migrated' | 'token'> & {
|
||||||
|
/**
|
||||||
|
* A data structure indicating how the chain's native currency units should be
|
||||||
|
* displayed in user interfaces.
|
||||||
|
*/
|
||||||
|
token: {
|
||||||
|
/**
|
||||||
|
* An abbreviation used to uniquely identity this native currency unit.
|
||||||
|
*
|
||||||
|
* Symbols must be comprised only of capital letters, numbers, and dashes
|
||||||
|
* (`-`). This can be validated with the regular expression:
|
||||||
|
* `/^[-A-Z0-9]+$/`.
|
||||||
|
*/
|
||||||
|
symbol: string;
|
||||||
|
/**
|
||||||
|
* An integer between `0` and `18` (inclusive) indicating the divisibility
|
||||||
|
* of the primary unit of this native currency.
|
||||||
|
*
|
||||||
|
* This is the number of digits that can appear after the decimal separator
|
||||||
|
* in currency amounts. For a currency with a `symbol` of `SYMBOL` and a
|
||||||
|
* `decimals` of `2`, an amount of `12345` should be displayed as
|
||||||
|
* `123.45 SYMBOL`.
|
||||||
|
*
|
||||||
|
* If omitted, defaults to `0`.
|
||||||
|
*/
|
||||||
|
decimals?: number;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
/**
|
||||||
|
* A field keyed by timestamps to document the evolution of the field. Each
|
||||||
|
* 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()`.
|
||||||
|
*
|
||||||
|
* For example, to insert a new value:
|
||||||
|
* ```ts
|
||||||
|
* const result = { ...previousValue, [(new Date()).toISOString()]: newValue };
|
||||||
|
* ```
|
||||||
|
*/
|
||||||
|
export type RegistryTimestampKeyedValues<T> = {
|
||||||
|
[timestamp: number | string]: T;
|
||||||
|
};
|
||||||
|
|
||||||
|
/**
|
||||||
|
* A block height-keyed map of {@link ChainSnapshot}s documenting the evolution
|
||||||
|
* of a particular chain/network's identity. Like {@link IdentityHistory}, this
|
||||||
|
* structure allows wallets and other user interfaces to offer better
|
||||||
|
* experiences when a chain identity is rebranded, redenominated, or other
|
||||||
|
* important metadata is modified in a coordinated update.
|
||||||
|
*/
|
||||||
|
export type ChainHistory = RegistryTimestampKeyedValues<ChainSnapshot>;
|
||||||
|
|
||||||
|
/**
|
||||||
|
* A timestamp-keyed map of {@link IdentitySnapshot}s documenting
|
||||||
* the evolution of a particular identity. Typically, the current identity
|
* the evolution of a particular identity. Typically, the current identity
|
||||||
* information is the record at index `0`, but in cases where a planned
|
* information is the latest record when lexicographically sorted, but in cases
|
||||||
* migration has not yet begun (the snapshot's `time.begin` has not been
|
* where a planned migration has not yet begun (the snapshot's timestamp has not
|
||||||
* reached), the record at index `1` is considered the current identity.
|
* yet been reached), the immediately preceding record is considered the
|
||||||
|
* current identity.
|
||||||
*
|
*
|
||||||
* This strategy allows wallets and other user interfaces to offer better
|
* This strategy allows wallets and other user interfaces to offer better
|
||||||
* experiences when an identity is rebranded, a token redenominated, or other
|
* experiences when an identity is rebranded, a token redenominated, or other
|
||||||
* important metadata is modified in a coordinated update. For example, a wallet
|
* important metadata is modified in a coordinated update. For example, a wallet
|
||||||
* may warn token holders of a forthcoming rebranding of fungible tokens they
|
* may warn token holders of a forthcoming rebranding of fungible tokens they
|
||||||
* hold; after the change, the wallet may continue to offer prominent interface
|
* hold; after the change, the wallet may continue to offer prominent interface
|
||||||
* hints that the rebranded tokens was recently updated.
|
* hints that the rebranded token identity was recently updated.
|
||||||
*
|
*
|
||||||
* Note, only the `IdentitySnapshot`s at index `0` and `1` can be considered
|
* Note, only the latest two {@link IdentitySnapshot}s should be considered
|
||||||
* part of an identities "current" information (based on their `time` settings
|
* part of an identity's "current" information. E.g. even if two snapshots have
|
||||||
* in relation to current time). E.g. even if two snapshots have active,
|
* active, overlapping migration periods (i.e. an older snapshot's
|
||||||
* overlapping migration periods (i.e. the snapshot at `2` is still relevant for
|
* {@link IdentitySnapshot.migrated} timestamp has not yet been reached),
|
||||||
* the snapshot at `1`), clients should only attempt to display the migration
|
* clients should only attempt to display the migration from the previous to the
|
||||||
* from the snapshot at index `1` to that at index `0`.
|
* latest snapshot.
|
||||||
|
*
|
||||||
|
* If the current snapshot's {@link IdentitySnapshot.migrated} isn't specified,
|
||||||
|
* the snapshot's index is a precise time at which the snapshot takes effect and
|
||||||
|
* clients should begin using the new information. If `migrated` is specified,
|
||||||
|
* the snapshot's index is the timestamp at which the transition is considered
|
||||||
|
* to begin, see {@link IdentitySnapshot.migrated} for details.
|
||||||
|
*
|
||||||
|
* Each 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()`.
|
||||||
|
*
|
||||||
|
* In the case that an identity change occurs due to on-chain activity (e.g. an
|
||||||
|
* on-chain migration that is set to complete at a particular locktime value),
|
||||||
|
* registry-recorded timestamps reflect the real-world time at which the
|
||||||
|
* maintainer of the registry believes the on-chain activity to have actually
|
||||||
|
* occurred. Likewise, future-dated timestamps indicate a precise real-world
|
||||||
|
* time at which a snapshot is estimated to take effect, rather than the Median
|
||||||
|
* Time Past (BIP113) UNIX timestamp or another on-chain measurement of time.
|
||||||
*/
|
*/
|
||||||
export type IdentityHistory = IdentitySnapshot[];
|
export type IdentityHistory = RegistryTimestampKeyedValues<IdentitySnapshot>;
|
||||||
+1
-1
@@ -2,7 +2,7 @@
|
|||||||
"name": "chip-bcmr",
|
"name": "chip-bcmr",
|
||||||
"private": true,
|
"private": true,
|
||||||
"scripts": {
|
"scripts": {
|
||||||
"start": "ts-json-schema-generator --no-ref-encode --path 'bcmr-v1.schema.ts' --type 'Registry' > bcmr-v1.schema.json && prettier 'bcmr-v1.schema.json' --write"
|
"start": "ts-json-schema-generator --no-ref-encode --path 'bcmr-v2.schema.ts' --type 'Registry' > bcmr-v2.schema.json && prettier 'bcmr-v2.schema.json' --write"
|
||||||
},
|
},
|
||||||
"description": "This package provides package scripts to generate the Bitcoin Cash Metadata Registry JSON schema. To regenerate the schema, install the dependencies with 'npm install', then run 'npm start'.",
|
"description": "This package provides package scripts to generate the Bitcoin Cash Metadata Registry JSON schema. To regenerate the schema, install the dependencies with 'npm install', then run 'npm start'.",
|
||||||
"dependencies": {
|
"dependencies": {
|
||||||
|
|||||||
@@ -197,7 +197,7 @@ To avoid leaking connection information to registry hosts, clients may choose to
|
|||||||
|
|
||||||
### Metadata Registry JSON Schema
|
### Metadata Registry JSON Schema
|
||||||
|
|
||||||
Metadata registries conform to the [**Metadata Registry JSON Schema**](./registry.schema.json) ([source TypeScript type definitions](./registry.schema.ts)). The JSON schema is internally-documented, but notable features are discussed below.
|
Metadata registries conform to the [**Metadata Registry JSON Schema**](./bcmr-v2.schema.json) ([source TypeScript type definitions](./bcmr-v2.schema.ts)). The JSON schema is internally-documented, but notable features are discussed below.
|
||||||
|
|
||||||
#### Identities
|
#### Identities
|
||||||
|
|
||||||
@@ -213,13 +213,13 @@ All identity metadata is organized into **identity snapshots**, data structures
|
|||||||
|
|
||||||
Snapshots can include general information about the identity like `name`, `description`, [`tags`](#tags), and [`uris`](#uri-identifiers). For identities that represent token categories, snapshots can include the current `category`, display information like `symbol`, and `decimals`, and detailed technical metadata like parsing, encoding, and semantic information about various types of NFTs available within the token category.
|
Snapshots can include general information about the identity like `name`, `description`, [`tags`](#tags), and [`uris`](#uri-identifiers). For identities that represent token categories, snapshots can include the current `category`, display information like `symbol`, and `decimals`, and detailed technical metadata like parsing, encoding, and semantic information about various types of NFTs available within the token category.
|
||||||
|
|
||||||
At any moment in time, only one snapshot is considered "current" for an identity. However, using the `time.complete` property, a snapshot can indicate that the identity's prior snapshot remains relevant (e.g. an in-circulation token identity is gradually migrating to a new token category).
|
At any moment in time, only one snapshot is considered "current" for an identity. However, using the `IdentitySnapshot.migrated` property, a snapshot can indicate that the identity's prior snapshot remains relevant (e.g. an in-circulation token identity is gradually migrating to a new token category).
|
||||||
|
|
||||||
#### Identity History
|
#### Identity History
|
||||||
|
|
||||||
Each identity in a metadata registry is represented by an `IdentityHistory` data structure, an array of [`IdentitySnapshot`](#identitysnapshots)s ordered from newest (at index `0`) to oldest. `IdentityHistory` data structures allow clients to construct a timeline of the evolution of a particular identity, helping users recognize and disambiguate identities that have changed significantly since the user last interacted with that identity.
|
Each identity in a metadata registry is represented by an `IdentityHistory` data structure, a map of ISO timestamps to [`IdentitySnapshot`](#identitysnapshots)s. `IdentityHistory` data structures allow clients to construct a timeline of the evolution of a particular identity, helping users recognize and disambiguate identities that have changed significantly since the user last interacted with that identity.
|
||||||
|
|
||||||
Typically, the current identity information is the record at index `0`, but in cases where a [planned migration](#handling-identity-snapshot-migrations) has not yet begun (the snapshot's `time.begin` has not been reached), the record at index `1` is considered the current identity.
|
Typically, the current identity information is the latest record when the keys (timestamps) are lexicographically sorted, but in cases where a [planned migration](#handling-identity-snapshot-migrations) has not yet begun (the snapshot's timestamp has not been reached), the immediately preceding record is considered the current identity.
|
||||||
|
|
||||||
#### Tags
|
#### Tags
|
||||||
|
|
||||||
@@ -312,7 +312,7 @@ When the `locales` extension is configured, clients should use this localized re
|
|||||||
|
|
||||||
The `authchain` extension is standardized for `IdentitySnapshot`s. When provided, `authchain` reduces the work and data required for clients to [verify the metadata](#chain-verified-identities) of a particular identity.
|
The `authchain` extension is standardized for `IdentitySnapshot`s. When provided, `authchain` reduces the work and data required for clients to [verify the metadata](#chain-verified-identities) of a particular identity.
|
||||||
|
|
||||||
The `authchain` extension value must be an array of strings. The first string (index `0`) must be the hex-encoded [authbase transaction](#zeroth-descendant-transaction-chains) for the identity (the identity's authbase is this transaction's ID). Each subsequent string must be the next transaction in the authchain, and the final string must be the latest known [authhead transaction](#zeroth-descendant-transaction-chains) for the identity.
|
The `authchain` extension value must be an numerically-indexed object of strings, where all indexes are contiguous integers beginning with `0`. The first string (index `0`) must be the hex-encoded [authbase transaction](#zeroth-descendant-transaction-chains) for the identity (the identity's authbase is this transaction's ID). Each subsequent string must be the next transaction in the authchain, and the final string must be the latest known [authhead transaction](#zeroth-descendant-transaction-chains) for the identity.
|
||||||
|
|
||||||
Clients may use the `authchain` extension to rapidly update their records for a particular identity using the following validation algorithm:
|
Clients may use the `authchain` extension to rapidly update their records for a particular identity using the following validation algorithm:
|
||||||
|
|
||||||
@@ -353,11 +353,11 @@ If this validation fails, clients should either:
|
|||||||
|
|
||||||
#### Handling Identity Snapshot Migrations
|
#### Handling Identity Snapshot Migrations
|
||||||
|
|
||||||
Each `IdentitySnapshot` must indicate a `time.begin` at which the snapshot begins to take effect. If no `time.complete` is provided, the snapshot's migration is considered **instant**: the new information should be displayed immediately after the specified time has been reached. If `time.complete` is provided, the snapshot's migration is considered **gradual**: the migration period begins at `time.begin` and should be complete by `time.complete`. Clients are encouraged to surface both kinds of migrations to users.
|
Each `IdentitySnapshot` is assigned to a timestamp at which the snapshot began or will begin to take effect. If no `IdentitySnapshot.migrated` timestamp is provided, the snapshot's migration is considered **instant**: the new information should be displayed immediately after the assigned timestamp has been reached. If `IdentitySnapshot.migrated` is provided, the snapshot's migration is considered **gradual**: the migration period begins at the `IdentitySnapshot`'s initial timestamp and completes upon reaching the `IdentitySnapshot.migrated` timestamp. Clients are encouraged to surface both kinds of migrations to users.
|
||||||
|
|
||||||
**Where possible, clients should notify users about upcoming and recent migrations that impact in-use identities.**
|
**Where possible, clients should notify users about upcoming and recent migrations that impact in-use identities.**
|
||||||
|
|
||||||
Note that while it is technically possible for registries to encode two overlapping migrations, clients should only attempt to use information from the latest migration (between the snapshots at index `0` and `1`). When validating registries, `IdentityHistory`s with out-of-order snapshots (i.e. snapshots are not ordered by `time.begin` with the latest snapshot at index `0`) or overlapping migrations should be considered malformed, and clients may refuse to accept malformed registries.
|
Note that while it is technically possible for registries to encode two overlapping migrations, clients should only attempt to use information from the latest migration (between the latest and previous snapshots when timestamps are lexicographically sorted).
|
||||||
|
|
||||||
## Test Vectors
|
## Test Vectors
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user