Introducing the Hashflow Cognitive Matrix
A universal framework for understanding incentive design in crypto and fiat systems — Part 3
By Varun Vruddhula, Arjun Chauhan, and BKS811
lokah samastah sukhino bhavantu
om namo narayana om nithyanandam
Donate: BTC bc1q5crw5ygzwpff7f0a2fcq6equh6ga5z4cnwwlrh
Sankalpa: To Ethereum with Love, from Bitcoin
“Whenever we look at something, the first thing we do is calculate what we can get from it. It doesn’t matter whether it is a person or an object. Our thoughts manifest in the form of fear or greed to calculate what there is in the situation for us. Our attention is centered on that object or person. It is possible to turn our attention towards our own inner space and ask, ‘What can I contribute?’, ‘What can I add?’, ‘How can I enrich others?’ If the process is only driven by the ask, ‘What can I get out of it?’ then it is driven by lust. If the process is driven by the ask, ‘How can I enrich it?’ it is driven by love!
Love is not a choice as we think it is. It is a basic necessity of life. When I say life, I don’t mean just breathing and staying alive. I mean being alive at the innermost being level, as a live Consciousness. If you can express love, if you can experience love, that is the only way of being alive as a Consciousness. If you don’t experience and express love, you may inhale and exhale, but you can’t say you are a live being. Love is being in the flow with Existence, to be total with it. Ego is like frozen ice. Love is like liquid water. Only when we are liquid do we become part of the ocean. Then we don’t have any private goal or destination. Each moment is blissful, incredibly ecstatic, just going with the plan of the cosmos. Living in this divine space is living the best life and doing the greatest service to society.”
Chapter 9: Multi-Centric Distributed Trade Networks
Mesopotamia c. 2000 B.C.E
A long time ago, in a land far far away, along a verdant strip in the desert known as Mesopotamia, Sargon the farmer had 100 apples.
His friend, Hammurabi, had 10 bushels of wheat.
They exchanged what they had and now Sargon had wheat and Hammurabi had apples. They bartered to meet their needs.
Then Sargon got a little creative. He came to Hammurabi with a special offer: 60 apples in return for 10 bushels of wheat with the promise that at a future date, he will deliver another 60 apples to complete the deal. 
Now, Sargon had the wheat he needed as well as an additional 40 apples leftover. With the extra fruit, Sargon could take the seeds and plant more malus domestica. In due time, Sargon was in a position to pay his friend Hammurabi who was happy to see a 20% rise in income. Everybody benefited. Thus, began the concept of credit within a non-zero-sum context to aid in societal wealth creation.
Indeed, in ancient Babylon, temples were known to have provided lending and issuing services from the wealth they held. Such loans typically involved issuing seed grain with repayment due from the subsequent harvest.
Establishing credit facilities within a common distributed standard such as seed grain or gold metal allowed Babylon to solve for certain efficiencies in the commerce and exchange layers. Yet, the geospatial scaling issue still remained, thereby limiting the occurrence of trade to the internal boundaries of each city-state of Babylon and the temple located at the center of economic activity therein.
India and China c. 5000 B.C.E — 1867 C.E.
The earliest payment instruments known to have been used during the Vedic period (c. 5000–1200 B.C.E) in India were metal coins. These coins were punch-marked and cast in silver and copper. With coins representing a physical equivalent, credit systems evolved that incorporated bills of exchange to further facilitate inter-spatial transfers. The use of such bills of exchange solved the geospatial scaling problem that was due to become prevalent among the Babylonians in Mesopotamia some thousands of years later.
During the Maurya dynasty (c. 321–185 B.C.E), an instrument called the adesha came to be adopted and deployed in widespread use. The adesha instrument could function as an order or demand draft on a banker or merchant guild obliging payment of the note to a third party. This corresponds to the definition of a bill of exchange as we understand it today.
During the pan-Asian Hindu-Buddhist period (c. 500 B.C.E — 1624 C.E.), there was considerable use of these adesha instruments along global trade routes. The Tamil Chola empire of India maintained extensive naval sea routes with East Asia through the Indonesian archipelago. Merchants in large towns and prominent ports of call circulated letters of credit and bills of exchange amongst one another. These adesha allowed merchants in India, Indonesia, and pan-Asia to communicate via a shared standard and reliably compute enforceable approximations of units of value.
Starting with the Qin Dynasty (c. 221–206 B.C.E) and continuing through the Tang (c. 618 C.E. — 907 C.E.) and the late Southern Song Dynasty (c. 960 C.E. — 1269 C.E.), Chinese currency developed with the introduction of standardized punch-marked coins and then later incorporated Chola adesha.
Adesha reduced the costs of coordination of contract execution, dispute resolution, and loss remedy across geospatial boundaries to such an extent that capital formation and cross border trade exploded exponentially across trade routes that connected the commerce flow of India, Indonesia, and China. This activity, in turn, led to the further development of multi-factor letters of credit. And these letters of credit then soon found their way across overland trade routes and trade networks along the transcontinental lower Siberian shelf.
This overland trade route allowed cross border trade with India to be linked with the Occident by land as well as through the previously established Indonesia — China sea routes.
The most prized good demanded from merchants and customers alike was the famous cotton from the temple town of Madurai, the seat of the Cholas in Tamil Nadu. The trade in exquisite Madurai cotton textiles and associated fineries and spices eventually evolved into the collection of trade networks that we now know as the Silk Road and the Spice Routes.
After the battle of Talas and the defeat of the Tang, knowledgeable Chinese prisoners of war were ordered to produce paper in Samarkand, or so the story goes.  The Islamic conquest of Central Asia in the late seventh through thirteenth centuries C.E. opened up this knowledge for the first time to what became the Muslim world. By the year 794 C.E., paper manufacturing could be found in Baghdad. The technology of papermaking and associated letters of credit and bills of exchange began to flow throughout the Islamic realms from the Indian and Chinese trade networks, and further evolved to revolutionize the commerce of Khwarazmian. Though the Khwarazmian were ultimately destroyed, the adesha survived the Persians’ destruction at the hands of the mighty Khan from Mongolia in c. 1219–1221 C.E.
Along with papermaking, the Emperor formerly known as Temujin and his descendants formally incorporated the use of Chola, Tang, and Song adesha (mixed letters of credit and bills of exchange) to transport large quantities of money without the risk of theft. The technology of paper-based bills of exchange and letters of credit began to be used as trade currency. The widespread use of standardized adesha began to directly connect the wealth-generating activities of the pan-Asian, Chinese, and Indian economic order to the trade seeking European Occident. Medieval Jewish merchants such as the Radhanites deployed these bills and letters as a part of an interconnected credit custody system spanning multiple geospatial boundaries, kingdoms, and trade networks.
Through their efforts, credit custody currency evolved into claim checks on local money and this framework was put into force on an unprecedented scale, eventually connecting ports as far away as the Rhone Valley in southern France with the terminal east coast of China. The unrelenting demand for adesha that could reliably procure bales of Madurai cotton as well as finished cotton products and spices from India led to the excursions of the various East India Companies who sought to monopolize this trade by any means necessary.
The demand for Madurai cotton and plant dyes from India was insatiable. These Indian staples of cotton textiles and Indigo soon established themselves as a dominant worldwide commodity money.
“Indian cotton textiles comprised a large proportion of the imports. In the case of Anglo-African trade, piece goods of Indian cotton were the most important trades in exchange for African slaves, making up 30 percent of the total export value in the mid-eighteenth century.
The English East India Company, therefore, wrote a letter to Fort William in India (15 February 1765) requesting that more textiles be sent to London for use in African markets to purchase slaves.” 
This movement ultimately led to the development of multi-centric distributed trade networks around the globe and jump-started the Industrial Revolution. The Industrial Revolution was above all a textile revolution that began in the United Kingdom as a means by which to disrupt and control the Madurai cotton trade. The aim was to create markets that reversed the direction of gold and silver flows going into India as payment for Madurai cotton.
“With a 5,000 mile coastline, India had adventurous seafaring merchants, who took great risks. A recurring theme in this history was a constant flow of gold and silver into India. The reason was that people in the West hankered after Indian goods — spices, cotton textiles, and jewellery — but Indians were uninterested in Western wares. To balance the books, Western merchants had to pay for the difference in gold and silver. Roman senators complained that their women used too many Indian spices and luxuries, which drained the Roman Empire of precious metal. Pliny the Elder, in 77 CE, called India “the sink of the world’s gold!” In the 16th century, Portugal protested that its hard-won silver from South America was being lost to India. The British Parliament echoed this lament in the 17th century…” 
Chapter 10: The Scaling Debate
“Crypto blockchain technology is the foundation for automation. The value of blockchain technology is that it provides proof of verification of computation.”
This framework uses debt-based paper currency and electronic equivalents together with the mechanism of financial securitization to create multi-factor adesha that operate to create abstract representations of and claims on underlying commodities, equity, or payment flows, priced in the units of account of the debt-based currency.
We now further observe that these financial security instruments together with a bank credit custody framework operate to instantiate and maintain a predominant financial market structure. For our purposes, the salient feature of this traditional financial market structure (Fiat or FNT) is that this market structure maps to a closed network based on a unicentric credit layer that simultaneously also operates as a debt-based insurance subrogation layer.
The Bitcoin solution has made it possible to lower the costs of coordination by orders of magnitude. As a result, the costs of decentralization (or cooperate-cooperate open-source consensus states) can now be far less than the costs of centralization (or defect-defect third-party enforcement rule states). Bitcoin has successfully demonstrated the concept of trust-minimized, decentralized trade networks through working software technology. A growing ecosystem of trade networks with new configurations has been enabled by the Bitcoin solution.
That said, the biggest criticism against Bitcoin or blockchain-based systems is that they cannot scale. A growing recognition that this issue may stem from a category mistake is more clearly revealed through the use of the Nakamoto Framework.
Under the Nakamoto Framework introduced previously in part 1 and part 2, CNT as a whole presents a decentralized system empowered by the resolution mechanism of open-source consensus. The ultimate technical value proposition of a layer 1 blockchain is not to compute a value but to reliably provide non-political and trust-minimized proof of verification of those computations.
If the value proposition of the network service is sufficient to garner demand, then the network token required to access those services has a corresponding value. For example, BTC offers non-political and uncensorable hard money as a network service with extremely high settlement assurance. ETH offers Solidity or automated smart contract technology as a network service. USD offers access to USD denominated trade networks, a deep national and export market, a relatively stable banking and financial sector, robust and predictable contract law, healthy court systems capable of reliable dispute resolution and so on. JPY offers access to JPY denominated trade networks with their associated market structure features. Market participants from multiple viewpoints and positions of interest are in the process of discovering the supply and demand equation ratios for these value propositions, which are then reflected in the demand for the BTC, ETH, USD, and JPY tokens required to access these respective network services.
This, however, does not necessarily imply that each layer of CNT must be equally decentralized. Each layer of CNT may differ in its apparent or actual degree of decentralization, but it is critical to realize that the governance layer in any framework carries the highest weight and ultimately decides whether a system falls within the decentralized CNT or centralized FNT category.
A centralized or distributed multi-centric contracts layer with a decentralized governance layer is a CNT model. But a decentralized contracts layer with a centralized governance layer is an FNT model even if it appears to be presented as ostensibly CNT looking code.
Scaling in this context often refers to transactions per second, which basically means how many read/write operations one can perform on a table in a unit time. Aiming to achieve the desired throughput by changing the rules of a CNT governance layer, however, is a significant compromise on decentralization.
Recall that the ancient Indians, Babylonians, Indonesians, and Chinese solved the scaling problem associated with commodity money by using adesha or mixed letters of credit and bills of exchange. Meaning the local money was stored somewhere safe in a vault by a merchant house, financial institution, government authority, or some other third-party enforcer, and the letter of credit was used as a claim check to redeem the money along different nodes in the inter-spatial trade network.
Since money is natively digital in CNT, cryptographic proofs can be used in lieu of claim checks. In addition, using cryptographic proofs as the currency for payments and trading allows users to spend and trade without giving up custody of their assets to an operator or other “trusted third party” although some users may choose to do that for other reasons such as time preference and convenience. The important thing to remember is that CNT frameworks decentralize power to the user layer such that users are not required to give up custody of their assets to an operator or other “trusted third party” in order to participate and trade on CNT networks. Cryptographic proofs can be traded at the contracts layer, taking advantage of the speed and efficiency of centralized and multi-centric distributed databases, but without an operator holding custody of user assets or private keys.
Cryptographic proofs are to crypto what paper currency is to commodity money.
Chapter 11: Freedom of Choice
In part 2, we discovered that the value proposition of the CNT blockchain governance model is decentralization, which allows the model to make statements about the following without relying on a central authority or third-party enforcer:
By decentralization, we specifically mean decentralization of power, of checks and balances, and reducing the risk of unilateral decision making that can wreck the system. Given that Third-Party Enforcement (TPE) and Forced Network Updates (FNU) might be a good optimization in some cases, identifying what aspects of the system could be centralized versus which ones must be decentralized will make the path to decentralization more practically oriented.
Systems scale when they have the freedom to make choices as opposed to being constrained by the fixed rules of a top-down governance model. A protocol that forces governance upon applications using that protocol compromises this freedom. Had those Indian, Chinese, Indonesian, and Babylonian traders been denied the skills and freedom to write their own contracts and letters of credit incorporated from the Chola adesha, the world would have been the poorer for it.
A relatively slow and costly governance layer using a consensus mechanism with superior thermodynamic security can be a feature for promoting trust-minimized non-political hard money with extremely high settlement assurance at layer 1 governance. Such a global foundation with exceptional thermodynamic integrity could then enable a reduction in the costs of coordination of trade and capital formation by orders of magnitude. Such a reduction in the costs of coordination for trade and capital formation would increase the availability of liquid capital for innovation, which then would result in an increase in the rate of innovation. An increase in the rate of innovation would then result in a concomitant increase in GDP growth, perhaps by multiples, as it occurred earlier with the rise of global liquid commerce powered by the use of the Chola adesha.
A trust-minimized and non-political layer 1 money with extremely high settlement assurance and exceptional thermodynamic integrity would also help mitigate the risk of unwanted manipulation of perceived approximations of units of value by vested interests.
An application that trades these approximations of units of value for commerce at the contracts layer cannot scale if it is subject to complex governance and consensus rules.
In contrast, a protocol that encourages open, trust-minimized, distributed, multi-centric independently operating hubs with minimal governance at the contracts layer incentivizes greater freedom and capital formation.
The ultimate technical value proposition of a layer 1 blockchain is not to compute a value but to reliably provide non-political and trust-minimized proof of verification of those computations. That is, to maintain an independently verifiable record of user balances and other user values in a decentralized database guaranteed by various degrees of thermodynamic security. In such a framework, the contracts layer interfaces with the governance layer only for very specific functions having to do with the fundamental utility of a crypto layer 1 blockchain, namely verification of computation and a read/write update of user balances.
A scalable solution built as a service on top of a layer 1 blockchain at the contracts layer could be centralized or multi-centric to allow third-party enforcement (TPE) and forced network updates (FNU) in discrete and specified ways to make the service better. This freedom would not necessarily adversely affect the overall decentralization and network resiliency of the entire system since the users have the choice to not use the service and because the hubs running the service cannot unilaterally perform read/writes on user values in layer 1 tables without user consent.
“Actually there is a very good reason for Bitcoin-backed banks to exist, issuing their own digital cash currency, redeemable for Bitcoins. Bitcoin itself cannot scale to have every single financial transaction in the world be broadcast to everyone and included in the blockchain. There needs to be a secondary level of payment systems which is lighter weight and more efficient. Likewise, the time needed for Bitcoin transactions to finalize will be impractical for medium to large value purchases. Bitcoin backed banks will solve these problems. They can work like banks did before nationalization of currency. Different banks can have different policies, some more aggressive, some more conservative. Some would be fractional reserve while others may be 100% Bitcoin backed. Interest rates may vary. Cash from some banks may trade at a discount to that from others …”
— Hal Finney 
But is that not the modus operandi of current centralized crypto Exchanges and OTC Desks, one may ask? Yes. The current crop of centralized crypto Exchanges and OTC Desks have attempted to solve for scaling through off-chain transaction processing and by using layer 1 blockchains as the sync layer to update user balances periodically. But this model continues to face challenges in the form of custody, credit, issuance, execution, clearance, settlement, collateral management, transparency, Proof of Solvency, Price Oracles, and cross-chain asset swaps.
We wrote this series to organize our study of various incentive designs and scaling solutions in order to build and contribute Hashflow. We began by recognizing patterns of cognition and behavior within the inner space and then eliminated them systematically until the inner space was emptied of pre-conceptions, pre-cognitions, and pre-planned patterns. Through that process, many common cognitive and behavioral patterns in the global consciousness could be clearly seen manifesting in historical movements.
Accordingly, Hashflow abstracts away various patterns found over the course of history and in the traditional financial market structure.
In traditional financial market structure, for example, the life cycle of an equity security undergoes several transformations such as issuance, dividends, stock splits, etc. These changes in the attributes of the equity represented by the security instrument are then broadcast by the issuer to various nodes in the traditional financial market structure network. These changes in the attributes are then sent out as further notifications to various brokers and institutions that record the changes in a computer file colloquially known as the security master. The security master file is decentralized amongst the various brokers and institutions and is periodically synced through a common set of procedures.
Hashflow turns the back office pattern found in the above example and other abstracted patterns into a market protocol for the development of an open, scalable, trust-minimized, multi-centric, distributed crypto market structure at layer 2.
Hashflow market structure for crypto can solve the problems associated with scaling and provide Exchanges and OTC Desks with automated issuance, execution, custody, credit, clearance, and settlement functions as well as collateral management, transparency, audited market data, and cross-chain asset swaps using logically primitive public key cryptography and Proof of Solvency at the contracts layer.
This approach provides the required benefits to users and the network without requiring modifications to layer 1 blockchains and without the need for a new blockchain or governance layer.
It enables users to trade BTC, ETH, and any other asset that can be parameterized and expressed as an ERC20 contract, as well as other emerging standards such as ERC721, ERC223, and any other contract from the traditional financial market structure that can be expressed as STAs or STOs.
Hint: it’s all in the optimization of multi-dimensional tradeoffs.
Chapter 12: The Hashflow Cognitive Matrix for scalable, open, distributed, trust-minimized market structures
Note — Within the scope of the Hashflow protocol, the term hub can be used to refer to both Exchanges and OTC Desks. Hashflow hubs can also be used to develop other applications such as derivative markets, lending, payment rails, etc.
Custody, credit, collateral, clearance, settlement and scaling solutions for the trading of traditional assets in the traditional financial market structure rely primarily on financial institutions with state-sanctioned charters. The Bitcoin solution and crypto-based consensus and resolution mechanisms for voluntary governance have decentralized this power at layer 1. This has allowed crypto-based technology to open the markets to anyone that wants to start a business and trade native digital assets.
Crypto technology introduces new business models into the issuance, execution, clearance, settlement, custody, Exchange and OTC markets. We observe that securities contracts are abstractions of underlying payment flows and associated contractual rights and claims. Crypto extends the abstraction of securitization and in some ways renders securitization redundant by allowing securities contracts to be instantly cleared and settled with zero counter-party and custody risk and full transparency of underlying operations.
While the emergence of crypto technology has created new and possibly boundary-less vistas for open, tokenized, liquid, scalable, trust-minimized distributed markets, the operational model of the current platforms and technologies that trade native digital assets is very similar to that of institutions in the traditional financial market structure.
Exchange and OTC Desk operators hold custody of user assets or user private keys and remain subject to loss, hacks, embezzlement, and mismanagement. In addition, there is no transparency of operations and traders and Liquidity Providers do not know the solvency status of the Exchanges and OTC Desks.
Fully decentralized Exchange (DEX) protocols solve the problem of custody and transparency but suffer from low speed, poor UI, price variability, and lack of liquidity.
There is a need to bridge this gap and provide the speed, convenience and liquidity features of traditional financial Exchanges and OTC Desks along with the no-custody, transparency, and solvency features associated with DEXs.
We observe that two big cost factors in the traditional financial market structure cause non-trivial capital drag that results in slower rates of user innovation and network GDP growth:
1. Truth in accounting (obtain trust and verification from human blockchain and traditional financial market structure for balance tables-credit-custody-issuance-execution-clearance-settlement-change functions)
2. Collateral management (layered human blockchain and network of claims, premiums, payouts, liens, and backstops) to mitigate the failure of truth in accounting
The table below shows the increasing operational costs of Intercontinental Exchange over the last 8 years. The total cost incurred to obtain truth in accounting and collateral management through (a) third-party vendors, (b) professional services, (c) technology and communication, (d) and general and administrative is exorbitantly high and rises each year.
Observe that these costs only show the net operational expenditure of one hub in the traditional financial market structure. As we sum the total capital spent to achieve truth in accounting and collateral management goals across hundreds of hubs in the traditional financial market structure, this would account for trillions of dollars in revenue loss and misallocated capital.
In addition, in the existing credit custody model of the existing traditional financial market structure, not only are capital allocation and truth in accounting expenses extremely high (in the magnitude of trillions of dollars on a system-wide basis) but large sums of capital either remain tied up as collateral or are unilaterally and inefficiently lent out.
Unlocking the capital misallocated in the system for truth in accounting and collateral management goals, and returning that capital flow to users would reduce the cost of trade, commerce, and capital formation by orders of magnitude. This would correspond to an increase in the rate of user innovation. An increase in the rate of user innovation can increase network GDP by multiples, as well as provide more freedom and wealth to network users on a per capita basis.
In CNT, the truth in accounting goals can be achieved for nearly no cost. The costs associated with collateral management can also be reduced by orders of magnitude by applying the right set of trade-offs. Hashflow uses Ethereum Smart Contracts and cryptographic proofs in Bitcoin to make liquid capital and open financial markets globally accessible through an open, distributed, scalable, trust-minimized crypto market structure with associated functions.
12.1 Scaling ETH
Hashflow scales ETH and any other asset that can be parameterized as an ERC20 contract as well as other emerging standards such as ERC721, ERC223, and any other contract from the traditional financial market structure that can be expressed as STAs or STOs by incorporating an open, trust-minimized, multi-centric, hub-spoke model where distributed financial hubs can (a) host centralized limit order books to execute trades and (b) use a layer 1 blockchain for decentralized key management, periodic rebalance, and net-settlement of user balances. Scaling ETH creates new liquid growth markets for any asset or instrument both in crypto and in the traditional financial market structure. These FNT assets can be parameterized and tokenized in a straight forward manner and traded in CNT systems with all the associated benefits of truth in accounting, custody, credit, issuance, execution, clearance, settlement, collateral management, transparency, Proof of Solvency, audited data feeds and cross-chain asset swaps.
Plasma is a concept for scaling that allows decentralized applications to move transactions off a root blockchain. These transactions are migrated onto other blockchains, called “sidechains” or “plasma chains” which are operated by small validator sets rather than the entire underlying network .
Minimizing the number of validators for certain transaction sets minimizes the costs of coordination required to achieve consensus on the finality of transactions. This, in turn, increases the net throughput or number of transactions per second within the system.
These costs of coordination can be reduced to nearly null, however, by using centralized systems to conduct trades and store trading data as opposed to using sidechains.
Using a trust-minimized, distributed multi-centric hub-spoke model at the contracts layer can offer superior scalability and reduced technical complexity, and yield the same if not better results when compared to building sidechains.
12.2 Proof of Solvency
Accepting that a certain degree of fraud is unavoidable, the incentives for the trust-minimized, distributed multi-centric hubs to act maliciously could be further reduced using dynamic range Proof of Solvency, which makes them auditable, accountable, and transparent in their capital reserves on a continuous basis.
Proof of solvency is measured by comparing the outstanding liabilities of a hub to its total asset reserves. Hashflow achieves Proof of solvency by combining Proof of Liabilities and Proof of Reserves.
Proof of Liabilities
Hashflow hubs are required to put all of their user asset holdings and balances into Merkle Trees and submit Merkle Roots to the blockchain. Using Merkle Trees enables each user to independently verify whether their most recent outstanding balance was included in the proof of liabilities. The more users that verify, the greater the degree of certainty of the proof.
Proof of Reserves
The local liquidity for all assets connected with a Hashflow hub can be independently queried by anyone to ensure that the hub has sufficient liquidity in its reserves to meet its liabilities.
Proof of Solvency = Proof of Reserves + Proof of Liabilities
As mentioned earlier, the Hashflow approach decentralizes power by allowing anyone to start a hub within an open, trust-minimized, distributed crypto market structure with the associated built-in functions of the traditional financial market structure as well as incorporating the benefits of crypto automation and verification. Hashflow crypto market structure offers the functions: custody, credit, issuance, execution, clearance, settlement, collateral management, transparency, Proof of Solvency, audited data feeds or Price Oracles, and cross-chain asset swaps.
Anyone, including financial institutions with state-sanctioned charters, can join the Hashflow network as Hashflow hubs and experience new market opportunities for additional revenue and growth.
With Hashflow anyone, including sovereigns and traditional financial institutions, can create and operate a market structure at almost null cost. Hashflow market structure also reduces the costs associated with truth in accounting and collateral management by orders of magnitude. Hashflow thereby empowers anyone, including sovereigns and traditional financial institutions, to access global markets and global liquidity and allocate capital more efficiently for private and public policy goals.
Hashflow thus shifts the emphasis from eliminating the middlemen to appreciating their value, limiting their power, and making the market for the middlemen more competitive.
Chapter 13: Hashflow Deep Dive
We define Smart Contracts as the trustless or trust-minimized escrows for all the network user accounts. Users deposit their assets into the Smart Contract and reference the hub on which they want to trade. This transaction is recorded on the blockchain. The Smart Contract relays this information to the respective hub via event listeners to allow the hub to update the user balances in its local database.
The users can then communicate instructions to the hub order book and conduct trades off-chain on the hub’s centralized order management system via FIX or other communication protocols.
In order to withdraw assets from the Smart Contract and exit the network, users must submit Withdrawal Proofs to the hubs for the quantity that they want to withdraw.
The hubs perform periodic rebalancing by batching all the incoming Withdrawal Proofs to construct a Merkle Tree and publish its Merkle Root to the blockchain via the Smart Contracts.
The users are allowed to withdraw their assets by providing a valid Merkle Proof once the rebalance is performed.
If the users deposit funds but do not start trading, they are allowed to withdraw their funds instantly without waiting for the rebalance to happen.
The Withdrawal Proof is a cryptographically signed message which contains the total quantity of an asset that the users wish to withdraw. These proofs make up the leaves of the Merkle Tree whose root must be published to the blockchain by the hub. The Smart Contract logic ensures that only addresses that are registered as hubs are authorized to publish the Merkle Root. This is to prevent fraudulent activity from the user in various variations of user: user and user: hub conspiracy models.
In order to reduce the proof size required to verify the user balances post-trading, we use Withdrawal Proofs pointing to the final balances instead of recording every trade on the blockchain. The problem with this tradeoff, of course, is that if a hub account gets compromised, the attacker has the ability to perform a rebalance by using fraudulent Withdrawal Proofs and withdraw funds that they do not own from the hub’s local liquidity pool.
This risk is mitigated and prevented by implementing the following parameters.
13.1 Dispute Time
Each rebalance operation is followed by a dispute time period that prevents users from withdrawing from the contract. This allows the hubs to revert the state update resulting from the current rebalance and recover their account if it learns via the event listeners that the rebalance was performed without their knowledge.
13.2 Minimum Rebalance Time
The minimum rebalance time is the least amount of time required before a hub can perform the next rebalance. This prevents a malicious actor with access to the hub private keys from repeatedly performing inconsistent state updates. Additionally, it allows the hubs to safely recover their accounts and revert the most recent rebalance state update.
13.3 Force Withdrawal
In the traditional financial market structure, margin requirements, both initial and maintenance levels, were instituted as a form of collateral management (layered human blockchain and network of claims, premiums, payouts, liens, and backstops) to mitigate the failure of truth in accounting and to address the risk of major losses to investors trading with borrowed funds. Noting the purpose of Regulation T in the traditional financial market structure, Hashflow adopts this general principle in its design and allows hubs to set force withdrawal boundaries for users based on their risk levels.
Users of Hashflow may unilaterally force withdraw a fraction of their total deposited assets from the Smart Contract at any time. The remaining portion is liquidated as a penalty and becomes part of the hub’s liquidity pool. This design is intended to incentivize the users to stay honest as unilaterally withdrawing the deposited assets after a bad trade will lead to a loss of funds and zero net gain.
Certain hubs may choose to set the Force Withdrawal Limit to 0, whereas other hubs may adjust this boundary, based on their risk profile. If a Hashflow hub engages in purely p2p activities, then the counter-party is at risk of encountering an unfulfilled trade if the Force Withdrawal Limit is NOT 0. Conversely, certain p2p hubs may have a positive Force Withdraw Limit but mitigate the counter-party risk by committing a portion of their net profits back to the local liquidity pool or to the Network Profit insurance (Pi) Pool that will be discussed later. On the other hand, the hubs could also allow the Force Withdrawal to be at 100% if acting as the counter-party for each trade or by running an exchange model.
13.4 Withdrawal Limits
The Withdrawal Limit is a function of the total deposits made by the users into the Smart Contract. The purpose of the Withdrawal Limit is to prevent users from withdrawing more assets than they own. Thus, for an attacker to withdraw a certain quantity of assets, they must first deposit assets equivalent to that quantity. This significantly reduces the incentive for a malicious attacker to launch an attack in the first place.
13.5 Asset Buy Limits
The users must be able to buy and withdraw an asset from the Smart Contract regardless of whether they originally made a deposit for that asset. Proposed current solutions such as Arwen, limit the users to only sell assets that they hold in an on-chain escrow, and buy assets that the hubs have put into an on-chain escrow reserved for their users . This design of collateralized channels, while ostensibly secure, requires the users to know beforehand the assets that they wish to buy. It also forces the hubs to create on-chain reserves for assets that they may or may not have, which significantly reduces the incentive for the hubs to operate in the first place.
A system that allows users to buy an asset and be able to withdraw them without requiring the hubs or the users to possess those assets beforehand is desirable. The hubs may have additional reserves to enhance the user experience or act as the counter-party to bring additional liquidity. This, however, should be a feature and not a requirement. We solve this by defining a Market Asset.
A Market Asset acts as a proxy to convert between different assets in the Smart Contract. Each time the users attempt to withdraw an asset from the Smart Contract, the quantity of that asset gets converted into Market Asset at its current price.
The Smart Contract then computes the Net Balance. The Net Balance for a user is defined as the sum of all assets deposited by that user into the Smart Contract and expressed as a Market Asset.
In traditional monetary economics, the equation of economic exchange is expressed as the following relation:
M = Total nominal amount of money supply in circulation on average in an economy
V = Velocity of money, which is the average frequency with which a unit of money is spent
P = Price level
Q = Index of real expenditures (or quantity of produced goods and services sold)
Note that the velocity (V) in this equation may be redundant/irrelevant for native digital assets because of unbounded digital divisibility and open architecture frameworks.
In Hashflow Tokenomics, the equation for economic exchange is expressed as the following relation:
NB = Net Balance,
Q = Quantity of Asset i,
P = Price of Asset i expressed in Market Asset
If the user’s Net Balance is greater than the quantity of the asset that they wish to withdraw, the Smart Contract allows the user to withdraw that asset.
Input: Withdrawal Proof, Quantity
1. Verify withdrawal proof
2. Convert the Quantity of asset to withdraw into Market Asset at the current Market Price
3. Compute the Net Balance of the user at the current Market Price
4. If Withdrawal Quantity < Net Balance
5. Update Net Balance
6. Convert the Quantity back from Market Asset
7. Update user portfolio balance for that asset
8. Transfer asset to the sender’s address
The Market Asset abstraction creates a vulnerability where the users deposit the Market Asset itself but eventually acquire more in quantity of that particular asset through trades. A dishonest user could use this as a leverage and attempt to withdraw more in quantity of an asset than they own. On the other hand, imposing any form of limit will prevent an honest user from withdrawing what they own.
To solve this problem, we chose BTC as the Market Asset and express the Net Balance of a user in BTC. Since BTC is stored on a different chain, a user’s attempt to withdraw BTC will only update the BTC balance on the Smart Contract. The quantity of ETH/ERC20 assets stored in the Smart Contract would remain unchanged even if a dishonest user attempts to report a false number for BTC withdrawal. In fact, the incentive for the user to act maliciously is non-trivially reduced since reporting a large withdrawal number will only adversely impact their Net Balance and hence the Withdrawal Limit.
13.6 Wallet Providers as the Price Oracles and Data Providers
The Smart Contracts must be updated with the latest prices in order to convert to and from Market Asset when the users attempt to withdraw, resulting in the Oracle Problem.
Allowing hubs to perform those price updates is one possibility. Doing so, however, also introduces a new attack vector. If a hub account gets compromised, it allows the malicious player to perform both price updates and rebalance, which would, in turn, allow them to withdraw any arbitrary amount and potentially drain all the liquidity.
Hence, there exists a need to decentralize this power and introduce another player with properly aligned incentives into the game to minimize this attack vector. We use Wallet Providers for this role.
Current proposed solutions to the Oracle Problem such as the approaches taken by Chainlink and Augur address the Oracle Problem by requiring the Oracles to stake a certain quantity of tokens to incentivize the Oracles to report the data honestly. Requiring Oracles to acquire the network tokens in order to participate in the network may be seen as a feature that helps increase the utility value of the network tokens. Consider, however, that in fact this may be a bug that adversely impacts the incentive design by introducing friction and discouraging participation by any Oracle to begin with. A system design that incentivizes competition without enforcing collateral requirements or token dependency to enable participation is desirable. Hashflow solves this problem by allowing anyone to report market prices but only rewards Oracles whose price data is mutually trusted and used by both users and hubs transacting with each other.
Hashflow allows anyone to become a Wallet Provider and participate in the network by performing price updates to the Smart Contract. The users and hubs may mutually agree to trust certain Wallet Provider services. This incentivizes an open, trust-minimized, scalable, user-centric distributed system with certain Oracles dynamically becoming the Schelling points for reporting prices for certain dynamic user graphs based on certain dynamic user preferences. This also removes the problem associated with a central point of failure as hubs and users will have the choice to select a different Wallet Provider if they mutually decide not to use a service.
It is critical to note that Price Oracles do not update the order books. The market prices are a function of transactions occurring locally on each hub’s order book. Price Oracles query these market prices from various hubs on the network and submit an aggregate price to the Smart Contract. This is done strictly to allow users to withdraw the right quantity of assets from the Smart Contract based on the latest price at which an asset was traded. Therefore, Price Oracles do not affect historical or real-time trading activity.
Chapter 14: Leveraged Liquidity solves the Liquidity Problem
In the late 2000s, Craigslist had one thing that Airbnb did not — a massive user base and associated inventory of listings. Airbnb knew through both market research and their own experience that Craigslist was the place where people who wanted something other than the standard hotel experience looked for listings. In other words, Craigslist users were Airbnb’s target market. In order to tap into this market, Airbnb offered users who listed properties on Airbnb the opportunity to post them to Craigslist. But since Airbnb did not have very many listings to begin with, there was no incentive for users to list on Airbnb.
Airbnb had a liquidity problem. Airbnb’s liquidity comprised ads or listings yet it had to figure out how to incentivize users to list on Airbnb when there was little network liquidity at the initial stages. So the story goes that Airbnb allegedly solved this by leveraging the ads or listings from Craigslist because Craiglist was the player with THE pool of listing liquidity.
Similarly, Google’s fundamental liquidity is the number of links reliably included in its Page Rank. Facebook’s liquidity is the number of active users on its platform. Medium’s liquidity is the number of blog posts available to read.
Liquidity is whatever the network is offering.
For financial Exchanges or OTC Desks, the total quantity of assets in reserve is not liquidity. It is the number of instructions, or quantity of corresponding bid-ask pairs found present at certain thresholds and ratios, available to trade those assets that constitutes the liquidity. Consider that when one describes an Exchange or an OTC Desk to be fast or slow, it is not the transactions per second that is the issue. It is the lack of inventory of instructions available to fill the incoming order that is the problem.
This lack of inventory of instructions in current DEX and CEX and OTC frameworks traces back to the lack of adequate crypto market structure and open trust-minimized protocol instructions that promote ease of use and value transfer as well as proof of security and solvency sufficient to adequately incentivize players with large capital reserves to participate.
14.1 Leveraging Liquidity
In the present model, Exchanges and OTC Desks buy liquidity from Liquidity Providers, other Exchanges, OTC Desks, and a variety of lit and dark pools. Hashflow abstracts this pattern into a protocol and provide hubs with the choice to share their revenue with the Liquidity Providers.
The Liquidity Providers, in turn, have the choice to select and fund hubs and other pools that best fit their incentives.
In addition to automated contracts with Liquidity Providers, the hubs can swap liquidity P2P by adjusting each other’s local liquidity pool balances.
14.2 Scaling BTC
From the graph above, it is apparent that the majority of these instructions are aimed at trading BTC pairs. Most DEXs currently only allow instructions to trade ETH-ERC20 pairs, which is 20% of the total volume compared to BTC, which accounts for 70% of the total volume. To solve this issue, we complimented the protocol by adding BTC support.
Payment channel networks such as Lightning and Interledger can support multi-asset trades, but only if users already have channels with sufficient sending capacity in the asset they want to sell, and sufficient receiving capacity in the asset they want to buy.
One way to solve this is to create a multi-centric, hub-spoke model at the contracts layer with a network of centralized hubs with large asset reserves creating channels and routing payments between peers. But the problem with this solution is that the incentive to maintain a collateralized channel with every new user that joins the network is non-existent. This model could still work if the capacity of the channels is kept relatively small. But doing so will impact the liquidity and trading volume. As a result, neither the users nor the hubs benefit from such a model, resulting in a defect-defect Nash equilibrium.
We solve this problem using Credit-Lightning Channels and Non-Atomic Swaps.
14.3 Credit-Lighting Channels and Non-Atomic Swaps
Lightning Channels must be 100% (or more) collateralized in advance, which is not capital efficient.
To prevent this, Hashflow only requires sellers of assets to fund the channel with assets they want to sell. Buyers and intermediary hubs do not need to collateralize these channels. Instead, buyers and intermediary hubs accept cryptographic proofs backed by deposits made by the seller as a payment.
They redeem this proof at a later date by submitting a Withdrawal Request to the hub and withdraw the purchased assets after the rebalance operation similar to how adesha were used as mixed letters of credit and bills of exchange during the Vedic and Chola periods.
We propose Credit-Lightning Channels where the BTC is stored in 2–2 Multisig Addresses controlled by both the users and the hubs. If the users wish to trade BTC, they must deposit BTC into this 2–2 address. The transaction is then verified on the Ethereum blockchain using Bitcoin-SPV libraries developed at Summa. Once the transaction is verified, it updates the users’ Net Balance in the Smart Contract and allows them to trade off-chain in the same way they would trade Ethereum based assets.
The hubs must maintain a Multisig Reserve Wallet in order to perform Rebalancing. Rebalancing is done by first transferring the BTC from the 2–2 Multisig Wallet of the users that have spent BTC to the Reserve Wallet. Then the BTC is sent from the Reserve Wallet to a 2–2 Multisig Wallet of the users who have received the BTC.
Hashflow requires the presence of a Reserve Wallet instead of allowing the hubs to perform peer-to-peer transfer for the following reasons:
- Easy availability of funds at all times if the users submit a fund Withdrawal Request.
- Minimize the risk of a Honey Pot Attack by making sure that the users only spend the BTC to a known BTC address at all times.
In order to reduce the risk associated with the keys of Reserve Wallet being compromised, it is recommended for the hubs to minimize the quantity of BTC Assets stored in the Reserve Wallet, perhaps to an amount sufficient to meet the users’ Withdrawal Requests. This quantity can more accurately be determined once there is more data on how frequently the users submit Withdrawal Requests. The lesser the number of Withdrawal Requests, the greater the security.
Although maintaining a Reserve Wallet has efficiency gains, it also adds to the security risk. If the Reserve Wallet gets compromised, users who have received BTC while trading are at risk of being unable to redeem their BTC upon submitting a Withdrawal Request due to the loss of funds. This risk, however, is considerably lower compared to the current centralized Exchange protocols that store users’ private keys and could be mitigated if the hub acts as the counter-party or maintains its own reserve of funds to compensate its users for the loss.
If a centralized Exchange or an OTC Desk is compromised, all of its users are exposed to the risk of losing all of their money. If a Hashflow Exchange or OTC Desk is compromised, only net-receivers are at risk of losing some money depending on the balance maintained in the Reserve Wallet. To mitigate this risk even further, Hashflow introduces an automated, distributed loss remedy mechanism in the form of a network insurance layer as described in the subsequent sections.
14.4 Wallet Providers as the Watchtowers
In addition to acting as the Price Oracles, Wallet Providers also act as the Watchtowers to prevent either party (hub or the user) from unilaterally closing the channel. This can allow users to withdraw their funds even if the hub becomes insolvent.
In order to ensure the safety of users’ funds, the hubs must pre-sign the transaction to spend UTXO from 2–2 Multisig to the users’ personal wallet for the quantity they want to deposit before they make the deposit. This transaction is held in the Wallet Provider’s custody and is only revealed to the users if a hub were to become insolvent. This prevents unilateral closure from either party or user fraud.
Similarly, the users are also required to pre-sign transactions that spend a percentage of the UTXO from the 2–2 Multisig address to the Reserve Wallet address of the hubs. The Watchtowers keep custody of these transactions as well and reveal them to the hubs only if the users have spent their BTC during trading and the hubs are attempting to perform rebalance. The percentage of the total UTXOs that the users are expected to spend is defined as the Margin Limit.
The Margin Limit is there to prevent or reduce the counter-party risk if a case were to arise where the users that have spent BTC in the off-chain trading activity refuse to sign the transactions upon receiving requests from the hubs during on-chain rebalancing.
The Margin Limit is not a fixed number. It is determined by the hub and can vary across different hubs based on their risk levels. It could be as low as 0% or as high as 100% of the UTXOs held by the 2–2 multisig address. Higher the number, lesser the counter-party risk. But it exposes users’ funds to the risk of loss if the hub and the Wallet Provider accounts were to ever get compromised simultaneously. Conversely, if the hub sets the Margin Limit to 0%, meaning that the user is not required to pre-sign a transaction that spends any UTXO, it reduces the security risk significantly but increases the counter-party risk if the users default after the trade and refuse to sign the transactions and release their BTC. Optionally, this counter-party risk could be avoided or reduced if the hub were to fund the Reserve Wallet from its personal account to make the user experience better or trade as a counter-party.
Since the risk profiles vary across different users and hubs, Hashflow allows the hubs to dynamically set and adjust their Margin Limit requirements beforehand and allow the users to trade on hubs with the knowledge of risks to which they would be exposed.
The steps to initiate BTC trading can be summarized as follows.
1. Users communicate to the hub the
a. UTXO that they want to deposit into the 2–2 Multisig Address
b. BTC Address to which they would like to receive the UTXO from the 2–2 Mutisig Address in case they decide to withdraw funds2. Hub creates a transaction spending that amount from the 2–2 Multisig Address to the Address provided by the users and sends it to the Wallet Provider3. The Wallet Provider communicates this information to the users4. Upon receiving the information, the users send UTXO to the 2–2 Multisig Address5. User creates a transaction spending the amount corresponding to the Margin Limit from the 2–2 Multisig Address to the Reserve Wallet Address provided by the hub and sends it to the Wallet Provider6. Both the partially signed transactions remain in custody of the Wallet Provider who acts as the Watchtower and reveals the transactions to the users or the hubs for signing and broadcasting if the hub becomes insolvent or if the user has spent the BTC while trading, respectively.
Chapter 15: User-Based Incentive Design
We found distributed incentive design to be a disproportionately ignored yet important consideration for our purposes in building Hashflow. This is not to say, however, that “incentives” explain the mystery of human behavior, desires, and cognition. At the same time, it is observed that people do respond to economic incentives given certain conditions. On the other hand, the very cognition of the incentive itself may reflect only an incomplete viewpoint on life and may not work as intended if that viewpoint or cognition changes.
15.1 No Upfront Collateral
Having Withdrawal Limits disincentivizes bad user behavior by disallowing the users to withdraw more than they deposit. But as a hub operator, it introduces a collateral constraint when withdrawing the revenue generated through commissions from the Smart Contract. The collateral requirement for a hub to operate may be seen as a feature as evident in other scaling solutions such as Lightning, but it may also be viewed as a bug from another angle. Lightning Supernodes cannot scale to conduct commerce because the overhead capital cost required to run such a supernode exceeds the returns.
If the goal is to reduce the cost of starting an Exchange or an OTC Desk, imposing collateral requirements or collateralized payment channels is counter-intuitive.
Hashflow, therefore, eliminates the collateral requirement condition and still allow each hub operator to periodically report their profits and withdraw from the Smart Contract. There exists, however, a need to introduce boundary limits on the quantity of assets that can be withdrawn by a hub in order to prevent malicious players from draining all the assets from the hub’s local liquidity.
For a hub, the Withdrawal Limit is defined as the maximum quantity that can be periodically withdrawn by a hub from its local liquidity pool in a single transaction. Hashflow hubs have the choice to commit a portion of their reported profits to the Network Profit insurance (Network Pi) Pool. This portion is used to determine the Withdrawal Limit of the hub.
Similar to Rebalance, commissions can only be reported periodically and each commission report is followed by a Dispute Time to allow the hubs to detect any malicious activities using event listeners and revert the state update if necessary.
1. Percentage of total profit committed = Withdrawal Limit of the hub2. Withdrawal Limit (expressed as percentage) = quantity of assets that the hub can periodically withdraw from its local liquidity pool in a single transaction
If a hub commits 100% of its profits to the Network Pi Pool, their personal profit would be 0, thus preventing them from withdrawing any assets. Conversely, if they do not commit any portion to the Network Pi Pool, they would not be able to withdraw anything either since their Withdrawal Limit would be 0. As a result, the hubs are incentivized to maximize their local liquidity and adjust their Network Pi Pool contribution based on what best fits their risk profile as well as the revenue being generated.
This model of contributing a portion of the profits to the Network Pi Pool could be perceived by the hubs as a massive downside in the form of expensive tax. But this perception is an error.
It is critical to understand that the contribution made by the hubs to the Network Pi Pool is not a tax.
In fact, it is a reimbursable premium paid towards an automated, subrogated, self-insurance pool that protects the hubs against any future losses. Crucially, in Hashflow crypto market structure, hubs can reclaim their premium payment (i.e. the portion of commissions that they had previously committed to the Network Pi Pool) using Hashflow Tokens (HFT).
The hubs through HFT and periodic Withdrawal Limits always have access to their full set of commissions or network profits despite having contributed a portion of the commissions to the Network Pi Pool.
15.2 Hashflow Token (HFT) and User Benefits
Current frameworks and approaches use tokens (e.g. Chainlink, Augur, Algorand and other protocols using proof of stake) to coerce actions deemed good for the network and punish actions deemed bad.
The two cipher prime incentive rules in existing networks are punishment and violence.
Hashflow cognizes a different game theoretical optimization where we allow for the logic of contribution to incentivize shared wealth creation through voluntary cooperation around an open-source token.
Hashflow token logic allows the HFT holders to actually capture cash flows in the form of network profits, unlike other tokens that have a nominal representational value based on belief. Moreover, unlike other network token approaches, if the users do not have HFTs, they can still access the network service. The protocol carries no dependency on HFTs to execute any function.
A token is a representation of network utility value. Fundamental utility token value must ultimately be tied to a service or function that is in demand, which the token unlocks. Similarly, the fundamental representational token value must ultimately be tied to a claim on future network cash flows.
If this tie-up between representational token value, network utility value, and contractual claims on network cash flows is not cryptographically guaranteed, then the token will find it challenging to retain or grow value in the open market.
This is the main reason why some “ERC 20 tokens” and other network utility and network security tokens lose value in the secondary market or why some tokens are ultimately removed from the code or forked.
Observe that BTC and ETH are utility tokens because their network services are in demand. In the case of BTC, for non-political and uncensorable hard money with extremely high settlement assurance, and in the case of ETH, for automated and programmable Smart Contracts (Solidity), respectively. It then follows that layer 1 ETH and BTC flows are the silver and gold flows that underpin the representational token value.
Similarly, a second-order layer 2 token can have value if it (1) represents AND (2) has cryptographically guaranteed contract claims on the underlying commissions or hashflows in the network as expressed in the currencies used by the Hubs to charge commissions.
Recall that the Network Pi Pool we defined earlier expands over time as more hubs join the network and commit a portion of their profits from trades to this pool. This pool is comprised of cash flow generated from network activity in the form of trades. This cash flow is called commission and can take the form of BTC, ETH or any other asset parameterized as an ERC20 contract token that the hubs decide to accept. These pools of profits or cash flows resulting from network operations can be claimed by the second-order token, which represents and guarantees withdrawal access to the growing bundled value of network profits. This growing bundled value is abstractly represented by the Hashflow Tokens (HFT).
HFT represents AND guarantees withdrawal access to the growing bundled value of network profits or hashflows. HFT gives the owners of the token actual enforceable cryptographically guaranteed rights to the network profits or hashflows in the form of BTC and ETH.
Users with HFTs can stake them into what we define as the Hashpool.
Hashpool Balance = Total HFTs staked by all users
The Smart Contract then computes the ratio of each user’s staking balance against the total Hashpool balance. This ratio is used to determine User Payouts, i.e, the total amount that the users can periodically withdraw from the Network Pi Pool.
User Payouts = HFT staked by the user * Network Pi Pool balance / Hashpool Balance
15.3 Subrogation Layer as Network Insurance
Hashflow creates a distributed network-wide insurance subrogation layer in lieu of capital reserves or collateral to incentivize Proof of Solvency and loss remedy. That is, anyone can stake HFTs into the Hashpool. The users’ stakes in the Hashpool with respect to the total stakes in the Hashpool determines the users’ claims on the Network Pi Pool. We euphemistically call this pool the Network Pi Pool simply because that pool is created from certain cashflows in the form of hashflows or layer 1 money strings in order to operate a profit insurance pool. But irrespective of the source, there remains a pool and owners of the HFT can withdraw from the pool in the form of payouts based upon a ratio table.
Rather than locking up collateral or buying insurance, users subrogate collateral and capital reserves and insure against trading losses and hacks through automated self-pooled insurance. This way, if they were to incur any loss due to bad trades or operational failure of the hub itself, the funds in the Network Pi Pool can act as the insurance pool to recover those losses without the need for third-party dispute resolution or other forms of third-party intermediary loss remedy mechanisms, and their associated costs of coordination.
In the traditional financial market structure, the goal of the insurance pools is to subrogate all the middle layers and take care of the loss in the most frictionless and most capital-efficient way possible. Despite these measures, the costs of coordination for two strangers to negotiate a deal, lock up collateral, procure insurance, or otherwise settle disputes or establish mechanisms of loss remedy in a courthouse is quite high, especially across geospatial boundaries. As a result, the predictable defect-defect Nash Equilibrium condition obtains with its concomitant drag on rates of network GDP growth, capital formation, and wealth creation.
Users are not required to own HFT to trade on the network. Instead, users mint HFT each time they provide liquidity to the network in the form of ETH or BTC. In order to calculate the amount of HFT that will be minted, we first compute the mint ratio for the hub, which is the ratio of its local ETH or BTC liquidity to that of the global liquidity of the entire network. This is to prevent a malicious hub from minting HFTs without a significant liquidity contribution to the network.
Mint Ratio = local hub Liquidity (in ETH or BTC) / Global network liquidity (ETH)
The Mint Ratio is then used to calculate the HFTs available to mint using the following relation
HFTs available to mint = Mint Ratio * Total HFTs yet to be minted
Finally, the quantity of HFTs minted is computed by calculating the ratio of liquidity provided by the user and the local liquidity of that hub.
HFTs minted = Liquidity Provided (in ETH or BTC) * HFTs available to mint / Local hub liquidity (in ETH or BTC)
The minted HFTs are distributed among the active players in the following proportions:
70% is minted by the Liquidity Provider20% is claimed by the Hub to which the liquidity was provided10% is claimed by the Wallet Provider that was used by the user and the Hub to enable transfer
Note — While the minting is currently a function of BTC or ETH liquidity in the network, more assets maybe added to the class of assets that allow for HFT minting in the future.
In a CNT framework, no user can be forced to borrow and use a particular token. Rather, users are offered the choice to acquire or invest in any token of their preference based on which network they find valuable. The value of the token is a measure of the users’ perception of the network utility value and depends on factors including the type of service the network offers, the network hash rate, whether the token provides claims on an underlying hashflow, whether the token is unforgeable and uncensorable, whether the token dynamics are designed for political manipulation, the token supply amount (limited or unlimited), the attention of developers, intensity of community support, number of users in the network, and so on.
In sum, Hashflow creates a layer 2 market structure for crypto that incentivizes players of the game to strengthen the integrity of the network, grow the network profits and insure against losses.
Hashflow market structure for crypto scales BTC and ETH and ties them together for mutual benefit in a non-zero sum game. This creates an integrated BTC-ETH-Hashflow game that provides anyone, including Exchanges, OTC Desks, Capital Allocators, Liquidity Providers, Sovereigns, Banks, Hedge Funds, Insurers, Corporate Actors, Technology Networks, Humans, Machines, etc., with automated issuance, execution, custody, credit, clearance, and settlement functions as well as collateral management, transparency, audited market data, and cross-chain asset swaps at nearly null cost using logically primitive public key cryptography and Proof of Solvency at the contracts layer.
The concept of the game mechanics of non-zero sum token design is an interesting one and worth investigating further. We will continue our study of token dynamics in part 4 of the series.
Some frameworks and patterns abstracted out by Hashflow
lokah samastah sukhino bhavantu
om namo narayana om nithyanandam
Donate: BTC bc1q5crw5ygzwpff7f0a2fcq6equh6ga5z4cnwwlrh
 Taylor, Allen. “The Evolution of Credit: From Mesopotamia to Marketplace Lending”.
 Martin Jan Mansson. https://imgur.com/UJKFytj
 Baker, R. D. “The Implausibility of the Barter Narrative & Credit Money in Ancient Babylon.” The Developing Economist 1.1 (2014). http://www.inquiriesjournal.com/a?id=1396
 Galli,Marco. Beyond frontiers: Ancient Rome and the Eurasian trade networks, Journal of Eurasian Studies, Volume 8, Issue 1, 2017, Pages 3–9. https://www.sciencedirect.com/science/article/pii/S187936651630032X?via%3Dihub
