Blockchains are built on a series of innovations in organizing and sharing data. The objective is to make one version of the reality, used by all participants, containing a far richer dataset than exists in any one system these days. This will inturn enable new industry processes to be developed, based on the use of transparent real-time data, and the expansion of auto-executing ‘smart’ contracts, with business logic encoded into the ledger. If we talk about the Stock market, Blockchain offers huge potential for tracing securities lending, repo and margin financing and monitoring systemic risks.
Beyond using the technology as an operating procedure for an exchange system, the blockchain has also found, through cryptocurrencies, a use as a way of raising capital, in place of traditional stock and equity markets.
1. Primary Market activities
Beyond using the technology as an operating procedure for an exchange system, the blockchain has also found, through cryptocurrencies, a use as a way of raising capital, in place of traditional stock and equity markets.
For several months already, a new form of public offering has been flourishing, not only because they deal with start-ups, but mainly because they are in the form of cryptocurrencies, like Bitcoin or Ether, from where comes the initialism ICO – Initial Coin Offering, with reference to IPO – Initial Public Offering. These operations are a quick way of securing financing – capital can be raised in as little as a few hours to a few days – for entrepreneurs in the world of blockchain, allowing them to test their ideas or project on a community of experts.
Taking into account the potential of this technology, these capital raise also attract more and more investors looking for added value, even if they do not always understand the technological specificities of the project.
2. Secondary Market activities and Trading
The blockchain has not only prompted innovation on the primary market, with the appearance of ICOs: it may also have a revolutionary effect on secondary market and trading activities.
The distinctive aspect of this process largely relies on the manner in which an efficient process of order matching and price formation is conceived. Essentially, the ability to use the blockchain, with an added value, for negotiating activities, depends on two factors: First, the nature of the financial instruments traded and second is the nature of the intended negotiating activity.
Using the blockchain for trading activities is conceivable even before the creation of the transaction for other instruments. This is typically the case for instruments whose trading price is purely bilateral.
The possibility of using a blockchain for trading purposes thus depends on multiple factors. Nevertheless, it can be expected that the application of the advantages provided by this technology to other segments of the value chain will have a major effect on trading activities. In particular, by streamlining the post-trading phase, blockchain is bound to have as much of an impact on the demand as on the supply of capital, by prompting a growing number of capital issuances on the markets and by increasing investment in and exchanges of instruments in circulation and therefore the volumes traded.
3. Post-trading activities
Blockchain can also simplify the landscape of traditional organisation and operation of post- trading activities.
In the traditional scheme of things, a transaction’s life cycle on the stock market requires the presence of a market intermediary, a trading platform and various post-trading infrastructures and intermediaries, including a clearing-house, a settlement agent, a depository and a central depository.
In the new model, the instruction to buy or sell a financial security on a stock market follows a complex cycle, both in technical and legal terms, due to the presence of these various entities. It is even sometimes difficult to track an order all the way from the investor to the delivery or payment: the clearing house makes it impossible to track an individual instruction due to multilateral settlement methods.
In financial markets, the steady disappearance of paper securities and their replacement with virtual assets has led to the replacement of physical settlement using cash, with digital trades. The need remains however, for a ‘golden record’, a way for market infrastructures and intermediaries to keep their individual databases updated by communicating with the other institutions involved at other levels of post-trading, in order to be able to reflect each transaction in the records for each intermediary/infrastructure. Therefore, golden record in the financial market would be a well innovated blockchain app that caters to the people of Stock market.
In case, you are looking to understand blockchain implications in your business sector in more detail, drop us an email on [email protected] or schedule a free consultation with our team of blockchain experts who can guide you through the blockchain implementation in a specific use case.
Hedera Hashgraph is the next generation distributed public ledger. The mechanism of the Hedera Hashgraph will be completely different from Bitcoin and Ethereum. Where Bitcoin and Ethereum are currently using the Conesus mechanism. Hedera Hashgraph will not be using the same technology, even they explored the new technique which will be ABFT (Asynchronous Byzantine Fault Tolerant).
ABFT (Asynchronous Byzantine Fault Tolerant)
From past few years BFT (Byzantine fault tolerance) has been standard for security in distributed systems. Byzantine fault tolerance means that honest members of a network can be guaranteed to agree on a common consensus, even if malicious members (Byzantine nodes) are trying to prevent that consensus, or trick them into reaching different conclusions. A system is BFT if it can guarantee that there will come a moment in time when all nodes agree on consensus, and they know they’ve reached consensus, and it is always the same consensus.
BFT means achieving this even while allowing for a wide range of faults or attacks. Byzantine faults include behaviors like lying, collusion, and selective non-participation. Clearly it will be harder for a set of nodes to come to valid consensus under these sorts of errors, compared to simpler scenarios where nodes may just crash.
Hyperledger also used the same system for Fabric and other flavours of Hyperledger. And one of the famous mechanism is PBFT (Practical Byzantine Fault Tolerance) and RBFT (Redundant Byzantine Fault Tolerance).
But above all the ABFT (Asynchronous Byzantine Fault Tolerant) is the strongest one. In a distributed system, Byzantine Fault Tolerance refers to the ability of the system to retain honest consensus in the network despite malicious nodes failing or manipulating with the false messages. Asynchronous Byzantine Fault Tolerant means that it can achieve consensus even if malicious node control the network and start altering the transactions. The Hedera Hashgraph consensus mechanism does not use a leader format as with the round-robin system of practical Byzantine Fault Tolerance, which allows it to be resistant to DDoS attacks aimed at leader nodes or small subsets of nodes.
In ABFT the whole system will start identifying which transaction happened and when it happened. Through this they can achieve verify the transaction easily and in better fashion.
Another advantage of Hedera Hashgraph is Fairness. It means that every transaction will be broadcast to all the nodes which are participants of the Hedera Hashgraph network. And the transaction order and time-stamp will also be accurate. This means that it does not have the transaction pool where all the transactions are being saved and after a certain period of time they will be mined. And miner decides which transaction they want to calculate. If you’re providing lesser fees there are chances that your transaction will take time to get confirmed. But in Hedera Hashgraph the transactions are being calculated once they released or broadcasted to network the system does not allow to choose any particular transaction on the basis of time and execution cost. This makes this system faster than Bitcoin and Ethereum.
To perform this action Hedera Hashgraph is using a Gossip Mechanism. In Gossip Mechanism instead of broadcasting transaction message, Hedera Hashgraph broadcasting the state to the network.
Software license management is a complicated topic, but knowing a little bit about its background can help you better understand ICOs, as the tokens being issued very much represent a form of license that floats across users and products.
Nothing wrong with that, in my view its quite the opposite, as you eliminate some of the legal hassles of buying equity in startups, but important fact nonetheless. Hope this article helps better understand what you might be buying the next time you purchase a token on a popular exchange or through a token crowdsale e.g. blocksquare — endorsement intended 🙂
What is software licensing?
A software license is a legal instrument (usually by way of contract law, with or without printed material) governing the use or redistribution of software. The software license usually answers questions such as:
Where and how and how often can you install the program?
Can you copy, modify, or redistribute it?
Can you look at the underlying source code?
To activate a software product usually a license key needs to be entered to turn on the full set of features available in a software package.
For example, if you download a free trial version of a software, you may need to purchase and enter a license key to start using the full paid version. Activation may be done offline or, more frequently, online. If you want to stop using the software on one computer and start using it on a different computer, you may need to deactivate the license on the old computer before you can transfer it to a new computer.
Volume licensing agreements are usually made available by most major vendors in the commercial, government and education sectors, allowing organisations the opportunity to streamline their software purchasing, negotiate discounts, simplify software deployments, achieve management economies and easily maintain a software asset management program to ensure software compliance.
There is a number of different software licensing models currently offered by software vendors, including a number of emergent models.
1- Device — Also known as ‘machine based’. License is locked to an individual machine.
2- User — License is assigned to a named user who must be identified to ensure the license agreement is validated and the license terms are adhered to.
3- Networked (WAN & LAN) — A license that covers machines that is on the same network infrastructure. This is either in Wide Area Network or a Local Area Network format. Also known as ‘concurrent license’.
4- Subscription (user or device) — License only available during the period of subscription. No rights to use it pre or post agreement dates (unless agreement renewed).
5- ‘Cloud based credits’ subscription — Cloud credits are the unit of measurement required to perform certain tasks or rights to run certain applications provided by the vendor. Hosted in the cloud and are usually a subscription model.
6- General Public License (GPL) — License and software available for free. Allows users to use, share, copy and modify the software. Separate legal metrics to ‘freeware’.
7- Client Access License (CAL, includes both device and user metrics) — Allows users to connect to server software to use the software’s features/functions.
8- Capacity Based License — License is based on the capacity of the CPU/Hard Drive or other hardware configuration elements.
9- Font licenses — Font specific license. Related to the fonts used online or internally by an organisation.
10- Freeware — License requires no purchase but the copyrights are still held by the developer.
Token Licensing Origins
When you are developing a new system like Blocksquare, your mind tends to search for parallels to make better sense of what you are creating. So, when the notion of tokens being the equivalent of a software license came to mind, I immediately googled “token license”, and to my surprise, the first few results were links to an IBM community website from 2012.
As it turns out, IBM developerWorks offered a kind of token licensing option to provide greater flexibility to its customers. But the fact that IBM, one of the biggest corporations, offered a novel licensing model back in 2012, was actually not the most astonishing part of my research.
Further exploration of the topic lead me to this article. Published in 2008, the piece writes about Aspen Technology, a company providing software for heavy industrial manufacturing, and the unique way they allowed its customers to purchase its smorgasbord of applications trough tokens, akin to buying a prepaid cell phone card.
After you have purchased tokens from Aspen Technology, you could use them to license any of the company’s products. So if the engineering suite required 50 tokens per user, and the plant manufacturing suite was worth 20 tokens per user, and the supply-chain app was worth, say, 10 tokens, you could divide that up in any combination you chose. Pretty cool, ha?
Token as a License
Opposed to traditional licensing, token based licensing gives you the ability to “reuse” the same licenses for different products and when the need arises. As tokens are sold or purchased on exchanges, the license can easily change hands, so more users can use the software for a limited time. In a token environment, a product may
require a predefined amount of tokens,
consume a predefined amount of tokens.
The concept of Tokens as a License is already taking place. Ethereum for instance, consumes Ether tokens to perform different actions on the provided software. Because the consumed tokens are being transferred to miners, and because they carry value, we percieve Ether as a currency rather than a license.
Token licensing could be considered as the most flexible method of licensing. Tokens available on exchanges can be regarded as a maintained “token pool” of cross user licenses enabling users access to the right product at the right time. The users are able to obtain a license as long as sufficient unused tokens are available on the market. When someone stops using a product, he can choose to re-sell the tokens and make them available for someone else to utilize or hold the tokens for later use.
The model may become very effective for software vendors who have a wide portfolio of applications where the usage patterns of individual apps are difficult to predict. This situation often occurs in technical markets, where the portfolio of software is used in a design flow, or to conduct a software experiment. Users may not be able to predict how much software to purchase at the beginning of the purchase cycle as the usage of apps may be dependent upon the challenges in a particular design.
From the perspective of the software vendor, it’s also an effective way to fortress a market position against point-tool competitors. The token software license model makes it financially easy for the customer to utilize the entire portfolio of software, and not try to buy the best-of-breed for every part of a work flow.
Concurrent Token Licensing
When deployed as a token license, the software vendor, instead of creating a license key associated with a product, checks the amount of tokens on a user wallet which is then weighed toward the price list of the product. With the token licensing model, the customer needs to purchase a certain number of tokens that enable the use of the software or a particular app.
Consumptive Token Licensing
A pure-play consumptive token, like a gumball machine, is a “use it up” model. In this model, when a product runs it checks out a certain number of tokens which are then consumed and no longer available to the user. The tokens may be burned (destroyed) or simply pass hands, either go back to the software provider (token issuer) or go to a 3rd party providing a key service or action for the software provider. This type of software license model applies best when licensing software that is transaction-oriented, and the software vendor wants to charge based upon the total number of transactions.
Token licensing for blockchain software solutions
Let’s take a look through a practical example of a blockchain powered solution — Blocksquare.io
Blocksquare is a network of fractional commercial real estate property tokens (i.e. PropTokens), with a decentralised marketplace to buy and sell these tokens, and a platform to conveniently keep track of property performance and communicate with property management. It is also an application that enables certified partners to tokenize CRE properties without technical skill requirements.
Blocksquare participants are a very diverse user group, with needs to access different functionalities and applications within the system. The various user groups are: (1) certified partners, (2) property management companies, (3) property holding companies, (4) PropToken Validators and (5) end users.
Certified partners use Blocksquare to create and issue new PropToken contracts. They offer these services to local real estate professionals looking to sell commercial properties. To deploy a PropToken contract, a certified partner must use three apps: the PropToken Creation Module, the Holding Company Selector and the Management Company Selector. Each app requires a certain amount of BST tokens to be held on the specified user’s wallet account. For purposes of making an example, we can define the following token licensing structure:
Creation Module → 200,000 BST,
Holding Company Selector → 50,000 BST
Managment Company Selector → 100,000 BST.
This in terms means, a certified partner would require to hold a total of 350,000 BST tokens to use the required product suite to be able to tokenise properties. The token license could also be split to separate accounts within a certified partner’s organisation. This could, for example, come in handy when a partner’s tokenization workflow divides tasks to separate departments.
On the other side, Property Holding Companies need to only be licensed to use the Holding Company Selector app. The app enables them to receive, evaluate and confirm new offers for title holding services. In our above example, the token license would require the company account to hold a balance of 50,000 BST.
Similarly, a Property Management Company would need 100,000 BST tokens to be licensed to use the Management Company Selector app — a marketplace for management companies offering services to the network of PropToken properties.
End users of the system may be given a tier based license, where entry level use would require no tokens, but higher level tiers would require certain BST token amounts to be held by the user.
As opposed to the concurrent token licensing for b2b users, end user licensing could be consumptive, requiring the user to pay for access to PropToken Generation Events.
With the regulatory environment still not providing a clear framework in almost all jurisdictions, we can not say for certain, how and if tokens can be regarded as mean for flexible licensing of blockchain based software solutions. In my personal view, the wider blockchain community should consider looking in this direction, as it may prove to be a strong point to clearly define what tokens are to regulators, as software licensing is already well defined by laws in most jurisdiction.
As regulatory perspectives are not my strong point, I asked Aljaz Jadek, associate at law firm Jadek & Pensa, one of Slovenia’s most renowned law firms, to share his personal view on the matter.
The issued tokens together with the smart contract and terms and conditions could constitute all elements of the license agreement. The license agreement is according to Slovenian law defined as an agreement through which the license provider undertakes to wholly or partly cede to the license acquirer the right to exploit a patented invention, technical know-how or experience, or a trademark, pattern or model, and the license acquirer undertakes to make a specific payment for such.
According to Slovenian law the license agreement must be concluded in a written form. Moreover the Electronic Business and Electronic Signature Act provides that the electronic form shall be deemed to be equivalent to the written form if the information in electronic form is accessible and appropriate for later use. I believe the blockchain technology could reach this standard, so the license agreements could be concluded in electronic form.
The nature of the token is crucial for the TaaL model. It is a question whether the token would be formed as a security or an identification paper or maybe something else? The main difference is that the creditor’s rights are not incorporated in the identification paper (token), so the license acquirer could exercise his rights also without such token. Practical use of such token is questionable. On the other hand a token which would carry a license acquirer’s rights would probably be subject to securities laws.
The license provider is obliged to deliver the subject of the license and is liable for the technical feasibility and the technical usability of the subject of the license. The token would probably not be considered as the subject of the license. This means that in the TaaL model the token issuer would have more obligations towards the token holders as we are currently witnessing in the ICO world.
The following legal aspect is relevant for the secondary exchange market. According to the Slovenian law either party to a bilateral contract may transfer the contract to a third person, who shall thereby become the holder of all the former’s rights and obligations deriving from the contract, if the other party consents thereto. In the TaaL model where the whole license agreement is transferred with the transfer of tokens the consent from the token issuer would be needed in order to validly transfer all rights and obligations from this license agreement to the new token holder. The consent could be given in advance along with the notification to the license provider about the transfer once the transfer occurs. Another solution could be that the acceptance of tokens by the token issuer is considered as an action from which it can be reliably concluded that token issuer’s consent on transfer of licence agreement exists. This means that the token holders would risk that the token issuer would at some point in time not give consent and thereby prevent the exchange of tokens on the secondary exchange market. Furthermore, the token seller (transferor) would be liable to the token buyer (transferee) for the validity of the transferred contract, which would probably be beyond his control.
According to the Slovenian law there is a difference in the TaaL model where only the license acquirer’s claims are transferred with the transfer of tokens. In this case the consent from the token issuer is not needed, but the token issuer (debtor) would need to be notified about the transfer of the licence acquirer’s claims. This means that the token issuer would need to be notified each time the token is exchanged on the secondary market. The token seller (transferor) would be liable to the token buyer (transferee) for the existence of the claims, which would probably be beyond his control. A clear advantage of this TaaL model would be that the token issuer could not prevent the exchange of the tokens on the secondary exchange market, as his consent is not needed for the transfer of license acquirer’s claims.
On the other hand rights and obligations from the license agreement could be transferred according to the rules of securities laws, depending on the nature of the token and the whole structure of the TaaL model.
The above mentioned points represent basic legal review of the TaaL model and just point out legal aspects and restrictions which need to be further analysed and addressed when constructing a TaaL model.
Token licensing has already some history behind its back and, with the adoption of blockchain technology and blockchain based tokens, it may become one of the most widely accepted licensing methods for decentralised applications.