The following are examples of the use of blockchain in specific contexts designed and proposed by Eqnon. Each use case starts with a background and problem description, followed by an extract of characteristics that might suggest the use of blockchain after which a design solution is proposed on the application, network and protocol level.
Crowdlending
People in underdeveloped markets have limited access to formal lending facilities, especially when they do not have a basic, stable income or cannot show a credit history. The use case described here is a blockchain-based platform where anyone can request or offer a loan. The maximum loan amount is determined by the borrower’s credit history or a set amount determined by the country’s GDP per capita if the borrower does not have a credit history yet. The borrower’s credit score is determined by his credit history and lenders (individuals or organisations) can offer a loan that is structured in a way preferred by the lender. Payments and repayments are made in digital currency using a smart contract that automatically updates the borrower’s credit score based on timing and amount of repayments. Digital currency may be exchanged for local currency using entities that can facilitate crypto-fiat currency exchanges. This type of crowdlending gives anyone unbanked in the world the chance to start lending with a very small amount and get access to increasingly larger loans if he can prove ability in repayments. Furthermore, this platform allows anyone in the world to trustfully lend to anyone in the world without using intermediaries. A token may be introduced to allow lenders to sell their anonymized credit data to entities that use the data for research or commercial purposes.
Characteristics relevant for blockchain
Various elements of the system may suggest the use of blockchain: automation of recurring transactions representing a unit of value that should be immutable as well as agreed upon and available to relevant parties.
Design of Solution
Protocol layer
As anyone should be able to lend to or borrow from anyone in the world the platform should use a blockchain that is public. There is no need to use the blockchain only within a private setting regulated by a centralized organisation, that is only accessible to entities that have been approved by the controlling organisation as this would limit the decentralized character of the platform and the scalability of the platform.
As billions of people still do not have access to formal lending, the platform needs to allow for billions of transactions a month or millions of transactions per day. All these transactions need to be recorded in real time and the smart contract to upgrade the credit score needs to run each time a transaction occurs. At this point in time it is uncertain whether existing protocols can handle these requirements regarding the number of transactions per second.
The smart contract is initially programmed by the developers of the platform, but any updates may be voted for by the entities that run a node. The voting system ensures the platform to be supported by the users as much as possible, which in turn will speed up growth of the platform.
Network layer
Nodes can be run by anyone to increase adoption and decentralization, but any majority hold by borrowers (or lenders) should be prevented to avoid that credit scores can be tampered with: a majority of either borrowers or lenders could lead to voting outcomes being biased and unfairly affect the counter lending party. All nodes have read access, but only nodes run by lenders have the ability to append transactions to the blockchain.
Organisations that use the platform and have dedicated IT systems for registering and tracking loans may need to integrate their systems with the blockchain if they want to interact with the blockchain in a fully automated way. An interface between their systems and the blockchain could allow for easy capturing of data from the blockchain into their systems and vice versa (i.e. appending transactions to the blockchain).
Energy consumption and data storage requirements of the platform are minimized to maximize speed and adaption of the platform. A node is selected for appending based on the number of stakes rather than being the first to solve a complex mathematical puzzle that requires a lot of energy. Furthermore, only a few data elements need to be registered (such as details about counterparty and loan status) and the calculation of the credit score is based on a straightforward algorithm.
As the platform will be rolled out on a global scale further study needs to be undertaken to find out the more specific data usage, archival and storage requirements in each jurisdiction.
Application layer
The primary users of the platform are the lenders and the borrowers. Both parties of a loan agreement (i.e. the borrower and lender) need to be able to see the loan agreement as well as the lender’s credit history, credit scoring and outstanding payments of the loan. In addition to that, the platform should facilitate a process that can match a borrower and lender by accepting a loan request from a lender, broadcasting the request to lenders, placing loan offers from lenders, setting up a smart contract based loan agreement and digital signing of the agreement. As many lenders are likely to use the platform on a smart phone in areas with limited internet (and electricity) connection, the platform should be designed to work well on smart phones, both on-line and off-line, with minimal energy consumption. Secondary users are entities that seek to access anonymized credit data of lenders for research or commercial purposes. A token is introduced so that lenders can sell their data to these secondary users.
Lenders might value the opportunity to get in touch directly with potential borrowers to further assess the borrower before signing a loan agreement, to track progress during the loan period and to personalize the microlending experience (e.g. an individual can now donate to a microfinance institution knowing to whom the money is going or lend directly to the end-borrower without intermediation of a microfinance institution).
Characteristics relevant for blockchain
Various elements of the system may suggest the use of blockchain: automation of recurring transactions representing a unit of value that should be immutable as well as agreed upon and available to relevant parties.
- A user applies for a loan, the request is broadcasted to loan providers who may bid to offer a loan. The user selects his preferred bid and a smart contract based agreement is produced. Each time a repayment is done the credit score is updated. The cycle repeats if the user decides to apply for another loan.
- A loan cycle consists of a loan payment period after which repayments are scheduled to take place in regular time intervals. A loan cycle is repeated each time the user reaches an agreement with a loan provider for a new loan.
- The main stakeholders are the user and loan providers, i.e. any individual or organization that wishes to offer a loan. Other stakeholders are entities that can exchange digital money for local currency or mobile money and entities that use the anonymized credit data for research purposes.
- In traditional lending institutions the loan matching, offering, processing, paying, tracking and closing is done by the institution itself or an entity to which the back office is being outsourced.
- The value transferred is the loan principle payment to the lender and the repayment of the principle and interest to the borrower. In addition, third parties can buy tokens to get access to the anonymized credit data and the revenues of these tokens will go to the borrowers. Part of the value transferred will be diverted to platform developers.
- Once (re)payments are confirmed by the receiving parties then credit scoring should be automated using smart contracts and immutable, which will optimize trust in the creditworthiness of the borrower, an important requirement to attract investors to the platform.
Design of Solution
Protocol layer
As anyone should be able to lend to or borrow from anyone in the world the platform should use a blockchain that is public. There is no need to use the blockchain only within a private setting regulated by a centralized organisation, that is only accessible to entities that have been approved by the controlling organisation as this would limit the decentralized character of the platform and the scalability of the platform.
As billions of people still do not have access to formal lending, the platform needs to allow for billions of transactions a month or millions of transactions per day. All these transactions need to be recorded in real time and the smart contract to upgrade the credit score needs to run each time a transaction occurs. At this point in time it is uncertain whether existing protocols can handle these requirements regarding the number of transactions per second.
The smart contract is initially programmed by the developers of the platform, but any updates may be voted for by the entities that run a node. The voting system ensures the platform to be supported by the users as much as possible, which in turn will speed up growth of the platform.
Network layer
Nodes can be run by anyone to increase adoption and decentralization, but any majority hold by borrowers (or lenders) should be prevented to avoid that credit scores can be tampered with: a majority of either borrowers or lenders could lead to voting outcomes being biased and unfairly affect the counter lending party. All nodes have read access, but only nodes run by lenders have the ability to append transactions to the blockchain.
Organisations that use the platform and have dedicated IT systems for registering and tracking loans may need to integrate their systems with the blockchain if they want to interact with the blockchain in a fully automated way. An interface between their systems and the blockchain could allow for easy capturing of data from the blockchain into their systems and vice versa (i.e. appending transactions to the blockchain).
Energy consumption and data storage requirements of the platform are minimized to maximize speed and adaption of the platform. A node is selected for appending based on the number of stakes rather than being the first to solve a complex mathematical puzzle that requires a lot of energy. Furthermore, only a few data elements need to be registered (such as details about counterparty and loan status) and the calculation of the credit score is based on a straightforward algorithm.
As the platform will be rolled out on a global scale further study needs to be undertaken to find out the more specific data usage, archival and storage requirements in each jurisdiction.
Application layer
The primary users of the platform are the lenders and the borrowers. Both parties of a loan agreement (i.e. the borrower and lender) need to be able to see the loan agreement as well as the lender’s credit history, credit scoring and outstanding payments of the loan. In addition to that, the platform should facilitate a process that can match a borrower and lender by accepting a loan request from a lender, broadcasting the request to lenders, placing loan offers from lenders, setting up a smart contract based loan agreement and digital signing of the agreement. As many lenders are likely to use the platform on a smart phone in areas with limited internet (and electricity) connection, the platform should be designed to work well on smart phones, both on-line and off-line, with minimal energy consumption. Secondary users are entities that seek to access anonymized credit data of lenders for research or commercial purposes. A token is introduced so that lenders can sell their data to these secondary users.
Lenders might value the opportunity to get in touch directly with potential borrowers to further assess the borrower before signing a loan agreement, to track progress during the loan period and to personalize the microlending experience (e.g. an individual can now donate to a microfinance institution knowing to whom the money is going or lend directly to the end-borrower without intermediation of a microfinance institution).
Tokenizing Carbon Credits
Carbon credits suffer from a lack of transparency, and numerous global markets for carbon and greenhouse gas offsets are not integrated, leading to leakage in tracking and accounting for carbon. Using blockchain technology to tokenise carbon credits and other environmental incentive schemes enables for greater end-to-end visibility and tracking, as well as increased coordination and trading across jurisdictions to reduce the displacement of emissions from one jurisdiction to another by simply relocating where emissions take place. Tokenisation of carbon credits also enables environmental incentives to become tradeable financial assets, and allows people anywhere in the world to earn tradeable assets in exchange for participation in the reduction of greenhouse gas and carbon emissions. (University of Oxford, 2018)
Characteristics relevant for blockchain
Various elements of the system may suggest the use of blockchain: automation of recurring transactions representing a unit of value that should be immutable as well as agreed upon and available to relevant parties. In this context it is helpful to distinguish between tracking the carbon emissions and tracking the carbon credit trades.
Design of Solution
Protocol layer
To increase transparency and accountability actual emissions of companies should be seen on the blockchain publicly as well as the related trading of carbon credits – there is no direct need to use a private blockchain.
The blockchain needs to be able to handle many thousands or even millions of transactions per second as the carbon credit market is large and carbon credits are traded extensively. This would allow the monitoring of actual emissions and tracking trades of carbon credits to be displayed on the blockchain in real time.
The development of the blockchain should not be completely decentralized as rules for credit issuance and trading are dictated by or derived from the Kyoto’s protocol. The public community may propose changes (such as a bug solution) or additions (such as new user applications) to the source code, but approval of these should be governed by the UNFCCC as the regulator of the Kyoto protocol execution.
Connection with other blockchains and related protocols might enhance the utility of the carbon credit token, but the possibility of this depends on how the global blockchain ecosystem evolves. In the initial phase credits can be exchanged for carbon emissions or fiat. In future phases credits might be exchanged for other tokens or assets once it is possible to securitize tokens (to be compliant with securities regulation) and connect to other blockchain based exchanges that can swap various types of tokens and assets or integrate carbon credit tokens in their own blockchain ecosystem.
Network layer
Nodes can be run by the public, but only UNFCCC approved nodes and trading exchanges should have writing rights on the blockchain. The nodes run by the UNFCCC certifying entities append the data about carbon credits to the blockchain as this is a responsibility of UNFCCC and data submitted by carbon emitters to UNFCCC are non-public. The nodes run by the trading exchanges write trading transactions to the blockchain as they manage the infrastructure for trading credits. Other nodes can verify transactions, but not append new ones.
To allow the tokenization of carbon credits the writers on the blockchain (carbon credit certifiers and credit trading exchanges) should make the necessary changes to their current systems to integrate with the blockchain. The credit certifiers need to ensure that their systems once approved automatically write newly issued or terminated credits to the blockchain in real time. For the trading exchanges instead of recording transactions in their own system, they will have to write new transactions directly and in real time on the blockchain.
Application layer
Applications need to be designed with the end-user in mind: the governments that need to reach their greenhouse gas emission reduction targets and carbon emitters that want to sell or purchase carbon emission rights.
These stakeholders have viewing rights only and should have the option to retrieve data from the blockchain automatically (e.g. using an API) or to log in a customized portal. A dashboard functionality could help the stakeholders in managing their emission targets.
For the carbon emitters it is important that they can see the number of carbon credits awarded and have the possibility to trade credits. They update their data to the credit certifier and not to the blockchain directly, so they only need viewing rights for their certified credits on the blockchain.
Governmental bodies should be able to aggregate and filter data based on jurisdiction using the blockchain and without retrieving that information from UNFCCC necessarily anymore. Governments need to be able to track their progress to reaching greenhouse gas emission reduction targets and to compare with progress of other governments. In addition to that, they need to be able to control carbon emitters and steer their progress towards reaching emission reduction targets.
In addition to the aforementioned end-users, it should be possible for developers and entrepreneurs to build other applications on top of the blockchain, such as applications that retrieve information from the blockchain for carbon credit research and development of ‘carbon-friendly’ energy projects.
Characteristics relevant for blockchain
Various elements of the system may suggest the use of blockchain: automation of recurring transactions representing a unit of value that should be immutable as well as agreed upon and available to relevant parties. In this context it is helpful to distinguish between tracking the carbon emissions and tracking the carbon credit trades.
- Carbon credits are created and subsequently traded by passing the following standardized steps that all projects need to go through: forecast carbon savings, submit project, get approval from host country, validate project, register process, monitor project’s emissions, verify monitoring, certify monitoring, issue credits and trade credits.
- Once carbon credits are issued they can be traded in perpetuity or until the carbon credit system is not accepted anymore by the participating countries or replaced by another carbon emission reduction incentive system.
- The main stakeholders are the project owners (both carbon credit issuers and those that seek to offset their carbon emissions), validators of the project (delegated entities of the United Nations Framework Convention on Climate Change or UNFCCC), Kyoto Protocol participants (mainly governments with a goal of national carbon emission reduction) and carbon credit trading brokers.
- Only the UNFCCC or approved entities validate the project, including calculation of forecasted emissions (comparing base line data with forecasts) and verification of actual data monitored. The spot price of carbon credits is determined in an open market that is being facilitated by six exchanges only.
- The value of a carbon credit can be measured as the number of tonnes carbon dioxide emission avoided, which can be monetized and traded accordingly based on the prevailing spot price as determined by the carbon credit trading exchanges.
- Once a carbon credit is issued the related (trading) transactions should be recorded and not changed (e.g. to audit if carbon emitters hit their emission goals and to tax carbon credit trading gains). For each transaction at least the new owner, time traded and trading price should be recorded and linked to the previous transaction.
Design of Solution
Protocol layer
To increase transparency and accountability actual emissions of companies should be seen on the blockchain publicly as well as the related trading of carbon credits – there is no direct need to use a private blockchain.
The blockchain needs to be able to handle many thousands or even millions of transactions per second as the carbon credit market is large and carbon credits are traded extensively. This would allow the monitoring of actual emissions and tracking trades of carbon credits to be displayed on the blockchain in real time.
The development of the blockchain should not be completely decentralized as rules for credit issuance and trading are dictated by or derived from the Kyoto’s protocol. The public community may propose changes (such as a bug solution) or additions (such as new user applications) to the source code, but approval of these should be governed by the UNFCCC as the regulator of the Kyoto protocol execution.
Connection with other blockchains and related protocols might enhance the utility of the carbon credit token, but the possibility of this depends on how the global blockchain ecosystem evolves. In the initial phase credits can be exchanged for carbon emissions or fiat. In future phases credits might be exchanged for other tokens or assets once it is possible to securitize tokens (to be compliant with securities regulation) and connect to other blockchain based exchanges that can swap various types of tokens and assets or integrate carbon credit tokens in their own blockchain ecosystem.
Network layer
Nodes can be run by the public, but only UNFCCC approved nodes and trading exchanges should have writing rights on the blockchain. The nodes run by the UNFCCC certifying entities append the data about carbon credits to the blockchain as this is a responsibility of UNFCCC and data submitted by carbon emitters to UNFCCC are non-public. The nodes run by the trading exchanges write trading transactions to the blockchain as they manage the infrastructure for trading credits. Other nodes can verify transactions, but not append new ones.
To allow the tokenization of carbon credits the writers on the blockchain (carbon credit certifiers and credit trading exchanges) should make the necessary changes to their current systems to integrate with the blockchain. The credit certifiers need to ensure that their systems once approved automatically write newly issued or terminated credits to the blockchain in real time. For the trading exchanges instead of recording transactions in their own system, they will have to write new transactions directly and in real time on the blockchain.
Application layer
Applications need to be designed with the end-user in mind: the governments that need to reach their greenhouse gas emission reduction targets and carbon emitters that want to sell or purchase carbon emission rights.
These stakeholders have viewing rights only and should have the option to retrieve data from the blockchain automatically (e.g. using an API) or to log in a customized portal. A dashboard functionality could help the stakeholders in managing their emission targets.
For the carbon emitters it is important that they can see the number of carbon credits awarded and have the possibility to trade credits. They update their data to the credit certifier and not to the blockchain directly, so they only need viewing rights for their certified credits on the blockchain.
Governmental bodies should be able to aggregate and filter data based on jurisdiction using the blockchain and without retrieving that information from UNFCCC necessarily anymore. Governments need to be able to track their progress to reaching greenhouse gas emission reduction targets and to compare with progress of other governments. In addition to that, they need to be able to control carbon emitters and steer their progress towards reaching emission reduction targets.
In addition to the aforementioned end-users, it should be possible for developers and entrepreneurs to build other applications on top of the blockchain, such as applications that retrieve information from the blockchain for carbon credit research and development of ‘carbon-friendly’ energy projects.
Your Identity on the Blockchain?
What are the implications if government decides to outsource the identity management of their citizens to the blockchain? What is our responsibility versus the role of the government?
Owning your own identity data using blockchain is more efficient, targeted and secure, but also requires you to be more responsible and to be protected by government against influences outside your control.
As the blockchain has already verified one’s identity there is no need for organizations to have their own identity check procedures – they simply ask the citizen for permission to access the blockchain based proof of identity. The citizen can be selective in which information to provide to whom for his own benefit. For example, he can customize his online shopping experience by sharing selective personal information (e.g. age, income, education) anonymously. Any further updates to one’s identity can be verified following specific rules governed by the blockchain (e.g. smart contracts for moving houses to update the citizen’s address).
Even though the data stored on the blockchain is more secure than in traditional identity management systems, a hack is not impossible (Buterin, 2017) and the citizen’s private keys to access the data can be lost or stolen. Even when the data is legally obtained, citizens are exposed to the risk that their privacy is not guaranteed by organizations who use the data. Apart from this, some amendments of the identity data still need to be verified outside the blockchain (e.g. when the citizen is born).
Therefore, the role of government in identity management remains important in order 1) to have a nation-wide backup plan in case of a major blockchain attack, 2) to ensure technologies are used to access the blockchain that minimize risk of loss or theft (e.g. using fingerprint), 3) to have privacy legislation in place for the use of blockchain data and 4) to check amendments to data that cannot be handled by smart contracts.
References:
Owning your own identity data using blockchain is more efficient, targeted and secure, but also requires you to be more responsible and to be protected by government against influences outside your control.
As the blockchain has already verified one’s identity there is no need for organizations to have their own identity check procedures – they simply ask the citizen for permission to access the blockchain based proof of identity. The citizen can be selective in which information to provide to whom for his own benefit. For example, he can customize his online shopping experience by sharing selective personal information (e.g. age, income, education) anonymously. Any further updates to one’s identity can be verified following specific rules governed by the blockchain (e.g. smart contracts for moving houses to update the citizen’s address).
Even though the data stored on the blockchain is more secure than in traditional identity management systems, a hack is not impossible (Buterin, 2017) and the citizen’s private keys to access the data can be lost or stolen. Even when the data is legally obtained, citizens are exposed to the risk that their privacy is not guaranteed by organizations who use the data. Apart from this, some amendments of the identity data still need to be verified outside the blockchain (e.g. when the citizen is born).
Therefore, the role of government in identity management remains important in order 1) to have a nation-wide backup plan in case of a major blockchain attack, 2) to ensure technologies are used to access the blockchain that minimize risk of loss or theft (e.g. using fingerprint), 3) to have privacy legislation in place for the use of blockchain data and 4) to check amendments to data that cannot be handled by smart contracts.
References:
- Buterin, V. (2017). The Meaning of Decentralization. [online] Medium. Available at: https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274 [Accessed 09 Mar. 2018]