Wikipedia contributors. “Negotiable instrument.” Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/wiki/Negotiable_instrument
Wikimedia Commons contributors, ‘File:Map of the Periplus of the Erythraean Sea.jpg’, Wikimedia Commons, the free media repository. https://commons.wikimedia.org/wiki/File:Map_of_the_Periplus_of_the_Erythraean_Sea.jpg
 Wikimedia Commons contributors, “File:Hinduism Expansion in Asia.svg,” Wikimedia Commons, the free media repository, https://commons.wikimedia.org/w/index.php?title=File:Hinduism_Expansion_in_Asia.svg&oldid=333273083
 Hall, Kenneth R. “Ports-of-Trade, Maritime Diasporas, and Networks of Trade and Cultural Integration in the Bay of Bengal Region of the Indian Ocean: C. 1300–1500.” Journal of the Economic and Social History of the Orient 53, no. 1/2 (2010): 109–45. http://www.jstor.org/stable/25651214.
 Hall, Kenneth. (2016). Commodity Flows, Diaspora Networking, and Contested Agency in the Eastern Indian Ocean c. 1000–1500. TRaNS: Trans -Regional and -National Studies of Southeast Asia. 4. 387–417. 10.1017/trn.2016.21. https://www.researchgate.net/figure/Fifteenth-century-view-of-the-inclusive-Indian-Ocean-maritime-trade-route-from-China-to_fig2_307555391
