<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Managing Risk in DeFi</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Position Paper</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Johannes Rude Jensen</string-name>
          <email>j.jensen@di.ku.dk</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Omri Ross</string-name>
          <email>Omri@di.ku.dk</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Department of Computer Science, University of Copenhagen</institution>
        </aff>
      </contrib-group>
      <fpage>133</fpage>
      <lpage>138</lpage>
      <abstract>
        <p>Decentralized financial applications (DeFi) are a new breed of consumer-facing financial applications composed as smart contracts, deployed on permissionless blockchain technologies. We situate the DeFi concept in the theoretical context of permissionless blockchain technology and provide a taxonomical overview of agents, incentives and risks in DeFi applications. We identify four key risk groups for potential stakeholders contemplating the advantages of decentralized financial applications. We contribute novel insights into a rapidly emerging field, with far-reaching implications for the financial services.</p>
      </abstract>
      <kwd-group>
        <kwd>DeFi</kwd>
        <kwd>Blockchain Smart Contracts</kwd>
        <kwd>Decentralized Finance</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>Decentralized financial applications, colloquially referred to as ‘DeFi’, is a new type of
open financial applications deployed on openly accessible, permissionless blockchains.
A rapid surge in the popularity of these applications saw the total value of the assets
locked in DeFi applications (TVL) grow from a range of $400-500m at the outset of
2020 to no less than $9.6bn towards the end of the third quarter of the same year1. While
scholars within the information systems and management disciplines recognize the
novelty and prospective impact of blockchain technologies, theoretical or empirical work
on DeFi remains scarce [1]. In this brief position paper, we provide a conceptual
introduction to ‘DeFi’ situated in the theoretical context of permissionless blockchain
technology. We introduce a taxonomy of agents, roles, incentives, and risks in DeFi
applications and present four potential sources of complexity and risk.</p>
      <p>Permissionless Blockchain Technology and Decentralized
Financial Applications
The implications and design principles for blockchain and distributed ledger
technologies have generated a growing body of literature in the information systems (IS) and
the management genres [2]. Primarily informed by the commercial implications of
smart contract technology, scholars have examined the implications for activities in the
financial services such as the settlement and clearing of ‘tokenized’ assets [3] the
execution and compilation of financial contracts [4]–[6], complexities in supply-chain
logistics [7] and beyond.</p>
      <p>A blockchain is a type of distributed database architecture in which a decentralized
network of stakeholders maintains a singleton state machine. Transactions in the
database represent state transitions disseminated amongst network participants in ‘blocks’
of data. The correct order of the blocks containing the chronological overview of
transactions in the database is maintained with the use of cryptographical primitives, by
which all stakeholders can manually verify the succession of blocks. A network
consensus protocol defines the rules for what constitutes a legitimate transaction in the
distributed database. In most cases, consensus protocols are rigorous game-theoretical
mechanisms in which network participants are economically incentivized to promote
network security through rewards and penalties for benevolent or malicious behavior
[8]. Scholars typically differentiate between ‘permissioned’ and ‘permissionless’
blockchains. Permissionless blockchains are open environments accessible by all,
whereas permissioned blockchains are inaccessible for external parties not recognized
by a system administrator [2].</p>
      <p>Recent implementations of the technology introduce a virtual machine, the state of
which is maintained by the nodes supporting the network. The virtual machine is a
simple stack-based architecture, in which network participants can execute metered
computations denominated in the native currency format. Because all ‘nodes’ running
the blockchain ‘client’ software must replicate the computations required for a program
to run, computational expenditures are priced on the open market. This design choice
is intended to mitigate excessive use of resources leading to network congestion or
abuse. Network participants pass instructions to the virtual machine in a higher-level
programming language, the most recent generations of which is used to write programs,
referred to as smart contracts. Because operations in the virtual machine are executed
in a shared state, smart contracts are both transparent and stateful, meaning that any
application deployed as a smart contract executes deterministically. This means that
once a smart contract is deployed, it will execute exactly as instructed.
2.1</p>
    </sec>
    <sec id="sec-2">
      <title>DeFi Applications</title>
      <p>For the purpose of identifying risks, it is sufficient to denote the concept: ‘DeFi
application’ as an arrangement of consumer-facing smart contracts, executing a predefined
business logic within the transparent and deterministic computational environment
afforded by a given permissionless blockchain. Since DeFi applications are deployed as
smart contracts and thus execute a given business logic deterministically, users interact
directly with the application independent of any external service providers.
Contemporary DeFi applications provide a range of financial services within asset management,
derivatives, lending, and insurance services.</p>
      <p>The metered pricing of computational resources on permissionless blockchains
