The concept of blockchain can be distilled down to three simple words: trust through transparency. The blockchain ledger creates trust by serving as a central point of truth for stakeholders to a transaction. The ‘truth’ i.e., the record of each transaction, is visible to all network participants. Accordingly, everyone has equal opportunity to “see behind the curtain”, and everyone should have equal opportunity to make decisions on the basis of that information.
Over the past few years, the original, public decentralized blockchain paradigm has evolved, and new iterations of blockchains have emerged with the promise to shape the business world of the future. Of these iterations, arguably none are more exciting than Vitalik Buterin’s Ethereum, which was conceptualized as a “Next Generation Smart Contract and Decentralized Applications Platform” – or a “World Computer”. Buterin’s Ethereum enables users to leverage blockchain technology by creating their own “arbitrary rules for ownership, transaction formats and state transition functions” (Buterin Whitepaper 2013). In other words, this introduced the possibility for developers to create “smart contracts”, which can be used to build business use cases atop blockchain infrastructure… the ensuing “hype” did not go unnoticed. It seemed like every second day revolutionary ideas for smart contract use cases appeared, leaving the community awed and impassioned: autonomous organizations, supply chain track and trace, community renewables, the list goes on.
The oracle problem
Nevertheless, buried under the “hype” there may be a fundamental issue with the concept of smart contracts. They are predominantly dependent on “oracles”, a trusted algorithm or third party, to connect them to the real world. Oracles could pose a serious problem to the operation of smart contracts because they undermine two of the primary advantages of blockchain technology: (1) the elimination of a single point of failure, and (2) the possibility for people to interact on a trustless basis (i.e., to truly see behind the curtain). While every smart contract use case aims to remove intermediaries from the equation, the smart contract’s inherent reliance on an oracle paradoxically intensifies the need for the user to trust in the actions of the oracle. This reliance is referred to as “the oracle problem”.
In the context of Decentralized Finance (DeFi), oracles are commonly used to transmit market prices, drawn from one or many exchanges, to a DeFi protocol that relies on outside pricing information. Such price inputs are critical to trigger liquidations, deleveraging, margin calls, and other forms of automated collateral management.[1] Consequently, an error in, or manipulation of, oracles can have serious consequences for these protocols. Drawing a comparison to current financial systems, it would be somewhat akin to a scenario where Bloomberg was hacked, and data was manipulated and could no longer be trusted.
The oracle problem raises a number of important questions for stakeholders in the DeFi space, including:
- How can stakeholders trust the oracle, or the entity operating the oracle, to provide unbiased and accurate information to the network?
- Which stakeholder(s) would be accountable for an oracle’s mistakes?
- What can you do now to protect yourself in the event of an oracle failure or attack?
At Dentons, we have the expertise to help your team assess and mitigate oracle related risks. For more information please reach out to Tracy Molino and Noah Walters.
[1] Nic Carter and Linda Jeng, “DeFi Protocol Risks: the Paradox of DeFi” (2021) at SSRN – “DeFi Protocol Risks: the Paradox of DeFi” (plu.mx)
