add the FBCH-BATON utility NFT

[2qx]

New Listing: FBCH-BATON

• Identity Name: Future BCH Baton
• Authbase: fbc0b001313509454331f23f4b1891a8d9a284421efcc33187f1a1cdd37ccb46

Evidence Linking Authbase to Identity

• Select one:
  • Direct evidence: a chain-resolved registry at the authhead provides substantially equivalent metadata for this authbase. The Authhead TXID is provided below:
  • Indirect evidence: the identity is burned or provably locked within a covenant, so the authbase can safely be linked using indirect evidence. Details and two or more corroborating, third party-archived URLs of reputable sources vouching for this association are provided below:

Each statement below is linked to a transaction or contract on Georg Englemann's sickpig blockexplorer:

• A pre-genesis vanity transaction was grinded for with the OP_RETURN FBCH-4FJGyVzxb46zn8EWYrd
• The authbase fbc0b00... was used to generate a single minting NFT with the commitment 40420f00 (1e6)
• That minting baton was used to mint and send a mutable NFT with the same commitment to a "gantry" contract.
• The minting baton repeated the previous step but for the commitment values (LE): 100,000, 10,000 & 1,000 to three different contracts
• The minting Baton NFT was burned minting a mutable baton with the commitment (1000-LE) in the last transaction above.

Every claim above can be substantiated with the transactions in block 858,444

• The authhead is controlled by the million block FBCH vault gantry and currently lives in the unspent outputs of the last transaction from here and onward.

• The salemkode token page correctly shows that minting is not active, and lists all four mutable child NFT batons.

Evidence Linking Identity to Authbase

This signed message proves association of the authbase and this account.

2qx on github mined the vanity authbase fbc0b001313509454331f23f4b1891a8d9a284421efcc33187f1a1cdd37ccb46 with the op_return FBCH-4FJGyVzxb46zn8EWYrd

This is the above message signed using the cashaddres: qzvl56y0w65q7tj0mh7m2yspdjx7tmuqcqgw9j6lxz

IKxgrn+s2NUxDRZ3pdRN9cXKWWfsN4K6Y5ZV5CcyIfv4WwsaVK2Q4nIjt6LL8sd4PWRtpbZojJ9XOfXqEC23fTY=

This is the same message signed with 2qx#72497; 🦇 (qqad5sy4jml3f6vcp246dulsex04xp48wq23d35rqe)

H+Sq6GNri66xvTT7PFeerCddCWp5+IlU0WUqOoqh1l3wYDERBrF8NkqOoSJjncA4Kxm7PkvBgzBLEm3DmUS+gvA=

Archived URL(s):

Evidence Linking Authbase to Categories

• Select one:
  • Token category is equal to the authbase for all Identity Snapshots.
  • Evidence is provided for differing category values below:

Substantiation of Other Claims

• Select one:
  • The submission (esp. the description) includes no claims requiring substantiation.
  • The claims in this submission can be corroborated with the following evidence:

This is an Audit by Bitcoin Cash Autist @A60AB5450353F40E .

The audit touches lightly on the battery contract that controlled the minting baton.

Since the minting baton was successfully burned and the four mutable batons are now contract controlled, it would take a tremendous amount of chain-work to start minting new tokens.

This is an overview of the FBCH contracts that control the FBCH-BATONs.

This is an integration guide for using the batons to validate the issuance of other tokens, which is mirrored on a post on Bitcoin Cash Research.

The four (4) mutable "gantry" batons are enforced as the first input and output of each transaction. If they aren't impossible to remove from the gantry, they whole contract system an all associated tokens would be considered worthless.

Checklist

