DRAFT – Using Financial Derivatives To Secure the Assets of Decentralized Applications (DAPPs)

Ethereum contracts can be formulated to act like decentralized applications, or DAPPs. Numerous DAPPs are already operating including a role playing game, an online marketplace, an internet service provider and a prediction market. Unfortunately, DAPPs are vulnerable to hacking, and the funds they hold can be stolen. The recent attack on a DAPP, known as DAO, has revealed that smart contracts’ bugs represent a serious problem, not merely an academic concern. Tens of millions of USD worth of ether were stolen by the hacker, which led to a nosedive of ether’s exchange price.

A group of researchers from the University of Massachusetts presented a new market based technique to secure a DAPP’s ether holdings via the use of futures contracts which are indexed by the exchange price of ether for DAPP’s tokens. Within the context of generally fair circumstances, the new technique can lead to recovery of the majority of ether lost secondarily to theft, with high probability even if all of the DAPP’s ether holdings have been stolen and the DAPP token holder will only be burdened with a modifiable ether withdrawal fee. Assuming a margin call with a probability of p in d days for a futures contract with a leverage of 2000%, the new approach will permit recovery of 50% of the stolen ether with a probability of p and a withdrawal fee of 5%. If the withdrawal fee is increased to 25%, more than 80% of the stolen ether can be recovered with a probability of p.

DRAFT – A DAPP Security Mechanism:

One of the biggest problems associated with ethereum contracts is the complexity of their logic. An attacker can exploit a vulnerability in smart contracts to execute unauthorized withdrawal of ETH. DRAFT secures the ether held within a smart contract, even if an attacker can make an unauthorized withdrawal of ETH at zero expenses. The new technique involves retaining a withdrawal fee, from the withdrawn amount of ether, which would be spent to buy insurance, in the form of FUT, or futures contracts, to hedge against a drop in the exchange price of ETH/TOK. An unauthorized withdrawal will presumably lead to a drop in price. If this happens, the contract will exchange its held FUT for ETH; thus, recovering a percentage of the stolen ETH. Nevertheless, the recovered ETH won’t be immediately available for withdrawal to prevent the occurrence of iterative attacks. The recovered amount will be locked in a recovery cache, until its release is voted for by TOK holders, only after the withdrawal code has been successfully patched.

The below figure illustrates the withdrawal workflow. Three general purpose withdrawal components, which are marked in green on the below figure, operate independently from the specific logic of the contract. This will make it possible for the code, used in implementation of these components, to be tested and reused for all DAPPs that utilize a withdrawal mechanism. The withdrawal process is comprised of eight step (each marked in blue on the below figure). For a contract D, these steps are:

1- A user communicates with D‘s specific logic to start ETH withdrawal. Generally, a complex chain of events can unfold for the withdrawal to ensue; however, deposit TOK represents the most typical scenario.

2- The contract logic will signal approval of the withdrawal of an amount of ETH of m, to the withdrawal processor.

3- The withdrawal processor will remove an amount of ETH of m from its cache while separating a withdrawal fee of fm. The withdrawal fee will be sent to an account on the futures exchange, which is controlled by D. The remaining amount of ETH which equals to (1-f)m will be held by the withdrawal processor.

4- The withdrawal processor will exchange fm of ETH for futures contracts FUT on the futures exchange to hedge against a drop in the ETH/TOK exchange rate. The bought FUT amount will be moved from an account controlled by D on the futures exchange to a cache which is controlled by the recovery processor.

5- The withdrawal processor will release an amount of (1-f)m of ETH to the user initiating the withdrawal. This is the final task for the withdrawal processor.

6- The recovery processor observes the price of the FUT within the account controlled by D on the futures exchange. In the end, the recovery processor will exchange FUT for ETH.

7- When ETH is withdrawn from the futures exchange, this amount will be held in a staging area which is quarantined from the rest of the contract’s logic.

8- Ultimately, the TOK holders will vote to pass the ETH held in the staging area back to the main ETH cache which is under control of the withdrawal processor. This process of manual voting guarantees that an attacker cannot steal the ETH held within D multiple times before a potential exploit is discovered.