Frequently Asked Questions
Hitchhiker’s Guide to the Hashflow Network
Last Updated: Sep 25, 2019
Bitcoin offers non-political and uncensorable hard money as a network service with extremely high settlement assurance and thermodynamic security. Ethereum offers Solidity and automated Smart Contract technology as a network service. Hashflow scales ETH and BTC at layer 2, by integrating Multi-Centric Distributed Plasma, Credit-Lightning Channels, and Non-Atomic Swaps to offer low-latency, non-custodial trading platforms as a network service.
Hashflow is a distributed network of open, trust-minimized, multi-centric hubs built on Ethereum and Bitcoin, each offering non-custodial, low-latency trading across different markets. These hubs comprise a scalable ecosystem that provides the speed, convenience and liquidity features of traditional financial Exchanges and OTC Desks along with the non-custody, transparency, and solvency features associated with DEXs.
No, Hashflow is not a blockchain. It is a layer 2 solution built on top of Ethereum and Bitcoin. All trading activities are conducted off-chain using Financial Exchange (FIX) protocols and layer 1 blockchain is used for managing custody, rebalance, and net-settlement.
Hashflow scales ETH and BTC and ties them together for mutual benefit, without requiring layer 1 mods, sidechains, or new blockchains.
Hashflow provides 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.
Hashflow provides anyone, including Exchanges, OTC Desks, Traders, Capital Allocators, Liquidity Providers, Banks, Hedge Funds, Sovereigns, Insurers, 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 SPV Proofs and Proof of Solvency.
Hashflow uses Ethereum Smart Contracts and Bitcoin Credit-Lightning Channels to store assets and perform rebalance and net-settlement. Hashflow achieves interoperability using Non-Atomic Swaps developed by Summa. All other operations are performed at layer 2 by open, multi-centric distributed hubs which operate independently and compete for business.
Hashflow incorporates a hub-spoke model where distributed, trust-minimzed financial hubs can (a) host Centralized Limit Order Books (CLOBs) and centralized transaction ledgers in local databases to execute trades and (b) use a layer 1 blockchain for decentralized key management, periodic rebalance, and net-settlement of user balances.
Performing all computations off-chain and performing periodic rebalances as users choose to withdraw removes unnecessary gas consumption, prevents the layer 1 blockchain from clogging, and makes the system capital efficient.
Each time a user wants to withdraw funds from the Smart Contract, they submit a Withdrawal Proof to the hub which contains the amount that they would like to withdraw. The hub constructs a Merkle Tree and submits the Merkle Root of these Withdrawal Proofs to the Ethereum Smart Contract. Once the Dispute Time has passed, users can provide the Withdrawal Proof and withdraw their funds from the Smart Contract.
The Withdrawal Proof is a cryptographically signed message that 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.
No. Anyone can register themselves as a hub in the Smart Contract.
A malicious user and a hub could theoretically conspire to include a Withdrawal Proof with false values. These downside risks and range of losses are mitigated using Dispute Time, Minimum Rebalance Time, Force Withdrawal, and Withdrawal Limit.
In order to reduce the proof size required to verify the user balances post-trading, Hashflow uses Withdrawal Proofs pointing to the final balances instead of recording every trade on the blockchain. The risks associated with this model are mitigated using Dispute Time, Minimum Rebalance Time, Force Withdrawal, and Withdrawal Limit.
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.
Hashflow encourages the use of traditional databases instead of sidechains for superior scalability and reduced technical complexity. However, hubs have the freedom to still deploy sidechains if they prefer.
Each rebalance operation is followed by Dispute Time that prevents the 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 they learn that the rebalance operation was performed without their knowledge via the event listeners.
The length of Dispute Time is dynamic and different for each individual hub. It is set by the hub during the initial registration process.
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 to the most recent rebalance state update.
The length of Minimum Rebalance Time is dynamic and different for each individual hub. It is set by the hub during the initial registration process.
Users are allowed to force withdraw their assets from the Smart Contract at any given time. However, the percentage or fraction of the total assets that can be force withdrawn by a user is determined by the hub at the time of registration.. Users can use this metric to assess the risk before they trade on the hub.
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. This allows users to buy an asset and be able to withdraw them without requiring collateralized user-hub channels for that specific asset.
Proposed current solutions such as Arwen, limit the users to only sell assets that they hold in an on-chain escrow, and to buy assets that the hubs have put into an on-chain escrow reserved for their users. 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 counterparty to bring additional liquidity. This, however, should be a feature and not a requirement. We solve this by defining a Market Asset.
Since BTC is stored on a different chain, any user’s attempt to request BTC withdrawal 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 malicious player attempts to report a false number in order to withdraw BTC.
Hashflow stores BTC 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.
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. 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.
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.
All trades are backed by user deposits into the Smart Contract. Funds can only be withdrawn after a Withdrawal Proof has been submitted and a rebalance has been performed.
The hubs must maintain a Multisig Reserve Wallet in order to perform rebalancing. Rebalancing is done by first transferring BTC from the 2–2 Multisig Wallet of the users that have spent BTC to the hub’s Reserve Wallet and and then transferring those funds from the Reserve Wallet to the 2–2 Multisig Wallets of the users who have received BTC.
Hashflow requires the presence of Reserve Wallets for the following reasons: (a) Easy availability of funds at all times if the users submit a fund Withdrawal Request. (b) Minimize the risk of a Honey Pot Attack by making sure that the users only spend BTC to a known BTC address at all times. However, hubs have the choice to not maintain a Reserve Wallet and implement a p2p mechanism instead.
Although maintaining a Reserve Wallet has efficiency gains, it also adds to the security risk. If the Reserve Wallet gets compromised, users who bought BTC while trading are at risk of being unable to redeem their BTC upon submitting a Withdrawal Request if there was an attack and a loss of funds.
This risk can be mitigated if the hub acts as the counterparty or maintains its own reserve of funds to compensate its users for the loss. If the hub were to operate on p2p basis, this risk can still be reduced by minimizing the quantity of BTC Assets stored in the Reserve Wallet, perhaps to an amount sufficient to meet the users’ Withdrawal Requests.
The lesser the number of Withdrawal Requests, the lesser the need to rebalance, smaller the surface area for an attack, more secure the system is.
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. 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.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.
Similar to hubs, 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 and store it with the Watchtowers. If a user has spent BTC, then the Watchtower allows the hub to sign the transaction and broadcast it.
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. This percentage is defined as the Margin Limit.
The value of Margin Limit is dynamic and can vary depending on the hub. Hubs with sufficient BTC reserves may not require users to pre-sign any amount. Other hubs must set their Margin Limits beforehand so that the users are aware of the risks before they transact with the hub.
No. Hashflow uses Summa’s Non-Atomic Swaps to verify BTC transactions on Ethereum and update user balances accordingly.
For a hub, the Withdrawal Limit is defined as the maximum quantity that can be periodically withdrawn 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 (Pi) Pool. This portion is used to determine the Withdrawal Limit of the hub.
Rather than locking up collateral or buying insurance, Hashflow hubs insure against trading losses and hacks through an automated self-pooled insurance by contributing a portion of their revenue generated via commissions to the Network Pi Pool. 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.
Hashflow token logic allows the HFT holders to capture cash flows in the form of network profits from the Network Pi Pool. 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.
The users’ HFT stakes with respect to the total stakes in the network determine the users’ claims on the Network Pi Pool.
A user can mint HFT by depositing ETH or BTC into the network and providing liquidity. The amount of HFT minted is calculated based on the ratio of the user’s contribution in relation to the global reserves of ETH or BTC in the network.
The minted HFTs are distributed among the active players in the following proportions:
70% is minted by the Liquidity Provider (User that deposits ETH or BTC)
20% is claimed by the hub to which the liquidity was provided
10% is claimed by the Wallet Provider whose service was used by the user and the hub to enable transfer
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.
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.
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.
Hubs can implement flexible commission structure to suit their business, save millions in operational costs, and facilitate trading without storing user keys. They have the freedom to set their own metrics for the periodicity of Minimum Rebalance Time, Dispute Time, Commission Rates, Fee Currency, Margin Limits, etc. Additionally, they can mint Hashflow Tokens (HFTs) by incentivizing Liquidity Providers to provide liquidity.
Wallet Providers act as the price oracles and must query market prices from various Hashflow hubs’ Central Limit Order Books (CLOBs) and report them to the Smart Contract. In addition, they act as the Watchtowers and prevent a user or the hub from unilaterally broadcasting BTC transactions to the blockchain.
Wallet Providers can mint HFT and get access to cashflows, if both the hub and the user mutually agree to use their service.
No. Hashflow doesn’t require the staking of tokens to perform an action. On the contrary, it rewards the services with tokens depending on their level of contribution to the network.
Your funds can only be unlocked using your public/private keys. Furthermore, each user has a Withdrawal Limit which is based on the amount that they deposit into the Smart Contract. To minimize this risk further, each rebalance operation is followed by Dispute Time that prevents users from withdrawing from the contract. This allows the hub to perform account recovery and prevent loss of funds.
Moderators are accounts chosen by the hub and help the hub with the account recovery process. It is similar to having a backup email to recover an account.
Each hub is referenced by its hub ID in the Smart Contract and the hub public key points to this hub ID. If a hub suspects that its account got compromised, it can use one of its moderator accounts to help replace the public key that was pointing to the hub ID with a new one and negate the impact of an attack if there is any.
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 Solvency = Proof of Reserves + Proof of Liabilities
Hashflow hubs are required to put the value assoicated with all of their user asset holdings and balances into Merkle Trees and submit Merkle Roots to the blockchain. Using Merkle Trees enables users to independently verify whether their most recent outstanding balance was included in the Liability Proofs. The more users that verify, the greater the degree of certainty of the proof.
Hashflow hubs must give users access to all the Merkle Leaves and the corresponding balance values associated with those leaves respectively. In order for the Liability Proof to be verified, (a) the sum of all balances must equal the total reserves in the Smart Contract (b) the users must be able to randomly submit any leaf to the contract and independently verify whether it was included in the Merkle Tree.
Users can withdraw 100% of their deposits if the Liability Proof is not submitted on time.
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.
Yes, but the hub needs to set up another account that is not linked with the hub ID in order to trade.
Hubs have 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, and trading off-chain on each other’s CLOB.
Using Non-Atomic Swaps allows users to update their BTC balance on Ethereum Smart Contracts and be able to withdraw other Assets equivalent to the value of BTC deposited. It also allows Liquidity Providers to mint Hashflow Tokens (HFTs) if they deposit BTC.
Yes, this is an attack vector and users must be aware of the risk and only transact with Wallet Providers or hubs that they trust. To reduce this attack further however, each price update by an oracle is followed by a time lock period before the prices are considered final and can be used to compute the Withdrawal Limits. This allows the users to exit if they detect any suspicious activity.
Hashflow can be used by Exchanges, OTC Desks, Wallet Providers, Liquidity Providers, Traders, and all other players wanting to create financial markets that can scale without storing user private keys.
Hashflow provides anyone, including Exchanges, OTC Desks, Traders, Capital Allocators, Liquidity Providers, Banks, Hedge Funds, Sovereigns, Insurers, 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 SPV Proofs and Proof of Solvency.
Our Smart Contracts are currently being audited and will be made public after the audits are complete.
Hubs and Wallet Providers could theoretically all come together to conspire against the users to skew market prices and then drain the network liquidity by performing a rebalance with false Withdrawal Proofs. It must be noted however that these actions are completely transparent and followed by timelocks. Anyone can setup event listeners to know instantly if a Hub or a Wallet Provider is conspiring and will have the chance to force withdraw the funds.
Plasma
Hashflow
Application specific transactions are migrated to sidechains operated by small validator sets
Yes
No
Application specific transactions are stored in centralized databases hosted by multi-centric hubs
Yes
Yes
0x, Uniswap
Hashflow
All transactions are settled on-chain
Yes
No
Lightning
Hashflow
Supernodes require collateral
Yes
No
Credit-based Channel
No
Yes
Watchtowers ensure integrity
Yes
Yes
Arwen
Hashflow
Users can only buy assets if the hub has an on-chain reserve for those assets with the user
Yes
No
Uses individual Channel capacity to determine the buying limit for the user
Yes
No
User Net Balances expressed in Market Asset price to determine the buying limit
No
Yes
Chainlink, Augur
Hashflow
Force Oracles to buy native token and use as collateral
Yes
No
Reward Oracles that show user growth and whose data is widely used
No
Yes
Maker, tBTC
Hashflow
Unicentric Price Oracle
Yes
No
Multi-centric trust-minimized Price Oracle
No
Yes
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 Traders, 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.
Figure ∞: High-Frequency Large-Value Transfer systems in Hashflow and Traditional Financial Market Structure
Coming soon....
Ready to experience Hashflow?
Read the whitepaper and learn more.