• I have reviewed the OpenTokenRegistry inclusion criteria, and this listing can be included in the registry.
• The listing completes all required fields:
  • name
    • Objective, authoritative, and neutral tone
    • No longer than 20 characters; exceptions may be allowed for existing legal names (please provide evidence above including the jurisdiction(s) in which the legal name is established).
  • description
    • Objective, authoritative, and neutral tone
    • Descriptions is appropriate for use in user interfaces without a disclaimer by unaffiliated, neutral, third parties (wallets, block explorers, exchanges, etc.); no exclamations, calls to action, or disputable statements.
    • All claims are substantiated above.
  • token information (if applicable)
    • Token category is defined.
    • If fungible tokens exist for the category, decimals is defined.
    • symbol
      • Globally-unique base symbol, including among assets not listed in OpenTokenRegistry.
      • Valid symbol (regular expression: /^[A-Z0-9]+[-A-Z0-9]*$/)
      • Appropriate minimum length (For new, primarily-fungible base symbols: minimum of 4 characters; non-fungible base symbols: minimum of 6 characters; see Symbol Length Recommendations)
      • No longer than 13 characters for base symbols
      • No longer than 26 characters for full symbols
  • uris.icon
    • Uses IPFS with a v1 CID. To convert a v0 CID (begins with Qm...), try dweb.link. For example, QmcNL1KcVmiDtwJe8WokrnzYeoHirsz1sNxNojncsxyb2p is a v0 CID. It can be viewed at https://dweb.link/ipfs/QmcNL1KcVmiDtwJe8WokrnzYeoHirsz1sNxNojncsxyb2p, which redirects to a subdomain equal to the v1 CID: https://bafybeigqogqx3n4cldk6nizl5vihopi2dkgvw4yqamc5rhleyqu25soe4e.ipfs.dweb.link/. The correct URI for this icon is: ipfs://bafybeigqogqx3n4cldk6nizl5vihopi2dkgvw4yqamc5rhleyqu25soe4e.
    • Either SVG format OR 400px by 400px AVIF, WebP, or PNG
  • uris.web
    • Domain name is owned by the issuing project or organization
    • Either HTTPS protocol OR ongoing activity demonstrated via optional URI identifiers (described in Substantiation of Other Claims)
  • Includes relevant historical information in previous snapshots OR this token has never been rebranded, redenominated, or reissued
  • All static data (images, animations, videos, binary files, etc.) uses IPFS with v1 CIDs to ensure file integrity (e.g. ipfs://ba...).

[georgedonnelly]

Hi, thanks for your PR!

• It looks like fbc0b001313509454331f23f4b1891a8d9a284421efcc33187f1a1cdd37ccb46 does not have any on-chain metadata. It's a good idea to have this.
• It's recommended to have a message in the website footer or at least in the frontpage footer taking ownership of the token and sharing its name, category, etc so users can easily verify authenticity via this informal manner.
• A more descriptive token name is a good idea.
• uri.icon is requested to be hosted on IPFS.
• token.nfts does not exist but this is an NFT series.

See more here: https://otr.cash/docs/list/

Thanks!

[2qx]

It looks like fbc0b001313509454331f23f4b1891a8d9a284421efcc33187f1a1cdd37ccb46 does not have any on-chain metadata. It's a good idea to have this.

The idea of having the contracts print metadata on-chain was explored, but there didn't seem to be much interest in that path.

There is metadata in the NFT commitment and it's used to emit an op_return message contractually. So the name of each series the baton is used to print is noted in the genesis transaction.

It's recommended to have a message in the website footer or at least in the frontpage footer taking ownership of the token and sharing its name, category, etc so users can easily verify authenticity via this informal manner.

Ideally, users will never have to know or interact with this token or category. Their wallet or app will automatically generate metadata for FBCH verifying the authenticity with this NFT Baton without the end-user ever having to know what it is.

User expectation at the moment is that CashTokens are collectible series of NFTs, or a pre-minted pool of Fungible Tokens, so moving the utility baton category id and information to the protocol page manages the expectation of people that would look to collect or trade the contract controlled utility baton.

A more descriptive token name is a good idea.

The names of the FBCH fungible series the batons mint go up to lock times of 4M so far, which localized is 9 characters. So with Future BCH as a base name, that works out to the 20 character limit exactly. The name Future BCH Baton is 16 characters.

uri.icon is requested to be hosted on IPFS.

The idea with the design of the icon is to render an image without hosting a file in perpetuity or the client having to make a network call.

The spaces in the SVG icon URI have been escaped with "%20", making the overall length now 367 characters, but technically more valid uri.

From a registry perspective, there is an obvious potential for abuse. But if it's an SVG under a certain length, what I'm seeing is that svg uris provide a much better, faster and more private user experience than using an IPFS gateway and pinning service.

These are non-collectable NFTs in this case, so the associated artwork is less important.

token.nfts does not exist but this is an NFT series.

The NFT entry has been updated to describe how the parseable bytecode is read and used, following the decentralized application example in the bcmr spec.

[2qx]

@bitjson I had originally wanted to add this NFT baton token so that it could appear on the salemkode explorer.

But the ability to add custom registries has been added there.

If token can't be added because the icon URI is data:image/svg+xml, should we go ahead and close this?