Skip to content

Latest commit

 

History

History
77 lines (46 loc) · 7.59 KB

Risks.md

File metadata and controls

77 lines (46 loc) · 7.59 KB
Raw

Compound Asset Listing - Risks

Protocol risks

Security

  • Codebase bug: smart contract bugs that might be exploited. For this reason Compound battle-tested codebase went to several round of audits.

  • External integrations failures: Currently Compound depends on Uniswap v3 TWAP and Chainlink oracles integrations. Oracle manipulations can lead to price manipulations as described in market's risk section. The UniswapAnchoredView contract enforces price swings to not be bigger than the anchor established, mitigating the issue. The contract also stores a fallback mechanism to Uniswap v3 TWAP prices whenever price reporters become unreliable, and this might mitigate the issue assuming that:

    • Proper monitoring solutions are setup to detect any downtime on reporters as soon as possible.
    • Admin actions are taken to activate fallback mechanism on oracle and that the corresponding Uniswap v3 pool has enough liquidity to avoid pool liquidity manipulations.

Governance

  • Wrong governance actions: A proposal containing dangerous transactions is executed. Like oversized COMP distribution issue. OpenZeppelin newborn relationship with Compound was set up out of the necessity to avoid having proposals undermining the protocol itself, being voted and executed.

  • Governance attacks: Concentration of big quantities of COMP (relative to thresholds and quorum parameters that might be present in the governance contracts) through loans/buy in few wallets that might defeat governance itself. This is a potential but unrealistic risk, as no concrete examples have been found.

Market

Market risks are deeply analyzed and covered in Gauntlet's report and they can be resumed in:

  • Price manipulation: If price manipulation happens in a low liquidity market, prices can changes fast and cause honest borrowers to be liquidated, being subjected to liquidation penalties.

  • Insolvency risk: The value of the funds held by the protocol is less than the liabilities of the protocol.

  • Liquidity risk: To be illiquid (not insolvent) depending on active borrows, borrow limits and collateralization ratios.

  • Not incentivized liquidations: The prices can crash so much that liquidations are not profitable anymore, leading to a lack of incentivized liquidators.

  • Cascade effect: Liquidations producing price crashes in external markets creating a deflationary spiral that triggers more liquidations. Some modifications have been proposed to mitigate this, specifically proposal #49.

We highly recommend going through the Gauntlet's report to understand how these risks are mitigated or addressed by the current protocol design.

Asset specific risks:

All assets specific risks (compatibility and compliance one) should be addressed in a structured manner. OpenZeppelin proposes a Checklist of topics to watch out for and evaluate when it comes to onboard new assets. Together with this checklist we provide a comprehensive Process to follow for new assets listing.

Compatibility

  • Extra asset features: How extra features can have unwanted or unexpected effects on the ERC20 functions involved in Compound integration (listed at the end of this document).

  • ERC20 deviations: Depending on how much the asset deviates from ERC20 standard, it might defeat basic protocol assumptions on how ERC20 tokens behave. Rebasing, deflationary or fees-driven tokens might give unexpected results on basic operations like transfer or balanceOf.

Compliance

  • Asset decentralization level: Having an asset highly centralized can lead to unexpected minting, and more if the asset has access control with centralized parties in power of it, where also transfer may unexpectedly fail for some blacklisting feature. It is important to asses sensitive asset's functionalities and determine the grade of decentralization.

  • External codebase bug/hack: Assets are smart contracts as anything else and they might contain bugs that can be exploited at some point. Assessing how those bugs can cause issues with Compound means in the first instance to recognize them and later study their implications.

List of external tokens interactions:

Lastly it is important to remark which are the concrete interactions between Compound and external asset's contracts.

Protocols contracts that interact with ERC20 tokens (including cTokens) and the relative functions interacting:

  • In CErc20

    • sweepToken to recover tokens mistakenly sent to the contract. This function transfers out of the contract the entire contract's balance of the requested asset. It is callable only by the administrator. One fixed issue, was about this function not being protected over assets with a double entry point. Read more about it here.
    • getCashPrior which is used internally to retrieve contract's underlying balanceOf. It is important to notice how this function result can be manipulated. Read more about it here.
    • doTransferIn used internally to move underlying tokens into the protocol by the use of balanceOf and transferFrom ERC20 methods. This function can handle non standard ERC20 and also accounts for fees-deducting assets like USDT.
    • initialize which is a single-call function used to setup proxy's storage when a new implementation is set. It uses the totalSupply function.

  • In Comptroller

    • updateCompSupplyIndex used internally to update to a new value the index of the supplyState of COMPs on a specific asset. Together with it also the block number is saved to support latest index's update. It checks the totalSupply of the cToken contract.
    • distributeSupplierComp used internally to update the compAccrued and compSupplierIndex mappings to latest value, actually accruing COMP on user positions. It uses the balanceOf function.
    • grantCompInternal which is used internally to send COMP tokens to the users. It uses the transfer function.

  • In GovernorBravoDelegate

    • castVoteInternal which is used internally to save the result of a vote cast. It uses the getPriorVotes function from COMP token.
    • cancel which is used to cancel a proposal which is not being executed yet and that makes uses again of the getPriorVotes function from COMP token.

ERC20 functions involved:

  • balanceOf
  • transferFrom
  • totalSupply
  • delegate and getPriorVotes only for COMP or COMP-like tokens