means that DeFi applications are constrained by the computational resources they can
use. Application designers seek to mitigate the need for the most expensive operations,
such as storing big amounts of data or conducting sophisticated calculations, in the
effort of reducing the level of complexity required to execute the service that their
application provides.</p>
      <p>Because the resources required for interacting with a smart contract is paid by the
user, DeFi application designers employ an innovative combination of algorithmic
financial engineering and game theory to ensure that all stakeholders of their application
are sufficiently compensated and incentivized. In table 2, we introduce a taxonomy for
the different types of agents and their roles in contemporary DeFi applications. We
highlight the incentives for participation and key risks associated with each role.</p>
    </sec>
    <sec id="sec-3">
      <title>Agent:</title>
    </sec>
    <sec id="sec-4">
      <title>Users</title>
    </sec>
    <sec id="sec-5">
      <title>Liquidity</title>
    </sec>
    <sec id="sec-6">
      <title>Providers</title>
    </sec>
    <sec id="sec-7">
      <title>Arbitrageurs</title>
    </sec>
    <sec id="sec-8">
      <title>Application</title>
    </sec>
    <sec id="sec-9">
      <title>Designers</title>
      <p>(Team and</p>
    </sec>
    <sec id="sec-10">
      <title>Founders)</title>
    </sec>
    <sec id="sec-11">
      <title>Role:</title>
      <sec id="sec-11-1">
        <title>Utilizing the application.</title>
      </sec>
      <sec id="sec-11-2">
        <title>Supply capital to the application in order to ensure liquidity for traders, borrowers or</title>
      </sec>
      <sec id="sec-11-3">
        <title>Return the application</title>
        <p>to an equilibrium state
through strategic
purchasing and selling of
assets.</p>
        <p>Design, implement and
maintain the
application</p>
      </sec>
    </sec>
    <sec id="sec-12">
      <title>Incentives for participation:</title>
      <p>Profits, credit,
exposure and
governance token yield
Protocol fees,
governance token yield</p>
      <sec id="sec-12-1">
        <title>Arbitrage profits</title>
      </sec>
      <sec id="sec-12-2">
        <title>Governance token appreciation</title>
      </sec>
    </sec>
    <sec id="sec-13">
      <title>Key risk:</title>
      <sec id="sec-13-1">
        <title>Market risks, network congestion,</title>
      </sec>
      <sec id="sec-13-2">
        <title>Systemic risk, admin-keys, Impermanent loss,</title>
      </sec>
      <sec id="sec-13-3">
        <title>Market risk, network congestion</title>
      </sec>
      <sec id="sec-13-4">
        <title>Software bugs</title>
        <p>Owing to the original open-source ethos of blockchain technology, application
designers are required to be transparent and build ‘open’ and accessible applications, in
which users can take ownership and participate in decision-making processes, primarily
concerning new features or changes to the applications. As a reaction to these demands,
application designers often issue and distribute so-called governance tokens.
Governance tokens are fungible units held by users, which allocates voting power in
majority voting-schemes. Much like traditional equities, governance tokens trade on
secondary markets which introduces the opportunity for capital formation for early
stakeholders and designers of successful applications. By distributing governance
tokens, application designers seek to disseminate value to community members while
retaining enough capital to scale development of the application by selling inventory
over multiple years.
3</p>
        <p>Identifying and Managing Risk in Decentralized Finance
Decentralized financial applications introduce a complex and volatile environment. In
this section, we identify and evaluate the four key risk factors which may introduce
complexities for stakeholders involved with these applications.
3.1</p>
      </sec>
    </sec>
    <sec id="sec-14">
      <title>Software integrity and security</title>
      <p>Owing to the deterministic nature of permissionless blockchain technology,
applications deployed on as smart contracts are subject to excessive security risks, as any
signed transaction remains permanent once included in a block. The irreversible or,
‘immutable’ nature of transactions in a blockchain network has led to significant loss
of capital on multiple occasions, most frequently as a result of coding errors, sometimes
relating to even the most sophisticated aspects virtual machine and programming
language semantics [9].
3.2</p>
    </sec>
    <sec id="sec-15">
      <title>Transaction costs, protocol fees and network congestion</title>
      <p>To mitigate abusive or excessive use of the computational resources available on the
