Weekly Update 17 January 2020: Some Thoughts on Financial Risk Analysis & DeFi

Here at Proof, one of our first visions for product creation was the concept of assured market trading. As our sector and our knowledge of financial products, services, and practice expands, we are beginning to look at existing risk management strategies and methodologies which govern the composition of existing structured instruments.

Parallel behaviors between existing decentralized protocols and expected standards in the traditional financial world help us discover deficiencies in our thinking as an industry and build insights to guide future development and messaging. Likewise, any readily available data and modeling of future changes has the potential of educating users on the systemic and counter-party risks involved when planning their personal finance. For this post, we are going to look at the entire Maker system which consists of Multi-collateral Dai, The CDP system, and an interest accruing savings account.

By checking out an existing DeFi platform and diagnosing risk factors, we can both understand where and how developments should be focused and begin to build mature models for packaging these outputs into coherent structured packages.

As an aside, the main reason for this investigation is that we believe the adoption of DeFi will hinge on users, platforms, and institutions having a coherent understanding of the risks of leveraging smart contract finance whether they are deployed on Ethereum or Quorum or Hyperledger or Corda or Hedera — ad infinitum.

Regardless of platform, we are interested in seeing if there are ways to compose structured products which help to offset, spread out, or mitigate certain risk factors.

We are going to in the Maker system by looking at three primary areas: Systemic risks, Counter-party Risks, and Collateral Risk. One of the most encompassing categories, Systemic risk includes concerns tied to Ethereum itself, Smart Contracts, Frontends, etc. Second, there exists risk in the counter-parties themselves (broadly defined here as ‘parties that can affect performance which would include Maker itself, other staking platforms utilizing Dai, and Ethereum itself). Finally, we have collateral risk which can be defined as risks associated with a collateral’s underlying characteristics.

Systemic Risk

Because smart contracts are hard to update and are immutable once deployed, many teams have implemented modular updates to their smart contracts. DeFi platform is the publicly available smart contract audits for that platform. Luckily, these are publicly available on a project’s creator and auditor’s Git or blog and are generally well written, include definitions, and are consumable by everyone.

Within the DAI (multi collateral Dai) audit, there are two minor aspects of the contract which are cited as possible issues. Mostly, these revolve around possible issues that may arise when Ethereum is congested (which means this would probably not be an issue for a similar system on a private chain unless that chain was being used as a payment rail for a use case such as banking process).

When looking at the systemic risks of a blockchain system, we also need to consider the effect that a systemic change can cause on an overlying product. For trading alone, systemic changes on public protocols has been an interesting idiosyncrasy of blockchain assets which have caused massive turmoil but overall has not (yet) created any world-ending existential issues. However, in a world of opinionated trading, systemic changes could cause dangerous inversion points which would be hazardous for any derivatives, ETF’s, or synthetic assets that would be priced with a blockchain asset in, say, an options or futures market.

(This is the behavior of Dai on Bitfinex during the transition from Sai to Dai)

For instance, Maker recently migrated their Dai system into a multi-collateral dai (more on this in the collateral risk section) system. Although the migration itself was handled masterfully, there were definitely some market effects which, had Dai been held in a structure, could have caused a financial inversion point that would have caused issues with any priced structured product.

(Maker and the sector worked to ensure, people were kept up to date wherever they looked)

That said, Maker and its partners kept the community updated with changes and even worked with tools to make sure users were kept up to date on the transition. Moving forward, as locked value expands and the offered products become more complex, systemic changes will need to be announced ahead of time and with clear direction as to what can be done to mitigate strange financial behaviors.

Regardless of whose responsibility it is to ensure these announcements are broadcast, the assets will still need extensive reporting with projected effects from large scale systemic changes.

Since Dai is not just affected by the system upon which it is built but also by the collateral, currency, and structural side, we are beginning to see that the system has all manner of overlapping risk vectors as a financial asset.

Regardless, the biggest systemic risk factor for all of DeFi is Ethereum itself which is a factor significantly too big for the scope of this post.

CounterParty Risk Analysis

