Core Contracts

Summary

Over-reliance on Ownable and role-based access control in numerous contracts creates single points of failure, increasing the risk of malicious admin actions or key compromise. This is a MEDIUM PRIORITY CENTRALIZATION RISK.

Vulnerability Details

Many contracts across the codebase rely on Ownable or AccessControl with onlyOwner or onlyRole modifiers to protect critical administrative functions. While access control is essential, over-centralization of power in a single owner or a small set of privileged roles creates single points of failure. If the owner key is compromised or a malicious admin gains control, they can unilaterally:

• Modify Critical Parameters: Change key protocol parameters like fees, interest rates, liquidation thresholds, emission rates, etc., potentially disrupting the system's economics or benefiting themselves unfairly.

• Pause or Shut Down Contracts: Halt core functionalities by pausing contracts, causing DoS and preventing users from accessing their funds or participating in the protocol.

• Withdraw Funds (in some cases): In certain contracts, owner roles might have the ability to directly withdraw funds or rescue tokens, potentially enabling malicious fund extraction.

• Manipulate Governance (Indirectly): While governance contracts exist, centralized control over core protocol parameters can undermine the intended decentralization and governance process.

Affected Contracts (Examples - Many contracts rely on Ownable or AccessControl):

• Governance.sol (Owner for parameter updates, timelock setting)

• TimelockController.sol (Admin for delay updates, role management)

• LendingPool.sol (Owner for parameter updates, pausing, rescue functions)

• StabilityPool.sol (Owner for manager and market management, pausing)

• RAACMinter.sol (Owner for pausing, updater roles)

• FeeCollector.sol (Admin for fee type updates, treasury/repair fund setting, pausing)

• RAACNFT.sol (Owner for minting, base URI setting)

• RAACToken.sol (Owner for tax rate setting, minter/burner roles)

• RToken.sol (Owner for reserve pool, minter/burner roles)

• DEToken.sol (Owner for stability pool setting)

• RAACHousePrices.sol (Owner for oracle setting)

• RAACPrimeRateOracle.sol (Owner for prime rate oracle setting)

• Auction.sol (Owner for auction parameters)

• ZENO.sol (Owner for minting)

Impact

Centralization Risk and Single Points of Failure. Over-reliance on privileged roles creates:

• Security Risk: Compromise of the owner key or malicious admin actions can have catastrophic consequences for the protocol and user funds.

• Trust Deficit: Centralized control undermines user trust in the protocol's decentralization and long-term security.

• Governance Weakness: Centralized administrative powers can circumvent or undermine the intended decentralized governance process.

• Operational Bottleneck: Relying on a single owner or small admin group for critical operations can create operational bottlenecks and slow down protocol upgrades or emergency responses.

Tools Used

Manually reviewed

Recommendations

1. Mitigation (Decentralize Control): Implement multi-signature wallets or governance-controlled roles for critical administrative functions. Replace onlyOwner modifiers with onlyRole(GOVERNANCE_ROLE) or similar and manage these roles through a decentralized governance process.

2. Timelocks for Sensitive Functions: Implement timelocks for critical administrative functions (parameter updates, address changes, pausing, emergency actions) using TimelockController.sol or a similar mechanism. This provides a delay period for stakeholders to review and potentially veto administrative actions.

3. Reduce Privileged Functionality: Minimize the number of functions that require privileged access. Where possible, automate processes or make them permissionless and governed by smart contract logic rather than manual admin actions.

4. Code Review: Thoroughly review access control across all contracts and identify functions that currently rely on onlyOwner or onlyRole modifiers. Assess the criticality of these functions and implement appropriate decentralization or timelock mechanisms.

Mitigation (Code Examples)

In Governance.sol, define a GOVERNANCE_ROLE and grant it to the governance contract itself:

In LendingPool.sol.setParameter (and other privileged functions), replace onlyOwner with onlyRole(GOVERNANCE_ROLE):