Rodrigue, Jean-Paul. https://transportgeography.org/?page_id=1048
Wikipedia contributors, “Battle of Talas,” Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=Battle_of_Talas&oldid=906632844
“Trade Routes in Medieval Islamic World.” Pearson Education, Inc.
Kobayashi K. (2018) The British Atlantic Slave Trade and Indian Cotton Textiles: The Case of Thomas Lumley & Co.. In: Shiroyama T. (eds) Modern Global Trade and the Asian Regional Economy. Monograph Series of the Socio-Economic History Society, Japan. Springer, Singapore
 Blog Editor, Indian cotton textiles in eighteenth-century Atlantic economy
 O’brien, Patrick. Philips’ Atlas World History. AtlasWorldHistory
World Silver Flows 1650–1750
Paul Kennedy, The Rise and Fall of the Great Powers: Economic Change and Military Conflict from 1500 to 2000, HarperCollins, 1989; Paul Bairoch, Victoires et déboires, histoire économique et sociale du monde du XVIe siècle à nos jours, vol II, Gallimard “Folio Histoire”, Paris, 1997; Angus Maddison, L’Economie mondiale: une perspective millénaire and Statistiques historiques (published in 2001 and 2003 respectively), Etudes du centre de développement, OECD, Paris.
Das, Gurcharan. “All the world’s gold.” https://www.thehindu.com/features/magazine/all-the-worlds-gold/article2395912.ece
 Finney, Hal. Re: Bitcoin Bank December 30, 2010, 01:38:40 AM
”The Biggest Cryptocurrency Hacks and Scams”
Akentiev, Anthony. “Plasma in 10 mins”. Available: https://medium.com/chain-cloud-company-blog/plasma-in-10-minutes-c856da94e339
 Robinson, Dan. “The Rainbow Network: An Off-Chain Decentralized Synthetics Exchange”. Available: https://rainbownet.work/RainbowNetwork.pdf
”Airbnb: The Growth Story You Didn’t Know”
Robinson.Dan. “The Rainbow Network: An Off-Chain Decentralized Synthetics Exchange”. Available: https://rainbownet.work/RainbowNetwork.pdf