Nova Bank security record

In the contract `BondDepositoryDai`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and initialize bond terms with provided parameters, set the adjustment settings, set bond terms based on parameters, set the contract address based on ID, set the required stake amount, and set the staking address using the helper option.  In the contract `Ownable` the role `_newOwner` has authority over the function shown in the diagram below. Any compromise to the `_newOwner` account may allow the hacker to take advantage of this authority and retrieve contract ownership, **even if the ownership has been renounced**.  In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and renounce/transfer contract ownership to arbitrary accounts.  In the contract `Ownable`, the role `_manager` has authority over the functions shown in the diagram below. Any compromise to the `_manager` account may allow the hacker to take advantage of this authority and push new ownership to a new owner address, or renounce management rights.  In the contract `ERC20TokenX`, the role `DEFAULT_ADMIN_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow the hacker to take advantage of this authority and set the buy or sell fee ratio, set the main pair address.  In the contract `ERC20TokenX`, the role `MINT` has authority over the function shown in the diagram below. Any compromise to the `MINT` account may allow the hacker to take advantage of this authority and mint tokens to a specified account.  In the contract `Distributor`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and add a reward recipient, set adjustment parameters, or remove a recipient from the list.  In the contract `Distributor`, the role `_policy` has authority over the functions shown in the diagram below. Any compromise to the `_policy` account may allow the hacker to take advantage of this authority and set adjustment parameters at specified index, remove recipient by verifying with index and address, and add a reward recipient.  In the contract `StakingV2`, the role `_manager` has authority over the functions shown in the diagram below. Any compromise to the `_manager` account may allow the hacker to take advantage of this authority and set the warmup period, as well as set specified contract to a given address.  In the contract `StakingV2`, the role `locker` has authority over the functions shown in the diagram below. Any compromise to the `locker` account may allow the hacker to take advantage of this authority and **transfer arbitrary amounts of sOHM out of the staking contract as the LockBonus**.  In the contract `Treasury`, the role `_manager` has authority over the functions shown in the diagram below. Any compromise to the `_manager` account may allow the hacker to take advantage of this authority and toggle access and update roles based on managing parameter, queue changes for different managing addresses, audit and update total reserves. ![](https://accelerator-tasks-prod.acc.corp.certik.com/11ef-9551-a32a6950-984e

The following require statement checks that `totalDebt` before `deposit` does not exceed `maxDebt`. ```solidity require( totalDebt <= terms.maxDebt, "Max capacity reached" ); ``` However, totalDebt is incremented in the same `deposit` function, and `totalDebt + value` could exceed `maxDebt` after the `deposit` function is executed. ```solidity totalDebt = totalDebt.add( value );

The public `claim()` function and `redeem()` function in the linked contracts accept an arbitrary `_recipient` address parameter, rather than using `msg.sender`. This design allows any user to call `claim()`/`redeem()` for another account without the account holder's consent. While this could be by design, to facilitate claims through the `StakingHelper` contract on behalf of users, it also opens the possibility for unauthorized claims on other users' behalf. We would like to confirm if this behavior is intentional.

When transferring deflationary ERC20 tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrive to the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. In BondV2.sol ```solidity=1159 IERC20(principle).safeTransferFrom(msg.sender, address(this), _amount); IERC20(principle).approve(address(treasury), _amount); ``` In Treasury.sol: ```solidity=399 IERC20(_token).safeTransferFrom(msg.sender, address(this), _amount); ```

The `distribute()` function in the `Distributor` contract calculates minting amounts for OHM tokens based on the current `totalSupply`, applying a rate (`_rate`) to determine the reward for each recipient. Since `totalSupply` increases with each minting operation within the same distribution cycle, recipients listed later in the iteration receive more rewards due to the inflated supply. This sequential dependency can lead to unintended distribution of rewards and potentially exceed predetermined minting limits. ```solidity function distribute() external returns ( bool ) { if ( nextEpochBlock <= block.number ) { nextEpochBlock = nextEpochBlock.add( epochLength ); // set next epoch block // distribute rewards to each recipient for ( uint i = 0; i < info.length; i++ ) { if ( info[ i ].rate > 0 ) { ITreasury( treasury ).mintRewards( // mint and send from treasury info[ i ].recipient, nextRewardAt( info[ i ].rate ) ); adjust( i ); // check for adjustment } } return true; } else { return false; } } ``` ```solidity function nextRewardAt( uint _rate ) public view returns ( uint ) { return IERC20( OHM ).totalSupply().mul( _rate ).div( 1000000 ); } ```

