Crown Platform NFT Framework (Part 2)

Creation and use of NFT Protocols

In the first article I explained the basics of the Crown Platform NFT Framework and how to start using it. If you didn’t read it, it’s recommended to do that before going forward. Today we will discuss the generation of the NFT protocols.

Non-Fungible Token Use Cases

Before proceeding I would like to mention that non-fungible tokens are gaining more and more traction in the blockchain industry. Business owners and developers are building use cases to leverage this technology. The phrase “tokenisation of assets” became a topic of many discussions at blockchain conferences. Interest is growing because of all the possible ways the technology can be used to simplify peoples’ lives and move ownership from the hands of companies to the hands of their users. These are some use cases of how you can apply the Crown NFT Framework in:

• Highly secure supply chain applications, where the goods’ authenticity can be proven by the blockchain
• Crypto-collectibles games, for example Cryptokitties and Gods Unchained
• Different forms of certificates (ISO documents, academic credentials, etc.)
• Digital art
• Physical goods tokenisation. Property titles (houses, cars, etc.)
• Fractional ownership of physical objects
• Financial assets
• Tickets for events
• Software and hardware licensing
• Digital identity
• Proof of existence
• Limited editions of valuable data sets

Crown Cards example NFT use-case at https://crwcards.com

Crown Community Cards

A simple use-case built to demonstrate some of the capabilities CrownPlatform and NFT’s have to offer. Crwcards.com will offer the Crown community credit card sized plastic “NFC” enabled cards with unique designs by blockdesigns.net. The card holds a link (URL) and metadata (text). Once a card is scanned by a phone, for example the link is immediately activated and the phone is taken to the users own webpage on crwcards.com. The webpage shows each card and holder the user owns along with the metadata contained in the NFT associated with the card. The text or metadata on each card and holder is a direct copy of the NFT metadata and is written in JSON format for easy digital reading.

{   
   "CardDetails": {
     "Username": "defunctec",
     "WalletAddress": "tCRWakMb8VWWj7kMcoaSKo65yT9APo1B9yA7w",
     "Tier": "1",
     "CardHash":   "c68ec016e5b28f63cb3cd2d922e6bdace5906eab54bd615d6da4514ba216c733",
     "Version": "1",
     "CreationDate": "28/01/20",
     "Active": "true"
   } 
}
{
   "HolderDetails": {
     "Username": "defunctec",
     "WalletAddress": "tCRWakMb8VWWj7kMcoaSKo65yT9APo1B9yA7w",
     "Tier": "1",
     "HolderHash": "3dd3c016e5b28f63cb3cd2d922e6bdace5906eab54bd615d6da4514ba216c732",
     "Version": "1",
     "CreationDate": "28/01/20",
     "Active": "true"
   }
 }

Crwcards.com are currently researching and developing a mobile application to scan cards and holders to confirm they match with the NFT details fetched from the blockchain. The app will be simple, one swipe and the app will confirm with a green tick or a red cross.

Non-Fungible Token Protocols

As I pointed out in the previous article, when you register an NFT protocol you define a set of rules for your non-fungible tokens registry. They must comply with pre-defined rules during registration and other operations (transfer, update, delete). The NFT protocol rule set contains the list of properties defined below. In the future these rules will be extended to adapt to other developers’ needs:

Token Protocol Id
NF token protocol unique symbol/identifier, can be an a abbreviated name describing this NF token type. Represented as a base32 string, can only contain characters: .abcdefghijklmnopqrstuvwxyz12345. Minimum length 3 symbols, maximum length 12 symbols.

Token Protocol Name
Full name for this NF token type/protocol. Minimum length 3 symbols, maximum length 24 symbols.

Token Metadata Schema URI
URI to schema (json/xml/binary) describing metadata format.
Token Metadata Mime Type
MIME type describing metadata content type, default: "text/plain".
Is Token Transferable
Defines if this NF token type can be transferred. Default: true.
Is Metadata Embedded
Defines if metadata is embedded or contains a URI. It's recommended to use embedded metadata only if it's shorter than URI. Default: false.
NFT Registration Signature
Defines who must sign an NFT registration transaction. Possible values:
- Self-Sign. Signed by the new token owner
- Sign by the NFT protocol creator
- Sign by the NFT transaction fee payer
Maximum Metadata Size
Defines the maximum size of the NFT metadata. Default: 255. Absolute maximum size: 255.
Token Protocol Owner Address
Owner of the NF token protocol.

