Oracles in FinTech Dapps

The use of oracles in Fintech services on the Ethereum blockchain was the topic of a recent meetup at the Mindrome co-working facility in Santa Clara, CA.

Speakers from Oracles.org, Oraclize.com, SmartContract.com, and TownCrier took attendees through a grand tour of this essential piece of disruptive products and services running on Ethereum.

Feeding Data, Pricing Products

Oracles are data feeds by another name. They are conflated in Fintech parlance with oracle machines (a variation of ancient and venerable turing machines) to mean the intermediaries that tap into trusted data sources and apply algorithms to deliver an answer or outcome within a Fintech (or Insurtech or Regtech) product or service.

We are building oracles into our work with the Ethereum insurtech startup to create price points for the company’s Flight Delay Dapp. These oracles feed historical and recent flight-delay information, weather conditions, seasonal variations, and other localized information into Flight Delay’s actuarial calculator to provide real-time pricing for specific flights.

The data sources themselves are not affected by the use of oracles, or even aware that their data is being used. But unlike most traditional insurance, which has premiums developed by historical actuarial data, the real-time nature of Etherisc’s Flight Delay and much of emerging Fintech/Insurtech/Regtech apps and services requires immediate data and decisionmaking.

This type of insurance is often referred to as “parametric insurance,” in that its price is determined by any number of parameters, which in turn are brought to life in specific policies by the oracles.

Addressing Hard Problems

The development and use of oracles present some hairy problems, as the Ethereum meetup speakers cheerfully conceded.

The challenges start with the nature of blockchain, which is just a ledger that does by itself communicate to the Internet. So oracles are needed as trusted intermediaries to deliver knowledge that apps and services require.

Maintaining data security and authenticity then emerges as an issue. As Thomas Bertani from Oraclize noted, traditional TLS (transport layer security) certificates can’t prove to a third party that data is authentic because of its inability to communicate. “With TLS, the data is just secure, but nothing more,” he said.

Jeff Flowers from Oracles.org covered the “proof-of-authority” concept for validating transactions on the Ethereum blockchain. He said this approach is “ideal for private networks and enterprises,” as it doesn’t require the “proof of work burn” found in the computer-intensive proof-of-work method.

Fan Zhang from Town Crier (a clever name for a project that harks back to one of the original trusted sources from medieval times) outlined how to embed trustworthiness on hardware in this process, and then to smart contracts that end up as blocks on a blockchain. Fan’s project is part of his ongoing PhD study at Cornell University, and uses uses SGX (Software Guard Extensions) technology from Intel to lock things down. Still, developers must be sure that the data delivered to a smart contract is exactly the same as from the source, he noted.

Sergey Nazarov from SmartContract.com took up the cudgel from there and outlined how to develop a network of trusted parties to establish consensus about data input. He noted that data providers themselves don’t want to become oracles.

Further down the chain, so to speak, is the challenge of securing payments. Sergey noted that you may not want to put payment credentials on-chain, but would then need a secure off-chain way to secure and protect the payers’ credentials.

We’re providing links to videos from this meetup below, so you can get the complete, detailed picture.

For your immediate questions, please email us at elena.t@protofire.io so we can learn how we can work with you.