• Rob Brown

Smart contract types - Bill of Sale

This post describes several ways to use Bill of Sale smart contracts in the No-Code Toolkit.

Image credit: myxlaw.com

Bill of Sale smart contracts can be used in the nSymbol No-Code Toolkit to support secure, trusted sale transactions using blockchain technology. This post defines Bill of Sale as a general contract type and then provides examples of specific sub-types for vehicle and farm produce sales.

The No-Code Toolkit is part of the nSymbol Tag application. A related blog post explains how No-Code smart contracts work within Tag.

Bill of Sale type

As explained in the post linked-to above, smart contracts are described in Tag using types. Smart contract types combine several related resources:

  • Chaincode (program that runs on a blockchain network)

  • Data setup files (define data fields to gather when creating contracts)

  • Legal text (optional text version of contract for humans)

Sub-types provide a mechanism for customizing types. Smart contract sub-types reference a base type and only modify or extend what is necessary. Of particular importance is the ability to reuse chaincode created by nSymbol. Outside of Tag, this type of chaincode usually requires specialized training (and a big budget) to create.

The Bill of Sale type is very simple. It includes a buyer, seller, product or service, and price. The buyer and seller are identified using blockchain addresses so that funds can be securely transferred over the network. The price is in US$ to maximize applicability.

Variations in this structure are easily supported by creating different sub-types. For example, price could be specified using ETH tokens for use on the Ethereum blockchain, or legal names for buyer and seller could also be included. This post only considers a few of the simplest examples.

The data fields used to represent the Bill of Sale type are as follows:

The chaincode used by the Bill of Sale type is also simple. All four fields are provided when the contract is created. Conversion of price into blockchain tokens (e.g. ETH) happens at creation time. Both buyer and seller must "sign" the contract (by clicking a button) for it to close and transfer funds. Sufficient funds must be provided when the buyer signs, and either party can cancel the transaction at any time.

For simple transactions the above smart contract will be enough. In other situations more data is needed as discussed below. Note that the more specific sub-types described below use the same chaincode as the Bill of Sale type. This means new chaincode does not have to be developed and tested which keeps cost and effort down. This also nicely illustrates a core value proposition of the No-Code approach.

Vehicle Bill of Sale sub-type

When selling a car additional information is usually required to comply with local government regulations. For example, most jurisdictions require legal names for the buyer and seller along with make, model and Vehicle Identification Number (VIN).

The Vehicle Bill of Sale sub-type references (or extends) the generic Bill of Sale type and adds another data setup file for vehicle data. The vehicle data fields gathered are as follows:

The Vehicle Bill of Sale sub-type uses the same chaincode as the generic Bill of Sale type. The same basic terms of exchange make sense as long as more data is gathered. The vehicle sub-type also defines more specific legal text which merges in vehicle data.

The is one additional requirement that may need to be considered. Some US states require a notary public stamp on a vehicle bill of sale. For sales in these states the legal text can be printed off and signed in the presence of a notary agent. An image can be taken of the legal contract with a notary stamp and attached to the smart contract along with other files.

Another way to address the notary requirement is to leverage blockchain technology once again. In particular, blockchain records are often used to fulfill a notary service. This could be implemented several different ways (e.g. using a smart contract or a dedicated notary service), but whichever approach is used must be considered acceptable by the local regulatory agency. The next section discusses blockchain notary services further.

Farm Produce Bill of Sale sub-type

Farm produce blockchain sales can be supported in a similar way to vehicle sales. Create a sub-type of Bill of Sale that stores produce-related data and more specific legal text. The requirements are a bit more challenging because there are a wide variety of products, many with specific data fields of interest, that are considered farm produce.

A variety of products or services is usually represented using a taxonomy or other form of machine-readable labeling system. For products and services, the best choice usually starts with schema.org, which is a consortium (backed by Google and Microsoft) to put names on all things that people search for.

In the schema.org world, detailed product codes are delegated to the Global Trade Item Number (GTIN) system. The GS1 consortium (creator of GTIN) is 40 years old and is responsible for UPC bar codes among other things. The GTIN is used exclusively within bar codes, but can also be used for other purposes.

This example uses cucumbers as a specific farm produce item. Under the GTIN system, there are four categories of cucumbers that can be identified:

Assuming that these categories are sufficient for the desired transactions, the data fields collected for a Farm Produce Bill of Sale are:

Staying with the example of cucumbers, the forms used to gather data for these smart contracts can be pre-loaded with the four categories of cucumbers listed above. Other types of farm produce can be supported simply by changing how pick lists in the form are pre-loaded with product categories.

A quantity and price-per-item is also stored to reflect how cucumber sales typically occur. If both values are provided when the contract is created, the total price stored in Bill of Sale data fields can be calculated. Note that this is only an example, and other sequences of gathering data can be used.

There is one other potential addition to this example related to notary services. When farm produce is grown in accordance with certain guidelines, it can receive an organic certification. In the US produce can be USDA certified organic with similar designations in other countries. Since organic produce can fetch a higher price, this would be useful information to capture in this example.

As with vehicle sales, there are several options to prove organic certification. One option is to take a picture of an official certificate that clearly shows the vendor's name and address. Another option is to use a blockchain notary service which is already on the radar for the USDA National Organic Program and other regulatory agencies around the world.


This post discusses how smart contract types work within the No-Code Toolkit. In particular, it explains how the same smart contract chaincode can be used to support multiple, similar smart contract types. Feel free to contact us with suggestions for other smart contract types or examples of user groups who might benefit from this approach.


© 2020 by nSymbol Technology Inc.