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.

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 funds 2. 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 Provider 3. The Wallet Provider communicates this information to the users 4. Upon receiving the information, the users send UTXO to the 2–2 Multisig Address 5. 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 Provider 6. 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.