Function `setContract` allows the contract owner (referred to as the "manager") to set various critical contract addresses, including the locker address. ```solidity=773 function setContract( CONTRACTS _contract, address _address ) external onlyManager() { if( _contract == CONTRACTS.DISTRIBUTOR ) { // 0 distributor = _address; } else if ( _contract == CONTRACTS.WARMUP ) { // 1 require( warmupContract == address( 0 ), "Warmup cannot be set more than once" ); warmupContract = _address; } else if ( _contract == CONTRACTS.LOCKER ) { // 2 locker = _address; } else if(_contract == CONTRACTS.RELEASE){ require( _address != address(0), "ZeroAddress" ); releasePool = _address; } ``` The function lacks proper validation when setting the locker address. Specifically, there are no checks to prevent the owner from changing the locker address multiple times or setting it to an invalid or malicious address. The malicious locker address could siphon `sOHM` tokens from the staking contract, and gain extra profit through warm up reward claiming.

The `BondV2` contract interacts with out-of-scope dependencies including the `stakingHelper` contract. The out of scope contracts get OHM token approval from the bond contract. The scope of the audit treats out-of-scope dependencies as black boxes and assumes their functional correctness. ```solidity=1311 if (useHelper) { // use if staking warmup is 0 IERC20(OHM).approve(stakingHelper, _amount); IStakingHelper(stakingHelper).stake(_amount, _recipient); ``` The `StakingV2` contract interacts with out-of-scope dependencies including the `releasePool` contract. The out of scope contracts get OHM token approval from the staking contract. The scope of the audit treats out-of-scope dependencies as black boxes and assumes their functional correctness. ```solidity=699 IERC20(OHM).safeApprove(releasePool, _amount); IReleasePool(releasePool).startRelease(staker, _amount, burnAmt, releaseLevel); ``` The linked contracts grant large token allowances to external contracts (`stakingHelper` and `releasePool`) without resetting the allowance afterward. If these external contracts are malicious or compromised, they can transfer an unlimited amount of OHM tokens from the `BondV2` and `StakingV2` contracts. The `stakingHelper` and `releasePool` contracts are not included in the scope of the audit and are treated as black boxes. Without auditing these dependencies, their security cannot be guaranteed.

After ownership is renounced, the potential for the original owner to regain ownership exists due to the contract code not resetting the state variable for the new owner candidate to a default value. This situation arises because the function to renounce ownership does not properly clear or update the related state variable. This allows the original owner to exploit this vulnerability under certain conditions, bypassing security checks and regaining ownership of the contract by calling the relevant function again.