When you create an application that will use Crown non-fungible tokens, you should make some technical decisions first:

• Create a unique NFT protocol ID and and a readable protocol name.
• Define metadata mimetype, for example: application/json, text/plain, application/xml etc. Also define a metadata schema URI if needed. It should contain a schema of the chosen mimetype.
• Decide if you want to embed metadata on the blockchain or just to keep a URI to the metadata. It can be an IPFS URI for example. Usually it’s recommended to keep a URI, unless it’s longer than the metadata you want to save. Also, be aware that the longer metadata field will be — the higher fee you will have to pay for it.
• Decide if you want your NFTs to be transferable in the future.
• Define an algorithm of how your tokens will be generated. Each token ID must be a unique 256-bit number. It can be a random number, a counter, the result of a 256-bit hash function, a combination of these methods or something else that gives a unique outcome.
• One of the most important decisions you have to make is to choose the NFT Registration Signature type. This field will define who will have the authority to sign new NFT transactions of your protocol. There are always at least two signatures present in every NFT transaction. One signature is a part of standard transaction flow. That signature belongs to a private key that pays the transaction fee. The second one can be one of the three types explained below.

NFT Registration Signature Types

Sign by the NFT protocol creator — defines a rule where each NFT generated must be signed by the Token Protocol Owner Address that was registered in the protocol transaction. It creates a flow where the protocol creator can control the process of issuing new tokens. In the first article we compare Crown NFTs to the Ethereum NFTs. This type of transaction generation can be compared to the mintable ERC721 token contract. In this implementation there is a minter (or minters) who have authority to generate new tokens and assign ownership of them. This approach can be applied to many different use cases, mostly when you put some valuable assets on the blockchain, or your business logic requires ability to govern the assets generation. For example, think about the Cryptokitties collectible game. In this game you can create new kitties by minting and breeding them. It wouldn’t be much fun if you could mint or breed cats every second and everybody could gain ownership of millions of them. So there are some rules applied that won’t let you do that (check out this article if you want to find out more about how the game works). The same approach can be applied to the Crown Platform. The difference is that you will put your business logic on your application back-end, and simply define rules for the NFTs on the Crown blockchain. That logic and the rules will manage the way your tokens are generated including the mandatory signature of the protocol creator. Other use cases for such type of protocol could be: secure supply chain, proven form of certificates. physical goods tokenisation, financial assets registration, licensing, etc.

Self-Sign. The difference from the Sign by the NFT protocol creator is that an NFT must be signed by the key of the created token owner, instead of the protocol creator owner key. This approach will fit use cases where you as an application/protocol creator don’t have to approve each token generation. Of course, they still have to comply with all the protocol rules, otherwise a transaction will be rejected by the blockchain. Such a model can be applied to use cases where no approver is needed, like proof of existence of information, ownership and provenance of an artwork or similar entity, self-sign certificates, etc.

Sign by fee payer means that neither protocol owner signature nor NFT owner signature is required. A token can be generated and assigned by anybody to an arbitrary Crown address. This is the least constrained type. You can use it for the same use cases as the Self-Sign approach if your model fits into it, or something like a gift-cards application. You can also leverage it for other use cases listed above if you want to allow such type of tokens generation.

NFT protocol API

In the first article I explained how to use the nftoken APIs. In the next release you will also have access the nftproto APIs that manages creation and access to the NFT protocols:

nftproto register|list|get|getbytxid|ownerof

You can get the same list and details on each API using help nftproto or help nftproto <command> calls from the Crown wallet command line or crown-cli tool. To register a new NFT protocol you simply have to call the nftproto register API with the defined list of rules. They will manifest the technical and business decisions about your token application.

