Blockwall Asset Classification Framework

The Asset Classification Framework developed by Blockwall offers a framework to simplify the complex structure of a DLT system, to identify the individual components of the system and aids in the educated analysis and comparison of crypto-assets. 

Illustration of the Framework 

Explanation of the Framework

Protocol Layer

The protocol layer encompasses the protocols of the DLT and their implementation. The protocols are the foundation of the entire DLT system as they define the set of formal rules that govern the system and codifies its architectural design. Protocols act as a set of constitutional agreements (for e.g., consensus mechanism, hashing algorithm, data distribution protocols, etc.) that all the system participants agree upon. The protocol has a genesis component, which refers to the processes required to undertake and complete before launching the system, and an alteration component (only in the case on on-chain governance), which is the processes in place to enable modifications of the protocol rules. 

‍

The network of a DLT system exists as a direct result of the implementation of the protocol rules. The network consists of an interconnected group of actors and processes that adhere to a technology standard (protocol) and actively participate in the exchange of data and information over integrated communication channels. The implementation has three core components: the communication component, the transaction processing component, and the validation component. The communication component is the exchange and sharing of data across participants; the transaction processing component is the set of actions required to add an unconfirmed transaction to the shared set of authoritative records; and the validation component is the set of processes required to ensure that actors independently arrive at the same conclusion with regard to the authoritative set of record. The implementation of the protocols facilitate the various steps in the settlement process that leads to the creation of an immutable ledger that saves all the transaction details of the DLT system. 

Data Layer

The data layer is assembled over time as the transactions are written to the ledger by the activities of the participants who comply with the protocols of the DLT system.  So, the data layer refers to the information processed and stored by the DLT system in the form of records. The core feature that a DLT system delivers is this shared data structure - the ledger - that has a set of crucial features such as persistence, transparency, standardization, and censorship resistance. The ledger provides the authoritative version of records at a moment in time that is both shared amongst users of the system and updated over time as users engage with one another via the system. The data layer consists of two components: the operation component and the journal component. The operation component is the processes which govern how (and which) data is used in the creation of new records, modification of existing records, and the execution of code (may also include smart contracts); the journal component that concerns with the contents of the stored records such as what data within the records is being referenced, or what is in the blocks. 

Developer Interface

One of the crucial layer, the developer interface, is targeted at developers and is kind of a middleware that facilitate the interaction of developers with the DLT system to use its features to create other products or applications (e.g. dApps, tokens, DEXs, etc.). They consists of an integrated development environment (IDE) that encompasses an execution environment (e.g. Ethereum Virtual Machine, WASM), the programing language (Domain Specific Languages or General Purpose Languages that are understood by the DLT system) to write codes, Application Programming Interface (API), Software Development Kit (SDK), compilers, and other tools that facilitate dApp development. The existence of this layer in a DLT system depends on the statefulness of the system. Stateful DLT systems (e.g. Ethereum, EOS) have their own execution environments that can range from a simple fixed-purpose machine to a more complex general-purpose virtual machine (e.g. Ethereum Virtual Machine, WASM). The Turing complete environment, especially that of a general-purpose virtual machine, theoretically allow the modeling of any program using the smart contract feature. In contrast, stateless DLT systems are based on simple scripting languages that lack Turing-completeness and offers limited or no smart contract functionality. Nevertheless, such systems can incorporate an external run-time environment through second layer protocols (e.g., side chains) developed on top of the DLT system.

Infrastructure Token

While the layers discussed above are the technological layers of a DLT system, the infrastructure token is the accounting mechanism that facilitates the economic rationale in the system. The Infrastructure token, sometimes the main/only product of the system (e.g., cryptocurrencies), is the game-theoretic incentive to the participants of the system. This is the medium through which Blockwall or any other individual/institutional investor invest in the technology. Often infrastructure tokens are considered as the shares/securities of a DLT project, especially with regulators seeking to classify some of them as security tokens. Nevertheless, the value of infrastructure tokens are expansive and not limited to the ownership of technology. Some infrastructure tokens act as the gas for transactions or used as a staking mechanism to participate in the validating process, governance, etc. Furthermore, the infrastructures tokens are standalone assets that can be used as a store of value, a medium of exchange and a vehicle for speculation in the crypto market. According to Blockwall’s investment thesis, the infrastructure token of a DLT system should be able to capture the value of its underlying technology. Therefore, the token economics of a DLT system is the most important criteria of our thesis.  

Features

The features are not an inherent layer of the DLT system and serve the sole purpose of mapping the functionalities and characteristics of the DLT system. Mapping this layer helps to identify the value delivered by the crypto-asset in the web 3.0 ecosystem, thus enabling an educated analysis and comparison with other DLT systems. Features of a system could be the smart contract functionality, unique qualities of the system such as high scalability, robustness, etc., or any significant technology (e.g. zk-SNARKS) that the system introduced. 

Layer 2 protocols

