Capturing Value on a Permissioned Blockchain, Trading it’s Value on a Public Blockchain

0 19


Shruti Kulkarni and Srihari Sardena

Context

VCs and Angel Investors invest in startups and SMEs, with a goal to achieve financial gains. The process of making an investment decision entails huge amount of auditing, scrutiny and verification due to the information asymmetry. This is a time consuming, resource intensive process with substantial transaction costs for both the investors seeking investment opportunities as well as startups/SME’s seeking fresh funds. Most of the startups have to deal with the following two challenges — (1) the early investors expect access to the latest information about the SME’s revenues and cash flows and liquidity/value unlocking on a continuous basis, (2) the private companies also have to deal with the challenge of authentic data and maintaining its confidentiality, leading to mistrust in the overall environment.

The proposed blockchain solution here aims to solve the above two mentioned problems by using a combination of a permissioned as well as a permissionless blockchain platforms. The use of a permissioned blockchain for maintaining the SME operations will ensure the privacy and security of their individual financial details, as it will be accessible only to the permissioned users. The use of public blockchain for tokenization of the cash flows from the SME will allow the investors to move their assets more freely. Since, the issuance of tokens in the public blockchain will be directly proportional to the profits coming from the SME cash flows, the investors will have a clear view of the business operations to make better investment decisions. This will also make the system tamper proof, and prevent fraudulent practices. Moreover, the use of public blockchain enables investors across the globe to find and invest in an idea they find interesting, even before the company goes public.

Goal

This use case has two main objectives — (1) Maintaining the financial transactions and cash flows of the company on a private blockchain (Hyperledger Fabric), thus bringing transparency to the Investor for ease of investment decision making and ownership, (2) Issuing tokens to the Investors backed by the profits coming from the cash flows of the SME, using a public blockchain (Ethereum).

High Level Approach

The high level functional approach for implementing this use is summarized below –

  • The SME and it’s Investors’ profiles will be maintained on Hyperledger Fabric.
  • For the initial setup, the company decides its initial token supply based on the cash flows and associated benchmark of a quarter which is stored in Fabric. The token issuance to the investors will be done based on their percentage shareholding on the Ethereum platform.
  • Subsequently, at a regular frequency (on a quarterly basis), the SME will keep uploading it’s cash flow statement, and the Fabric platform will record the details and make updates to the benchmark.
  • Based on the benchmark variation, the corresponding changes to the overall and investor specific tokens will be pushed to the Ethereum platform.
  • The Ethereum platform will maintain the changes in the number of tokens of the individual token owners and maintain investor wallets.
  • The investors can execute transactions (i.e., transfer, redemption of tokens, etc.) on the Ethereum platform.

Token Economics

  • At Token Issuance, the SME provides the initial cash flow of the quarter (CFi), along with the initial total supply of tokens (TSi) and the benchmark (BM) associated with it.
  • The tokens are distributed to the Investors (incl. founders) proportional to their existing equity % in the company
  • Every quarter, the SME will upload the cash flow document and the benchmark will be recalculated as follows –
  1. BM(new) = (BM(initial)/CFi) * (Cash flow of the current quarter)
  2. % variation in Benchmark = ((BM(new) — BM(initial))/BM(initial)) * 100
  • Based on the % variation in Benchmark, tokens will be burnt as per the following rules –
  1. If the benchmark variation is negative or is less than 50%, no tokens will be burnt
  2. If the benchmark variation is between 50% and 100%, 5% of the Initial Token Supply (TSi) of the tokens will be burnt.
  3. If the benchmark variation is > 100%, 10% of the TSi of tokens will be burnt.
  4. The tokens will be burnt, till the outstanding tokens will be 50% of TSi.
  5. When the SME goes public or is acquired, all the outstanding tokens will be burnt.

The SME specific tokens can be exchanged against an exchange-traded platform-specific security token (To be developed) and hence traded, leading to liquidity for the token owners.

Technical Architecture

The architecture of the platform can be defined in three layers (as shown above) –

  1. The Blockchain Network layer –

This layer consists of two blockchain networks –

  1. Hyperledger Fabric network (permissioned blockchain)
  • It is setup with 2 Orgs, and 4 peers nodes (2 peers in each Org). Each Org represents an SME.
  • Fabric CA is used for Identity Management. An SME user will be registered and enrolled in Fabric CA. This SME user can then add it’s Investor users in the system by registering and enrolling them in Fabric CA. There are two Fabric CAs configured for this platform, one associated with each Org.
  • Chaincodes are written in Golang for saving the SME cash flow document, and the benchmark variation details, along with other SME and Investor profile details. These chaincodes are installed and instantiated on all the peer nodes.

2. Ethereum network (public blockchain)

  • The SME and Investor wallets are created and maintained on the Ethereum Ropsten Network.
  • A Smart Contract written in Solidity and deployed on Ethereum contains the logic for token creation, issuance and distribution to Investors. The smart contract is based on the functionalities derived from ERC20, and will be extended to ERC777 and ERC1400 standards in future.

The ERC20 standard includes the following functions –

The additional functionalities of burn and minting tokens are implemented as follows –

The wallet addresses of the users and contract address of the token are stored in Fabric for reference and authentication purposes. The interaction between the two blockchains is achieved through RESTful web APIs that contain the business logic of the application.