network, computational resources required to interact with smart contracts are metered.
This creates a secondary market for transactions, in which users can outbid each other
by attaching transaction fees in the effort of incentivizing miners to select their
transaction for inclusion in the next block. In times of network congestion, transaction fees
appreciate to an extent to which single applications or sub-components gross several
hundreds of thousands of dollars from users interacting with the application.2 While
intermediary service providers occasionally choose to subsidize protocol transaction
fees3, application fees are in near all cases paid by the user interacting with the DeFi
application. Because application designers seek to lower the aggregate transaction
costs, protocol fees, slippage or impermanent loss through algorithmic financial
modelling and incentive alignment, stakeholders must carefully observe the state of the
blockchain network. If a period of network congestion coincides with a period of
volatility, the application design may suddenly impose excessive fees or penalties on
otherwise standard actions such as withdrawing or adding funds to a lending market.
2 https://etherscan.io/gastracker
3 Coinbase.com
3.3</p>
    </sec>
    <sec id="sec-16">
      <title>Participation in decentralized governance</title>
      <p>Responding to implications of the historically concentrated distribution of native assets
amongst a small minority of stakeholders, DeFi application designers increasingly rely
on a gradual distribution of fungible governance-tokens in the attempt at adequately
‘decentralizing’ decision-making processes. While the distribution of governance
tokens remains fairly concentrated amongst a small group of colluding stakeholders, the
gradual distribution of voting-power to liquidity providers and users will result in an
increasingly long-tailed distribution of governance tokens. Broad distributions of
governance tokens may result in adversarial implications of a given set of governance
outcomes, for stakeholders who are not sufficiently involved in monitoring the governance
process.
3.4</p>
    </sec>
    <sec id="sec-17">
      <title>Application interoperability and systemic risks</title>
      <p>A key value proposition for DeFi applications is the level of interoperability between
applications. As most applications are deployed on the Ethereum blockchain, users can
transact seamlessly between different applications with settlement times rarely
exceeding a few minutes. This facilitates rapid capital flows between old and new applications
on the network. While interoperability is an attractive feature for any set of financial
applications, tightly coupled and complex liquidity systems can generate an excessive
degree of financial integration, resulting in systemic dependency between applications
[10]. This factor is exacerbated by the often complex and heterogeneous methodologies
for the computation of exposure, debt, value, and collateral value that DeFi application
designers have used to improve their product. An increasing degree of contagion
between application may introduce systemic risks, as a sudden failure or exploit in one
application could ripple throughout the network, affecting stakeholders across the entire
ecosystem of applications.
4</p>
      <p>Conclusion: Is DeFi The Future of Finance?
