Aside from vulnerabilities inherent to any cryptocurrency use cases such as loss of private keys, implementations of AnyHedge should minimize user exposure to the following vulnerabilities.
An adversary can compromise an oracle and then provide false pricing data or emit messages with bad timing, thus influencing contracts to their benefit. This can cause damage in unfair contract maturation, premature liquidations or prevention of just liquidations. To discourage these attacks, oracle providers should be properly incentivized, kept as unaware of contract details as possible, and regularly checked for consistency. To minimize the impact of these attacks, AnyHedge contracts may make use of multiple oracles.
A faulty oracle can emit ambiguous data that invites dispute from contract parties. For example, an oracle may sign two messages for the same time period or have a delay in message emission. In addition to the mitigation in the oracle compromise scenario, we also expect that over time a diverse market of oracles will form, with the most reputable providers becoming more widely used.
The messages oracles emit may not be of sufficient time resolution to cover all possible liquidation needs. There is a trade-off between higher time resolution and vulnerability to temporary price irregularities. In general, as the liquidity of Bitcoin Cash and the external asset increase, the time resolution of oracles can also be increased with confidence.
Similar to derivatives in custodial exchanges, parties with ample capital can manipulate market conditions and create sharp prices changes, which in turn trigger liquidations. Custodial exchanges may even be considered less vulnerable due to their ability to apply human judgement and roll back trades. This is an inherent weakness to automated non-custodial solutions and parties should pick an oracle that robustly aggregates price information to minimize this vector.
If there is an oracle message that allows a liquidation, then the contract can be liquidated. However if the liquidation is not carried out in a timely manner, then the contract may enter maturity. Then liquidation and maturity both become valid and the maturity transaction may preempt the liquidation.
Generally, any delay in liquidation or maturity redemption may lead to slippage. To ensure this scenario is minimized, AnyHedge parties should employ automated services that watch oracle price feeds and execute redemptions for them.
An inadequately or maliciously built client can fail to do necessary verifications when constructing AnyHedge contracts, opening up the possibility of one party cheating the other in parameters or even outright theft. Users should be careful in selecting reputable clients whether provided by an exchange or a standalone outfit.
At all stages of its existence, funding, liquidation and maturation, an AnyHedge contract is vulnerable to hostile fee market conditions. A transaction can fail to pay sufficient fees given chain congestion, opening it to delays and race conditions. AnyHedge benefits from being built on Bitcoin Cash, where fees are expected to be highly predictable over time.
Both the constructing software and smart contract script itself may contain unexpected vulnerabilities that allow for parameter manipulation or even outright theft. In solutions with a central contract, as commonly found on Ethereum, such a vulnerability can be existential and either result in catastrophic failures, as seen in the DAO, or require widespread, disruptive and difficult to coordinate migrations. AnyHedge benefits from its transactional nature in this regard, and is further protected by being hidden behind P2SH until redemption. If a vulnerability is discovered, an upgraded version can be deployed smoothly for all new constructions with minimal disruptions, as there is no central contract to be migrated from. For existing contracts, they are only immediately vulnerable to parties with complete knowledge of their contract parameters. We expect those knowledgeable parties to be highly limited such as the participating parties themselves, any involved exchange, and any automation services they may employ. In the case of a known vulnerability, the redeemers can ensure safety, even when they must reveal the script, by sending their redemption transaction directly to a trusted miner or group of miners with the understanding of block inclusion without rebroadcast.
We take the reliability of our protocols very seriously, so we had a third party do a mathematical analysis of the AnyHedge protocol.