Type alias ParsableNftCollection

ParsableNftCollection: {
    bytecode: string;
    types: {
        [bottomAltstackHex: string]: NftType;
    };
}

Interpretation information for a collection of parsable NFTs, a collection in which each NFT may include additional metadata fields beyond a sequential identifier within its on-chain commitment. Note that ParsableNftCollections differ from SequentialNftCollections in that parsable collections require a parsing bytecode with which to inspect each NFT commitment: the type of each NFT is indexed by the hex-encoded contents the bottom item on the altstack following the evaluation of the parsing bytecode.

Type declaration

  • bytecode: string

    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. If undefined, this NFT Category includes only sequential NFTs, with only an identifier and no NFT fields encoded in each NFT's on-chain commitment.

    The parse bytecode is evaluated by instantiating and partially verifying a standardized NFT parsing transaction:

    • version: 2
    • 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 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.

    For example: 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 identifier and the remaining segment of the commitment as the first NFT field value.

    If undefined (in a SequentialNftCollection), this field could be considered to have a default value of 00d26b (OP_0 OP_UTXOTOKENCOMMITMENT OP_TOALTSTACK), which takes the full contents of the commitment as a fixed type index. As such, each index of the NFT category's types maps a precise commitment value to the metadata for NFTs with that particular commitment. E.g. an NFT with an empty commitment (VM number 0) maps to types[''], a commitment of 01 (hex) maps to types['01'], etc. This pattern is used for collections of sequential NFTs.

  • types: {
        [bottomAltstackHex: string]: NftType;
    }

    A mapping of hex-encoded values to definitions of possible NFT types in this category.

    • [bottomAltstackHex: string]: NftType

      A definitions for each type of NFT within the token category. Parsable NFT types are indexed by the hex-encoded value of the bottom altstack item following evaluation of NftCategory.parse.bytecode. The remaining altstack items are mapped to NFT fields according to the fields property of the matching NFT type.

Generated using TypeDoc