Discussing the Limitations of Blockchain Artefact Design

Table of Links

Abstract and Introduction

1 Literature Review

2 Methodology and Artefact Requirements

3 The Implementation and Integration of the Artefact

4 Artefact Evaluation

5 Discussion

6 Conclusion and Future Work, and References

4 Artefact Evaluation

As evident in the artefact demonstration, the artefact successfully executes the lifecycle of a leveraged trade in the deterministic computational environment afforded by the Ethereum blockchain. This is achieved by interfacing with the Dai stablecoin system through a microservice acting as a wrapper around the smart contracts. We present the summarized results of the final evaluation cycle, leading to the present iteration of the artefact (Table 3.)

Table 3. Evaluation of the artefact requirements

While the requirements for the present iteration were tentatively met, the evaluation reveals significant drawbacks in the artefact design. First, the Dai stablecoin system and the Ethereum blockchain introduces several domain-specific limitations, as the maximum obtainable leverage ratio is constrained by the collateral requirement for the asset class, and position sizes are constrained by transaction fees and on-chain liquidity constraints in decentralized exchanges.

Second, requirements two and three introduces significant challenges for the integration of the artefact. Compliance with the requirement for a non-invasive integration using standardized API calls means that the present iteration of the artefact cannot access user funds through the hardened exchange environment, as this level of access would compromise the industry mandated cold-storage requirements. Instead, the implementation requires that the user holds sufficient funds in an associated browser-based wallet which can expose an API[8] enabling the signature of the transaction input data comprising the recursive logic which creates the leveraged position. To fund such a wallet, the user must first download and install the wallet software in her browser and subsequently connect the wallet with the exchange and fund the wallet by transferring the correct amount of assets from the exchange (or elsewhere) to the wallet. Additionally, the use of an external browser-based wallet implies that the user must carry the transaction costs for the recursive operation. As the recursive operation utilizes a decentralized exchange (DEX) instead of the exchange orderbook itself, liquidity provisioning for the artefact is externalized.

[8] We used MetaMask for the implementation: https://metamask.io/