Running a delta-neutral or farming fund is a complex and risky activity, with exposure to numerous potential hazards, such as faulty smart contracts, counterparty blow-ups, and illiquidity.
At Dialectic, we have been operating Chronograph, our fixed-income vehicle, for over a year. To manage these risks, we have created a comprehensive risk framework, coupled with an infrastructure of automated alerts, triggers, and actions to minimize risk and maximize yield.
In this post, we will share our risk framework and provide an overview of our in-house infrastructure to inspire those who engage in this landscape on a daily basis.
The risk framework
In DeFi, every strategy involves exposure to multiple risks, and therefore risks must be analyzed across the full spectrum. We identify five macro-categories of risk:
Smart contract
Economic
Oracle
Governance
Bridge
Smart contract risk
The security of underlying contracts that govern a protocol can vary greatly, depending on the protocol's complexity and Lindy effect, as well as any conducted audits. Audits improve the security of a given protocol, but the reputation of the audit firm and the type of testing performed (such as fuzzy, formal verification, re-entrancy, and economic attacks) are important considerations. An audit is conducted on a specific snapshot of the codebase, so an upgrade can nullify the audit unless the differences are considered harmless.
Another aspect of risk evaluation is contract upgradability. Teams often split the state and logic of the protocol by using proxy contracts. This approach makes it easy to push an upgrade by changing only the logic part of the protocol, without migrating the state (i.e., the liquidity of the protocol) used by the users. However, this approach is a double-edged sword, as a new upgrade could introduce a faulty vulnerability in the codebase.
In our in-house stack contract, upgrades are tracked with on-chain alerts. We have a strict policy of removing liquidity for a fixed amount whenever a contract upgrade is pushed to have the market figure out (white and black hats) if there is a problem.
Governance risk
As outlined in the previous paragraph, the protocol's entitled governor(s) can modify the underlying logic at will. The delegated admin can be an External Owned Account, a multisig, or a DAO.
Protocols that delegate admin powers to an EOA are considered the most unsafe because the protocol relies on a single point of failure. Multisigs can add an additional layer of security if the key signing is truly distributed and diversified across multiple participants. Adding external entities to the signing set can further increase the security score. DAOs are considered to be the highest standard in security, but the voting power distribution is critical to ensure no single entity can push a malicious proposal to the protocol. Furthermore, on-chain governance suffers from voter apathy, as shown by Build Finance's hostile takeover event.
Every upgradable smart contract on a blockchain should be set behind a timelock contract, regardless of whether it's controlled by an externally owned account (EOA), a multisig, or a decentralized autonomous organization (DAO). This approach represents the highest standard of security for smart contracts, as it gives users time to evaluate any scheduled upgrade during the time delay between submission and execution.
In our stack, every upgradable contract is tracked through an on-chain alert to prevent any hostile attack with a prompt exit. It's worth noting that even non-malicious upgrades can introduce unintended faults in the codebase. For instance, the Nomad bridge exploit occurred when a routine upgrade led to the complete draining of the bridge. There were 41 days between the execution of the upgrade and the date of the hack. To mitigate the risks of newly-introduced vulnerabilities, we enforce a fixed amount of time away from the protocol if any protocol upgrade is executed, giving the market time to find out any eventual vulnerabilities.
Economic risk
Analyzing the economic risks of engaging with a protocol must be conducted on several levels.
Firstly, providing liquidity to a pool exposes us to the underlying assets in the pool. If one of the asset's prices goes down in value, liquidity providers (LPs) will suffer an unrealized loss due to how prices of an automated market maker (AMM) are calculated. Analyzing the risk profile of every asset is mandatory to correctly assess the underlying risks. The liquidity of the asset, the liquidity depth, and the counterparty's risk profile (whether a centralized issuer or a decentralized protocol) all factor into the aggregated risk of the pool.
Secondly, entering a farm could expose us to different costs such as price impact, deposit or withdrawal fees, and gas costs. These more or less hidden costs could be overlooked, although they might have a significant impact on effective returns. It's essential to estimate the lifespan of a given strategy net of its associated cost.
Oracle manipulation
Protocols that implement an oracle could be exploited through the manipulation of their oracle. In the content of a money market like Compound or Aave, an attacker would manipulate the price of an asset listed as collateral and take a loan against it, leaving the protocol with bad debt. Recent examples of such attacks include Mango's and Lodestar's exploits.
For a start, the implemented oracle could be either off-chain or on-chain.
A reliable and robust off-chain provider, such as Chainlink, can make an attack much more complicated, as the provider aggregates different price feeds and implements different safeguards against manipulations.
However, protocols might implement an on-chain oracle, which might be more prone to manipulation. Avoid like the plague protocols whose implementations just read a market quote, as they are easily manipulated in the contest of an atomic transaction. An attack would involve:
execute a quite big trade on the reference exchange to push the price up to the sky
take a loan against a collateral whose value is now faked
make the opposite trade to move the price back and free the capital
Given that such an attack would be atomic, the attacker would not bear any inventory risk. Furthermore, no upfront capital would even be needed as it could be executed through a flash loan.
An improvement over just reading the market quote is to implement a Time Weighted Average Price (TWAP), like using Uniswap V2’s. The concept behind a TWAP is to push the prices into a list and compute the average of the most recent N prices. Using a TWAP would make the protocol immune to atomic transactions attack, as the attacker would have to carry the inventory risk on an asset with an inflated price long enough to influence the TWAP, with the risk of being arbitraged back and taking a loss. However, given a TWAP incorporates every price during the selected time windows, large outliers could still make important changes. Furthermore, if an attacker can move a price significantly at the end of a block and move it back immediately at the start of the next one, it could affect the TWAP enough in order to strike a profitable attack.
Therefore, it is very important to analyze the liquidity profile of every asset that is included in the oracle process to properly evaluate the associated risks. This includes asserting the liquidity depth of the pool that feeds the oracle, along with finding, if any, other venues of liquidity that can be used by arbitrages to push the price back to a fair value in the case of a manipulation attack.
Bridge
Bridges are among the main targets for hacks because of the high complexity of their infrastructure and their high network effect in the form of the total value locked (currently 11.3B according to DeFiLlama). Therefore, the bridge risk must be carefully analyzed.
Whenever a user bridges an asset from chain A to chain B, the funds are locked in the chain of origin, and a representative IOU of the asset is created on the chain of destination. If the user wants to bridge their funds back, all they need to do is burn the IOU on chain B and have the funds released on chain A. Given that most existing blockchains cannot communicate with each other by default, a set of relayers is given the authority to monitor both chains and execute mints and burns.
There are several ways to enable this 2-way communication channel between blockchains. We can differentiate bridges into four broad categories (1 and 2). In order from more to less secure:
Natively verified
Locally verified
Optimistically verified
Externally verified
Natively verified bridges are the most secure bridges. The communication is achieved by having a light client of one chain implemented directly into the other chain’s virtual machine, meaning the full nodes of each chain verify the correctness of each transfer. This is considered the most trust-minimized way to enable communication as the security is guaranteed by the security of the underlying chains. Cosmos’ Inter-Blockchain Communication Protocol (shortly IBC) and Aurora’s Rainbow Bridge with Ethereum belong to this category.
Locally verified bridges are secured by the underlying chains they operate on, yet they are verified only by the parties involved in each transaction. Although they have a weaker security assumption than natively verified bridges, they are considered to be decently secure and less expensive to run. Connext and Hop belong to this category.
Optimistically verified bridges rely on an honest minority assumption, as all transactions are considered to be valid but can be challenged during a dispute period. If a challanger is successful and it is proven that a transaction is invalid, the transaction is reverted. Among others, the Nomad bridge belongs to this category.
Externally verified is the most popular yet most dangerous category as it relies on an external set of verifiers used to relay data between chains, which might potentially collude or be exploited. The set of relayers can be either permissioned (i.e., Wormhole) or permissionless (i.e., Axelar, Celer). Usually, open relayer sets are secured by bonded tokens, whose cost of attack (acquiring the tokens/bribe) against the expected payoff must be analyzed.
The risk score
After outlining the risks, we came up with a risk score formula. The risks are compounded by using a discount system that is applied geometrically.
Each category's risk discount falls within a specific range. For instance, if the protocol’s codebase is forked from something battle-tested like Uniswap V2, the risk discount will be 0. On the other hand, if the codebase is novel, the discount will be 60%.
Below is a table comprising the risk discounts we apply to each category.
The allocation to the protocol/strategy is then defined based on the associated risk score and the expected return.
Medici
Anyone who has ever interacted with a Gnosis Safe knows how cumbersome (yet incredibly secure) executing a transaction can be. Our fund executes multiple transactions daily, so using Safe alone was a totally unrealistic option. Yet, we could not rely on EOAs to perform our daily operations for obvious security reasons, so we had to find a solution to this problem.
We found that Gnosis Safe’s modules were the best way forward, offering a great tradeoff between security and execution. Modules are plug-ins that allow adding extra access-control logic to the Gnosis Safe multisig, opening up a vast design space.
We described an early version of our Modules based farming infrastructure in a previous post.
With the above architecture, storage and execution are split into two separate buckets. The funds are always secured by an n-of-m multi-signature, while the daily operations are delegated to the modules. Each module contains a limited set of whitelisted calls (such as depositing, withdrawing, collecting rewards, and eventually selling) which can be called by a whitelisted EOA on behalf of the Safe. In the remote case that the address is compromised, no harm can be done as the action space is quite limited. The delegated EOA is nothing more than a series of scripts that are used to achieve automated, optimized, and flawless execution.
The off-chain part of the stack is composed of services that constantly monitor and trigger execution if needed, reading from external APIs. Every piece of data is then written to a local database that is visualized through Grafana and used to generate reports for internal and external usage.
Defensive MEV
We now show an example of how automation can help with risk minimization.
As history shows, bridges can be pain points as they are often targeted by hackers. Through automation, it is possible to mitigate the risk of being affected by a bridge hack to some extent.
In our in-house stack, the bridges we have exposure to are always monitored by querying their balances on the main chain (usually Ethereum). If an unusual outflow is spotted according to our predefined heuristics, the stack automatically triggers an emergency withdrawal on the destination chain by swapping the affected assets with a native asset of the chain before a proper market reaction.
Regarding the example given of triggering an emergency withdrawal in the event of an unusual outflow from a bridge, we acknowledge that this operation may be exploitative to some extent, as users who provide liquidity may bear the loss. However, at Chronograph, preserving the fund's principal is our top priority. This is just one example of the many automated triggers we can put in place to reduce our risk exposure. The design space for improving risk control is vast, and we are constantly exploring new ways to make our product even more appealing to investors.
Conclusions
Yield farming can be highly profitable, but it also comes with risks. To mitigate those risks, it's important to have a coherent and quantifiable risk framework in place. At Chronograph, we have developed such a framework, which allows us to offer above-market rate returns while also reducing risk.
Through automation and monitoring tools, we can reduce the amount of human time required to execute strategies and greatly diminish the chance of human error. This frees up our team to spend more time hunting for alpha and identifying good opportunities.
However, DeFi is still a highly adversarial environment, and malicious actors are always looking for exploits. To be profitable long-term, yield farmers need to be constantly aware and deeply analyze any opportunity based on the risk factors we have outlined.
We are continuously evolving our risk frameworks, automation tools, and monitoring infrastructure. To do this, we need the best-in-class talent, and we are always looking for talented individuals to join our team. If you are interested and think you can contribute in a meaningful way, please reach out to us on Twitter at 3pa15 / Meph or via email at ab@dialectic.ch.
