Creating a useful NFT

Getting your Trinity Audio player ready...

This article was first published on Dr. Craig Wright’s blog, and we republished with permission from the author.

Download the relevant code as a ZIP/RAR file here.

The concept of a non-fungible token (NFT) has been used to create items associated with speculation and money laundering (Wilson et al., 2022). Yet, as I hope to demonstrate in this post, the same technology can significantly simplify the deployment of many existing applications, including in accounting and trade. In today’s example, we will go through some of the steps of creating a bill of lading (BoL) that links the identities of corporations to a series of invoices and uses NFTs to reference and trade the ownership certificates associated with goods and commodities.

In this example, LDAP is utilized to search and index the corporate names and the identity keys that are associated with them through a X.509 certificate signed by a certificate authority (CA). Note that we will start going through the example section by section, and as I do so, the code will be linked in files that can be downloaded. The images of the Google (NASDAQ: GOOGL) co-lab environment will connect to the source code. The various areas will require updating so the code can incorporate all the changes needed for the implementation in existing systems. Where necessary, it will be left to the person downloading the files to implement any other libraries used in the local application with which this is integrated.

Note that I have made multiple assumptions concerning any existing systems this will be run with. Likewise, accessing keys from LDAP servers and converting them to BSV addresses, using TXIDs for bill of lading numbers, etc., involves detailed knowledge of existing systems and complex cryptography operations, which must be customized based on the individual needs of the business implementing the solution.

From here, we need to consider the connection to the LDAP server. The connection can be made using a variety of authentication techniques, and may involve a username and password, as shown in the figure below (Code 2). Alternatively, a connection can be based on a digital certificate or token-based authentication methodology (Code 3).

Not all LDAP servers support certificate-based authentication using the Simple Authentication and Security Layer (SASL) External mechanism (Zeilenga & Melnikov, 2006), which makes the server determine the authorization identity based on the client’s presented certificate during a successful SSL/TLS handshake. Alternatively, other forms of certificate-based authentication may be utilised. For example, in a later post, I will demonstrate how to use a Bitcoin address as a tokenised form of authentication, which is beyond the scope of this post.

Creating NFTs for our goods

Non-fungible token (NFT) systems do not need to represent exchange items but can be a means of creating the product marketplace and item references that were referred to in the original release of Bitcoin under the marketplace. The bill of lading example provided (Code 4) is minted to an NFT (Code 5) that can be transferred as goods are moved or even if the goods are sold while in transit.

I will get around to documenting the other aspects of the NFT referenced. But first of all, I will note that we can create a simple transferable bill of lading token using the information that we are already talking about. Also, note that I am using a single sat and haven’t accounted for mining fees or other things that must be considered in a real-world implementation. The system would be minted by the individuals creating the goods, and the certificate of the goods acts as an ownership certificate that is transferred and minted into the bill of lading contract document.

With all of this information, we can now produce the ‘GoodNFT’ token that the manufacturer of goods will use to create a token application. It is important to note that for the from_nft method, I have used a mock utxo_from_nft function that returns a simulated unspent transaction output (UTXO). When you implement such a function in a real-world shipping application, you will replace it with your function that queries the UTXO set for a UTXO representing the NFT. In real-world coding, it will also be necessary to add error handling.

Note that the information used can be extended. I have created a simple set of definitions in data dictionaries that can go into more detail, including serial numbers, if required. The distributed hash table (DHT) link could also provide additional information that references the particular item. One area, such as marks and numbers, can be extended to include individual identifiers for each item. An example would be a value referencing a particular phone if multiple phones were sold.

Implementing tokens in salesforce

In this example, I’m not going into all the details of how to make a wallet. As I go through examples each week, the information I provide will gradually result in enough information to do each stage, but there is only so much one can do at once. Additionally, while I would like to see other methodologies, including key-value databases, we will now use widely accepted methods when accessing a Bitcoin (BSV) node, including libraries such as bsv or moneybutton/bsv.

There are many methodologies for getting transactions, so I will not address them in this post. I shall, in later posts, but for now, I will say it’s mainly a placeholder.

Next, we will start adding code to handle the signatures from each party involved in the bill of lading.

We can then start implementing the signing code.

For the next part, I will assume that we have already received a raw transaction saved as a binary file, transaction.bin. This is read as a byte vector and then parses the byte vector into a Bitcoin (BSV) transaction.

Overall, there are multiple steps involved in creating such a system. First, developing a system that monitors the network or engages in a simplified payment verification (SPV) exchange between individuals will be necessary. Then, over the coming weeks and months, there will be a document of a complete wallet solution that can be built using all of this. The idea here is to slowly teach you how to create a system that will mint a product from a producer and attribute an NFT ownership certificate against it. In doing so, I will start documenting how to create a proper SPV wallet application that can be used in accepting headers produced by the miners (aka nodes) on the network, and how it can be implemented with Bitcoin in creating real-world solutions.

