The Biggest Hurdle Facing Decentralized Finance (DeFi)
Last month, I provided a solution for Chainlink on how best to model implied volatility (IV) on-chain for both Bitcoin and Ethereum options using price feeds and oracles.
If you’re not super familiar with how Ethereum smart contracts work or The Oracle Problem, I’ll give a brief summary before diving into one of the major issues facing public blockchain protocols.
The Isolation Problem of Public Blockchain
Public blockchains are gaining popularity because of the their emphasis on both decentralized infrastructure and payment authorization. The premise is that decentralization provides fairness when it comes to data sharing, payments, and other industry applications which are typically offered as a service by a central authority — like Visa, Mastercard, Google, or Paypal.
While blockchains certainly offer a unique solution to the decentralization problem, they have unique issues surrounding off-chain data ingestion that can introduce security risks, fraudulent transaction, and just plain wrong application state that becomes immutable (non-removable) within the history of the blockchain ledger.
In other words, blockchains have a data problem.
So the question becomes:
How do you consume data from the real world, and how do you know it can be trusted so that transactions added to the ledger are both accurate and fair?
Data Problems Become Oracle Problems
To sum it up, the data problem with blockchains revolves around a very simple limitation — blockchains cannot pull in data from or push data out to any external system as a built-in functionality. As such, blockchains are isolated networks very akin to a computer with no Internet connection.
Companies like Chainlink are attempting to solve this problem by offering prebuilt solutions known as price feeds.
These price feeds are essentially oracles that collect data off-chain and aggregate them into a single-source of truth using a weighted average.
While this works well with price feeds and raw data, the major issue facing smart contracts currently is that higher order financial modeling becomes nearly impossible. And if blockchains’ ultimate goal is to decentralize finance (DeFi), then it’s a problem that will need to be solved going forward.
The Disconnect Between Traditional Finance & DeFi
The issue that I see facing public blockchain protocols when it comes to DeFi isn’t necessary a philosophical problem (centralization vs decentralization), it’s a technical problem.
When it comes to risk management or portfolio allocation in traditional finance (TradFi), fund managers often use financial models to make portfolio allocations that quantify risk in a variety of manners. These risk management metrics often take the form of greek letters: alpha, beta, delta, gamma, rho, theta, etc. which allow managers to measure portfolio sensitivities to market changes in underlying prices, market volatility, interest rates, and other factors.
In addition to this, quantitative money managers often use bayesian modeling to model portfolio performance as a distribution of probabilities, so these greek letters may take on values of multiple probability distributions summed together (Bayesian statistics).
The major issue facing blockchains right now is that if you’re going to truly decentralize finance, you have to make available the same sets of tools that are available to traditional finance, otherwise all you’re doing is taking on risk that you can’t quantify.
Current Limitation of Smart Contracts
In the previous section, I mentioned that risk management and thus portfolio management often boils down to greek letters. These greek letters are usually partial derivatives of a variety of financial modeling equations, the most famous one being the Black-Scholes Model for option pricing.
Here, we see the problem facing blockchains when it comes to TradFi modeling, which is the fact that oftentimes, TradFi models include distributions. In the case of the Black Scholes Model, that “N” symbol is a log-normal distribution.
Which brings us to our most crucial and technical problem facing smart contracts today…
The major problem with Ethereum smart contracts is that Solidity as a programming language does not support floating point [decimal] numbers, which makes manual calculations of implied volatility with something like the Black Scholes Merton (BSM) Model within a smart contract impossible.
If you don’t have floating point numbers, you can’t model continuous distributions, which means you can’t do TradFi modeling on-chain. This is a major hurdle facing Solidity in terms of adoption for decentralized asset management.
Comparatively, all modern programming languages such as Python, Java, C++, Javascript, Go, and even Rust all support floating point numbers.
Python is right now the defacto language for financial modeling because of it’s extensive availability of finance libraries such as TA-Lib and Mibian. If independent financial professionals and developers for independent quantitative asset managers are going to adopt smart contracts as a viable transparent money management solution, then this floating point number problem will need to be solved.
And these libraries will need to be rebuilt on-chain because nobody wants to waste time doing Black-Scholes calculations by hand. Developers want to focus on solving real world problems, not reinventing the wheel.
The Only Viable Current Solution
The only solution that’s available and scalable in terms of performance right now for doing TradFi modeling with Ethereum is to do all that modeling off-chain in a midlayer API, round the result to an integer or an array of integers, and return that result to the calling oracle.
Besides the inability to do this modeling on-chain because of the lack of floating number support in Solidity, even if you tried, the gas prices would probably kill your transaction because of the number of calculations needed under the hood — there’s a lot of sigmas involved with calculating distributions.
In the Colab Notebook below, I provided a working example of how TradFi modeling would need to be done in Ethereum’s current version of Solidity.
As an example for Chainlink, I showed how you would model implied volatility (IV) for Bitcoin and Ethereum option contracts using Chainlink price feeds.
In short, you need to do all the heavy lifting in the midlayer API, and then cache or stash the result as rounded integers on-chain, in which case the smart contract more or less is just serving as a database.
But this introduces a whole plethora of philosophical issues that run counter to blockchain’s premise: if the financial modeling itself isn’t decentralized, what good is decentralizing the results of those models?
This is a major issue that the Ethereum Foundation will need to address because this is the direction in which all of finance is moving: probabilistic risk management.
It’s also the intersection of where probabilistic deep learning and finance are beginning to work together, so deep learning frameworks like TensorFlow will also need to come on-chain as well.
If smart contracts cannot eventually offer this basic floating point number functionality to do TradFi modeling on-chain, how can you truly expect to decentralize all of Western finance?
Practically Decentralizing Western Finance
As I write finish writing this article, I’m looking at my Starbucks coffee to the right of my laptop. It cost me $1.86 today, a decimal point number.
If Starbucks’ POS system was built in Solidity, they’d have to round that number and charge me $2 exactly. Finance doesn’t work that way in the real world.
We still have a ways to go before we decentralize and democratize the financial world completely. But I trust the Ethereum Foundation developers are up to the task of bridging this gap between TradFi and DeFi.
If you learned something from this post, give me some claps and a follow…
And if you need something done right…
Synvestable — Your Global S&P 500 Consulting Partner