2. The Business Logic(web app) Middle Layer –

This layer contains the web application code written in a RESTful microservices based architecture. The application is built with two microservices as follows –

  1. The microservice for Capturing the Company Value on Fabric –
  • This web application is built using Nodejs. It uses the fabric-node-sdk based REST APIs to communicate with the Fabric blockchain.
  • The fabric-client based APIs are used to register and enroll users in Fabric CA. Every time a user logs into the system, the fabric-client is used to check if the user is already registered and enrolled. On successful authentication, a JWT token is generated for the user that stays valid till the user session expires. This token is used as an authentication token for accessing any functionalities built upon Fabric.
  • This microservice contains functionalities for maintaining the SME and Investor Profiles in Fabric. Apart from this, it contains the main logic for maintaining the initial and periodic benchmark variation details, along with the details of the uploaded cashflow document in each quarter.
  • Cash flow Document Upload and Value Capture API – The SME user will upload the cash flow document for each quarter on the platform. For the initial setup, the initial benchmark will be taken as input from the user and stored in fabric along with other details from the document. The number of tokens to be allocated to each investor will be calculated and sent to the Ethereum API for transferring the tokens to individual investor wallets.
  • In subsequent quarters, a scheduler will read the contents of the document uploaded by the SME, will calculate the new benchmark( as described in the section Token Economics), and will store the details along with the document hash and it’s storage location in Fabric.
  • Based on the new benchmark, the number of tokens to be burnt are calculated for each investor and sent to the Ethereum APIs, along with the investors’ wallet addresses, where the tokens are burnt from each investor’s wallet.

2. The microservice for Tokenization of the Company Cash flows on Ethereum

  • This web application is built in Java using the Spring Boot framework. The Ethereum client library used for writing transaction code is Web3j. The Token Smart Contract is written in Solidity. The abi and bytecode generated after compiling the smart contract are used to convert the smart contract into Java Wrapper Classes using Web3j command –

/web3j solidity generate -b /path/Contract.bin -a /path/Contract.abi -o /destinationPath -p solidity.learning.contracts

  • The Wallet creation and storage API – This function creates the wallet for the users in Ethereum, and return the generated keys and wallet address as response. The wallet address is passed to the Nodejs Web API to be stored in Fabric. The generated keys are stored in a location on server.
  • The Token Creation and Distribution API – This function takes in the token name, symbol, token price, initial token supply as input from the user, and triggers the token smart contract that gets deployed on Ethereum. It returns the contract address in it’s response that is stored in fabric. The number of tokens to be transferred are sent from Fabric API as input to trigger the transfer of tokens from SME wallet to the Investor wallets.

3. The Front End Layer –

The UI and Front End of the application is built in Angular 7 and Material Design.

Implementation Approach Analysis

Some important points of analysing the approach of blockchain implementation of this use case are as follows –

  • Before finalizing the approach of using a private(Hyperledger Fabric) and public (Ethereum) blockchain, we had also considered using Hyperledger Burrow. But, the Burrow EVM does not serve the purpose of this use case, as we needed to create and maintain the Security Tokens on a public blockchain, in order to make the tokens available for exchange and liquidity.
  • We have used REST APIs to communicate between the Fabric and Ethereum networks. This is not a case of ledger interoperability, and there is no separate mechanism of authentication required for the flow of data between the two blockchains. We are storing the references of transaction on Ethereum(eg: wallet addresses, contract addresses) on Fabric, and these are used for sending transactions to Ethereum.
  • In order to implement a Security Token Contract, we needed to implement a token standard that can be extended to include advance functionalities in future. We have currently implemented the ERC20 token standard, and we plan to extend it to use the ERC777 standard (advanced standard for fungible tokens) and eventually to extend it to the ERC1400 Security Token Standard.

Future Roadmap

In order to utilize the larger scope of this use case, we intend to extend it’s functionalities in the next phase. Some changes in pipeline are as follows-

  • Set up and Issuance of a Platform token, which can be exchanged with any of the SME’s digital token and will be listed as a Security Token in one of the exchanges.
  • SMEs will be able to create their own scheduler for periodic cash flow document upload and benchmark calculation.
  • SMEs will be able to add metrics other than Quarterly Cashflows (e.g. No. of customers/users added per quarter, No. of stores opened per quarter etc) to back the tokens in the Fabric platform and will be able to use one or combination of these metrics.
  • With the addition of new Investors, the equity distribution and the token redistribution should change to reflect the new equity % of the investors.
  • Individual SMEs would be able to set up / configure the algorithm based on which the token distribution and redistribution will take place.

Authors

Srihari Sardena is a Senior Blockchain Developer at Intain. With prior experience in Java and J2EE, Srihari now works on development of Chaincodes (Smart Contracts) in Golang. He has expertise on working on Ethereum and writing smart contracts in Solidity. https://www.linkedin.com/in/srihari-sardena-a701b18b/

Shruti Kulkarni is Technical Architect — Blockchain at Intain, has expertise in backend development using Java, Nodejs and related technologies with both SQL and NoSQL databases. Currently, working on developing Blockchain solutions on Hyperledger Fabric using Golang(for Chaincodes/Smart Contracts), Java and Nodejs(Web App). www.linkedin.com/in/shrutihk

You might also like

Pin It on Pinterest

Share This

Share this post with your friends!

WhatsApp chat