Industry 4.0: Smart Contracts for the Manufacturing Industry

For indu4.0, blokk has designed and coded two smart contracts with the goal to help them solve existing problems in the manufacturing industry.
Michael Schranz
Michael Schranz
February 3rd, 2023

For indu4.0 a start-up based in Zug (Switzerland) blokk has designed and coded two smart contracts with the goal to help them solve existing problems in the manufacturing industry. You can find more details about the indu4.0 start-up and the job we have done for them on our case presentation

In this blogpost we will elaborate on the two smart contracts - ERC-20 and ERC-721 - that we have coded for indu4.0. You will read about the use cases of these two smart contracts in the context of the manufacturing industry. You will get some insights into the specifications of the smart contracts and learn about critical aspects and terminology associated with them. 

INDU token - ERC-20 - nature and utility of this security token

ERC-20 is the main technical standard for smart contracts used to implement fungible tokens in the Ethereum blockchain. The ERC-20 tokens which we developed for indu4.0 can be thought of as chips that grant their respective owners access to participate in a digital ecosystem like indu4.0. The INDU token is designed to give indu4.0 customers access to exclusive services and pay for them. 

The following services have been established with this ERC-20 token: 

  • Access to services: INDU - the project's own native cryptocurrency - gives customers access to various services and makes payment transactions more secure. 

  • Access to marketplace: The indu4.0 platform makes it easy for buyers and suppliers to find qualified partners. The sophisticated filtering system provides fast and accurate results.

  • Access virtual trade fairs in the Metaverse: Virtual trade fairs in the Metaverse will make it possible to participate in events from anywhere in the world and, for example, to attend presentations of new machines and products in a 3D showroom.

  • Loyalty program: By actively using the platform, customers are rewarded with INDU tokens.

After a first meetup with the founders of this start-up we defined the following development specifications for this ERC-20 smart contract.

ERC-20 smart contract specifications for the INDU token

  • Symbol: INDU

  • Name: indu4.0

  • Token Standard: ERC-20 Standard

  • EVM Chain: ETH Mainnet, Fantom

  • Later the INDU token should be available on different chains (multichain). Our approach is to always deploy the same smart contract and lock away the tokens accordingly.

  • Deployment on Ethereum L1 and extend later on further EVM-compatible sidechains and / or Layer 2 (L2) solutions. 

  • In the current stage, the root token contract must first be deployed on Ethereum before it can be deployed / bridged to L2 solutions such as Arbitrum or else.

  • Development environment: Hardhat & TypeScript

  • Git Platform: Private GitLab repository

  • Libraries: OpenZeppelin

  • Deliverable: Fully-fledged Hardhat repository including smart contract code, testnet deployment & unit tests with 100% code coverage (no code fuzzing nor symbolic execution tests).

  • Tokenomics: Fixed percentage-based token number at the beginning of the entire supply: e.g. 750'000'000 (i.e. minting at contract creation time).

  • Mintability through the access control role owner must be enabled.

  • Permit function for Meta-Transactions

  • NOT to be included: No burnability, no votes, no timelock, no flash minting, no snapshot, no pausability, no upgradability (check explanations of these terms at the end of this blogpost)

Code snippet of this INDU token - ERC-20 smart contract 

Below you can see a code snippet of the created ERC-20 smart contract. The language used to write this code is solidity.

```sol
// SPDX-License-Identifier: MIT
pragma solidity 0.8.17;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/draft-ERC20Permit.sol";

/**
 * @title indu4.0 ERC-20 Smart Contract
 * @author indu4.0 AG <token@indu40.io>
 * @notice The INDU token serves as a payment token for usage
 * and advertising on the indu4.0 platform.
 * @dev You can cut out 10 opcodes in the creation-time EVM bytecode
 * if you declare a constructor `payable`. For more in-depth information
 * see here: https://forum.openzeppelin.com/t/a-collection-of-gas-optimisation-tricks/19966/5.
 * @custom:security-contact Kay Baur <security@indu40.com>
 */
contract Indu40 is ERC20, ERC20Burnable, Ownable, ERC20Permit {
    /**
     * @dev Constructor for the deployment without any premint.
     */
    // constructor() payable ERC20("indu4.0", "INDU") ERC20Permit("indu4.0") {}

    /**
     * @dev Creates an initial amount of INDU tokens for the deployer.
     */
    constructor() payable ERC20("indu4.0", "INDU") ERC20Permit("indu4.0") {
        _mint(msg.sender, 750000000 * 10 ** decimals());
    }

    function mint(address to, uint256 amount) public onlyOwner {
        _mint(to, amount);
    }
}

```

NFT solution with ERC-721 - application and benefits

ERC-721 is a standard for NFTs (Non-Fungible Token). In other words, this type of token is unique and can have a different value than another token of the same smart contract. All NFTs have a uint256 variable called TokenId and for each ERC-721 contract, the pair of contact addresses and uint256 TokenId must be globally unique. This is exactly why this standard is optimal for the case of indu4.0: Blockchain technology is used to protect copyrights of drawings, plans and ideas that can be shared via the indu4.0 platform. 

The main reason to create this NFT solution and the associated service is the possibility to securely transfer and store documents, and at the same time provide a proof of ownership for clients of indu4.0. You can find more details about the development of this ERC-721 contract below.  