In Part 1 we introduced a crypto-collectibles game — CryptoKnights. It’s a game where you can own digital assets that represent unique knights. Every other instance has different properties based on the DNA generation algorithm, just like with the Ethereum Cryptokitties game. Now we’ll define a list of properties for our new NFT protocol:

• Protocol Id: ckt
• Protocol Name: CryptoKnights Collection
• Generate the NFT protocol owner address:
• NFT Registration Signature: Sign by the NFT protocol creator
• Metadata mimetype: application/json
• Metadata schema hosted at the URL: https://api.myjson.com/bins/16m4o2

{
    "title": "Asset Metadata (Ethereum compatible metadata)",
    "type": "object",
    "properties": {
        "name": {
            "type": "string",
            "description": "Identifies the asset to which this NFT represents"
        },
        "description": {
            "type": "string",
            "description": "Describes the asset to which this NFT represents"
        },
        "image": {
            "type": "string",
            "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
        }
    }
}

• The metadata will not be embedded, it will contain a link to the metadata URI
• Our token should be transferable
• The token generation process will be a result of the SHA256 hash function with the pre-image: concatenation of a unique number and the metadata itself

To register the protocol from the Crown command line you will make a call:

nftproto register ckt “CryptoKnights Collection” CRWKXU1RRRmizKf2J74XuZjYPxUzMd7QSsB4 2 “application/json” “https://api.myjson.com/bins/16m4o2" true false 255

As a result you will get a transaction ID: 127eca7233dc2d9130d88387f55d8931cab63935fd686935529896006217769a. To uniquely identify an NFT protocol you can use the protocol ID or the transaction ID. Now you can query information about protocol(s) using other nftproto APIs:

nftproto get ckt
result:
{
    "blockHash" : "b4f4c3d0c90afb13020be9afd86f8e523d013d2d35e2e81a4c11e97b82c466d4",
    "registrationTxHash" : "127eca7233dc2d9130d88387f55d8931cab63935fd686935529896006217769a",
    "height" : 570,
    "timestamp" : 1580224126,
    "nftProtocolId" : "ckt",
    "tokenProtocolName" : "CryptoKnights Collection",
    "tokenMetadataSchemaUri" : "https://api.myjson.com/bins/16m4o2",
    "tokenMetadataMimeType" : "application/json",
    "isTokenTransferable" : true,
    "isMetadataEmbedded" : false,
    "nftRegSign" : "SignByCreator",
    "maxMetadataSize" : 255,
    "tokenProtocolOwnerId" : "CRWKXU1RRRmizKf2J74XuZjYPxUzMd7QSsB4"
}
nftproto ownerof ckt
result:
CRWKXU1RRRmizKf2J74XuZjYPxUzMd7QSsB4
nftproto list
result:
{
    "blockHash" : "b4f4c3d0c90afb13020be9afd86f8e523d013d2d35e2e81a4c11e97b82c466d4",
    "registrationTxHash" : "127eca7233dc2d9130d88387f55d8931cab63935fd686935529896006217769a",
    "height" : 570,
    "timestamp" : 1580224126,
    "nftProtocolId" : "ckt",
    "tokenProtocolName" : "CryptoKnights Collection",
    "tokenMetadataSchemaUri" : "https://api.myjson.com/bins/16m4o2",
    "tokenMetadataMimeType" : "application/json",
    "isTokenTransferable" : true,
    "isMetadataEmbedded" : false,
    "nftRegSign" : "SignByCreator",
    "maxMetadataSize" : 255,
    "tokenProtocolOwnerId" : "CRWKXU1RRRmizKf2J74XuZjYPxUzMd7QSsB4"
}

The nftproto list is an API that will return you a list of existing NFTs based on provided arguments (use help nftproto list for the details). If you want to have a look at more interactive tutorials, feel free to watch these videos:

NFT Protocol Registration

NFT Reading API

Crown Platform Sandbox

I hope this article was useful and gave you an overview about the NFT Framework on the Crown Platform. We are eager to see what applications you will build on the Crown blockchain. Thank you for your attention!

The public testnet release build is available here.

Happy testing and coding!