From a general viewpoint, a BC resembles a LL, which is an abstract data structure whose instances are logically interconnected by pointers. Thus, BC transactions are stored in the form of a LL, whereas those transactions are persisted in sequentially ordered blocks. However, the resemblances of LLs and BCs end there, since the process of composing a chain is entirely different given by the consensus protocol. For instance, the major differences lies on the processes of gathering information from the peer‐to‐peer1 network, the assembling of information (i.e., transactions) into blocks, as well as the appending of new blocks to the blockchain.

The capacity of BC to provide a trustworthy, decentralized, and publicly available data storage makes it an interesting opportunity for organizations to increase business agility and reduce costs by removing intermediaries.3 However, it is important to note that a BC can be implemented in different ways, being typically named Distributed Ledger (DL), by modifying permissions to read and write, as well as the participation in the block‐validation process.l1 In this regard, BCs are essentially public with respect to (i) read, (ii) write, and (iii) consensus participation, whereas DLs are named based on any modification of these parameters. Moreover, the different types can be classified according to varying read and write permissions:

• Public Permissionless determines the most prevalent BC type. Bitcoin1, Ethereum2, and most Altcoins (i.e., forks of the Bitcoin code) are considered public permissionless BCs, because of their unrestricted read and write permissions, as well as the open participation in the consensus mechanisms. Thus, being open to anyone with Internet access. Public permissionless BCs are the standard type of a BC deployment and most cryptocurrencies are implemented as such.
• Public Permissioned DLs enable write permissions, which are restricted to selected entities, but it is public in the sense that anyone is able to read. For example, this deployment type can be used for use‐cases where multiple trusted authorities want to publish public data, accessible to anyone (e.g., publishing hashes of academic certificates).
• Private Permissioned DLs resemble the trust model of traditional databases, where read and write permissions are restricted and, consequently, data can only be read by authorized parties. Restricting permissions creates a hierarchy between its participants (e.g., via rolebased actions), where main features of the blockchain (e.g., transparency, immutability, and decentralization) may not be suitable for a potential application.
• Private Permissionless are closely comparable, but not identical, to public permissionless DLs. However, the notion of the reading access is restricted to a certain group or community. Therefore, the writing and reading permissions are publicly open to all participating members of this private group. A dedicated supply chain BC serves as a possible example, where the information exchanged is only readable by its authorized members, but all members can issue transactions without boundaries.

Therefore, depending on the needs of the application domain, the inherent power of disintermediation can increase of trust through transparency among the stakeholders involved. Nonetheless, while BC’s have started its widespread adoption within the FinTech (Financial Technology) domain, many other application areas, use cases, and specific blockchain types are emerging. However, it is important to observe that the BC applicability relies on a multitude of different facets, which are usually determined by dedicated application needs in terms of performance, security, and scalability, which have to be carefully considered in a long‐term analysis.3

While the short‐term expectations of emerging technologies are often overestimated, BCs are expected to cause rather evolutionary than revolutionary change. With that in mind, BCs may cause disruption in various industries, not only from a technical side, but BCs may also challenge existing business models, business processes and beyond.