Nebula is a graph-based representation of DeFi, designed to model the composability nature of decentralised finance for risk assessment and navigation purposes.
In this blogpost we propose to leverage the developed tool to decompose and analyse the yielding portfolio of a popular DeFi user, namely Bizyugo.
Note that given our domain of expertise, we exclusively focus on BTC, Stablecoins and ETH denominated pools. Other assets and protocols are discarded from the analysis.
Bizyugo is a prominent DeFi farmer, managing a wallet that ranks among the top in the space. Currently, it holds 5th place on DeBank and 3rd on DegenScore. This wallet has been active for an extended period, with a diverse range of positions spanning across the DeFi ecosystem. Its portfolio is particularly notable for its breadth, consisting of 78 protocols, 12 chains, and 135 assets. In this post, we use our internal tool, Nebula, to dive into Bizyugo's portfolio and uncover potential inefficiencies.
When evaluating a DeFi portfolio, the first step typically involves loading it into a preferred portfolio management system (PMS), such as DeBank, where high-level metrics such as number of protocols, chains, assets and AUM are readily visible. However, this perspective does not offer visibility into the portfolio’s more complex, n-order exposures.
For instance, the manager might fail to recognize exposures to a specific oracle they find unreliable. Furthermore, as the portfolio expands, the likelihood of such oversights increases, potentially resulting in poorly informed allocation decisions.
Nebula is introduced and detailed in Introducing Nebula : A graph based representation of DeFi as a knowledge graph representing DeFi. Since the last blog post, we have updated its structure. The major additions being:
• Added Contract nodes representing Asset and Pool implementations, to which they are connected through the IMPLEMENTED_AT relationship.
• Added Wallet nodes representing addresses that are not contracts themselves.
• Added (Pool)-[:CONTAINS]->(Pool) relations, utilized to represent the relationship between gauges and liquidity pools, as seen on Curve Finance, where LP tokens can be staked in a gauge contract or a Convex pool.
• Added CEX nodes representing centralized exchanges, backing tokens like cbBTC, cbETH, BBTC ...
The current structure of the graph is defined by the following schema :
As for Bridges, one could argue that pool nodes should be directly connected to the Oracle they depend on. This functionality will be included in the upcoming Nebula update.
Going forward, the color coding for nodes is defined as follows:
We integrate the subject's wallet into the Nebula graph as a node, linking it to each of its positions (Pool nodes) via an 'IS_IN' relationship. Leveraging the graph's pool-centric architecture, we can efficiently map all the wallet's dependencies by executing the following Cypher query.
The query identifies the newly introduced wallet node ("Bizyugo") and initiates a Breadth-First Search (BFS), traversing all possible directed edges originating from the wallet. This process maps the entire network of dependencies, providing a comprehensive view of how the wallet is interconnected with other entities within the graph.
To address the blind spots of traditional PMS, we leverage Nebula across four different risk assessment scenarios to reveal hidden exposures.
To quantitatively propagate the exposures through the graph, we define the following procedure:
1) Set the usd_exposure field to 0 for all nodes in the graph.
2) Set the usd_exposure field for each pool connected to the wallet, with the corresponding dollar value allocated to it in the portfolio.
3) For each pool with usd_exposure > 0, increment the usd_exposure of all nodes connected (through an arbitrary number of directed edges) to the pool by the pool's usd_exposure amount.
In terms of Cypher queries, it translates to the following set of instructions:
N-order asset exposure refers to the indirect exposure a portfolio has to a crypto asset through another DeFi entity (Protocol, Asset, Oracle...). For instance, if stablecoin A is backed by asset B, there is an inherent dependency on asset B. Depending on the nature of asset B backing A, the portfolio manager might not be comfortable entering the position, as the security profile (including risks related to the smart contract, governance, and economics) of asset B also impacts asset A.
In the following example, we break down an allocation of deUSD to an Abracadabra pool, which introduces additional dependencies on Maker and Lido through deUSD's collateralization mechanism. If Maker fails, deUSD will be affected as well.
Even though Lido and Maker are considered trusted protocols in the ecosystem, the accumulation of these N-order asset exposures within a portfolio can distort the manager's perspective, leading to an underestimation of the exposure to various entities and the correlated risks across positions.
Another aspect of DeFi closely monitored at Dialectic is the governance risk of the book, coming from EOA (Externally Owned Account) exposures. Key smart contracts owned by simple wallets represent major points of failure in the space. Instead, we place more trust in ownership through reasonable timelock contracts and multisigs, which we can actively monitor.
In the query below, we reveal the subject portfolio’s exposure to one EOA address through the SOLV protocol. Using the capital propagation method described earlier, we calculate a total of $120,000 worth of BTC (2) that could potentially be siphoned by this wallet, resulting in a 0.4% loss at the portfolio level, which currently represents the equivalent of one month of yield in the BTC-yielding ecosystem.
The (Solv protocol)-[:IMPLEMENTED_AT]->(contract) relationship represents an implementation contract of the Solv protocol, which could be a router, factory, oracle, or any other contract used to implement the protocol logic.
Oracles are a crucial part of DeFi, controlling lending markets and other protocols. When they lack sufficient resilience, they can be vulnerable to manipulation, causing significant losses for unsuspecting liquidity providers. Some oracles are more reliable than others, with Chainlink being our preferred choice over custom implementations. Nebula enables us to measure and track exposure to this risk.
Below is an example of the top3 dependency on the Chainlink oracle obtained through AAVE, mkUSD and DOLA positions.
Similar to our approach with EOAs, we closely track dependencies on centralized entities like exchanges. The collapse of FTX and others has led to substantial losses and a shaken community, so we are focused on minimizing our exposure to these risks. Nebula plays a key role in helping us identify and monitor these vulnerabilities effectively.
In the following query, we illustrate how one can retrieve exposures of the subject wallet to centralized exchanges:
Our main objective being to construct a high-performance portfolio with a strong focus on risk-adjusted returns. Let us leverage our risk scoring algorithm, which uses Nebula as a backbone for risk propagation, along with our returns tracking engine to identify inefficiencies in the portfolio, such as positions with poor risk-adjusted returns.
Our algorithm identified a $5,000 allocation to the DOLA/mkUSD BalancerV2 liquidity pool as the most inefficient position in Bizyugo's book, with a high-risk score of 60% (see annex [1]) compared to an average return of 1% (see annex [2]). Given both the size of the allocation and the pool's TVL, which also stands at $5,000, this appears to be a neglected position.
This is a typical position we would rotate into safer or higher-yield opportunities.
We found that the flat view provided by traditional PMS is inadequate for effectively managing large portfolios engaged in DeFi activities. A flat view is inherently skewed and fails to represent the full spectrum of risk exposures.
In this blog post, we utilized Nebula to address this limitation through concrete examples. While our approach was relatively manual, involving the design of queries and analysis of visual results, the true potential of Nebula emerges when external algorithms are integrated to interact with it.
Nebula's purpose is not to rely on visual outcomes but to enable other algorithms to interact with the graph, producing statistics and guiding investment decisions. From risk management to automated rebalancing, Nebula serves as a data backbone, essential for other programs to safely and efficiently navigate the complexities of DeFi.
Risk scoring being a central topic in the space of DeFi portfolio optimization, we propose to outline our risk scoring algorithm based on Nebula in the next blog post.
[1] Text-based representation of the DOLA/mkUSD BalancerV2 pool dependency graph, optimized for easier manipulation within our systems. The base risk scores aggregate to 60% at the pool level, classifying it as High risk (with classifications being Low, Medium, High, or Degen).
[2] Historical APR of the DOLA/mkUSD BalancerV2 pool. We observe occasional spikes in the APR, likely resulting from sporadic trades routed through the pool. A negative APR accounts for impermanent loss or tokens depeg.
