There are two main considerations behind UFiT’s design of NFT Abstraction Layer, or NFTAL, which wraps all heterogeneous (relative to the carrying blockchain of UFiT) assets into a generic form of NFT, called UNFT, that is used by the user function modules.
1. Cross Chain and UNFT
The significance of cross chain integration to a financial transactional network is that the transactions and the processing thereof can be independent of asset origination and clearing. While UFiT is ultimately deployed on a specific carrying blockchain (specifically, on Ethereum at its first launch), the user function modules are not programmed to assume any specific details of the physical features of the underlying network, and the isolation of such details is the purpose of NFTAL. Even when the underlying network can only carry one form of asset, for instance, ERC-20 on Ethereum, or TRC-20 on Tron, NFTAL wraps such details with its generic asset description interface, through which the user function modules execute their financial logics.
If the underlying network is indeed capable of cross chain integration, NFTAL still wraps whatever form of NFT supported by that network into UNFT. This requires that NFTAL provide slots for heterogeneous asset adaptors to be plugged into, which verifies and locks the natively originated assets for wrapping. Once the assets are wrapped and locked, the financial functions will be programmed at the higher level of user functions.
2. UNFT Is Beyond Crypto Assets
It is critical to note is that our understanding of NFT is not limited to the category recognized by most participants in the crypto circle. We envision the inevitable rise of a paradigm where crypto and real-world assets are combined to create a rich set of innovative financial instruments. In order to support the demand of such potential growth of DeFi activities we must be able to bring over all necessary information describing an arbitrary asset originated from an arbitrary blockchain.
But the DeFi solutions presently available prove to be unable to achieve deliver such functionality, not even for a straightforward non-structured asset such as an equity share. Assuming it is to be handled on Ethereum, the usual treatment on Ethereum is the issuance of an ERC-20 token, which is quite similar to a stock symbol (or ticker) in the real world, but everything else that describes this symbol is essentially lost. For more complicated assets, such as an Account Receivable in supply chain finance, it becomes more challenging.
Common sense tells us that there is no practical way for user function modules to built-in knowledge of the infinitely possible real-world assets. The chosen design of NFTAL is to leave such details to the heterogeneous asset adaptors that are plugged into the layer. In recent years large institutions have initiated enterprise blockchains to the end of standardizing financial assets on these networks. UFiT’s solutions will work with these existing systems rather than reinventing the wheel.
3. The Building Blocks of NFTAL
The type Fungible Token (FT), also known as “homogeneous token”, is the most common form of token taken by blockchain assets at present. Tokens of this type can be arbitrarily divided and mixed. In NFTAL such FTs are expressed by the data structure Token.
None Fungible Token (NFT), also known as “heterogeneous token”, is handled internally by NFTAL with a structure illustrated in the following graph.
As the name of this data type suggests, Pointer isn’t an asset by itself but rather a directive handle pointing to a set of relevant information describing an asset or instrument. It is a 256-bit number, which can point to complex data structure stored in the smart contract, so it is suitable for the construction of complex financial data. In the above illustration, the “ASSETs” being pointed to by Pointer can be a Token or another embedded Pointer. Due to such directivity of Pointer, it can be nested infinitely to form any complex asset structure that meets financial applications’ requirements.
Another generic construct, Auxiliary can store any structurally coded information, typically providing the auxiliary information about how to interpret the ASSETs.
Auxiliary can also be nested, but it is not directive. With the capabilities offered by Pointer and Auxiliary, developers can transform complex cross chain assets, including those generated from real-world enterprise blockchains, into the UNFT form, which allows high level user modules of UFiT to parse and analyze the coded information relevant to the asset without the need of “hard coding” the asset knowledge in these modules.
This is the data structure designed to meet the needs of data centric applications where sensitive information such as time stamps, high valued storage locations, various proof or cipher strings, and other asset descriptions (for instance, indebtedness or credit worthiness), etc. must be kept private. If these applications are implemented on blockchain where inputs and outputs are handled by smart contracts, the problem of exposed sensitive information arises. In these applications the asset owner should be the one that controls the permission of viewing the data, and the support structure allowing such authorization and control is Native. The current version of Native adopts the symmetric encryption technology ChaCha20, which is fast and secure.
Users can package the Native data structure in the client application and get the corresponding key. After packaging, the Native data can be entered into smart contracts for relevant processing. During the process, the encryption of all contents of the Native data structure are unbreakable. When decryption is needed, the owners of the Native data can transfer their keys privately off chain to the intended users according to their needs, so that they can decrypt the relevant native information on chain.