One thing that a risk manager would need to consider when examining the Maker system would be the myriad of other platforms that utilize Dai and the effect those locking mechanisms will/would have on the underlying CDP issuance scheme. Although discreet on a platform-by-platform basis, the effect of having Dai interacting in so many systems while also having the issuing platform offering accounts with competing apr kind of boggles the mind with possibilities on how participants could affect valuations of more complex offerings.

Given that Compound, Aave, and Maker (just to name a few) utilize a lending protocol to offer interest bearing accounts with Dai locking, and given that these systems have variable interest rates, a model for seeing how interest rates between the three shift another’s borrow-to-lend ratio would be necessary for a mature addition of cDai as high net worth users move between different protocols.

Likewise, there is a form of counter-party risk on the levels of the development teams themselves, the underlying MKR token (and its price), market liquidity for a unit issuing ETF, and more. We are working on a model for taking these aspects into consideration in a closed system (such as a Project Ubin), however, in our findings, attempting to comprehensively detail these possible actions is the task of a long term data project.

Collateralization Risk

One commonality across all lending platforms as well as derivative issuance and pretty much every financial asset is the existence of collateral. Although there

We will be working to incorporate these lessons into our own OrFeed and Structured systems as well as adapting some of the more complex analysis into a quick-to-consume format for users of all levels. Obvious Ethereum, systemic, and counter-party risk factors contributing to the collateralization pools aside, one very large area that needs to be addressed is the existence of off-chain data on these platforms.

(Oracle delivered data is essential to know what the value of locked collateral is in order to maintain and issue a CDP)

In the world of blockchain, an oracle is a service which takes off-chain data such as prices, discrete quantitative data, and events and places them into an environment that programs on a blockchain can use. This data acts as the backbone for how DeFi assets behave and there is considerable debate about how they should be handled. This conversation is for another time however since we are just looking at potential risk.

In the interest of pricing and delivering data to manage traditional assets, financial engineers have literal mountains of paperwork determining how, where, why, how, what, who, how, and how data will be used to price assets. This paperwork consists of levels of documentation, definitions, specifications, organizational maps, contingency plans, contracts, and then some more contracts to legislate. They also are explicit in reporting their vendors while also being ensuring some sort of rational liability chain (through more contracts). There are levels of designations looking at observable inputs as quoted prices, inputs other than quoted prices, inputs with unobservable inputs, and other measurements just to keep an orderly transfer of liabilities, assets, and packages.

Modeling this price includes extremely deep looks into who would be liable in the event of a dispute, FASB and GAAP reporting standards, and adherence to standards upon standards. Although there have been many strides in how the industry handles on-chain data, merely attempting to ‘decentralize’ these data sources will not be enough. Reporting, reputation, and risk assessment will be extremely important for data on-chain regardless of our dismay regarding 3rd party sources.

We are having many debates internally about the philosophies and practice regarding collateral risk and on-chain data internally as we work through our OrFeed system.

Some Ideas

• Valuation controllers ensure that the price verification population is complete by reconciling against source systems. Establishment of a Valuation Controller (someone or something responsible to ensure sufficiency and appropriateness of price verification procedure). An underlying DAO or even Augur could fulfill this purpose although there would need to be modifications on reporting mechanisms in order to adhere to GAAP standards.
• Currently, as also touched on by Vitalik Buterin, the price-feed architecture that almost all crypto platforms requiring fair pricing inherits risks from both the structural side as well as the counter-party side. Finding a systemic way to offset one of these thus allowing for a more discrete risk scope.
• In order to maintain fair pricing for both entry and exit, derivative platforms may need to factor in risk on multiple levels to create more sophisticated pricing. Although it may be a bit tough to maintain decentralization, derivatives would factor in the volatility levels (Vega) of the underlying portfolio in order to reconcile independently offered quotes with potential price variance. This may also require the establishment of a high-liquidity options market in order to establish realistic volatility values.

Structures as Offset

This post is not meant to scare. Rather, we hope it inspires. The mitigation of risk is one of the most important aspects of financial institutions. One big question regarding all these risk factors is if there is a way to structure diversified portfolios to offset and compartmentalize these risks. Track our progress on the Structured git and stick around for more updates.