Layer 2 protocols are built on top of a base layer protocol in order to amend or extend the capabilities of the underlying protocol. These meta-protocols provide enhanced features such as scaling, compute, privacy, smart contract functionality, decentralized exchange functionality, etc. Furthermore, some layer 2 protocols (e.g., side chains) are able to provide smart contract functionality to a stateless DLT system by offering an external runtime environment.  In addition to smart contract, the side chains reduce the ‘attack surface’ of the base layer DLT, increase the scalability, and offer additional privacy and confidentiality. Thus, the existence of such layer 2 protocols makes an underlying DLT system a fit to the investment thesis of Blockwall. A layer 2 protocol can have its own infrastructure token and can provide its own developer interface to integrate the functionalities to a dApp. But a layer 2 protocol is always depended on the base layer infrastructure provided by layer 1 protocol. Thus a dApp built on top of a layer 2 protocol uses the features of the layer 2 protocol and the features of the underlying layer 1 protocol (dApps can be developed without using any layer 2 protocols; solely based on the layer 1 infrastructure). 

Products

Products serve the end users and are often developed by third parties on the top of the DLT infrastructure. The products become successful by offering a unique value to the end-user and monetizing the value captured by the customer, much like the internet platforms of today (e.g. uber, AirBnB, PayPal, etc.) But the similarity ends here as the products developed on a DLT system is much more depended on its infrastructure rather than the conventional internet platforms. Most of the dApps, the main products on a DLT infrastructure, require the end-user to use the infrastructure tokens to perform an action (e.g. initiate transaction, access a feature, etc.) or require the developer to use the tokens to access the resources of the infrastructure. Thus, a product developed on a DLT system is tied to the token mechanism of the DLT for its eternity and the monetization of the value delivered will always include a marginal fee to its DLT infrastructure. Thus the demand for the product will indirectly create a demand for the infrastructure tokens and enhance the value of the underlying infrastructure protocol.

User-Interface

The last and final layer in our framework is the user interface, which connects the end-user with the infrastructure token of the DLT system or other products developed on top of the infrastructure protocol. With respect to infrastructure tokens, the user-interface is mostly the wallets that allow end-users to hold, send, and receive the tokens. The wallets can be offered by the blockchain network itself or by third parties. With respect to products (eg. dApps, DEXs, etc.), the user interface is the front end developed by the respective third parties or gateways to dApps such as Metamask. This is one of the most important layers for the adoption of the products and services facilitated by the DLT system, but there is a general lack of user interfaces, especially a general user interface (e.g. dApp browsers), in the ecosystem now. 

‍

‍

(We are grateful for the prior works done in the crypto space to classify and analyze DLTs. Especially, the research done by the Cambridge Center for Alternative Finance on DLT systems helped us to gain an in-depth understanding and formulate our thoughts. Further, the articles by Jill Carlson and Joel Monegro, and the investment thesis by Joel Monegro & Chris Burniske certainly inspired our investment thesis and asset classification framework.)

Glossary

• DLT: Distributed Ledger Technology - encompass both blockchains and DAGs (Directed Acyclic Graphs)
• Unconfirmed transactions: End users create transactions and broadcast them to the network through various means. These transactions are waiting for confirmation.
• Log (mempool): Each fully-validating node stores unconfirmed transactions in its log
  (‘mempool’). Logs may differ from one node to another.
• Record: Each record producer now arbitrarily selects a set of unconfirmed transactions from its log and creates a candidate record. After performing the necessary steps specified by the protocol to make the candidate record valid, it broadcasts the record to connected nodes.
• Journal: Each node will verify the received candidate record: if it complies with protocol rules, the node will add the record to its own instance of the ledger - the journal. Journal states may differ from one node to another.
• Ledger: The ledger represents the globally agreed upon an authoritative set of records that constitutes the state of the system. It results from the convergence of synchronized individual journals.
• Auditors: Checking submitted transactions and records for validity, reporting invalid records to the network, and relaying valid transactions and records. Ability to perform an independent audit of the system state. Often called full/fully-validating nodes
• Record producers: Producing and submitting sets of candidate records for potential inclusion into the ledger. Often called miners or validators.
• Lightweight clients: Querying auditors for data regarding specific transactions; do not fully validate the system.
• End-users: indirect users of the system who require a gateway to access the system (e.g. custodial wallet service). 
• Oracles: transmitting external data to the system.
  
  

References

1. Cambridge Centre for Alternative Finance (2018). Distributed Ledger Technology Systems: A Conceptual Framework. University of Cambridge - Judge Business School. Accessed from: https://www.jbs.cam.ac.uk/faculty-research/centres/alternative-finance/publications/distributed-ledger-technology-systems/#.W_VpPuhKjIV 
2. https://blog.usejournal.com/products-platforms-and-protocols-bbef1c726561
3. https://hackernoon.com/difference-between-sidechains-and-state-channels-2f5dfbd10707
4. Monegro, Joel & Burniske, Chris (2017). Placeholder thesis summary. Accessed from: https://ipfs.io/ipfs/QmZL4eT1gxnE168Pmw3KyejW6fUfMNzMgeKMgcWJUfYGRj/Placeholder%20Thesis%20Summary.pdf

Monegro, Joel (2016). Fat protocols. Accessed from: http://www.usv.com/blog/fat-protocols