# Open Finance Overview and our vision If liquidity is calculated based on the lock-up amount of the open financial agreement on Ethereum, it has reached $1.5 billion by the end of June 2020, a 30-fold increase from early 2008. On-chain liquidity is constantly transferred and extended between different agreements, from lending agreements to liquidity agreements to asset agreements. The on-chain liquidity pool enables open financial agreements to provide loans with lower interest costs, enabling decentralized transactions with large amounts and low sliding points. Mobile galaxies are expanding at an unprecedented rate. Liquidity, although it can make money flow effectively, but it is easier to escape the gravity of any vertical agreement. Because liquidity pursues maximization, it is difficult for a vertical agreement to retain liquidity and capture network value in its single agreement. With the development of open finance, product innovation and iteration are also moving forward rapidly. We need to achieve liquidity retention and capture the network value through the way of protocol matrix. Among them, the three types of agreements are crucial to the open financial network and play the role of infrastructure, namely, asset agreement, liquidity exchange agreement and lending agreement. In each of these categories, there are already some projects in the market, such as asset class agreements DAI, USDT and FUSD, swap class agreements Uniswap and Honingdas Network Swap, and lending class agreements Compound and Aave. Our vision is to build core protocols in each classification, and ultimately to create a matrix of synergy and interconnection, to form connectivity and synergy at the liquidity and asset levels, and to freely interact and integrate with other open financial protocols in the three categories. We aim to share liquidity and network effects through core protocols, while retaining the full openness of free interaction and integration with other protocols. Our protocol architecture has a basic principle, namely, to build the protocol matrix and maximize the utility of liquidity in the protocol matrix. There are three important dimensions: the first dimension is liquidity agreement, including Honingdas Swap, decentralized exchange, trading agreement, derivatives agreement; the second dimension is lending agreement, including lending market, mixed lending platform, money market, etc.; the third dimension is asset agreement, mainly stable asset tokens (such as FUSD) and interest-bearing tokens (such as UBill NFT). Our protocol can not only freely interact with other open financial protocols, but also run on different blockchain platforms, so we can rapidly expand the protocol matrix from the Ethereum ecosystem to other platforms (including other first-tier and second-tier networks). The FVM is ours. Our design intention is to through the protocol integration way to realize the expansion of Honingdas Network network value, make any protocol or decentralized application or block chain can connect with us without friction and interoperability, eventually build a self evolution, self-adjustment, self-motivation and self-governance open financial platform. Honingdas Network core system tokens ($HDS), as applied tokens, will be widely used in Honingdas Network network governance, risk buffer and incentive mechanism. Given that Binance Smart Chain has the most dynamic and prosperous open financial ecosystem, early in the project, we will deploy various underlying protocols and our system core governance currency, $HDS, based on the BSC network. However, we are also clearly aware of the problems of ethereum itself (the underlying relatively limited scalability, consensus algorithm owe flexibility, token model autonomy, which is not allowed to pay for other tokens, etc.), as the Honingdas Network network gradually mature, we will migrate to the FVM at the right time, in order to better implement our approved consensus mechanism and token model, but anyway, we will always remain neutral to any public chain. **Open financial models and value capture** As the infrastructure of crypto digital finance, the open financial agreement plays the role of the foundation in the pyramid of open finance. At the bottom layer of the protocol stack, the asset protocols provide the necessary infrastructure for the functional protocols at the upper level, and the main asset protocols are stablecoin FUSD, commodity tokens (NFT carbon emission quota, NFT renewable electricity, ALL BLUE NFT, etc.) and coupon tokens UBill NFT. We believe that crypto digital finance will develop in the combination of centralized finance and decentralized finance, presenting the "front store and back factory" model. Centralized finance will undertake the function of the front-end store, directly facing users and providing services for it; while decentralized finance will sink into the back-end factory, as the infrastructure, to provide services and help for the upper-level applications and centralized finance, and eventually become a vertical network that runs through the whole ecology. With decentralized financial liquidity and assets growing, it will eventually become a unified pool of liquidity, for all decentralized financial agreement to provide the original liquidity, so, our goal is to establish a internal born in decentralized financial ecological agreement matrix, become a connection between decentralized and centralized financial parallel universe wormhole. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://honingdas.gitbook.io/honingdas.net/open-finance-overview-and-our-vision.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.