ERC-721 Smart Contract Specifications for indu4.0

  • Name: indu4.0 Data Security

  • Symbol: IDS

  • Token Standard: https://eips.ethereum.org/EIPS/eip-721

  • EVM Chain: ETH Mainnet, Fantom - possible Polygon( TBD)

  • Deployment on Ethereum L1 and extend later on further EVM-compatible sidechains and/or L2 solutions. In the current stage, the root token contract must be first deployed on Ethereum before they can be deployed/bridged to L2 solutions such as Arbitrum.

  • Base URI: https://ids.indu40.com

  • Structure of complete URL: https://ids.indu40.com/SHA256HASH

  • Mintability through access control role owner should be enabled.

  • NOT to be included: No burnability, no votes, no timelock, no flash minting, no snapshot, no pausability, no upgradability.    

  • Development environment: Hardhat & TypeScript

  • Git Platform: Private GitLab repository

  • Libraries: OpenZeppelin

  • Deliverable: Fully-fledged Hardhat repository including smart contract code, testnet deployment & unit tests with 100% code coverage (no code fuzzing nor symbolic execution tests will be run).

Code snippet of ERC-721 smart contract

Below you can see a code snippet of the created ERC-721 smart contract.  

```sol
// SPDX-License-Identifier: MIT
pragma solidity 0.8.17;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/utils/Counters.sol";

/**
 * @title indu4.0 Data Security ERC-721 Smart Contract
 * @author indu4.0 AG <token@indu40.io>
 * @notice The IDS non-fungible tokens are used to digitally
 * safeguard documents and drawings on the blockchain.
 * @dev You can cut out 10 opcodes in the creation-time EVM bytecode
 * if you declare a constructor `payable`. For more in-depth information
 * see here: https://forum.openzeppelin.com/t/a-collection-of-gas-optimisation-tricks/19966/5.
 * @custom:security-contact Kay Baur <security@indu40.com>
 */
contract Indu40DataSecurity is
    ERC721,
    ERC721URIStorage,
    ERC721Burnable,
    Ownable
{
    using Counters for Counters.Counter;

    Counters.Counter private _tokenIdCounter;

    constructor() payable ERC721("indu4.0 Data Security", "IDS") {}

    function _baseURI() internal pure override returns (string memory) {
        return "https://ids.indu40.com/ids/";
    }

    function safeMint(address to, string memory uri) public onlyOwner {
        uint256 tokenId = _tokenIdCounter.current();
        _tokenIdCounter.increment();
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
    }

    /**
     * @dev The following functions are overrides required by Solidity.
     * More details on why this is necessary can be found here:
     * https://forum.openzeppelin.com/t/the-following-functions-are-overrides-required-by-solidity/20104/4.
     */
    function _burn(
        uint256 tokenId
    ) internal override(ERC721, ERC721URIStorage) {
        super._burn(tokenId);
    }

    function tokenURI(
        uint256 tokenId
    ) public view override(ERC721, ERC721URIStorage) returns (string memory) {
        return super.tokenURI(tokenId);
    }
}

```

Essential terminology for the indu4.0 smart contract specifications explained

Since we assume that certain terms in connection with blockchain or smart contracts are not part of everyone's general knowledge and vocabulary, we explain the most important terms around blockchain and web3 development in our glossary

If you plan to create a smart contract it is helpful to know what kind of options you have to shape it the way you need it and add the functions that increase value in your context of use. As an example: For the indu4.0 ERC-20 smart contract, we defined the following:

  • Mintable: The owner account can create tokens up to the theoretical limit of 2^256-1 (maximum value for a uint256 type before it overflows or reverts). A premint functionality is built in, e.g. x-amount of tokens are minted to the deployer's address at construction time (i.e. when the smart contract is deployed).

  • Burnable: An ERC20 extension that allows token holders to destroy both their own tokens and those that they have an allowance for, in a way that can be recognised off-chain (via event analysis). The total token supply is decreased accordingly. Burning in this context means that the token is sent to the address 0x0 for which nobody has the private key.

  • Permit: Implementation of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in EIP-2612. Simply put, with this functionality token holders will be able to allow third parties to transfer from their account without paying gas. Or in other words, it allows for gasless transactions aka so-called meta-transactions.

  • Ownable: A simple mechanism with a single account authorised for all privileged actions. In this context, the only privileged action is related to the mint function.

In our blockchain and web3 glossary we explained additional features that can be implemented in smart contracts (beside others): 

Concluding remarks on smart contracts and links to more use cases and blockchain knowledge

As this example of indu4.0 shows, smart contracts are a very important aspect for the technical implementation of platforms and applications developed with blockchain technology. Highest code quality and maximum security in the implementation of smart contracts are therefore essential. Through smart contracts, all or parts of an agreement are automatically executed and stored on a blockchain-based platform as soon as the criteria defined in the code are met. Errors and loopholes can accordingly have fatal consequences. 

Other client projects where the blokk team coded smart contracts to implement the needed functionality:

indu4.0 who uses distributed ledger technologies (DLT) with the objective to solve existing problems in the manufacturing industry, demonstrates a pretty exotic approach of how digital transformation can take place in the manufacturing industry. There are more obvious boosters of the so called “industry 4.0” such as IoT (internet of things), big data analytics, machine learning, augmented and virtual reality. It would not be realistic to claim that DLT will be the main driver for the next industrial revolution but we think that many more web3 and DLT applications will be introduced to test and validate the value of blockchain technology in order to foster product innovation and digital transformation in general. If you are eager to read more details about Ethereum ERC-20 Meta-Transactions, just click on that link and jump to this blogpost, written by our Blockchain Engineer and White Hat Hacker, Pascal Marco Caversaccio.