In this position paper, we have examined the potential implications, complexities and
risks associated with the proliferation of consumer facing DeFi applications. While
DeFi applications deployed on permissionless blockchains present a radical potential
for transforming consumer facing financial services, the risks associated engaging with
these applications remain salient. Practitioners contemplating an engagement with
these applications ought to consider and evaluate key risks prior to committing or
allocating funds to DeFi applications. Scholars interested in DeFi applications may
approach the theme from numerous angles, extending early research on the market design
of DeFi applications [11] or issues related to governance tokens [12] and beyond.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <string-name>
            <given-names>J.</given-names>
            <surname>Kolb</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Abdelbaky</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R. H.</given-names>
            <surname>Katz</surname>
          </string-name>
          , and
          <string-name>
            <given-names>D. E.</given-names>
            <surname>Culler</surname>
          </string-name>
          , “
          <article-title>Core concepts, challenges, and future directions in blockchain: A centralized tutorial</article-title>
          ,
          <source>” ACM Comput. Surv.</source>
          , vol.
          <volume>53</volume>
          , no.
          <issue>1</issue>
          , pp.
          <fpage>1</fpage>
          -
          <lpage>39</lpage>
          ,
          <year>2020</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <given-names>O.</given-names>
            <surname>Labazova</surname>
          </string-name>
          , “
          <article-title>Towards a Framework for Evaluation of Blockchain Implementations,”</article-title>
          <source>in Fortieth International Conference on Information Systems</source>
          ,
          <year>2019</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          <string-name>
            <surname>O. Ross</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          <string-name>
            <surname>Jensen</surname>
          </string-name>
          , and T. Asheim, “
          <article-title>Assets under Tokenization: Can Blockchain Technology Improve Post-Trade Processing?</article-title>
          ,” in
          <source>Fortieth International Conference on Information Systems, Munich</source>
          <year>2019</year>
          ,
          <year>2019</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          <string-name>
            <given-names>J. R.</given-names>
            <surname>Jensen</surname>
          </string-name>
          and
          <string-name>
            <given-names>O.</given-names>
            <surname>Ross</surname>
          </string-name>
          , “
          <article-title>Settlement with Distributed Ledger Technology</article-title>
          ,” in Forty-First
          <source>International Conference on Information Systems</source>
          ,
          <year>2020</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          <string-name>
            <given-names>B.</given-names>
            <surname>Egelund-Müller</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Elsman</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F.</given-names>
            <surname>Henglein</surname>
          </string-name>
          , and
          <string-name>
            <given-names>O.</given-names>
            <surname>Ross</surname>
          </string-name>
          , “
          <source>Automated Execution of Financial Contracts on Blockchains,” Bus. Inf. Syst. Eng.</source>
          , vol.
          <volume>59</volume>
          , no.
          <issue>6</issue>
          , pp.
          <fpage>457</fpage>
          -
          <lpage>467</lpage>
          ,
          <year>2017</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          <string-name>
            <given-names>O.</given-names>
            <surname>Ross</surname>
          </string-name>
          and
          <string-name>
            <given-names>J. R.</given-names>
            <surname>Jensen</surname>
          </string-name>
          , “Compact Multiparty Verification of Simple Computations,” in BIR Workshops,
          <year>2018</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          <string-name>
            <given-names>B.</given-names>
            <surname>Düdder</surname>
          </string-name>
          and
          <string-name>
            <given-names>O.</given-names>
            <surname>Ross</surname>
          </string-name>
          , “
          <article-title>Timber tracking: reducing complexity of due diligence by using blockchain technology (position paper</article-title>
          ),
          <source>” in 2nd Workshop on Managed Complexity</source>
          ,
          <year>2017</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          <string-name>
            <given-names>A. M.</given-names>
            <surname>Antonopoulos</surname>
          </string-name>
          and
          <string-name>
            <given-names>G.</given-names>
            <surname>Wood</surname>
          </string-name>
          , Mastering Ethereum:
          <article-title>Building Smart Contracts</article-title>
          and
          <string-name>
            <surname>Dapps. O'Reilly Media</surname>
          </string-name>
          ,
          <year>2018</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          <string-name>
            <given-names>L.</given-names>
            <surname>Luu</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.-H.</given-names>
            <surname>Chu</surname>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            <surname>Olickel</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Saxena</surname>
          </string-name>
          ,
          <article-title>and</article-title>
          <string-name>
            <given-names>A.</given-names>
            <surname>Hobor</surname>
          </string-name>
          , “Making Smart Contracts Smarter,”
          <source>in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security - CCS'16</source>
          ,
          <year>2016</year>
          , vol.
          <volume>24</volume>
          -28-Octo, pp.
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          <string-name>
            <given-names>L.</given-names>
            <surname>Gudgeon</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Perez</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Harz</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            <surname>Livshits</surname>
          </string-name>
          ,
          <article-title>and</article-title>
          <string-name>
            <given-names>A.</given-names>
            <surname>Gervais</surname>
          </string-name>
          , “The Decentralized Financial Crisis,” pp.
          <fpage>1</fpage>
          -
          <lpage>15</lpage>
          ,
          <year>2020</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          <string-name>
            <given-names>G.</given-names>
            <surname>Angeris</surname>
          </string-name>
          , H.-T. Kao,
          <string-name>
            <given-names>R.</given-names>
            <surname>Chiang</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Noyes</surname>
          </string-name>
          , and T. Chitra, “
          <article-title>An analysis of Uniswap markets</article-title>
          ,” pp.
          <fpage>1</fpage>
          -
          <lpage>25</lpage>
          ,
          <year>2019</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          <string-name>
            <given-names>G.</given-names>
            <surname>Tsoukalas</surname>
          </string-name>
          and
          <string-name>
            <given-names>B. H.</given-names>
            <surname>Falk</surname>
          </string-name>
          , “
          <string-name>
            <surname>Token-Weighted Crowdsourcing</surname>
          </string-name>
          TokenWeighted Crowdsourcing,” Manag. Sci.
          <volume>66</volume>
          (
          <issue>9</issue>
          )
          <fpage>3843</fpage>
          -
          <lpage>3859</lpage>
          . https// doi.org/10.1287/mnsc.
          <year>2019</year>
          .3515 Full, no.
          <source>October</source>
          ,
          <year>2020</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>