Chain Reorganizations

Building a contract on a permissionless blockchain carries the inherent risk of being exposed to irregularities of the underlying chain. In the case of Bitcoin Cash, this manifests primarily as chain reorganizations and splits. Reorganizations can either occur naturally due to propagation latencies, or as a result of malicious hash-power-based attacks. A split in this context refers to deliberate extensions of alternative tips which subsequently gain their own value.

As an external source of data, block-height-based oracles should remain deterministic in the event of reorgs and splits. In other words, oracles must not sign different data for the same timestamp or block height, as long as they keep the headers of corresponding blocks as proof. As block emission is used only as a proxy to time, there is no special requirement to adhere specifically to a block that wins an orphan race. On the other hand, signing two messages for the same height with different price data creates race conditions and opens contracts to potential disputes. An oracle that double-signs should be considered compromised, and discouraged from further use.

Assuming the oracle maintains a trustworthy feed, contract maturation should be mostly unaffected by reorganizations. In some cases, there will be the inconvenience of rebroadcasting maturation transactions if they are excluded in the reorganized chain and mempool. More worthy of attention is the case of liquidation. A liquidation transaction, especially when close to maturity, can be removed via reorganization and enter a race condition against a maturation transaction. For a typical reorganization to impact a contract, the remaining time must be very small and therefore the price difference will be small with limited impact on the outcome. This race condition and liquidations in general can be minimized by using a reasonable amount of collateral.

In extreme cases of deliberate attack, a high-value liquidation can even be evaded in the hopes of a price recovery by colluding with large miners. We do not expect such attacks to be a large concern because they are subject to the same disincentives against large scale double-spend based attacks. That is, the Bitcoin Cash price drop consequent from such an obvious attack makes it unlikely for invested ASIC miners to collude.

In the case of an economically significant and persistent chain split, the oracle must decide which chain its prices will be based on. Since the contract exists on both chains after the split, its redemptions will also be replayable on both chains. On the unsupported chain, redemptions will likely result in inaccurate outcomes based on prices for the supported chain. On the supported chain, redemptions can be expected to result in a relative gain for Hedges given the typically lower price on both chains after a significant split. If AnyHedge is widely adopted, complications in contract redemption may provide a disincentive against deliberate chain splits. Alternatively, concerns of a persistent split may dampen demand for AnyHedge over the period of uncertainty.

It may be possible for the oracle to adopt a dual chain model where it aggregates prices from both chains in its feed. However, this is likely to lead to even more complicated situations, as users face the uncertainties of redeeming on both chains. Additionally, new and unreplayable contracts would be unable to continue using the feed. It may be more reasonable for the oracle to simply pick a chain to support, so that complications will be limited to contracts that cross the split.

Third party audit of mathematical soundness.

We take the reliability of our protocols very seriously, so we had a third party do a mathematical analysis of the AnyHedge protocol.

Read the results