One example we could derive from here is to take the file saved in “Code 10” and send it to an EDI application. But, like all coders, I’m lazy. Using the GoodNFT I have just designed, we will take the NFT information we have passed and send it to an EDI Ship Notice/Manifest document. For those who don’t know, the pyx12 library can be used to create an EDI 856 document. EDI has strict standards. So, it will be essential to ensure that when we create an EDI 856 document with the data from our GoodNFT, we map all the values correctly. Doing so would assume that the information from the source has been entered correctly and the manufacturer follows standards.

In the EDI 856 document example shown below, I’m assuming that the block timestamp and transaction details reference the time of the settlement in the transaction. I heard of an average settlement time of ten minutes for real-world applications. So, while individual transaction times could be linked to NTP, this is sufficient for what I’m providing for free.

This information allows us to create invoices and purchase orders within Salesforce (Code 12).

But, that is all I’m doing for tonight. So, to finish up, I will quickly explain a bill of lading and note the various requirements of such a document. Yet, as you may have guessed from the EDI section, it remains important to note that this is a complex area that requires specialist knowledge and more than just coding.

Explanations of a Bill of Lading

A bill of lading (B/L) is a legal document used in international trade to acknowledge the receipt of goods and provide details about the shipment. The standard fields commonly found in a bill of lading include the following:

1. Shipper: Information about the party or company that is shipping the goods.
2. Consignee: Information about the party or company that is receiving the goods.
3. Carrier: Information about the shipping carrier or transportation company responsible for transporting the goods.
4. Notify Party: Optional field to specify a third party to be notified about the arrival or status of the goods.
5. Port of Loading: The name of the port where the goods are loaded onto the vessel.
6. Port of Discharge: The name of the port where the goods will be unloaded from the vessel.
7. Vessel/Voyage: Details about the vessel name and voyage number identify the specific vessel and voyage on which the goods will be transported.
8. Bill of Lading Number: A unique identifier assigned to the Bill of Lading for reference and tracking purposes.
9. Description of Goods: A detailed description of the goods being shipped, including the type of goods, quantity, weight, packaging, and any special instructions or handling requirements.
10. Marks and Numbers: Unique markings or labels on the packaging or containers used to identify and track the goods.
11. Gross Weight/Net Weight: The total weight of the goods, including the weight of packaging (gross weight) and the weight of the goods alone (net weight).
12. Measurement: The dimensions or size of the shipment, including length, width, and height.
13. Freight Charges: Information about the freight charges associated with the shipment, including the currency and payment terms.
14. Incoterms: The International Commercial Terms (Incoterms) that specify the rights and responsibilities of the buyer and seller regarding the shipment and delivery of the goods.
15. Date of Shipment: The date when the goods are loaded onto the vessel.
16. Signature: Signatures of the authorized representatives from the shipper, carrier, and consignee, acknowledging their agreement to the terms and conditions of the Bill of Lading.

These are the commonly used fields in a Bill of Lading, but the exact format and lots may vary depending on the specific requirements of the shipping company or trade practices in different countries. Note that this blog post is not a definitive solution for all possible outcomes. Moreover, some of the areas in a goods description included in our GoodNFT may be extended to include the following:

1. Type of Goods: Specify the nature or type of goods being shipped, such as electronics, textiles, machinery, perishable goods, hazardous materials, etc. This information helps in determining appropriate handling and storage requirements.
2. Quantity: Indicate the quantity of goods being shipped. This could include the number of units, packages, pallets, or containers.
3. Weight: Provide the weight of the goods, which may include gross weight (total weight of the goods and packaging) and net weight (weight of the goods without packaging). It helps in determining transportation costs and ensuring compliance with weight restrictions.
4. Packaging: Describe the packaging used to contain the goods, such as cartons, drums, crates, or pallets. Mention any special packaging instructions if required.
5. Dimensions: If applicable, include the shipment’s measurements, such as length, width, and height. This information assists in space allocation and determining compatibility with transport equipment.
6. Marks and Numbers: Specify any unique marks, numbers, or labels associated with the packaging or containers. These markings identify and track the goods throughout the supply chain. In our example, we will gradually integrate them to allow for a global tracking system that traces logistics goods. But, this is only the first post.
7. Special Instructions: If there are any specific handling instructions or requirements for the goods, such as temperature control, ventilation, stacking limitations, or fragile handling, they should be mentioned clearly.
8. Harmonized System (HS) Codes: Include the appropriate HS codes that classify the goods based on internationally recognized coding systems. HS codes facilitate customs clearance and ensure accurate categorization of goods for regulatory and statistical purposes.

Also, note that I haven’t included any customs details, which would need to be completed in the final code.

Download the relevant code as a ZIP/RAR file here.

References
Wilson, K. B., Karg, A., & Ghaderi, H. (2022). Prospecting non-fungible tokens in the digital economy: Stakeholders and ecosystem, risk and opportunity. Business Horizons, 65(5), 657–670. Https://doi.org/10.1016/j.bushor.2021.10.007
Zeilenga, K., & Melnikov, A. (2006). Simple Authentication and Security Layer (SASL) (Request for Comments RFC 4422). Internet Engineering Task Force. https://doi.org/10.17487/RFC4422

Watch: Match Molly NFTs, what makes NFTs valuable? Opensource NFT Program