# The Blockchain Oracle Problem in Decentralized Finance--A Multivocal Approach
## 2 Literature Background
### Narrowing the Oracle Problem in Decentralized Finance  
As explained above, the blockchain oracle problem refers to the inability to determine the veracity of data provided by oracles [39]. The uncertainty may arise from an unreliable data source, low oracle reputation, or both [42]. However, as discussed in a recent paper [16], the consequence of this condition varies according to the specific sector in which blockchain is implemented. In the supply chain, the oracle problem refers to the fact that information collected on the blockchain is filtered by the producing company so that unwanted or sensitive information may not be registered [27; 43]. In the academic sector, the oracle problem does not affect the authenticity of the transcript but does question the credibility of the issuing authority [41]. A certified issue by a low-ranked university, in fact, will not gain more credibility for being stored on a blockchain [44]. In the IPRs field, the oracle determines a more social problem in which authors and certification authorities are vying for the role of the oracle, as the one who does, obtain a greater power over the other party [45]. In resource management, since the data flow is bi-directional, namely when resources are both stored and shared, there is the need for two types of oracles (inbound and outbound). This further dependency, of course, doubles the problem. Finally, in the case of health records, the oracle involvement can constitute an additional attack vector for hackers to steal or modify patient records. When multiple oracles and external databases are implemented, and there is the inability to monitor their security, it will also be impossible to determine the reliability of patient's data on the blockchain [14]. Decentralized finance, as a real-world application, requires oracles to operate. However, the impact of their implementation strictly depends on the extrinsic data required. In  
Figure 1: Dimensions of the oracle problem. DeFi, data such as KYC are not required (at the moment), since smart contracts manage all the transactions, and no centralized authority supervises the identity of the contractors [46]. Therefore, oracles are not implemented to collect personal data. Consequently, no GDPR or security issue arises, and no external server is needed for sensitive data management [47]. The only data that remain transparent are the transactions that only belong to pseudonym addresses. Unlike the academic sector and IPRs management, a smart contract's authorship is guaranteed solely and exclusively by the private key that signs the agreement. Theoretically, whether the person who uses the private key is the legitimate owner of the wallet or not is not relevant for the correct execution of a DeFi contract [21; 42]. Since not regulated through a KYC procedure, there is no way to enforce an unwanted operation on a crypto wallet. On the other hand, as the application is decentralized, there is also no authority to appeal. The last thing to consider to narrow the oracle involvement in DeFi environment is the fact that those applications are meant to communicate with each other (interoperability) so that data flow in both directions. This creates similar issues as those found in blockchain applications for resource management (dual oracle problem) [48]. Regardless of the specific decentralized financial application, the only data required pertains to financial assets' quantity and price. Unlike the data production of a traced bottle of wine, asset data constitute publicly available knowledge that can easily be verifiable. Oracles based on the wisdom of the crowd should then be able to \"trustlessly\" fetch this sort of data. However, malfunctions, tampering, and collusion can still easily alter the data provided. Being financial contracts that often manage transactions of millions of dollars also dramatically affects the incentive to alter the communication channel [38].