Spheron Network security record

Taking Example of createLease()(same applies for closeAndRenewLease)<br>- Whenever <code>createLease()</code> gets called the function would throw error.<br>- <code>createLease()</code> gets called from <code>Bid.sol::matchOrder()</code>.<br>- In <code>createLease()</code> there is a <code>onlyBidContract()</code> modifier which passes as msg.sender is Bid<br>contract. Inside <code>createLease()</code>,<code>escrow.lockToken()</code> gets called :<br><code>escrow.lockTokens(order.creator, order.token, _toPrecision(leaseCostPlusFee, token.decimals));</code>- <code>lockTokens()</code> contains a <code>onlyRole(DEFAULT_ADMIN_ROLE)</code> which means only admin can call<br>this function but in our case <code>msg.sender</code> would be computeLease contract address so<br><code>lockTokens()</code> function will fail due to the<br><code>onlyRole(DEFAULT_ADMIN_ROLE)</code> modifier.<br>

Some tokens have a fee on transfer, for example USDT. Usually such fee is not enabled but could be re-enabled at any time.<br>With this fee enabled the deposit() and withdraw() function would receive slightly less tokens than the amounts requested in the function parameter. This will create an accounting problem, as the whole <code>amount</code> variable gets added in unlock Tokens mapping but actually it will receive slightly less tokens than <code>amount</code>.<br>So in mapping it should add the actual received amount.<br>As main functionality is dependent on Lock and Unlock Tokens this should be handled correctly

Malicious Admin can steal away provider earnings Whenever provider or user calls <code>closeLease()</code>, malicious admin can frontrun this transaction and increase the <code>protocolPerc</code> to a very high value such that the very major part of tokens as fees.<br>Now as protocolPerc has been set to almost 99% using<code>setProviderFeePercentage()</code> So provider would get very less amount of tokens as earnings and other major amount (99%) goes as fees to protocol.<br>Here providerAmount would be only 1% of total amount and protocolFee would 99% of total amount.<br>

Malicious User would pay less tokens even if he has used the service provider by provider more than the specified time in the order.<br>Lets understand using an example:<br>1. There is a matched order between user and provider and the conditions are `order.numOfBlocks   = 100` and `acceptedPrice = 1e18`<br>2. Let's say after passing of 200 blocks the provider calls `closeLease()` to close the lease.<br>3. As user has used the service for 200 blocks he should pay tokens for 200 blocks.<br>4. But user would only pay the tokens for 100 blocks of service.<br>5. So it would be loss to provider as he will not receive tokens for remaining 100 blocks.<br>6. According to our example loss of 100e18 to provider

There is no check while calling <code>withdrawProviderEarnings()</code> , <code>withdrawFizzNodeEarnings()</code> and <code>with drawProtocolFees</code> that the withdrawls are in pause state or not.If <code>pauseWithdrawal</code> has been set to true there should be no withdrawals from the protocol.But by calling <code>withdrawProviderEarnings()</code> , <code>withdrawFizzNodeEarnings()</code> and <code>withdrawProtocolFees</code> they can withdraw funds even though the <code>pauseWithdrawal</code> has been set to <a href="http://true.it/" target="_blank">true.It</a> breaks the core functionality of the protocol

Provider would not be able to claim earnings if providerRewardWallet is set as contract address.Let's suppose a provider has added himself into registry and has set providerRewardWallet to contract address where he wants the fund.<br>Now when he wants to claim his earnings via Escrow.withdrawProviderEarnings() he would not be able to claim due to the below check <code>require(msg.sender == providerRewardWallet, "Not Provider Reward Wallet");</code> So due to above check the provider would not be able to claim as contract address doesn't have <code>withdrawProviderEarnings</code> function selector and whenever the provider calls <code>withdrawProviderEarn ings()</code> from his address it would revert due to above condition. <code>"Not Provider Reward Wallet"</code>

There should be a deadline set during signature verification otherwise the signature can be used for an indefinite period of time.

The above function should only be called by owner but it lacks modifier onlyOwner so anyone can initiate claiming of penaltyAssets, although the assets are being transferred to the owner so this is a low issue. And emit PenaltyAssetsDistributed(msg.sender, penaltyAssets); event is emitted with msg.sender which is wrong if anyone else apart from the owner calls this function.<br><code>solidity function claimPenaltyAssets() external { require(penaltyShares > 0, "No penalty shares"); uint256 penaltyAssets = pToken.convertToAssets(penaltyShares); penaltyShares = 0; pToken.transfer(owner(), penaltyAssets); emit PenaltyAssetsDistributed(msg.sender, penaltyAssets); } </code>

<code>solidity function updateCollateralConfig(CollateralConfig memory _collateralConfig) external onlyOwner { _updateCollateralConfig(_collateralConfig); } function _updateCollateralConfig(CollateralConfig memory _collateralConfig) internal { if (!CoreLogic.validateCollateralConfig(_collateralConfig, PARAM_PRECISION)) revert InvalidCol lateralConfig(); slashingBuffer = _collateralConfig.slashingBuffer; isSlashingBufferAbsoluteValue = _collateralConfig.isSlashingBufferAbsoluteValue; liquidationThreshold = _collateralConfig.liquidationThreshold; collateralFactor = _collateralConfig.collateralFactor; emit CollateralConfigUpdated(_collateralConfig); } </code><br>The above function. is called by owner to update the collateral config, It updates certain important states including liquidationThreshold , the problem is when liquidationThreshold is updated it can trigger sudden liquidation for healthy positions too If we take a look at coreLogic.startLiquidation() it has a check and when liquidationThreshold is changed the check can be bypassed suddenly and healthy positions can become unhealthy and become prone to sudden liquidation.<br><code>solidity if (fullRepayTokenAmount < (collateralValue * liquidationThreshold) / paramPrecision) { revert CannotLiquidateHealthyAgent(); } </code>

IWETH constant weth = IWETH(0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2); // need to manually update for each chain//@audit [L] hardcoded address for weth, WETH has diff address on diff chains