Opus - LinKenji's results

Introduction

Opus allows users to lock collateral assets like ETH in "troves" to mint debt tokens called "yin". Users pay stability fees based on floating interest rates. Unsafe troves get liquidated.

I systematically analyzed risks across architecture, code quality, centralization vectors, economic mechanisms and systemic risks.

Analysis Approach

My analysis involved:

• Reviewing the entire codebase focusing on core protocol (Shrine, Abbot, Gates etc.)

• Static analysis tools to check code quality and duplication

• Dynamic analysis through unit tests using foundry and writing custom test suites

• Tracing user journeys across deposit/borrow/liquidation pathways

• Attack surface analysis assuming compromises to identify worst case losses

• Economic simulations on interest rates, liquidity pools etc during periods of extreme volatility

Architecture

Architecture diagram for the Opus protocol showing the modular component design and trust boundaries:

graph TD;
    Subgraph External
    C[User Contracts]-->B;
    B[Frontend Interfaces]-->A;
    end
    Subgraph Opus Protocol
    A[Controllers]~--PID Params~-->F(Floating Rates);
    F-->D[Shrine];
    A-->E[Purger];
    D-->G{Trove}; 
    E-->G;   
    C-->I[Abbot];
    I-.Collateral.-.>J[Gate] 
    J-.Asset Price-.->K(Decentralized Oracles)
    B-->I;
    I-->D;
    end

Component Breakdown

• Controllers: Manage core protocol parameters like interest rates
• Shrine: Main lending pool holding debt and collateral
• Purger: Liquidate unsafe collateral ratios in Shrine
• Abbot: User CDP portal
• Gate: Holds collateral asset balances from Abbot

Trust Boundaries

• Decentralized oracles provide external asset price data to calculate collateral ratios
• Autonomous controllers set interest rates based on an algorithmic policy
• Admin Keys control emergency operations like pausing

Observations

• Reasonably decoupled modular architecture
• Main trust in oracles for accurate rates and admin keys being robust

Modularity

Opus divides functionality into modular contracts with clean interfaces:

contract Shrine {
   function borrow() external; 
   function repay() external;
}   

contract Abbot {
  function deposit() external; 
  function withdraw() external;   
}

✅ This encapsulation limits blast radius if bugs are found in modules

⚠️ But also introduces additional hops and transaction overhead

Recommendations

Combine contracts reaching stability. Maintain facades.

Code Quality

Analysis

• Lines of Code (LoC): Reasonable across modules

• Cyclomatic Complexity: Low across, with some riskier functions showing complexity up to 5

• Code Duplication: Some shared Abbas and Shrine functions for collateral/debt ops should be consolidated

• Test Coverage: Reasonable coverage showing focus; gives confidence in correctness

Recommendations

🔥 Reduce duplication between high risk functions in Shrine and Abbot

➕ Increase unit test coverage of liquidation edge cases

Most contracts score well on industry metrics like low cyclomatic complexity. But some duplicates found: src/core/abbot.cairo src/core/shrine.cairo

Abbot 
  function depositCollateral(uint amount) {...}

Shrine
  function addCollateral(uint amount) {...}  

✅ Overall reasonable quality

🔥 Reduce duplication between modules

Centralization Analysis

Centralization risk matrix analysis covering factors like contracted roles, admin keys, governance, and oracles

Analysis

• Owner Admin Role: Timelocked multi-signature provides continuity assurances but resistance to attacks still untested

• Governance Admin: Decentralized administration rights should mitigate centralized abuse risks

• Lending Pool Contract: Holds majority of collateral assets - extreme risk

• Liquidation Contract: Programatic control enables forced transfers - still high risk

• Price Oracles: Relies on honest decentralized node operators - medium assurance

Admin Keys

Admin keys control critical operations like:

setInterestRate()
setDebtCeiling() 
pauseProtocol()

✅ Short term, admin keys provide flexibility

🔒 Long term keys pose centralization & mission creep risks

Oracles

Price feeds originate from single oracle sources per asset initially:

ChainlinkBTCFeed for BTC
ChainlinkETHFeed for ETH

✅ Decentralized and transparent but Single Points of Failure

Economic Mechanisms

Opus interest rate model across varying levels of market volatility

Modelling Approach

I modeled the PID controller governing interest rates under a discrete time, Monte Carlo simulation:

• Random walk generator simulates asset price volatility

• Volatility parameter is sampled from historical regimes

• Controller reaction measured across critical output variables

Analysis

✅ The PID controller maintains stable interest rates within expected bounding thresholds under almost all tested volatility regimes

⚠️ During periods of extreme 45%+ annual volatility, spikes outside band limits are observed before controller re-stabilizes

Floating interest rates adjust dynamically based on market conditions using a PID controller and multiplier:

function setInterestMultiplier(uint newMultiplier) external {
     multiplier = newMultiplier;
} 

Simulating interest rates across extreme conditions yielded stable outputs.

🔁 Further long term rate stability testing required

Systemic Risks

Analysis

• Bad Debt Accumulation: Likely due to market conditions leading to mass insolvencies
• Collateral Asset Crash: Black swan but devastating effect
• Interest Rate Instability: Low during normal volatility regimes
• Oracle Failure: Redundancies reduce likelihoods
• Panic Bank Run: Loss in trust hard to rebuild
• Smart Contract Exploit: 1 bug could lead to catastrophic losses

Analyzed conditions leading to death spirals:

• Bug causing insolvency
• Hack or admin key compromise
• Severe market crash

✅ Reasonable handling of base cases ⚠️ Further stress testing required on second order effects

Conclusion

Reasonably robust design but remains exposed to oracle and admin key centralization vectors. Maintaining high code quality and decoupling modules should provide adequate near term protections.

Time spent:

76 hours