User Experience

We expect to first deploy AnyHedge in a centralized exchange via non-custodial wallets and then expand to other exchanges that will ideally be federated. As liquidity builds up, non-exchange products such as merchant solutions can be built on top of and contribute to the overall liquidity. Highly privacy aware users or those needing censorship resistance may start using decentralized order books.

Deployment with custodial wallets is possible, but it is unlikely to gain widespread adoption. A custodial AnyHedge wallet acquires the censorability and custodial risk of existing custodial futures products, while maintaining an onchain footprint. This makes such a setup unlikely to be competitive with existing solutions. It is possible some forms of custodial solution may offer better user experience and gain adoption, but we do not expect them to be dominant.

A typical setup will likely start with a non-custodial client-side wallet either implemented as a script embedded in a web page, or a dedicated program the client runs outside the browser. If a dedicated client is developed, it can either be standalone, or integrate into an existing extensible wallet such as Electron-Cash.

In its most basic form, funding an AnyHedge contract requires both parties to be online for interaction. For market makers, this means they will need to stay online to find takers, a reasonable requirement considering their general need to adjust to changing market conditions.

To maximize liquidity and ensure good user experience, we expect AnyHedge order books to settle around a small number of fixed parameters such as duration, allowed price change before liquidation, and hedge amounts. Market makers can compete by offering different premiums on both the Hedge and Short side. Common parameters are even more valuable in the context of federated liquidity and a future secondary market of transferable AnyHedge contracts.

On the taker side, we expect speculators to use the full order book for optimal efficiency. For application-specific uses of AnyHedge we expect that more convenient user interfaces will be available that expose an underlying ask book through fixed premiums, similar to popular swap services. Both trading and applicationspecific interfaces should be possible regardless of whether the liquidity comes from centralized exchanges or a federated liquidity pool.

On the other end of the user spectrum, ad-hoc contracts with arbitrary parameters are possible for sophisticated users with specialized needs. Construction of these contracts is similar to existing multi-signature transactions where one party specifies parameters, constructs a transaction, and passes it to the other party to be fully signed and broadcasted.

When sufficient liquidity is available, merchant solutions can offer automated hedging in arbitrary units for received Bitcoin Cash. Providers of automated solutions may even enter long term contracts with liquidity providers independent of existing order books to offer predictable, stable premiums.

Another way to package AnyHedge contracts is as a fixed deposit account. Savers may enter longer term hedging contracts, with services that assist with renewal at maturity or liquidation. These arrangements are strongly linked to real market conditions where savers will earn or pay a premium depending on supply and demand.