Liquidity

To be useful as a stability solution, AnyHedge must meet the needs of all contract parties. Especially, takers with high time preference must be able to fill their desired volume of contracts within a short time and with predictable premiums. Fulfilling these needs requires a large amount of liquidity which we describe as easily accessible market makers competing at all times on both Hedge and Short sides. In this section, we explore different setups in matchmaking, their impacts on liquidity, and the trade-offs they incur.

1. Centralized

While AnyHedge is decentralized in nature, it still requires that Hedges and Shorts find each other efficiently. Decentralized exchanges are an excellent fit for AnyHedge but they face a difficult problem: centralized exchanges currently provide the most responsive and scalable matchmaking, and by extension attract the most liquidity with the lowest spread. For this reason, we foresee that AnyHedge will first be deployed on centralized exchanges, with centrally controlled and permissioned order books combined with a non-custodial client-side wallet. This setup preserves all advantages of AnyHedge, including no custodial risk, except that the exchange is aware of the details of the contract.

The order book is an important point of failure in the stability mechanism and therefore centralized control over it is a risk. However, just as liquidity is scattered across many centralized exchanges today, as AnyHedge adoption grows the market will become more resilient to censorship and failure of any single exchange.

2. Federated

Using the non-custodial nature of AnyHedge, exchanges can open up an API for their maker orders, allowing them to trustlessly coordinate AnyHedge contracts with external takers while guaranteeing their own fees. This offers a good balance for the implementing exchanges. As the liquidity pool deepens, more volume is attracted and both exchanges can benefit. Liquidity sharing is traditionally achieved by arbitrage but that may be difficult here because the contracts are less fungible than typical asset pairs. Exchanges can negotiate among themselves how they intend to divide the fees and they can refuse connection to unauthorized or uncooperative peers. Over time, multilateral cooperation can evolve into a de facto federation with users getting the benefits of a wide view of liquidity, a measure of robustness against censorship and an unfragmented, highly liquid order book. We envision that the global and trustless pool of demand will in fact attract a new class of second layer services such as point of sale systems and peer-to-peer banking, growing the whole market for participating exchanges.

3. On-chain

AnyHedge is not fundamentally reliant on exchanges. Any two willing parties who have access to an oracle can enter a contract. However in practice, liquidity discovery and efficient matchmaking immediately becomes a problem without a centralized book. We envision that just as OTC trading desks exist elsewhere, tools will be released for ad-hoc contracts independent of any exchange. Where they suffer in liquidity and trading speed, they make up by enjoying high degrees of privacy, independence from a permissioned order book, and greater flexibility to choose or even provide their own oracles.

Bitcoin Cash covenant-based funding contracts can also be created to facilitate such independent trading. An on-chain maker can fund a P2SH output that establishes all contract parameters except for the counterparty’s payment details. A counterparty who agrees with the terms can complete the funding and redeem the funding contract into a complete AnyHedge contract. The presence of these funding contracts on the blockchain will act as a censorship resistant, trustless, permissionless order book with global liquidity. However at least in the medium term, we expect the relatively high friction of fees and race conditions for funding and revocation to lead to less liquidity than centralized and federated options.