There is no upper limit restricting parameter of `setAdjustment()`, potentially enabling arbitrary increments on control variables. The commented-out requirement line suggests an intended check against the `terms.controlVariable` to restrict the increment size, which is important for maintaining controlled adjustments. ```solidity=1024 function setAdjustment( bool _addition, uint _increment, uint _target, uint _buffer ) external onlyPolicy { // require( // _increment <= terms.controlVariable.mul(25).div(1000), // "Increment too large" // ); adjustment = Adjust({ add: _addition, rate: _increment, target: _target, buffer: _buffer, lastBlock: block.number }); } ``` Besides, the `BondDepository.sol` contract's design permits the potential for bond price manipulation through the unregulated adjustment of the `terms.controlVariable` via the `adjust()` function. This function dynamically alters the controlVariable based on the `adjustment.add` boolean flag—incrementing it when TRUE and decrementing it when FALSE. ---------------------------------------------------------------------- Here are the code blocks that related to the bond price calculation: ```solidity function deposit( uint _amount, uint _maxPrice, address _depositor ) external returns ( uint ) { require( _depositor != address(0), "Invalid address" ); decayDebt(); ...... uint value = ITreasury( treasury ).valueOf( principle, _amount ); uint payout = payoutFor( value ); ...... adjust(); //**COMMENT from CertiK: This function is used to modify the value of variable terms.controlVariable according to the value of adjustment.add. When adjustment.add is TRUE, terms.controlVariable increases each time, otherwise terms.controlVariable decreases each time.** ``` ```solidity function adjust() internal { uint blockCanAdjust = adjustment.lastBlock.add( adjustment.buffer ); if(adjustment.rate != 0 && block.number >= blockCanAdjust) { uint initial = terms.controlVariable; if (adjustment.add) { terms.controlVariable = terms.controlVariable.add( adjustment.rate ); if (terms.controlVariable >= adjustment.target) { adjustment.rate = 0; } } else { terms.controlVariable = terms.controlVariable.sub(adjustment.rate); if (terms.controlVariable <= adjustment.target) { adjustment.rate = 0; } } adjustment.lastBlock = block.number; emit ControlVariableAdjustment(initial, terms.controlVariable, adjustment.rate, adjustment.add); } } ``` ```solidity function decayDebt() internal { totalDebt = totalDebt.sub( debtDecay() ); lastDecay = block.number; } function payoutFor( uint _value ) public view returns ( uint ) { return FixedPoint.fraction( _value, bondPrice() ).decode112with18().div( 1e16 ); } function bondPrice() public view returns ( uint price_ ) { price_ = terms.controlVariable.mul(debtRatio()).add(1000000000).div( 1e7 ); if ( price_ < terms.minimumPrice ) { price_ = terms.minimumPrice; } } function debtRatio() public view returns ( uint debtRatio_ ) { uint supply = IERC20(OHM).totalSupply(); debtRatio_ = FixedPoint.fraction( currentDebt().mul(1e9), supply ).decode112with18().div(1e18); } function currentDebt() public view returns (uint) { return totalDebt.sub(debtDecay()); } function debtDecay() public view returns (uint decay_) { uint blocksSinceLast = block.number.sub(lastDecay); decay_ = totalDebt.mul(blocksSinceLast).div(terms.vestingTerm); if (decay_ > totalDebt) { decay_ = totalDebt; } } ``` In the Treasury.sol contract: ```solidity function valueOf(address _token, unit _amount) public view returns (uint value_) { if (isReserveToken[_token]) { // convert amount to match LMDA decimals value_ = _amount.mul(10**IERC20(LMDA).decimals()).div(10**IERC20(_token).decimals()); } else if (isLiquidityToken[_token]) { value_ = IBondCalculator(bondCalculator[_token]).valuation(_token, _amount); } } ``` Referring to the above code, the bond price can be expressed as the following formulas: $$ \begin{align} bondAmount &= \frac{Value}{bondPrice \times 10^{16}} && \tag 1\\ bondPrice &= controlVariable \times \frac{totalDebt'}{totalSupply \times 10^9} + 100 && \tag 2\\ totalDebt' &= totalDebt \times \left( 1 - \frac{\Delta block}{vestingTerm} \right) && \tag 3\\ where \ \ & \Delta block \leq vestingTerm && \notag\ \end{align} $$ - $Value :$ the amount of reserve tokens paid by users - $controlVariable :$ `terms.controlVariable` whose rise and fall is controlled by function `adjust()` - $\Delta block :$ the current `block.number` minus the `block.number` at the last call - $vestingTerm :$ the total number of blocks for bond issuance set by the `owner` - $totalDebt :$ record the total issuance of bonds - $totalDebt' :$ record the latest total issuance of bonds - $totalSupple :$ record the total iss

The OHM token contract does not grant the MINT role to the `Treasury` contract in its constructor or initialization phase. ```solidity=457 constructor( address _feeReceiver, uint _buyFeeRatio, string memory name_, string memory symbol_, address[] memory _coolingProtectors, uint _coolingPeriod ) ERC20Token(name_,symbol_) { feeReceiver = _feeReceiver; buyFeeRatio = _buyFeeRatio ; _setupRole(DEFAULT_ADMIN_ROLE,msg.sender); _setupRole(INTERN_SYSTEM,msg.sender); _setupRole(INTERN_SYSTEM,_feeReceiver); _setupRole(COOLING_PROTECTOR,_feeReceiver); for(uint i = 0 ;i< _coolingProtectors.length;i++) { _setupRole(COOLING_PROTECTOR,_coolingProtectors[i]); } coolingPeriod = _coolingPeriod; } ```