Type alias NftCategoryField

NftCategoryField: {
    [identifier: string]: {
        description?: string;
        encoding: {
            type: "binary" | "boolean" | "hex" | "https-url" | "ipfs-cid" | "utf8" | "locktime";
        } | {
            aggregate?: "add";
            decimals?: number;
            type: "number";
            unit?: string;
        };
        extensions?: Extensions;
        name?: string;
        uris?: URIs;
    };
}

A definition specifying a field that can be encoded in non-fungible tokens of a token category.

Type declaration

  • [identifier: string]: {
        description?: string;
        encoding: {
            type: "binary" | "boolean" | "hex" | "https-url" | "ipfs-cid" | "utf8" | "locktime";
        } | {
            aggregate?: "add";
            decimals?: number;
            type: "number";
            unit?: string;
        };
        extensions?: Extensions;
        name?: string;
        uris?: URIs;
    }
    • Optional description?: string

      A string describing how this identity uses NFTs (for use in user interfaces). Descriptions longer than 160 characters may be elided in some interfaces.

      E.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.
    • encoding: {
          type: "binary" | "boolean" | "hex" | "https-url" | "ipfs-cid" | "utf8" | "locktime";
      } | {
          aggregate?: "add";
          decimals?: number;
          type: "number";
          unit?: string;
      }

      The expected encoding of this field when read from the parsing altstack (see ParsableNftCollection). All encoding definitions must have a type, and some encoding definitions allow for additional hinting about display strategies in clients.

      Encoding types may be set to binary, boolean, hex, number, or utf8:

      • binary types should be displayed as binary literals (e.g. 0b0101)
      • boolean types should be displayed as true if exactly 0x01 or false if exactly 0x00. If a boolean value does not match one of these values, clients should represent the NFT as unable to be parsed (e.g. simply display the full commitment).
      • hex types should be displayed as hex literals (e.g.0xabcd).
      • https-url types are percent encoded with the https:// prefix omitted; they may be displayed as URIs or as activatable links.
      • ipfs-cid types are binary-encoded IPFS Content Identifiers; they may be displayed as URIs or as activatable links.
      • locktime types are OP_TXLOCKTIME results: integers 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. (Note, sequence age is not currently supported.)
      • number types should be displayed according the their configured decimals and unit values.
      • utf8 types should be displayed as utf8 strings.
    • Optional extensions?: Extensions

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

    • Optional name?: string

      The name of this field for use in interfaces. Names longer than 20 characters may be elided in some interfaces.

      E.g.:

      • BCH Pledged
      • Tokens Sold
      • Settlement Locktime
      • Seat Number,
      • IPFS Content Identifier
      • HTTPS URL
    • Optional uris?: URIs

      A mapping of identifiers to URIs associated with this NFT field. 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.

Generated using TypeDoc